Last Modifield: 05/20/2002
The initial goals of the working group have been largely completed. In particular, it has produced a number of RFCs (see list below) that define the base Label Distribution Protocol (LDP), the basic MPLS architecture and encapsulations, and definitions for how MPLS runs over ATM and Frame Relay links.
The current goals of the working group are:
1. Complete outstanding items from the original MPLS effort:
(6/12) Applicability Statement for Extensions to RSVP for LSP-Tunnels (8/08) Applicability Statement for CR-LDP (6/12) LDP State Machine
(10/19/99) MPLS Loop Prevention Mechanism
(8/08) Constraint-Based LSP Setup using LDP (2/07) Carrying Label Information in BGP-4 (8/29) Extensions to RSVP for LSP Tunnels (8/29) MPLS Support of Differentiated Services (6/27) LSP Modification Using CR-LDP (9/01) Definitions of Managed Objects for LDP (8/29) MPLS Label Switch Router Management Information Base
2. Advance the Proposed Standards developed by the MPLS WG to Draft Standard. This includes the LDP, CR-LDP, and RSVP-TE signaling specifications as well as the encapsulations.
3. Specify appropriate extensions to LDP and RSVP for authentication of LSP originators.
4. Complete work on the MPLS-TE MIB.
5. Specify improved fault tolerance mechanisms for LDP
6. Specify MPLS-specific recovery mechanisms to allow one label-switched path to be used as backup for a set of other label-switched paths, including cases which permit local repair. What constitutes the necessary set of MPLS-specific recovery mechanism should be ascertained through cooperation with the CCAMP and TE working groups.
7. Document additional MPLS encapsulations to allow the operation of label-switched paths over additional lower-layer technologies, such as time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming fiber to outgoing fiber).
8. Complete work in progress for specifying the framework for IP multicast over label switched paths.
|Done||Submit documents from original MPLS effort to IESG|
|JAN 01||Shepherd completed MPLS specifications through IESG review and RFC editor processing|
|FEB 01||MPLS-TE MIB ready for advancement to Proposed Standard|
|MAR 01||Framework for IP multicast over label-switched paths ready for advancement.|
|JUN 01||LDP fault tolerance specification ready for advancement to Proposed Standard.|
|AUG 01||Specification for MPLS-specific recovery ready for advancement.|
|NOV 01||Base MPLS Proposed Standard RFCs ready for advancement to Draft Standard.|
|DEC 01||LDP end-to-end LSP authentication ready for advancement to Proposed Standard.|
|RFC2702||I||Requirements for Traffic Engineering Over MPLS|
|RFC3034||PS||Use of Label Switching on Frame Relay Networks Specification|
|RFC3035||PS||MPLS using LDP and ATM VC Switching|
|RFC3031||PS||Multiprotocol Label Switching Architecture|
|RFC3032||PS||MPLS Label Stack Encoding|
|RFC3038||PS||VCID Notification over ATM link for LDP|
|RFC3033||PS||The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol|
|RFC3063||E||MPLS Loop Prevention Mechanism|
|RFC3107||PS||Carrying Label Information in BGP-4|
|RFC3210||I||Applicability Statement for Extensions to RSVP for LSP-Tunnels|
|RFC3209||PS||RSVP-TE: Extensions to RSVP for LSP Tunnels|
|RFC3212||PS||Constraint-Based LSP Setup using LDP|
|RFC3213||I||Applicability Statement for CR-LDP|
|RFC3214||PS||LSP Modification Using CR-LDP|
|RFC3215||I||LDP State Machine|
|RFC3270||PS||MPLS Support of Differentiated Services|
MPLS Working Group minutes ======================================== ============================== Chairs: George Swallow <firstname.lastname@example.org>, Loa Andersson <email@example.com> 1. Agenda bashing 2. Fast Reroute 2a. Fast Reroute Extensions to RSVP-TE for LSP Tunnels draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt Alia Atlas This document defines extensions to and describes the use of RSVP-TE to establish backup LSP tunnels for local repair of LSP tunnels. It is a "consensus" draft that resulted from the combination of multiple prior drafts. Since the -00 version the draft was reorganized to describe LER/LSR behavior for each role in fast-reroute. Details were combined which were the same, regardless of technique used (one-to-one or facility backup) and removed redundancy. Behavior was clarified to facilitate interoperability between techniques. A number of technical modifications were made as well (see the presentation in the proceedings). The authors believe the draft is ready for working group last call. Multiple implementations currently exist. The have resolved the issues found in interoperability testing at Isocore and elsewhere. There was consensus in the room, and last call will be issued following the IETF meeting. 2b. Sven Van den Bosch Backup Record Route for Fast Reroute Techniques in RSVP-TE draft-decnodder-mpls-ero-rro-fastreroute-02.txt MPLS fast reroute is considered as a solution to protect traffic against link and node failures by re-directing the traffic locally to a backup LSP. A backup LSP can be either a detour LSP or a bypass tunnel. This document describes two methods to optimize the routing of detour LSPs such that they merge faster, a distributed method and a centralized method. The distributed method uses the Backup Record Route Object (BRRO) and the centralized method uses the Backup Explicit Route Object (BERO). There were several issues raised about the draft that were addressed in this revision. The first was support of distributed detour computation by allowing BERO to use loose hops, and the second was regarding the object length - messages could become very long. The BERO may now be "compressed" by only specifying relevant nodes. The third issue was operation with inter-area LSPs, and that was addressed with a change to the BRRO procedures. The next steps are implementation, future investigation of performance gain and label state for different network topologies. Further comments are invited on the list. They requested that this become a working group document. Scott Bradner, SUB-IP Area Director, said that any call for a working group draft in this WG must mention what in the charter it is addressing. The response is that it enhances the fast reroute extensions, which is in the charter. There was little interest in this draft expressed in the room; it will be further discussed on the list. 2c. Distinguishing link and node failures using RSVP Hellos draft-vasseur-mpls-linknode-failure-00.txt Jean-Phillipe Vasseur The aim of this draft is to provide a method to distinguish a link failure from a node failure using RSVP hello extensions. The ability to make this distinction is important when re-using link bandwidth to provide multiple protection paths (assuming that only one failure will occur at a time), which results in significant bandwidth savings. See the presentation in the proceedings for an animated tutorial on the draft's mechanisms. It also fits in the charter as a part of the fast reroute work item. The draft was requested to be accepted as a working group document. George asked if there are new procedures, or if this would be an informational draft. The answer is that it would be an information draft. Lou Berger asked how this is related to the work in GMPLS to detect node and link failures - it seems that this duplicates that work. JP said that they are complementary - you can run one or the other. It's an alternative. Scott said that given that we already have something that does this, there should be only one. Scott also said that complicated technology proposals shouldn't be made in a short presentation - people should read the draft and discuss it on the list. He would like to see discussion on the list first. Yakov Rekhter said that hello mechanisms have been overloaded to detect the liveness of both control and data planes, and he is concerned by such overloading - he feels that they should be unbundled into separate mechanisms. There was a question on how fast link or node failure can be detected. There's no way to do it faster than a round trip time, so you can't always guarantee 50 ms or any other particular time. Further discussion will be taken to the list. 3. Encapsulation Encapsulating MPLS in IP or GRE draft-rosen-mpls-in-ip-or-gre-00.txt Eric Rosen In various MPLS applications, label stacks with multiple entries are used. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks which do not have MPLS enabled in their core routers. This draft specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE. Each of these is applicable in some circumstances. This allows two LSRs to be "adjacent" when they are separated by an MPLS-less IP backbone. It servers a clear need for network transitions. Eric noted that the WG charter allows work in "MPLS-in-foo", so it fits in the charter. The issues are the IP encapsulation does require a "scarce" protocol number, and the GRE encapsulation doesn't use the key field or the checksum. For both, there are also MTU, TTL, QoS, and DSCP issues that are discussed. There has been support expressed on the list, and no objections. Eric proposed that it be moved forward for Proposed Standard. Scott complemented him on his presentation and said it should go ahead. We had strong consensus to make it a WG item. 4. OAM 4a. A Framework for MPLS User Plane OAM draft-allan-mpls-oam-frmwk-03.txt Dave Allan This draft discusses many of the issues associated with user plane OAM for MPLS. The goal is to provide tools to perform "in service" maintenance of LSPs. Included in this discussion is some of the implications of the MPLS architecture on the ability to support fault, diagnostic and performance management OAM applications, potential solutions for distinguishing user plane OAM, and a summary of what the authors believe can be achieved in addressing all aspects of the MPLS architecture. In his presentation, he replaced the words "user plane" with "data plane". The motivations for the draft were to explore all issues associated with instrumenting MPLS LSPs. The document outcome is to see what can be done in any given MPLS "level", and what can be done by leveraging the entire architecture. Topics covered include mechanisms for distinguishing OAM flows, return path, multi-provider issues, and OAM applications. The changes since the last version are a new section on OAM probe state association, new section on the use of hierarchy to simplify OAM, enhanced security section, and minor editorial changes. The current state of the document is that the authors feel it is largely complete. They proposed that it be adopted as a WG draft - it contains common MPLS WG input into both WG and ITU-T SG 13 efforts, and is a useful survey of the space. It would be even better with additional WG input, then it can be put to bed. Tom Nadeau said that it's a pretty reasonable document. 4b. IP-based Tool Requirements for MPLS Networks draft-nadeau-ip-basedtool-requirements-00.txt Tom Nadeau This memo describes requirements for operations and management based on IP-based tools for MPLS networks. The document scope is requirements for IP-based tools for fault detection, diagnostics, statistic reporting, and security management. The motivation is that providers have been coming to the authors with OAM requirements that differed from those that were available from both the IETF and the ITU-T, and there was a concern that current requirements did not reflect real operational environments. There were also disparately located requirements for MPLS-related OAM scattered about, and they felt it would be best to put these together into one place. The base message from providers is that they wanted an evolutionary approach rather than a revolutionary approach that might have new hardware requirements and require fork-lift upgrades in their networks (sensitive to both OPEX and CAPEX). Since they published the draft, they have received comments that will result in revisions, and they would like to move the requirements from Dave Allan's framework document, and make it a WG document. Tom asked Scott if he agreed that the requirements be combined in one place, and Scott agreed that sounded like a good idea. Jerry Ash said that some service providers have provided requirements against MPLS MIBs, and should those requirements also be applied to OAM? Tom said that some of the requirements were specific to MIB changes, but some of the others were overall requirements that do apply here as well. Dimitri Papadimitriou would like a discussion of how data plane OAM interacts with control plane mechanisms like fast reroute. Dave Allan supports getting all of the requirements in one place. 4c. Detecting MPLS Data Plane Liveness draft-ietf-mpls-lsp-ping-01.txt Kireeti Kompella This document describes a simple and efficient mechanism that can be used to detect data plane failures in MPLS LSPs. There are two parts to this document: 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. Changes from the last revision were the packet format was changed and a version number field was added, a "Don't Reply" reply mode was added, the reply flags were removed, and return codes were extended. RSVP session formats were modified, VPN IPv4/v6 formats were defined, L2 VPN endpoint and L2 circuits were defined, downstream mapping format was changed, and PAD and Error Code TLVs were introduced. The next step is that the base document is done for base MPLS tunnels as well as applications such as VPNs, and it is time to get it out and go to WG last call. Tom Nadeau had two questions - there's no reference in the document for the encapsulation type, and the document needs clarified on what is required to be implemented and what is optional - what's the base implementation? Kireeti said that the draft already does that, and it will be improved. Shahram Davari asked if there were requirements for this work, and Kireeti said they were implied in the draft, and there is a real problem in that we need to know if our MPLS networks are working. Tom Nadeau said the requirements draft he discussed previously also covers this draft. Kireeti also said that if something is missing, we can add it later. There was consensus for last call, and it will be issued following the meeting. George said that for the framework and requirements, he would not want them to become WG documents yet; rather, the authors should get together and see what information should go into each document and produce new higher quality revisions that can then become WG drafts. We agreed that will be the plan. 5. Load Balancing Guidelines for MPLS Load Balancing draft-allan-mpls-loadbal-00.txt Dave Allan RFC 3031 permits MPLS load balancing while making no specific representations as to implementation requirements. This has subsequently become an issue with respect to the reliability of path test mechanisms. Load balancing algorithms may separate path test probes from the path of interest. This draft proposes guidelines for implementation of load balancing such that path test mechanisms are not impacted. The motivation is that it is desirable that when multiple NHLFEs exist, that both the user traffic and any OAM probes follow the same path through the network. The goal is consistency in monitoring and fault isolation. The draft requires that for next hop selection, you not use reserved labels, don't include the "S" bit, and don't include TTL. The proposal is to obtain the sense of the WG that some solution is required, and to adopt the draft as a WG starting point. Kireeti said that this violates the principal of reproductive freedom what's in my body is mine, and don't tell me what to do with it. This is similar to allowing implementations to do what they want for SPF. You can tell me what to put on the wire, but not how to implement it in my box. Dave agreed that what's in your box is your business, but the externally observable behavior of your box IS the issue here and is important to service providers. Kireeti said that this should be information if it is published at all, but certainly not standards track or a BCP. Dave said that anything that bounds detection time of problems in the network is good, and carriers want bounded detection times. Kireeti kept arguing that this is a paradigm change to the forwarding path. We have ECMP and it works, and it's up to each vendor to decide how they implement it. Dave said that is going to be important for PWE3 as well, since you need to bound the detection time for failures on pseudo-wires as well as for the transport LSPs. Kireeti also doesn't want any limits on label depth that were discussed in the draft. Not looking at the S bit is also bogus. Eric Rosen agrees with Kireeti's comments. While its a good OAM requirement that OAM packets need to follow the data packets, he doesn't agree with the way the document tries to do it by imposing the restrictions it does. Alia Atlas also agreed - this is a revolutionary approach rather than evolutionary approach due to the required changes in the forwarding path. It's bad to adversely affect ECMP in order to support OAM. In some cases, you don't know that length of the label stack. Dave said that the only reason he discussed label stack depth in the draft was an attempt to keep it simple. He also wanted measurement consistency on a per-node basis rather than a per-LSP basis. Shahram Davari said that this probably breaks MPLS ping. Kireeti asked the ADs at what point do we stop intruding into boxes? This came up not just here, but also in the routing area discussion on SPF implementation. He suggested that this just be published as an information RFC saying "this is a good idea". Scott said that this is really an IAB/IESG plenary discussion rather than something that should be discussed here. If the WG believes that something is wrong with the way something was done in the boxes, and the WG consists of box builders, than that's the consensus. Be he hasn't seen a consensus at the microphone for this point. There was considerable opposition to this being a WG document. Further comments will be taken to the list. 6. Bi-directional LSPs Bi-directional LSPs for Classical MPLS draft-dube-bidirectional-lsp-00.txt Rohit Dube This draft proposes extensions to support bi-directional LSPs for classical MPLS. Specifically, RSVP-TE is extended with objects similar to those in GMPLS to allow establishment of bi-directional LSPs. It's a pretty simple protocol extension to make this work. Kireeti disagrees that GMPLS is different from MPLS - it is a superset of MPLS, and bidirectional as defined in GMPLS works in MPLS as well, so this draft is unnecessary. Kireeti and Rohit discussed some the differences between the two approaches, but Kireeti felt that the GMPLS approach is sufficient for the requirements. Rahul Aggarwal had a second comment along the same lines - just use what was already done for GMPLS. George added that while it's simple to do an extension for bidirectional, it's harder to make sure it works for fast reroute and make-before-break. So he wants some though on how these other mechanisms would be supported for bidirectional as well as just the data flow. Rohit agreed that these could require some additional work. Discussion will be continued on the list. 7. MPLS Security Analysis of the Security of the MPLS Architecture draft-behringer-mpls-security-03.txt Michel Behringer This document analyses the security of the BGP/MPLS VPN architecture as described in RFC 2547, especially in comparison with other VPN technologies such as ATM and Frame Relay. The document consists of two main parts: the requirements for security in VPN services are defined, and MPLS is examined with respect to these requirements. The analysis shows that MPLS VPN networks can be equally secured as traditional layer-2 VPN networks such as ATM and Frame Relay. This was originally written as a white paper for customer consumption, and he decided to also make it available as an internet draft. The question being answered by the draft is can you operate an MPLS backbone in a secure manner. What secure means here is address space and routing separation, hiding the MPLS core structure, resistance to attacks, and impossibility of VPN spoofing. This allows MPLS to be a replacement for L2 services, like ATM and Frame Relay. It does NOT address the security of the operations of RFC 2547, such as misconfiguring VPNs and security of the implementations due to bugs. He was concentrating on the security of the architecture, but it's still possible to shoot yourself in the foot. It does not yet include Inter-AS operations. It's pretty stable. There is one open issue - during rerouting, one label too many might get popped for a short time. He's still researching this to see if it's a bug in the implementation, or a bug in the protocol. Questions: Is this useful? What is missing? Does it fit in this WG? His goal is to publish it as an informational RFC. Eric Rosen said that this addresses the issue as to whether a VPN implementation fits the requirements, and he feels it belongs in the PPVPN working group. Michael asked if this document could become a security section for RFC 2547? Eric wasn't sure if he would take that approach, but in any event, he still thinks it should be in the PPVPN WG. Dave McDysan said that this draft was used to help with the PPVPN requirements document, and he also would like to see it in the PPVPN WG - it's already been referenced. Michael said that he's already presented it there, and the answer was no at that time. Dave said that it's already been included in the PPVPN requirements. Loa said that a question heard from customers is - Is the MPLS architecture, and VPNs on top of it, secure enough to replace L2 VPN networks? Loa feels that this work is important and needed. Yakov said that this document would be a great replacement for the security section in rfc2547bis - that security section should just be a pointer to this document. Ananth Nagarajan said that this needs to be expended to cover the carriers of carriers case. Marco Carugi (PPVPN co-chair) agreed with Yakov's comments, and that it should be generalized into a complete security framework for all of the PPVPNs technologies, not just rfc2547. Scott agreed with Marco. But George feels that when it comes to security, it's better to be specific than general. George said that discussion of this document should be moved to the PPVPN email list. 8. Multicast Extended RSVP-TE for Multicast LSP Tunnels draft-yasukawa-mpls-rsvp-multicast-01.txt Allan Kullberg This document specifies extensions and mechanisms to RSVP-TE in order to support MPLS point-to-multipoint LSPs. The changes from -01 were: - All tree modifications via changed TERO - Always from sender node via Path message - Avoids race conditions - Supports Graft/Prune - Leaf Initiated Join/Leave - Leaf node sends Join/Leave message directly to sender node - Sender node sends changed TERO - Looks like single node Graft/Prune - Sequence number in TERO hop (Saves comparing entire TERO) - Terminating node flag in TERO hop - Allows node to be branch and leaf - MulticastNotify message for error indications - Error handling description The future directions are: - Add sequence # to TRRO (Saves compare of entire TRRO) - GMPLS Notify instead of McastNotify? (Reuse is good) Allan requested that this become a WG draft. Rahul said that there is a draft that describes how to do multicast in tunnels using PIM, and seems less complex. Allan said that this draft doesn't require the use of a multicast routing protocol. George asked what's the driving need that this is trying to satisfy? Allan said that this to support multicast without requiring the use of an IP multicast address as the destination. Discussion will continue on the list. 9. LDP FT/Restart draft-farrel-mpls-ldp-restart-applic-01.txt Adrian Farrell There are two drafts for recovery of LDP sessions after failures, draft-ietf-mpls-ldp-ft-06.txt and draft-ietf-mpls-ldp-restart-05.txt. These drafts have completed WG last call and have moved forward to IESG review. There is a need for information indicating which draft should be implemented and when. In addition, draft-ietf-mpls-ldp-ft also has options. Implementation choices are complex, so this draft was written to give guidance on when it is advisable to implement a LDP restart mechanism and which approach might be more suitable. The draft has expanded to contain additional background information. The draft is stable, but has a few updates still needed - in particular, Yakov had some comments that Adrian is working on. Adrian requested that this become a WG document with a view to moving forward as an informational draft. George spoke in favor of the draft. But it was a late addition to the agenda, and people need more time to read it. So people are encouraged to read it and discuss it on the list. 10. Workgroup Status 10a. LDP to Draft Standard status Loa Andersson Loa presented the current results from the LDP implementation survey. The full presentation appears in the proceedings. Some highlights follow: 12 Responses - 10 Public, 2 Anonymous. - 10 Product; 2 Beta - 11 On sale; 1 Other - Implementation Approach 7 From spec; 4 Purchased/free code + additions; 1 Purchased code. Highlights - Every item in survey questionnaire implemented by at least 2 respondents. - Each of the 8 Label Distribution Modes implemented and tested; Legend T Tested against another independent implementation I Implemented by not tested against another independent implementation N Not implemented. T I N T I N ======= ======= 8 2 2 DU, Ord Cntl, Lib Reten 6 1 5 DU, Ord Cntl, Con Reten 7 1 4 DU, Ind Cntl, Lib Reten 6 0 6 DU, Ind Cntl, Con Reten 7 1 4 DoD Ord Cntl, Cons Reten 4 3 5 DoD, Ord Cntl, Lib Reten 6 1 5 DoD, Ind Cntl, Cons Reten 4 2 6 DoD, Ind, Cntl, Lib Reten - Platform and Interface Label Spaces both widely supported. T I N T I N ======= ======= 12 0 0 Per Platform 7 1 4 Per Interface - Basic and Targeted Sessions both widely supported. T I N T I N ======= ======= 12 0 0 Basic/Directly Connected 11 1 0 Targeted - TCP MD5 Option not widely implemented. T I N ======= 3 1 8 - Interface Types T I N ======= 12 0 0 Packet 6 2 4 ATM 2 3 7 Frame Relay This will continue to be updated as responses come in, and a draft will be written summarizing how LDP is being used and if anything should be removed in order for it to become a Draft Standard. 10b. MPLS MIB review meeting report Joan Cucchiara & Tom Nadeau There was an open MPLS MIB meeting held this past Saturday in Atlanta. The agenda was: - Review of Final Changes for MIBs requested by MIB Doctors - Review Interaction between MIBs: MPLS-TC, MPLS-LSR, MPLS-LDP, MPLS-TE, MPLS-FTN, TE-TE, LINK-BUNDLING, MPLS MIB Overview draft - FINAL ACTION Items for Authors Complete detail of changes are recorded at the IETF ID Tracker Site: https://datatracker.ietf.org/public/pidtracker.cgi - Many minor changes DESCRIPTION clauses Clarification of examples Editorial in nature (split REFS, IPR statement) - Very few significant changes See the presentation in the proceedings for the complete list of changes to each of the MIBs. Next steps: - Goal is to update MIBs and Overview by 12/15 (MIB co-authors) - Depends on - IESG Comments on latest MIBs - Resolution of issues on email list - Additional Working Group "LAST, LAST, LAST Call" at that time? Tom asked for clarification from the chairs on whether we need another WG last call. Loa said yes, but it would only be on the changes since the last WG last call, and on the MIBs as a group. So all six MIBs need to be ready at the same time. The overview document will be last called at the same time. If there are any additional comments that people have, please make them this week so that the MIBs can be updated by the above deadline. Loa thanked everyone that participated in the MIB review, and the MIB authors, for all of their hard work in getting the MIBs done. 10c. Status of MPLS WG Internet Drafts George Swallow George presented the status of all MPLS wg documents. The presentation is included in the proceedings. Among the drafts awaiting updates from authors was: MTU Signalling Extensions for LDP <draft-ietf-mpls-ldp-mtu-extensions-00.txt> Kireeti said that the draft needs to be redone based on received comments. There should be a new version by the second week of December. George also note that it's time to move forward on draft status for the architecture, encapsulation, ATM VC switching, and RSVP-TE RFCs. Loa said that the CR-LDP decision was documented in an individual draft, was reviewed by the IESG (which returned comments), and there was a general comment on grammar. Scott will be reviewing it for grammar, after which it will be sent to the RFC Editor.