The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Draft MPLS minutes
MPLS Working Group WG Chairs: George Swallow <swallow@cisco.com>, Loa Andersson <loa.andersson@utfors.se> George chaired the meeting. Andy Malis took the minutes. (Thanks Andy!) 1. Overview of ISOCORE Interoperability Tests Rajiv Papneja, rpapneja@isocore.com Rajiv presented the results of the March MPLS interoperability testing at ISOCORE. They tested RSVP-TE with FRR, MPLS LDP signaling, and MPLS as a transport for L2 VPNs, specifically including VPLS. Their service provider sponsors provide the list of functionality to be tested as input to the test plans. They had ten vendors participating in the testing, and they built a network with both core LSRs and edge LERs. They used ISIS-TE as the IGP for RSVP-TE. More than 30 interoperability issues were discovered in 7 days of testing. More than 15 fast reroute scenarios were tested, and they achieved <40 ms switch-over in the scenarios. The found a number of issues in the testing. Some of the highlights of these issues were: * They found issues with reverse compatibility in FRR for the nodes that don't support it. There was an issue with ISIS-TE in that not all vendors had implemented the latest drafts, so they recommend that all vendors update their code. * They also suggest that all vendors support ERO in the RSVP-TE Path message (they found that some did not). * In the LDP HELLO message, they found incompatible values in the transport address TLV, and an ambiguity in the definition of the LDP TLV length definition. They recommended on how these problems need to be corrected in RFC 3036. * There were also ambiguities in the value of the LSR-ID over targeted and basic discovery. This also needs to be fixed in RFC 3036. * Some vendors were advertising per-interface label space for targeted LDP sessions when they should have been using per-platform labels due to an ambiguity in the Martini signaling draft. * Backward compatibility issues between the different revisions of the VPLS draft. * An ambiguity in the Address List TLV in Address Withdraw messages. Their upcoming testing will be GMPLS interoperability in April, MPLS Leading Edge testing in July and August, and the 4th MPLS 2003 Demo following the MPLS 2003 conference. 2. TE-related drafts Reoptimization of explicit loosely routed MPLS TE paths http://www.ietf.org/internet-drafts/draft-vasseur-mpls-loose-path-reopt-01.txt Jean-Philippe Vasseur, jpv@cisco.com This draft proposes a mechanism for the reoptimization of loosely routed explicit paths. A loosely routed explicit path is as a path specified as a combination of strict and loose hop(s) that contains at least one loose hop and zero or more strict hop(s). The path calculation (ERO expansion) to reach a loose hop is made on the previous hop defined in the TE LSP path. This draft proposes a mechanism that allows: - the TE LSP head-end LSR to trigger a reoptimization on every loose hops along the path, - an LSR to signal to the TE LSP head-end that a better path exists to reach a loose than the path in use. A better path is defined as a path with a lower cost, where the cost is defined by the metric used to compute the path. This primarily applies to inter-area TE LSPs and inter-AS TE LSPs when the path is defined as a list of loose hops (generally the loose hops are the area border routers) but the mechanism is also applicable to any loosely routed explicit paths within a single routing domain. If and only if at least a better path exists in an area or AS, reoptimization is triggered. The reoptimization can be event-driven or timer-driven, and triggered from both the head-end and from a mid-point LSR. Comments have been received from service providers acknowledging their interest in deploying this technology. Rahul Aggarwal suggested an improvement in one of the mechanisms in the draft to simply the operation in some situations. JP agreed with the suggestion. Philip Matthews asked a question about the use of PathErr notification, since they can be lost in the network. JP explained how the draft can compensate for such losses. JP proposed that this become a working group draft. George said that the IETF has to decide how it's going to treat the entire set of inter-area and inter-AS TE drafts before this draft can be accepted. This topic is going to be discussed later in the week at the sub-IP Directorate meeting. Plus, decisions to accept drafts are always made on the email list. There may also be working group charter changes required before taking this on. A hum 'vote' showed some support for making this a WG draft in the room. Definition of an RRO node-id subobject http://www.ietf.org/internet-drafts/draft-vasseur-mpls-nodeid-subobject-00.txt Jean-Philippe Vasseur, jpv@cisco.com In the context of MPLS TE fast reroute, the merge point (MP) address is required at the point of local repair in order to select a backup tunnel intersecting a protected TE LSP on a downstream LSR. However, existing protocol mechanisms are not sufficient to find the MP address in multi-area or multi-domain routing networks. As a result, the current MPLS Fast Reroute mechanism cannot be used to protect inter-area or inter-AS TE LSPs from a failure of an area border router or Autonomous System border router. This document specifies the use of existing RRO IPv4 and IPv6 subobjects (with a new flag defined) to define the node-id subobject in order to resolve this issue. Use of MPLS TE FRR bypass has been identified as a key requirement by service providers. This draft proposes a simple flag definition to allow backup tunnel selection of inter-area/inter-AS TE LSPs. Again, JP asked this draft be adopted as a WG draft. George said that this is a very simple point solution, and very straightforward, and he's in favor of adopting it. There was widespread support in the room. This will be ratified on the list. MPLS Traffic Engineering Fast reroute: bypass tunnel path computation for bandwidth protection http://www.ietf.org/internet-drafts/draft-vasseur-mpls-backup-computation-02.txt Jean-Louis Le Roux, jeanlouis.leroux@francetelecom.com This draft proposes a model called the "Facility based computation model" for computing bypass tunnels paths in the context of the MPLS TE fast reroute, while allowing bandwidth sharing between bypass tunnels protecting independent resources. Both a centralized and a distributed path computation scenarios are covered. The required signaling extensions are also discussed in the draft. Jean-Louis described how the model can efficiently perform the path computation. He showed how the draft fits into section 6 of the current MPLS WG charter, and presented the history of the drafts that were combined in order to produce this draft and the changes from -01 to -02. The major change was the introduction of the SDLG concept - Shared SRLG (shared risk link group) Dependency Link Groups. Conclusion: FRR is now largely implemented and deployed. BW protection is a key requirement to protect sensitive traffic on non-over-provisioned networks. The facility-based computation model seems the most efficient approach for bypass tunnel placement. Vishal Sharma said that he had suggested some improvements to the draft that removes the need for protocol extensions. Jean-Louis said that those comments applied to version 1 of the draft, and not to version 2. Jean-Louis asked that this be made a WG draft. Most of the room had not yet read it, so George was hesitant to make a determination now. He said it should be discussed further on the list. MPLS Traffic Engineering Soft preemption http://www.ietf.org/internet-drafts/draft-meyer-mpls-soft-preemption-00.txt Matthew Meyer, mrm@gblx.net This draft discusses MPLS TE soft preemption, a set of protocol modifications extending the current concept of preemption with the goal of reducing or eliminating traffic disruption of preempted TE LSPs. Under present RSVP-TE signaling methods, LSPs are immediately displaced upon preemption. The introduction of a new preemption pending flag helps to more gracefully mitigate the re-route process of displaced LSPs. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect overbooked until the LSP can be re-routed. The problem to be solved is that preemption can be unnecessarily disruptive to the network, especially in conjunction with Diffserv, and preemption may occur even when there is excess capacity in the network. There is a concrete and operational issue that needs to be resolved. This draft proposes RSVP-TE mechanisms that can be used to treat the lower-priority flows better. George, as one of the authors of RFC 3209, said that there is a hole in that RFC and this RFC plugs it, and he supports this as a working group item. Rahul said that he's also supportive of this, and he proposed an improvement to the policing function. Matthew agreed. Kireeti Kompella said that we need to discuss RRO vs. PathErr on the list. JP said that the first drat used PathErr, but it was changed to RRO in the second draft based on implementation experience. Adrian Farrel asked that the authors not come up with protocol solutions to respond to nonstandard deployed versions of the specification. Matthew and George both agreed. The room agreed that this be made a WG draft, and it will be ratified on the list. 3. Graceful Restart LDP DoD Graceful Restart http://www.ietf.org/internet-drafts/draft-thomas-mpls-ldp-dod-restart-00.txt Bob Thomas, rhthomas@cisco.com LDP graceful restart is a mechanism that helps reduce the negative effects on MPLS traffic caused by the restart of an LSR's control plane, specifically by the restart of its LDP component on LSRs that are capable of preserving MPLS forwarding state across the restart. RFC 3478 defines procedures for LDP graceful restart for downstream unsolicited label distribution but leaves procedures for downstream on demand label distribution a subject for future study. This document defines graceful restart procedures for downstream on demand label distribution. Bob gave an overview of how his draft builds upon the mechanisms already in RFC 3478, and specifies changes to the Label Request and Label Abort messages. It also makes changes to the behavior of a neighbor router immediately following an LDP outage. Bob asked that the WG accept the completion of LDP restart as a work item, and this draft as the way to address the issue. Rahul said that he was one of the authors on RFC 3478, and at the time that document was done, there was no requirement for DoD. He asked what the requirement is for this draft. Bob said that the motivation is MPLS over ATM, which uses DoD. There are MPLS over ATM deployments that could take advantage of this. Rahul also had some technical suggestions that he will take offline with Bob. There was widespread support for making this a WG document. It will be ratified on the list. 4. OAM OAM Requirements for MPLS Networks http://www.ietf.org/internet-drafts/draft-nadeau-ietf-oam-requirements-01.txt Tom Nadeau, tnadeau@cisco.com As transport of diverse traffic types such as voice, frame relay, and ATM over MPLS become more common, the ability to detect, handle and diagnose control and data plane defects becomes critical. Detection and specification of how to handle the defects is important, because such defects may not only affect the fundamental operation of an MPLS network, but also because they may impact SLA commitments for end customers of that network. This draft describes requirements for user and data plane MPLS operations and management. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks, and some of these requirements have appeared in other documents, including Y.1710. This draft specifies OAM requirements for MPLS, as well as for applications of MPLS such as pseudowire voice and VPN services. At the last meeting, the authors were directed to combine their separate drafts into a single OAM requirements draft. This draft is the result of that process. Tom would like to see it accepted as a WG document. Dave Allen, the co-author, said that other Standards Develop Organizations are using this document as a stake in the group for IETF MPLS OAM requirements. The group showed support. Y.1711 and LSP-PING http://www.ietf.org/internet-drafts/draft-allan-y1711-and-lsp-ping-00.txt Dave Allen, dallan@nortelnetworks.com Y.1711 and LSP-PING are products of ITU-T SG13/Q3 and the IETF MPLS WG respectively. Each is reflective of the design philosophies of the communities of their origin. The purpose of this draft is to compare and contrast design elements of the two approaches. The conclusion drawn is that the approaches are complementary and comprehensive instrumentation of MPLS is ultimately possible using both. Dave gave an overview of Y.1711. In Nov. 2002 it was recommended for publication. It focuses on point-to-point LSPs, without penultimate hop pop (PHP). There has been ongoing new work in order to support multipoint-to-point LDP networks using PHP. It uses a "bloom filter" to encode the FEC information as a 128-bit string. The initial focus is mis-branching detection, and current proposals relate to LDP availability. He compared Y.1711 to LSP-PING, which is based on the ping/traceroute paradigm. It has good diagnostic capabilities, but is difficult to scale for proactive detection. Dave's conclusion is that the two protocols are complementary in philosophy and design. Y.1711 has utility as a detection tool, and then you use LSP-PING and traceroute from a CLI to find out what's going wrong. Dave concluded his talk by inviting people to read his Y.1711 FEC-CV tutorial, available at http://standards.nortelnetworks.com/y.1711_fec_cv_public.ppt Kireeti said that this is a good comparison of the two approaches, and the fact they are not competing, but are complementary. He would like to help with some of the wording for the LSP-PING part. He also had some comments on the definition of "transaction" in the draft - he would like to see that improved. He also pointed out that LSP-PING can be run periodically to use it as a detection mechanism. The CLI part is mostly for traceroute, rather than ping. He compared LSP-PING to the Frame Relay local management interface, which polls for status every 10 seconds. The difference between Y.1711 and running LSP-PING periodically is that you are notified of outages in seconds rather than milliseconds, but you are still notified. Tom Nadeau said that he things the scalability concerns with LSP-PING are unnecessarily harsh in the document, and that the document is tilted more towards Y.1711 than it should be. Shahram Davari said LSP-PING has become more complicated as the work on it has progressed, and that it now really isn't that much simpler than Y.1711. Detecting MPLS Data Plane Liveness http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-02.txt Kireeti Kompella, kireeti@juniper.net This document describes LSP-PING, which can be used to detect data plane failures in MPLS Label Switched Paths. There are two parts to the draft: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. Kireeti discussed the recent changes in the draft. Many clarifications were added, ECMP support was added, and the router alert option is a MUST in echo requests. There are still issues to be fixed, so there will be at least one more revision. The current text on the MPLS TTL is broken, and it will be fixed. Sections 5 and 11 will be removed. The label stack in downstream mapping with clarified. Downstream mappings still need clarification. ECMP address selection needs to be expanded upon. The timestamp will be changed to NTP format. Next steps: New revision in the next couple of weeks, and reissue the WG last call. Rahul said that there is a lot of value in LSP-PING in L3 VPNs. Kireeti said that just IP ping works fine for this application. Rahul talked about why LSP-PING is valuable in this situation. George said that a good place to discuss this issue is in the framework document (which doesn't exist) or in the requirements document. George is going to propose in the sub-IP meeting that such a document be developed in this WG. Marco Carugi proposed that existing technologies should be examined to see how it can be used in PPVPN troubleshooting. George agreed. Kireeti said that Tom Nadeau is working on how to use LSP-PING primitives with other protocols than MPLS, such as L2TPv3. There was general agreement that we need a document that discusses the total set of tools that can be used in this context. 5. MIBs Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-01.txt Tom Nadeau This draft defines a MIB module with managed objects for MPLS fast rerouting. Tom reported that the current status is that we've gained a lot of experience and the MIB has been updated based on that, and is almost ready for working group last call. The major changes were adding full support for both Facility and One-to-One backup. The conformance statement was updated to require either, but there is a common section that is mandatory. There are two implementations, and a third one is on the way. Tom is pretty confident that the MIB works and after the next revision will be ready for working group last call. Please send comments to the mailing list. Multiprotocol Label Switching (MPLS) Label-Controlled ATM and Frame-Relay Management Interface Definition http://www.ietf.org/internet-drafts/draft-nadeau-mpls-lc-if-mib-00.txt Tom Nadeau This MIB module completes the picture for the base MPLS MIBs by managing label-controlled Frame Relay and ATM MPLS interfaces (this function was left out of the base MIBs). It's been updated based upon MIB review and comments on the list. Implementations have started, and feedback is coming in on that as well. He said that this should be progressed as a separate document from the base MIBs, and be accepted as a WG document. Very few people in the room have read the draft. George asked for more people to read it and comment. Multiprotocol Label Switching (MPLS) Management Overview http://www.ietf.org/internet-drafts/draft-ietf-mpls-mgmt-overview-03.txt Tom also gave an update on the Management Overview document. The authors agree that the document is ready to progress because it reflects all pending updates to the MPLS MIBs, including the TE MIB. There will be a quick re-spin and Tom would like it go to last call at that time. George said that a last call will be issued shortly after the meeting. 6. Explicitly routed Multicast Requirements for Point-to-Multipoint capability extension http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-p2mp-requirement-00.txt Seisho Yasukawa, yasukawa.seisho@lab.ntt.co.jp This document presents a set of requirements for adding Point-to-Multipoint (P2MP) traffic engineering to MPLS. It identifies the functional and performance extensions required to realize MPLS-based Content Distribution Networks. It also identifies functional extensions required to implement CDN/VoIP/VPN service convergence networks. These extensions can be used to provide high performance and scalable broadband service network with MPLS. Yasukawa-san discussed the requirements in terms of market trends in the explosive growth of broadband subscribers, especially in Japan. Service providers much create a new broadband service infrastructure to meet this demand. It must accommodate not only IP, but current voice traffic as well. Among applications for these services include VoIP, VPNs, and content distribution, including IPTV, live distribution, video conferencing, and VPN multicast. There are a number of technical challenges to this sort of a service network. A primary challenge is that current MPLS mechanisms are not optimized for multipoint distribution due to its point-to-point nature. The requirements in the draft include the coexistence of P2P and P2MP LSP tunnels, P2MP path computation in the IGPs, P2MP LSP management based on tree-based RRO, QoS control mechanism (SE/FF) for P2MP LSPs, IPv4 and IPv6 support, interworking with IP multicast, and VPN multicast support. A number of possible broadband applications for this technology are discussed in the draft. Conclusion: P2MP MPLS is attractive technology for next generation broadband IP service convergence network. He proposed defining a P2MP MPLS signaling protocol extension based on conventional RSVP-TE. George said that this general topic is in the WG's overall charter, but there needs to be a revision to the charter before this can become a working group draft since there's no specific work task for this at this time. Philip Matthew remarked that there should be cross-pollination with the MBONE-TE folks, since that is where many of these requirements are being discussed. Extended RSVP-TE for Point-to-Multipoint LSP Tunnels http://www.ietf.org/internet-drafts/draft-yasukawa-mpls-rsvp-p2mp-01.txt Alan Kullberg, akullber@netplane.com Point-to-multipoint technology will become increasingly important with the dissemination of new, real-time applications, such as content delivery services and video conferences, which require P2MP real-time transmission capability with much more bandwidth and stricter QoS than non-real-time applications. This draft defines protocol extensions to RSVP-TE in order to establish, maintain, and teardown a P2MP LSP. These extensions allow service providers to offer services that utilize P2P and P2MP LSPs in the same service network. Alan talked about the changes in the draft from the first revision. The point is to extend RFCs 2205, which supports multicast but not TE, and 3209, which supports TE but not multicast, to support both multicast and TE. Alan asked for more feedback on the WG list, and he would like to make it a WG draft. Scott Bradner (SubIP Area Director) said that the IESG needs to approve a charter change in order to add this as a new work item for the WG. It's premature to ask the WG to make this a WG draft. 7. Header Compression George said by way of introduction that this set of drafts cannot be accepted as MPLS working group items yet until after the Sub-IP Directorate meeting later in the week, because these don't very clearly sit in any particular working group or area at this time. This work was first presented in the Adelaide meeting three years ago, and its status has been very much unclear since then. Requirements for End-to-End VoIP Header Compression http://www.ietf.org/internet-drafts/draft-ash-e2e-voip-hdr-comp-rqmts-00.txt Jerry Ash, gash@att.com VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is typically no more than 30 bytes. VoIP header compression can significantly reduce the VoIP overhead through various compression mechanisms. This is important on access links where bandwidth is scarce, and can be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). This draft gives a problem statement and requirements for end-to-end VoIP header compression, possibly over MPLS. Jerry gave an overview of the list of requirements from the draft, from providing efficient voice transport to robustness to packet loss and delay minimization. He discussed the background of the work over the last three years, and then described the two proposed solution drafts, using cRTP (RFC 2508) and end-to-end header compression. End-to-End VoIP Header Compression Using cRTP http://www.ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-01.txt This draft proposes to re-use the methods in cRTP to determine the header compression context and to use the cRTP session context ID to route a compressed packet between the ingress and egress routers. End-to-End VoIP over MPLS Header Compression http://www.ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-01.txt This draft proposes to use RSVP extensions to signal the header compression context and other control messages between the ingress and egress LSR. It provides two approaches to determining the header compression context: a) re-use the methods in cRTP to determine the context, and b) re-use the methods in George Swallow's and Lou Berger's "simple" approach to determine the context. Scott is nervous about application-dependent solutions, and wanted clarification on what "end-to-end" meant. This means from voice gateway to voice gateway, rather than true end station to end station. The main issue is finding the right home for this work - some people believe that the MPLS WG is the right place, and the authors would like to propose that this is the right place. Scott wanted to make sure that the authors were aware of the robust header compression work ongoing in the transport area. The answer is yes. In fact, the primary author of that work (Steve Casner) also thinks this work belongs in the MPLS WG. George and Scott agreed that this will be brought up in the Sub-IP Directorate meeting. 8. Draft Status Update George Swallow New RFCs RFC 3443, TTL Processing in MPLS Networks (PS) RFC 3469, Framework for MPLS-based Recovery (INF) RFC 3477, Signaling Unnumbered Links in RSVP-TE (PS) RFC 3478, Graceful Restart Mechanism for LDP (PS) RFC 3479, Fault Tolerance for LDP and CR-LDP (PS) RFC 3480, Signaling Unnumbered Links in CR-LDP (PS) RFCs (On RFC Editor's Queue) LSP Hierarchy with Generalized MPLS TE (PS) http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-hierarchy-08.txt George said this has been on the editor's queue for a long time. Scott said that it's waiting for normative references. Link Bundling in MPLS Traffic Engineering http://www.ietf.org/internet-drafts/draft-ietf-mpls-bundle-04.txt Including these two, there are now a total of 27 MPLS RFCs, so the WG has been prolific. IESG Last Call MPLS LDP Query Message Description http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-query-06.txt Fast Reroute Extensions to RSVP-TE for LSP Tunnels http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt IESG Evaluation Improving Topology Data Base Accuracy with LSP Feedback http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-05.txt This is on the IESG agenda for the next teleconference, in two weeks. Awaiting action on BGP Restart Graceful Restart Mechanism for BGP with MPLS http://www.ietf.org/internet-drafts/draft-ietf-mpls-bgp-mpls-restart-02.txt Note: Last call in IDR working group - ends 11/29 Yakov Rekhter said that this is implemented by several vendors and interoperable. It is on hold in IDR until BGP is published. Awaiting updates from Authors MTU Signaling Extensions for LDP http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-mtu-extensions-00.txt George asked Kireeti for the status. Kireeti said that further clarifications are needed, but he's been unable to contact his coauthor. He promised an update in the next month. The last call will need to be redone. Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-09.txt Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base http://www.ietf.org/internet-drafts/draft-ietf-mpls-ftn-mib-05.txt Bert Wijnen said that if we don't have the final versions of these documents by the next IETF, they will all be put in the waste bin. Tom is planning to send updated revisions soon. Nearing completion Detecting Data Plane Liveliness in MPLS http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-02.txt Other Drafts Encapsulating MPLS in IP or GRE http://www.ietf.org/internet-drafts/draft-ietf-mpls-in-ip-or-gre-00.txt This is ready for working group last call. A last call will be issued after the meeting. Applicability Statement for Restart Mechanisms for LDP http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-restart-applic-00.txt Adrian said that he's waiting on what happens with the DoD restart document, because it should be included in this document. George might rather get this out there first, since it will be an informational RFC. There will be a WG last call after the meeting. 9. Charter Discussion There will be a spin on the WG charter between now and the next meeting. If there are additions that people would like to be added to the work plan, please put them on the list. George is currently leaning towards adding an OAM framework document, multi-area/multi-AS TE, soft preemption, and the point-to-multipoint TE extensions. |
|