The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] MPLS meeting minutes from Adelaide
Title: MPLS meeting minutes from Adelaide Here are the draft meeting minutes from Adelaide. Apologies for the tardiness in getting these out; this was due to a combination of the travel plans of the chairs and our minute-taker, Tony Bogovic. Thanks to Tony for transcribing minutes. - Vijay
Two MPLS WG sessions were held during the 47th IETF meeting in Adelaide, Australia. The first session was held on Monday, March 27, 2000 from 7:30pm until 10:00pm. The second session was held Wednesday, March 29th from 9:00am through 11:00am. Vijay Srinivasan and George Swallow chaired both sessions of the MPLS WG.
The agenda for the first MPLS WG session appears as follows:
Presenter Internet Draft Talk Duration
Kompella draft-kompella-mpls-optical-00.txt 13
Lang draft-lang-mpls-rsvp-oxc-00.txt 13
Saha draft-saha-rsvp-optical-signaling-00.txt 13
Ashwood-Smith draft-fan-mpls-lambda-signaling-00.txt 13
Rajagopalan draft-tang-crldp-optical-00.txt 13
Bernstein draft-bernstein-mpls-sonet-00.txt 13
Mannie draft-mannie-mpls-sdh-control-00.txt 13
Kompella draft-kompella-mpls-bundle-00.txt 13
Lang draft-lang-mpls-lmp-00.txt 13
Swallow Discussion on organizing optical work 15
Ravikanth draft-vaananen-mpls-svc-diff-framework-00.txt 13
The agenda for the second MPLS WG session follows:
Presenter Internet Draft Talk Duration
Davari draft-ietf-mpls-diff-ext-05.txt 13
Makam draft-makam-mpls-recovery-frmwrk-00.txt 13
Huang draft-chang-mpls-path-protection-00.txt 13
Matthews draft-farrel-mpls-ldp-ft-00.txt 10
draft-matthews-mpls-ldp-ibb-00.txt
Kankkunen draft-kankkunen-vompls-fw-00.txt 2
Berger draft-berger-mpls-hdr-comp-00.txt 13
Swallow draft-swallow-mpls-simple-hdr-compress-00.txt 13
Heinanen draft-heinanen-mpls-splsp-00.txt 13
Iwata draft-fujita-mpls-crldp-crankback-00.txt 13
Wright draft-wright-policy-mpls-00.txt 13
Schrijvp draft-schrijvp-mpls-ldp-end-to-end-auth-00.txt 13
Sumimoto draft-sumimoto-mpls-vpn-interworking-00.txt 13
Srinivasan Last calls, charter discussion 8
The following captures the minutes of all the agenda items listed above (in the same order):
-----
'Extensions to IS-IS/OSPF and RSVP in support of MPL(ambda)S', <draft-kompella-mpls-optical-00.txt>, Kireeti Kompella
Kireeti Kompella started off his presentation by discussing network design considerations, but mentioned that the focus of the talk was on forwarding adjacencies.
He then listed a number of network design considerations. In particular, he pointed out that network design, policy boundaries, and administrative domains are all the customer's choice. Moreover, he mentioned that the network model employed could be the overlay or peer-to-peer models as well as a range of other models. Additional network design considerations he discussed include: reliance on open standards, multi-vendor network, training, MIBs, monitoring, management, control, and simplified, unified tools.
He followed by listing a number of characteristics that Service Providers (SPs) would like to realize in their network. Namely, a unified approach, common paradigms, control procedures, leverage technology advances, capacity planning, forwarding adjacencies, shared risk avoidance, link bundling, and fast restoration.
Then he discussed switching granularities. In particular, he enumerated different switching options, i.e., labels, lambdas, channels or sub-channels. In doing so, he posed the question 'what to switch'? He followed by indicating that it depends where in the network it is: LSR, ADM, OXC, etc. He mentioned that the key point was that at any point in the network, you switch only one thing.
Subsequently, he spoke about the appropriateness of using RSVP for MPLambdaS. The rationale was that LSPs were more demanding than lambda-switched paths, since LSPs are shorter lived than lambda switched paths. The point being that if RSVP can handle LSPs, then it can handle lambda switched paths. And, he said that the existence proof was that MPLS/RSVP is already deployed in large networks.
He went on to discuss forwarding adjacencies, which were a key part of this draft. He described them as control driven and an LSP advertised as a link in IS-IS or OSPF for the purpose of aggregating forwarding state. In addition, he mentioned that they represented a new paradigm that can be used for both MPLS LSPs or lambda switched paths.
Further, he stated that the forwarding adjacencies represented a paradigm for a hierarchical LSP structure in the following order: packet switched LSPs, TCM-switched LSPs (SONET trails), lambda-switched LSPs (Optical trails), fiber-switched LSPs. He also mentioned state reduction, fate sharing, that it was useful for 'regular' LSPs, and that it integrates LSPs, SONET trails, optical trails and fiber-switched paths.
He also described the new Traffic Engineering TLVs that were defined. Namely,
link type (extends the notion of termination capable and termination incapable), link media type (changed label across objects), shared risk link group, label request object, and add link media type (OXC/ADM-specific).
He concluded his presentation by discussing the next steps for this work. In addition to proposing to make this draft a MPLS WG document, he said that he would incorporate comments from the mailing list and produce version 01 of the draft. Also, he questioned whether this draft should be divided into two.
During the question/answer period, Don Fedyk asked about the constraints for a forwarding adjacency and mentioned that the constraints are wide. To which, Kireeti Kompella replied that LSPs have constraints, not forwarding adjacencies. They decided to take this discussion off-line.
Incidentally, questions on status of the draft were deferred towards the end of the session, where the organization of the optical work was discussed.
----
'Extension to RSVP for Optical Networking', <draft-lang-mpls-rsvp-oxc-00.txt>, Jonathan Lang
Jonathan Lang began his presentation by highlighting a number of optical networking requirements, including small trail establishment latency, rapid failure detection/notification, rapid/intelligent trail restoration, support for bi-directional trails, etc.
Then he covered the proposed extensions to RSVP for optical networking. The first was the Label Suggestion Object. He stated that it reduces trail establishment latency. This, he mentioned, was accomplished by the upstream OXC suggesting a label to the downstream OXC, yet the downstream OXC can ignore the label suggestion. The second extension included Bi-directional Trail Establishment. He pointed out that it reduces trail establishment latency and increases success probability. He went on to say that when both of the above objects are used together Label Contention Resolution is possible.
He then proposed another extension, which is the Failure Notification object. This extension impacts the restoration requirement. Specifically, the need to react to network failures rapidly; responsible nodes must be notified quickly and restoration decisions made intelligently.
Finally, he mentioned that a modification to the Bundle Message was proposed in the draft.
There were no questions.
----
'RSVP Extensions for Signaling Optical Paths', <draft-saha-rsvp-optical-signaling-00.txt>, Debanjan Saha
Debanjan Saha started off by stating that the intent of this contribution is to make RSVP more suitable for signaling light-paths. Then he listed some requirements for light-paths, i.e., permanent, bi-directional, protection and restoration light-paths. In this way, extensions to RSVP can be proposed to satisfy these requirements.
Then he mentioned that bi-directional light-paths are needed because signaling twice is expensive. Also that SONET requires the forward and backward paths to be on the same circuit pack and to avoid label assignment collision. To accommodate bi-directional light-paths, he proposed a new C-Type for the Label Request Object and a new C_Type for the Label object.
Further, he mentioned that protection and restoration are more complex. He continued by indicating that new objects were needed for signaling span protection mode. Moreover, he stated that two approaches could be taken for path protection. Namely, the first approach is 1+1 style dedicated backup paths, while the second is shared backup paths. Moreover, he asserted that simple extensions could make that happen, i.e., a new C_Type for the Session Attribute object.
He concluded by summarizing his presentation. He mentioned that 3 RSVP extensions were proposed to address specific requirements for signaling light- paths - new C_Types for the Label Request and Label objects and a new C_Type for the Session Attribute object.
During q/a, George Swallow asked how do you know you can share the bandwidth? To which, Debanjan responded that that could be achieved with, e.g., a resource class in OSPF.
-----
'Extensions to CR-LDP and RSVP-TE for Optical Path Set-up', <draft-fan-mpls-lambda-signaling-00.txt>, Peter Ashwood-Smith
This draft specifies extensions to RSVP-TE and CR-LDP for optical LSP set-up. Peter Ashwood-Smith touched on some mechanisms, TLVs, and objects that are required to support optical LSP setup.
At one point, he mentioned that the draft coined the term Composite Labels. They allow the signaling protocol to set-up entire fiber/lambda and/or sub-lambda paths employing a single end-to-end mapping/resv message.
Also, he mentioned that a particular problem is that there exist cases of optical cross-connect that cannot do wavelength/waveband conversion. Peter stated that a number of solutions exist, one of which includes carrying a Label set of acceptable wavelengths (labels) in request/path messages.
Then he wrapped up his presentation by stating that goal one of the draft was to specify a set of TLVs for RSVP-TE and CR-LDP for flat and composite optical/time etc. labels. And, to make sure that is a superset of all present and predicted future hardware.
There were no questions.
----
'Extensions to CR-LDP for Path Establishment in Optical Networks', <draft-tang-crldp-optical-00.txt>, Bala Rajagopalan
Bala Rajagopalan kicked-off his presentation by mentioning that this work does not take into account the interworking scenarios; that it is solely based on the implementations Tellium wanted to perform.
Then he identified the new extensions this draft specifies. They include: signaling port ID, signaling optical switched path ID, signaling both end-points of the path being established, path attributes, and signaling requirements for both span and path protection. Moreover, he identified some new TLVs such as Route_Record (records the path being set up at port level); he mentioned that the ingress node initiates this TLV. Finally, he discussed bi-directional path setup, where two adjacent OXCs form a Master/salve relationship.
There were no questions.
---
'Some Comments on the Use of MPLS Traffic Engineering for SONET/SDH Path Establishment', <draft-bernstein-mpls-sonet-00.txt>, Greg Bernstein
Greg Bernstein began his presentation by stating that there is interest in the use of an IP based control plane for a circuit switched infrastructure. He then cited lambda switching, fiber switching, SONET/SDH paths, and so forth. Moreover, he asserted that the contents of the 'pipes' may or may not be IP traffic, in fact, it may or may not be known. As a result, he said that different provisioning modes are desired, i.e., end system initiated (w/o knowledge of network topology), network management initiated (w/o end system, SPLSPs), and the service layer as peer (e.g., IP router controls lower layer connections).
Subsequently, after motivating the topic of the draft, Greg spoke about MPLS application decomposition. He broke it up into information needed to compute paths, information that only needs to be known between adjacent switches, information that all switches in the path need to know, and information intended only for end systems of the path.
Greg then went into a quick review of SONET signals. He stated that they were all bi-directional. And, restricted in concatenation variations, which include standard concatenation, arbitrary concatenation, and virtual concatenation.
Finally, he pointed out some additional considerations such as connection bundling, the routing of multiple STS-1s along the same route at the same time, degrees of transparency, STE, LTE, PLR, line protection types, etc.
There were no questions.
-----
'MPLS for SDH Control', <draft-mannie-mpls-sdh-control-00.txt>, Eric Mannie
Eric Mannie began his presentation by asserting that a wavelength is still expensive, thus, there is a need to multiplex separated pipes. As a result, he continued, SDH/SONET will continue to be a huge market in the medium-term.
In addition, he mentioned that MPLS could be used to dynamically control SDH paths. The idea being to employ the signaling plane of MPLS + IP or ATM routing + SDH switching. Also, he stated that SDH defines a multiplexing structure that can be controlled by MPLS to switch. He then pointed out that the draft covers the following SDH aspects: STM-N and lower order signal switching and virtual and contiguous concatenation.
Further, he discussed labels in this context. Namely, that a label identifies a part of a SDH path not a frame and that there is one multiplex table per interface. He also mentioned two feasible label allocation approaches: 1) sequential label allocation, i.e., independent of any SDH semantic, and 2) hierarchical label based on SDH multiplex. Then he discussed the benefits of using multiplex entry names as labels. That it identifies directly signal type and position and allows easy debugging (does not need to know the matching to debug).
He also talked about multiplex entry notation and coding, and followed that with examples of operations such as LSP tunneling could be used to sub-structure a signal and could also establish an LSP inside an existing LSP. An example he provided was that of downstream on demand allocation, where simple SDH CAC and periodic multiplex checking/re-synchronization could be employed.
In addition, he talked about routing and signaling for SDH. For routing of SDH paths, he mentioned that the multiplex table at each I/F must be known. He also discussed SDH signal concatenation of AU-4 and TU-2 and interconnection of different signals such as VC-3, TUG-2, VC-11. He mentioned the impact on the signaling protocol is that source routing is required with a label list/range and that the exchange of signaling and routing messages are over SDH.
His conclusions were that SDH paths can be dynamically established and released, and that MPLS provides a suitable signaling plane for SDH control. He mentioned that the draft explains how and discusses issues. He also said that the draft will be extended to cover SONET, SONET-SDG conversion, sub STM-0 (if needed), CR-LDP and RSVP-TE extensions to cover SDH signaling, and OSPF and IS-IS extensions to cover SDH routing.
No questions were asked of the speaker.
----
'Link Bundling in MPLS Traffic Engineering', <draft-kompella-mpls-bundle-00.txt>, Kireeti Kompella
Kireeti began by describing the concept of link bundling. That is, a pair of LSRs may be connected by multiple, parallel links, and from a MPLS traffic engineering perspective for the expressed purpose of scalability, treating all these links as a single link may be desirable.
He pointed out two link bundling alternatives: 1) finer granularity is achieved when each link in the bundle is numbered. Alternatively, 2) by advertising a single link, coarser traffic engineering results with less IGP information needed, thus, fewer IP addresses are required; the trade-off being the loss of information for each individual link.
Then he introduced TLVs for link bundling including: maximum LSP bandwidth, maximum bandwidth available to an LSP at a given priority level, maximum bandwidth of component links, maximum of {link bandwidth, unreserved bandwidth} over all component links, etc.
Further, he specified the procedures needed to accomplish this. That is, RSVP must track unreserved bandwidth at each priority for each component link and report maximum LSP bandwidth to the IGP; IS-IS/OSPF will advertise summary information, and CSPF for an LSP with bandwidth b and setup priority p (ignoring all links whose max LSP bandwidth at p is less than b).
He also enumerated the applicability of link bundling to multiple parallel TE links, multiple lambdas in a fiber, multiple channels in a TDM link, etc.
He concluded by pointing out the next steps for this draft and making a proposal. He said that the draft would be updated by including clarifications and a usage example. Then he proposed to make it a MPLS working group document.
In the q/a period, Don Fedyk said that he likes the idea of link bundling, but then he inquired about why the floating point numbers increased from 8 to 16; he believes it should remain at 8. Kireeti responded by indicating that due to capacity planning, 16 floating point numbers are required.
---
'Link Management Protocol (LMP)', <draft-lang-mpls-lmp-00.txt>, Jonathan Lang
Jonathan Lang said that this draft describes a new protocol that is being proposed for link provisioning and fault isolation.
He started out by specifying the need for link management. Then he cited a few examples illustrative of the diversity of OXCs configured with IP links. In particular, he pointed to two: 1) a single bi-directional control channel spanning OXCs, and 2) a number of unidirectional user bearer channels.
He then covered the four main functions LMP comprises. The first was control channel management. He stated that a bi-directional control channel is required per IP link. He also mentioned a number of other characteristics: that the backup control channels are pre-configured, control channel implementation is unrestricted, and use of a Hello protocol. He described in more detail the Hello protocol. Specifically, a unicast Hello message is periodically transmitted, contains sender's Hello interval, contains sequences numbers (SendSeqNum, RecSeqNum), and it detects a node reboot.
The second function was link connectivity verification. He stated that the requirements include the user bearer channels are opaque until allocated and messages are sent/received over any bearer channel. For verification, initial configuration and periodic validation of free bearer channels and (fiber, lambda) Label exchange. Then he described how to initiate link connectivity verification. That is, BeginVerify initiates process (c), BeginVerifyAck signals start of Test procedure (c), Test procedure (3-way handshake, and EndVerify terminates process.
The third feature of LMP is a LabelSummary exchange. He stated that it synchronizes label matching and correlates link properties, and exchanges when labels or link properties are changed, and so forth.
Finally, he concluded his presentation by describing fault localization - the fourth function of LMP. He mentioned that it isolates link and channel failures and initiates protection/restoration mechanisms.
During q/a, Peter Ashwood-Smith asked if monitoring an individual wavelength itself disturbs it in any way? Jonathan Lang answered affirmatively that that is the tradeoff between power and of knowing the health of your channels and bearer channels.
-----
Discussion on MPLS extensions in support of Optical Networks, George Swallow
Rob Coltun, the Routing Area Director, mentioned that all the contributions thus far are outside the charter of the MPLS WG. He went on to say that no actions could be taken at this point with respect to the above drafts. He proceeded with a clarification that, not that the drafts are not appropriate for the MPLS WG, but that they are outside of the WG's charter. Also, he stated that a good portion of drafts are applicable to MPLS, in fact, that optimize MPLS.
George Swallow suggested that the charter reflect this work, and once that is accomplished, the charter will be sent to IESG for approval. He also stated that getting the optical work going is very orthogonal to the LDP, CR-LDP, and RSVP-TE Internet Drafts.
Rob Coltun also mentioned that what contributions fall into what particular WGs besides the MPLS WG, such as the IPO WG, is yet another consideration.
Someone else raised the point that an interim step would be if the co-authors would combine their drafts as well as to get issues discussed on the MPLS WG mailing list. That these steps would be unofficial until the IESG approves the new MPLS direction. Bilel Jamoussi added that he agrees that the co-authors should get together and try to combine the contributions.
Subsequently, George Swallow made the suggestion that before the next MPLS WG session at this IETF meeting, the co-authors of the above drafts should get together and discuss how their work can be combined. He believes that a small number of conflicts exist.
----
A Framework for Service Differentiation in MPLS Networks, <draft-vaananen-mpls-svc-diff-framework-00.txt>, Muckai Girish
Muckai Girish initially covered the contributions of this draft. He mentioned that it creates a framework for service differentiation, discusses a set of services, identifies traffic management element functions in various network elements, and so forth.
Then he went on to describe the framework for services in more detail. In particular, he mentioned that the framework is described by two components: the traffic contract and the service objectives. He asserted that one can create a lot of services based on these components such as best effort service, bounded loss service, enhanced best effort service, etc.
In discussing how the services are implemented, he mentioned that control and data plane mechanisms are required. For example, control plane mechanisms include triggers and policy and admission control, while data plane mechanisms can comprise of a label-forwarding paradigm.
He then identified particular network elements/devices such as hosts, MPLS edge nodes, CPE routers, MPLS core routers, etc. Having done that, Muckai specified the mandatory functions in Service Provider border routers, which included admission policy, admission control, direct and indirect mapping, policing/marking, shaping, aggregation, queue management, scheduling, and classification policy.
He concluded his talk by focussing on the future actions related to this work. He suggested that this draft be a MPLS WG document if the WG believes that it is useful. Also, he wanted to solicit comments and input and contributions from others to improve and extend the draft. Ultimately, his aim was to have this document eventually published as an informational RFC.
Consequently, George Swallow then said that this work is outside the charter of the MPLS WG.
---
'MPLS Support of Differentiated Services', <draft-ietf-mpls-diff-ext-05.txt>, Shahram Davari
Shahram Davari began his presentation by providing a history of how this work developed. He noted that the current draft had gone through five instantiations, where each version benefited from comments made by the working group.
He then proceeded to describe two models for DS Behavior. Namely, the first is the uniform model, where a tunnel's ingress PHB is the same as the packet's PHB; he mentioned that this model is the default and it is useful when transiting the same administrative domain. The second is the tunnel model, where a tunnel's PHB may be different from a packet's PHB. Moreover, the packet's PHB is preserved and restored.
Subsequently, Shahram discussed the E-LSPs, configured and signaled, that are defined in the draft. On the one hand, in the configured E-LSP, the PHB <=> EXP mapping is configured in each LSR. On the other hand, for the signaled E-LSP, the PHB <=> EXP mapping is signaled for all BAs support. He also mentioned that support for signaled E0-LSP is optional, and that a new DiffServ object for Signaled E-LSP was defined.
Shahram also remarked that support was added for LAN/802.1 in the draft, of which 3 scenarios exist. That is, 1) LAN/802.1 switches between two LSRs; 2) LAN/802.1 interface between two LSRs, where no LAN/802.1 switches are present, and 3) MPLS enabled LAN switches, which he stated is not currently defined in the IETF and therefore is not considered in this draft.
Further, he disclosed that some new Error Status Codes (e.g., Error Type and Unsupport PHB) were introduced in the draft. And, that the per-LSP bandwidth signaling was clarified in the draft, particularly noting the purposes of bandwidth signaling; i.e., DiffServ LSP admission control, adjusting DiffServ provisioned resources (e.g. PSC scheduling weight), no per-LSP or per-flow scheduling is required, and E-LSP BW refers to all transported PSCs.
Shahram wrapped up his presentation by indicating that all the open issues of the second version of the draft were resolved, and all the comments on v03 and 04 were incorporated (i.e., bandwidth signaling and push/pop behavior), except one request to add an extension for signaling per PHB/per-PSC bandwidth at E-LSP setup. He also mentioned that the next step would be to release version 05 of the draft in the next 1-2 weeks.
During the Q/A, Lou Berger thought that extra wording was needed in the draft that discusses the compatibility issues between nodes that are DiffServ and non-DiffServ enabled. Shahram agreed to look it over.
----
'Framework for MPLS-based Recovery', <draft-makam-mpls-recovery-frmwrk-00.txt>, Vas Makam
Vas Makam initially covered the purpose and contribution of this draft. He stated that the purpose was to form a consensus on terminology, requirements, and recovery models. Then he went on to discuss the MPLS protection objectives; some of which include: facilitate fast recovery of working traffic; maximize network reliability and availability; allow protection of traffic at various granularities, and maintain switching actions in separate MPLS protection domains independent of each other.
Subsequently, he went over new terminology that was added to draft, such as Path Switch LSR (PSL), Path Merge LSR (PML), Working Path, Recovery Path, and Protection Domain. Having gone through some terminology, he then covered MPLS recovery requirements, which include mechanisms to configure recovery (enable or not enabled) and perform recovery at PSL and PML upon failure detection or the receipt of FIS, etc. Moreover, Vas also cited some comparison criteria that can be employed such as recovery time, full restoration time, and backup capacity.
Vas concluded by citing some expected updates to the drafts and next steps for this work. The coming updates include: cover switch-"back" to loosely explicit routed paths, add requirements on alarm correlation, add to the objectives that the protection algorithm should be scalable, and add a note that not every alternative mentioned is implemented. As for next steps, Vas mentioned that after feedback from the MPLS WG and the corresponding mailing list, any issues would be clarified and resolved. He then proposed to move this draft to a MPLS WG document. Consequently, George Swallow said that that suggestion would be put on the MPLS WG mailing list. George also mentioned that the 1+1 case requires 2 variants.
Also, Vijay Srinivasan indicated that this work was also inserted in the MPLS WG charter but was not yet approved. George Swallow remarked that the work on protection switching was implicit to the traffic engineering text already in the charter so no new words were required to cover this work.
---
'A Path Protection/Restoration Mechanism for MPLS Networks', <draft-chang-mpls-path-protection-00.txt>, Changcheng Huang
Changcheng Huang started his presentation by stating the purpose of this work. Namely, the purpose is to propose a path protection mechanism for MPLS that is fast, scalable, bandwidth efficient, and allows for path merging. He also outlined the key features of this proposal, i.e., Liveness Message, Reverse Notification Tree, Lightweight Notification, and to minimize delay. Subsequently, he described two configurations in more detail: 1) Reverse Notification Tree (RNT), and 2) the hop-by-hop approach.
He then spoke about further issues being explored vis-à-vis this work. In particular, enhancing scalability by aggregating information about faults and investigating tunneling or nesting approaches in relation to 'legacy' LSRs. Moreover, handling multiple faults was another item, i.e., he expressed a need to identify all scenarios, and for each scenario, to indicate which approach (if any) will work.
He wrapped-up his presentation by focussing on the next steps for this work. They include soliciting feedback from the MPLS WG mailing list and then moving to a MPLS WG document, to consider extensions to RSVP and LDP/CR-LDP to facilitate implementation, and to consider how this work may apply to the optical case.
Afterwards, George Swallow mentioned that there has not been much feedback from the MPLS WG mailing list concerning this work, and he believes that before it becomes a MPLS WG document, more discussion on the mailing list needs to take place.
Also, Shahram Davari asked whether RNT is manually configured. Changcheng's response was no, not necessarily, it can also be configured through signaling extensions.
-----
LDP Fault Tolerance, <draft-farrel-mpls-ldp-ft-00.txt> & <draft-matthews-mpls-ldp-ibb-00.txt>, Philip Matthews
At the outset, Philip mentioned that both drafts, <draft-farrel-mpls-ldp-ft-00.txt> & <draft-matthews-mpls-ldp-ibb-00.txt>, addressing LDP/CR-LDP fault tolerance will be combined. Then went into a description of fault tolerance.
Subsequently, he put forward two applications that can make use of this work. First, a hitless on-card software upgrade: the old stack can be running, while upgrading the LDP and/or TCP stack on the card. Second, an application that is intended to control redundancy, assuming a router with separate control and data planes. For example, forwarding is accomplished on the interface cards, while LDP signaling on the control card; thereby, the backup control card can be ready to take over immediately if the primary control card fails. However, he pointed out some problems with this approach, i.e., because LDP runs on TCP, it is very difficult to keep the TCP connection alive when doing this switch.
Further, he then stated how the two drafts were similar and how they differed. Both drafts have a common framework that goes as follows: allow the old TCP connection to die, continue to forward labeled traffic, then establish new TCP connection and in LDP initialization say 'continue old LDP session'. However, he pointed out that the two drafts differ in their ACK scheme. He proceeded to discuss how each draft ACK scheme works: on the one hand, <draft-farrel-mpls-ldp-ft-00.txt> extends implicit acknowledgements already present in the LDP protocol; in this way, neighbors know which messages have been received and which have been lost. On the other hand, <draft-matthews-mpls-ldp-ibb-00.txt> carries an application-level sequence number in the LDP Message ID and adds an ACT TLV to message, etc.
He also mentioned that both methods work and each approach have their pros and cons. The disadvantage for <draft-matthews-mpls-ldp-ibb-00.txt> is that it forces one style of use for the Message ID field, while <draft-farrel-mpls-ldp-ft-00.txt> is less future-proof to protocol extensions.
Also, he pointed out that a combined draft would use certain aspects of one draft and other aspects of the other draft such as the explicit ACK approach from <draft-matthews-mpls-ldp-ibb-00.txt> would be used as well as it would take the idea of FT and non-FT labels from <draft-farrel-mpls-ldp-ft-00.txt>. Moreover, he mentioned that a new sequence number TLV is being added in the combined draft. He said to refer to messages being sent to the MPLS WG mailing list for more details.
Finally, he stated that their intent is to add an optional extension to LDP, to produce a combined draft in time for the next IETF meeting in Pittsburgh, and that they will ask that the combined draft become a MPLS WG document at that meeting, aiming for a standards track RFC.
During the Q/A period, Rob Coltun asked the speaker to differentiate between failure detection and a time-out. Due to time limitations, they were asked to take this up on the mailing list.
--
'Voice over MPLS Framework', <draft-kankkunen-vompls-fw-00.txt>, Anti Kankkunen
At the outset, Anti Kankkunen mentioned that he was only allotted 2 minutes to present the VoMPLS draft and that that was not enough time to present any details concerning the draft. As a result, he pointed out where to locate the draft, and he also wanted to convey the idea behind VoMPLS. That is, the use of MPLS as an efficient transport of VoIP services with predictable QoS/GoS in an IP / MPLS network, where voice over MPLS is equivalent to VoIP over MPLS.
---
'MPLS/IP Header Compression', <draft-berger-mpls-hdr-comp-00.txt>, Lou Berger
Lou Berger began by enumerating the objectives of the MPLS/IP header compression draft. In particular, to enable header compression for MPLS encapsulated traffic and to optimize for maximum compression. He mentioned that end-to-end compression was not a requirement and that it was targeted at 'lower speed' links, where lower speed was not specified but was hardware-specific.
He mentioned that the key consideration was whether MPLS headers are compressed. He went on to cover two options: 1) end-to-end with header compression over MPLS, and 2) link-by-link with compression of MPLS/IP headers. Subsequently, he discussed the pros and cons of each approach, concluding that both are reasonable depending on the application.
He then outlined the basic approach. That is, it begins with standard IP header compression, then support for compression of MPLS packets is added, where the first draft preserves the standard compression header (2 bytes, 4 bytes when UDP checksums are used, and +1 byte per EXP field change). He stated that it does not increase with more MPLS headers. And, that the second draft, <draft-berger-mpls-hdr-comp-over-ppp-00.txt>, defines PPP link layer support, which parallels RFC 2509 (IP header compression over PPP).
He concluded by highlighting two issues. First, the bit naming collision with draft-koren-avt-crtp-enhace-01.txt, and second, he remarked that it was not clear which IETF working group this work should proceed in.
---
'Simple Header Compression', <draft-swallow-mpls-simple-hdr-compress-00.txt>, George Swallow
George Swallow enumerated the motivating factors that lead to this work. Namely, that in VoIP, headers account for a significant portion of the packet. And, for networks in which voice traffic dominates, significant bandwidth savings can be achieved by compressing headers. He then remarked that a trade-off between less bandwidth efficiency for better processing efficiency exists. He went on to say that this could be done from access point to access point, where allowing compression on access links without requiring edge routers to perform header compression. He also stated that the same techniques are being employed in PacketCable.
Further, he described the actual compression technique, mentioning that the technique operates without the need for re-synchronization, that the MPLS label serves as the Context ID, and so forth.
George then proceeded to list some draft refinements. Namely, he noted that 3 flags were used for MPLS TTL, inferring length from received MTU, and for re-computing checksum. And, he also mentioned that the SCID (Sub-context ID) had two purposes: 1) to allow multiplexing across an LSP, and 2) to handle simple format variations in a packet stream.
During the Q/A period, Shahram Davari asked how does this technique handles label merging? George's response was that the setup was accomplished via RSVP signaling, thus, merging is not permitted.
George Swallow then posed a question to Rob Coltun, who is the Area Director of the Routing Area. He asked what should be done with the draft he presented as well as Lou Berger's draft on the same subject. Rob's initial response was to defer that decision until VoMPLS BOF. Lou Berger then mentioned that the generic header compression schemes are not MPLS specific, thus, he had a 'strong opinion' that this work should reside in the IETF Generic WG. Rob then inquired about the operational demand for this work. Finally, it was decided that this work will be done in the MPLS WG and that it will be described in the MPLS WG charter.
----
'Soft Permanent LSPs for CR-LDP', <draft-heinanen-mpls-splsp-00.txt>, Juha Heinanen
Juha Heinanen began his presentation by stating that this idea is similar to soft PVCs in FR and ATM networks. And, because MPLS does not have such a capability, that this was an effort to introduce it.
He then went on to define a Soft Permanent LSP (SPLSP). He mentioned that it is a permanent LSP that originates or terminates at an interface of an MPLS node. Moreover, that it is owned and (re)established by the originating MPLS node, and that labels at originating and terminating interfaces are determined by the originator. He also gave a few SPLSP examples.
Subsequently, he discussed the motivation of SPLSPs. He mentioned that some of the scenarios where SPLSPs would be useful to employ include: when an MPLS domain does not want to exchange MPLS control information with another domain, an MPLS CPE does not implement an MPLS control plane, or an MPLS domain wants to dynamically re-establish an LSP without notifying its user.
Juha then provided some particulars concerning the draft. He mentioned that the draft discusses a SPLSP CR-LDP implementation, where setup is achieved using a Label Request Message in which the Label TLV carries the label requested at the terminating interface. And the terminating interface is identified by an IP address carried in the last ER-HOP. He also mentioned that the interface and label selection at the originating node is a local matter.
He concluded by stating that he strongly feels that supporting SPLSP capability is needed one way or another.
During q/a, someone commented about MPLS being uni-directional, but most applications, he stated, use bi-directional flows. He went on to ask if there was a way to get that reverse path setup. Juha mentioned that he does not see a problem in accomplishing that.
Also Rob Coltun mentioned that this would be an ideal talk for the TEWG. Juha responded by stating that he does not believe in the merits of traffic engineering, rather that he prescribes to shortest path approaches.
---
'Crankback Routing Extensions for CR-LDP', <draft-fujita-mpls-crldp-crankback-00.txt>, Atsushi Iwata
Atsushi Iwata began his presentation by asking the question why is crankback required. He asserted that crankback routing is a powerful technique for rerouting upon setup blocking. That it is useful for end-to-end LSP restoration. And, that it requires notifying the upstream LSR of the location of a blocked link or node.
He then stated that the focus of his talk is specifying the extension to CRLDP to support crankback routing. He noted that this could be extended to RSVP-TE as well.
Subsequently, he pointed out some behaviors of the rerouting TLV. That it is included in a notification message. And, in the LSP failure case, upon an end-to-end restoration, the rerouting TLV is included in a label withdraw message.
He also mentioned that identifying blocked links or nodes is necessary. For this, two kinds of identification are employed. One approach is a protocol-independent identifier and the other is protocol dependent identifier, both are specified in the draft.
He concluded his presentation by requesting that this draft covering a crankback extension for CR-LDP be accepted as a MPLS WG document or to merge it with <draft-ietf-mpls-cr-ldp-xx.txt> for inclusion in the crankback/restoration section. To this, George Swallow said that he would prefer to hold off making this draft a MPLS WG document until some of the other related work starts maturing, since specific TLVs will probably change.
---
'Requirements for Policy Enabled MPLS', <draft-wright-policy-mpls-00.txt>, S. Wright
S. Wright initially reviewed some aspects of Policy Based Networks (PBNs). In particular, he stated that the policy and rap WGs developed the PBN architecture. Moreover, the Policy Information Base (PIB) is stored in the policy repository. And, the PIB is a higher level abstraction than MID.
He went on to point out that policy is also relevant to MPLS networks. He mentioned that the rationale for such a combination included consistency (e.g., align with DiffServ PIB work), integration, controllability, flexibility and MPLS abstraction.
He then cited a few policy examples related to MPLS. That is, LSP admission policies and LSP life cycle policies, where a PBN example is LSRs as PEPs. Also, he stated that it should be possible to policy enable an MPLS network; the main implication being that PIB elements correspond to MPLS concepts and MPLS MIB elements (e.g. LSPs).
He concluded by saying that he wanted to bring this policy work to the attention of the MPLS WG to gauge if this work was appropriate. The consensus in the WG was that it is worth working on, thus, contributions in this area related to MPLS should be brought to the MPLS WG. Moreover, George Swallow stated that policy and MPLS are two things that have very much in common and much to do with each other, so it is worth working on.
---
'End to End Authentication for LDP', <draft-schrijvp-mpls-ldp-end-to-end-auth-00.txt>, Peter Schrijvp, Yves T'Joens
The speaker mentioned that the objective of the draft was to describe two procedures to authenticate. Namely, procedure 1 was challenge-based, while procedure 2 was based on a Digital Certificate and Digital Signature.
Then, two questions were posed to the MPLS WG. That is, should this be seen as framework today, to be technically detailed with various methods, and does the MPLS WG want to take this work up?
A discussion then ensued on this topic. First, George Swallow asked if anyone in the MPLS WG sees any immediate need for this functionality. Vijay Srinivasan then mentioned that someone else proposed authentication capabilities of RSVP. George followed by stating that RSVP authentication is not MPLS specific. This discussion was postponed until the charter discussion is discussed towards the end of this MPLS WG session.
---
'MPLS VPN Interworking', <draft-sumimoto-mpls-vpn-interworking-00.txt>, Junichi Sumimoto
Junichi Sumimoto began his presentation by posing the question why VPN interworking was necessary. He then proceeded to answer the question by stating that a number of different MPLS VPN solutions have been developed; this was due to lack of a standard specification for MPLS VPNs. Thus, he concluded that a MPLS VPN interworking method that enables a VPN service over MPLS networks is definitely required.
He declared that the Interworking Model assumes an MPLS network to be the base for providing VPN services. He went on to enumerate three service assumptions that are provided by MPLS VPNs. Namely, 1) security support, 2) QoS calls support, and 3) dynamic routing information distribution. Moreover, he then listed the three functional capabilities (FCs) (refer to draft) that are required at the interworking interface to enable the interworking of the three services. He also showed the implementation methods for the three FCs and discussed how an extranet is constructed.
Junichi concluded his presentation by asserting that a MPLS VPN interworking method to enable a VPN over MPLS is definitely needed. Moreover, that the presentation focused on a static interworking solution for the purposes of a faster deployment cycle, and dynamic interworking will be discussed in the future.
During the q/a period, Bilel Jamoussi mentioned that VPN work is outside the charter of the MPLS WG. This led Rob Coltun to add that starting a MPLS VPN effort to document the few methods being implemented in the market would be worthwhile to do. In addition, he stated that that effort would not have the charter to select a particular method.
Marco Carugi also mentioned that realizing interoperability among various MPLS VPN approaches is very important to France Telecom. He went on to say that ITU SG13 Q20 is studying this very issue. In fact, he mentioned that they are convening a meeting in Paris from May 29 through June 2, 2000 to discuss this very topic. Also, he said that IETF representation in the ITU on this matter would be very helpful indeed.
George Swallow mentioned that the VPN effort is more general since not all VPN solutions are MPLS based. Bilel Jamoussi added that this work should be referred to as 'Network-based VPNs', since it is more general.
Also, with regard to Junichi's presentation, the WG decided that this work is best suited for the VPN BOF (or prospective WG), not the MPLS WG.
----
Charter Discussion, Vijay Srinivasan
Vijay Srinivasan led off the discussion concerning the MPLS WG charter. He started out by mentioning that he sent out an update to the charter the evening before the start of this MPLS WG session and proceeded to describe some aspects of what was written.
Joel Halpern then pointed out that a mismatch exists between the goals and the 10 items listed in the charter. He proceeded by pointing out an example, i.e., the charter states that 'Mar 00 - produce a doc which defines support of DiffServ over MPLS networks'; he mentioned that this does not match any of the 10 items above that statement.
Bilel Jamoussi then asked if the framework document was still useful, since it expired a long time ago. He continued by pointing out that it is low in the MPLS WG priority queue.
Subsequently, Juha Heinanen asked about the status of the label encapsulation draft. To which, Rob Coltun responded that interdependency exists among a number of MPLS WG drafts. In particular, he mentioned that until the LDP draft moves forward, the label encapsulation draft could not proceed. George Swallow then volunteered that Bob Thomas should have a new LDP draft out in mid-April. He continued by indicating that the IESG provided some comments that will be accommodated by making the necessary changes in the LDP draft; George mentioned that Bob will do this in coordination with the other co-authors of that document. George believes that this should be done by sometime in April. In other words, that the LDP draft will be re-submitted to the IESG in April 2000.
Rob Coltun then asked about the status of the MPLS Framework draft. The response was that the person that was moving that draft forward was overcome by events so unless somebody in the MPLS WG volunteers to tie up the loose ends and polish the document, it will not move forward.
In addition, Vijay wanted to gauge the reaction of the MPLS WG on the header compression work, i.e., whether it is an appropriate work item for the group. The upshot was that there was consensus to perform work in that area.
George Swallow then asked a related question about the work in policy and authentication. Someone suggested that coordination with the rest of the IETF was necessary. Bilel Jamoussi then added that policy helps in managing MPLS networks.
There was also some issue about the connection between policy and authentication, which led someone to say that policy and authentication are different, thus, there was no need to combine them, rather to treat them as two separate work items.
After this discussion, George Swallow and Vijay Srinivasan took action items to add authentication, policy, and compression to the MPLS WG charter.
At this point, the 47th IETF MPLS WG meeting was concluded.
|
|