Last Modified: 2003-10-22
The working group is also responsible for specifying the necessary MIBs for the functionality specified in the base MPLS technology.
The first generation of the MPLS standards are largely complete, and the current WG work items are:
- procedures and protocols for multicast protocol extensions for point-to-multipoint TE, including soft-preemption
- Define requirements and mechanisms for MPLS OAM
- Define an overall OAM framework for MPLS applications
- MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG
- Determine (with CCAMP) what procedures are appropriate for evaluating proposals to extend the MPLS and GMPLS protocols, and document these
The Working Group chairs tracking of the working group documents can be viewed at http://urax.utfors.net/~loa/MPLS_WG_Drafts.htm
Done | Submit documents from original MPLS effort to IESG | |
Done | Framework for IP multicast over label-switched paths ready for advancement. | |
Done | LDP fault tolerance specification ready for advancement to Proposed Standard. | |
Done | Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards | |
Done | Specification for MPLS-specific recovery ready for advancement. | |
Done | Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards | |
Done | Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards | |
Done | Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards | |
Done | Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards | |
Done | Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards | |
Oct 03 | Advance the Label Distribution Protocol to Draft Standard | |
Oct 03 | Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard | |
Oct 03 | Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard | |
Nov 03 | Together with CCAMP complete and establish the (G)MPLS change process | |
Nov 03 | Submit specification on LSP Ping to the IESG for publication as a Proposed Standard | |
Mar 04 | Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs | |
Apr 04 | Advance MPLS Architecture and MPLS encapsulation to Draft Standard | |
Apr 04 | Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard | |
Apr 04 | Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard | |
Aug 04 | Submit an OAM Framework Document to the IESG for publication as an Informational RFC | |
Oct 04 | Advance | |
Nov 04 | Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) |
RFC | Status | Title |
---|---|---|
RFC2702 | I | Requirements for Traffic Engineering Over MPLS |
RFC3031 | PS | Multiprotocol Label Switching Architecture |
RFC3032 | PS | MPLS Label Stack Encoding |
RFC3034 | PS | Use of Label Switching on Frame Relay Networks Specification |
RFC3035 | PS | MPLS using LDP and ATM VC Switching |
RFC3036 | PS | LDP Specification |
RFC3037 | PS | LDP Applicability |
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 |
RFC3209 | PS | RSVP-TE: Extensions to RSVP for LSP Tunnels |
RFC3210 | I | Applicability Statement for 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 |
RFC3353 | I | Framework for IP Multicast in MPLS |
RFC3443 | PS | Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032) |
RFC3477 | PS | Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) |
RFC3469 | I | Framework for MPLS-based Recovery |
RFC3478 | PS | Graceful Restart Mechanism for Label Distribution Protocol |
RFC3479 | PS | Fault Tolerance for the Label Distribution Protocol (LDP) |
RFC3480 | PS | Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol) |
RFC3612 | I | Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) |
MPLS Working Group WG Chairs: George Swallow <swallow@cisco.com>, Loa Andersson <loa@pi.se> Tom Nadeau took the minutes - Thanks Tom! NOTE: [NNG] means that the speakers name was not given at the mike. 1. Agenda Bashing/Update Loa -- MPLS has been rechartered within routing area. MIB modules/management overview have been sent to the IESG. 2. Encoding of Attributes for LSP Establishment Using RSVP-TE <draft-farrel-mpls-rsvpte-attributes-00.txt> Adrian Farrel Adrian -- Asked to make this a WG document? George -- Room support? (no hands) non-support (no hands) Continue discussion on the list. 3. RSVP Graceful Restart Extension <draft-rahman-rsvp-restart-extensions-00.txt> Reshad Rahman Adrian Farrel -- Should this be in CCAMP? George -- They didn't ask me, but I suggest it goes in CCAMP. The only rationale for MPLS might be that there is slightly lower work load here. Rahul -- Why isn't it enough to just recover. Why do we need this? Reshad -- If a node preforms ERO expansion prior to the restart, it may not have sufficient information to construct the some ERO expansion. After a bit of discussion and polling the room, it would appear that there is a fair amount of interest and that the work belongs in CCAMP. 4. TTL-Based Security Option for LDP Hello Message <draft-chen-ldp-ttl-00.txt> Albert Tian Alex Zinin -- You cannot negotiate security messages with an insecure mechanism. There are DOS attack potentials. Albert -- The multicast addresses are harder to spoof. Alex -- I understand how the TTL hack works. But the fact that you are trying to negotiate the usage using insecure messages is the problem. Albert -- "secure" is relative here. Alex -- Take to list. George -- are there any SPs that feel there is a need for this? (silence) 5. LDP signaled LSPs for external prefixes <draft-minei-mpls-ldp-external-00.txt> Ina Minei Eric -- I see no advantage to do this. Dangerous to distribute routing information w/ non-routing protocols. Yakov -- We have seen this movie before. There are no issues with overloading LDP. Luca -- You are adding more state to your core routers to support this. Why not use iBGP to do this? George -- Asked a question about label withdraw times in the event of a failue. Won't that slow convergence? Alex -- If you have more than one originator injecting more than one FEC, how do you break the tie? Ina -- You consider this and do something smarter at the tail end. Alex -- External prefixes are injected into LDP. Have you compared the overhead of this versus that of using IGPs? Ina -- don't see why this is an issue. Alex -- This assumes external prefixes are injected into an IGP. How much state will routers have to maintain versus in the normal ibgp case. Ina -- If you are trying to compare an IGP to an LDP solution. Luca -- Clarification. In an IBGP you don't have to run this anywhere but in the edge routers (BGP free core). There is less state in the core. Using your solution you add more state to the core. Ina -- but it has more danger of misconfiguring your distribution. Vach -- Best for Luca to resubmit his BGP short-cuts draft which would fix this problem. If I wanted such a solution I would rather do this than the current one. George -- Continue this on the list. 6. Requirements for Point to Multipoint extension to RSVP-TE <draft-yasukawa-mpls-p2mp-requirement-00.txt> Seisho Yasukawa Loa -- Comments? Yiqun Cai -- ID is taqlking about requirement of P2MP lsps (TE), but also describes an extension to RSVP-TE. This seems that the WG has already decided to extend RSVP_TE. The better way would be to split them, and address both requirements separately. Second, this talks about mcast deployment in a service provider environment. I think this needs to be presented in the MWG and discussed. Dave Meyer -- I had discussed this with George, but ran out of agenda time. This should be discussedin MWG. James Miles -- Dmitri's earlier point talked about whether this was a requirements document? Are we going to extend this? What is the scope of the document? Seems that the next step is that providers need to run RSVP-Te to the edge. Loa -- When we wrote this it was to describe how p2mp TE LSPs worked. Loa -- Could I see the support in the room to make this a WG document. A fiar number. Oppositoion. A few. Need to confirm on the list that there is good support w/ a few opposing. People that were opposed should speak at the Mike. Toerless -- I don't understand how this framework is supposed to work. The document seems to jump over one architectural element (p2mp). Yiqun -- The document tries to address mcast vpn and other items. We need to discuss whether or not this best solves this problem usiung p2mp RSVP-TE LSPs or something else. George -- I would tend to agree with that last comment. 7. Extended RSVP-TE for Point-to-Multipoint LSP Tunnels <draft-yasukawa-mpls-rsvp-p2mp-03.txt> Seisho Yasukawa/Allan Killberg [Update on state of draft] George -- Can't do anything on this on the next draft until we get the requirments accepted. 8. IP Multicast With PIM-SM Over a MPLS Traffic Engineered Core <draft-raggarwa-pim-sm-mpls-te-00.txt> Rahul Aggarawal George -- When the RPE gets an indication of the interface, how does that count? Rahul -- The SPE sends a joint ack message. George -- what goes into it? Rahul -- it contains a set of messages including the PTMP ids. George --- you are keeping labels at the last hop to keep context? Rahul -- this is just the session object. George -- If you have more than one tunnel, you would have to turn PHP off. [NNG] -- Are the labels interface or global space? Rahul -- doesn't matter. [NNG] -- The way you use labels to distinguish label states. Does this support PIMSM, but you did not describe how these are forwarded. Rahul -- Sure, I can add that. George -- Please show up at 1 to continue discussion (PIM?) 9. Requirements for multicast service using a group label over MPLS <draft-choi-mpls-grouplabel-requirement-01.txt> Min Suk Sung George -- Discussion on the draft... Andy Malis -- When we sections 4.5, this is not a requirements draft; it contains protocol specifications. There are requirements in section 4.3, but these assume a mechanism (group label) and just reverse engineer that. Really doesn't talk about requirements. George -- Other point that Loa made is that originally when we started MPLS, we made an architectural decision to not have globally unique labels. We would need to change this to accomodate this draft. Min -- We tried to consider where is the relevant location of the labels. George -- Continue on list. 10. MPLS over Layer 2 Tunneling Protocol (Version 3) <draft-townsley-l2tpv3-mpls-00.txt> Mark Townsley Yakov -- One significant subtle distinction between GRE and L2TP. Neither IP or GRE require signaling, but L2TP requires signaling. Don't combine into two documents. Loa -- I rule that out betcause we have IP/GRE document in WG last call. Yakov -- To have a multi-vendor interop implementation requires specification of both signaling and protocol in standards track at same time. Mark -- Both are specified in two documents in IDR. Yakov -- They are not WG documents. If you want to provide BGP as a signaling mechanism for L2TPvp3. Mark -- There is a section on this. Please read the document. Yakov -- In this case, 2547 is just an example of p2mp signaling (so is VPLS). When you do this, so should signaling be done in BGP? Mark -- Depends on what your VPLS network is using for signling. In general when you want to reach a PE over IP and you say "this is the IP addr of my PE" and you use BGP or wahthave you to signal this, even w/o L2TPv3 encap, when you advertise this normally -- you imply use this PE IP address w/ this protocol ID. I am also saying to also use the cookie in addition to these things. Yakov -- Need another document ot explain that BGP can be used for signaling. On your last point: talk about security that L2TP provides. Before this is a WG document, the security team should review this to make sure that the statements are ok. Eric -- I would like a very small document that explained the encap. Put cookie stuff into security considerations. I disagree w/ Yakov's statement. The cookie value is different depending on how it is signaled. We don't want to start an L2TP signaling paradigm. Yakov -- this document doesn't have to contain signaling. doesn't make sense to progress encap w/ signaling document. Eric -- Signaling is application dependent. George -- Get a sense of the room, not for this draft, but for MPLS/L2TP as an encap type. How many think we need to do this. We have several opposed and several in favor. Continue on list. 11. A Framework for MPLS Data Plane OAM <draft-allan-mpls-oam-frmwk-05.txt> Don Fedyk Eric Rosen -- This is taking MPLS and trying to make it ATM. I recommend starting over. Tom -- I agree w/ Eric. Lets start over. George -- I don't think that we need to throw away everything, but we should be focusing on describing a framework within which we can define tools that meet operational requirements. Loa -- This is why I wanted Dave/Tom to do the edits. Jerry -- I think the document covers the entire solution space. Craig White -- I would like to underscore what the chairs just said. I am not particularly interested in where the technology comes from, but more of what does it do for me. I feel like we are going to end up with hacks to address requirements, but lets document this somewhere. Loa will work to form a design team to create a combined draft between this and the nadeau draft. 12. Detecting MPLS Data Plane Failures <draft-ietf-mpls-lsp-ping-04.txt> Kireeti Kompella / George Swallow Kireeti -- Reviewed latest changes. Draft is nearly complete. A new version will be posted resolving the last few issues. Hope to go to last call prior to Seoul 13. LSR Self Test <draft-ietf-mpls-lsr-self-test-01.txt> George Swallow George -- The draft is mostly complete. A few issues are hanging contigent on the lsp ping draft. More discussion on list. 14. BFD For MPLS LSPs <draft-raggarwa-mpls-bfd-00.txt> Rahul Aggarawal Rahul -- Since BFD is light weight, you can turn on fault-detection on a larger number of LSPs. Subsecond fault detection can be possible (i.e.: bypass LSPs). Alex -- Did you think through the convergence issues w/ subsecond detection and IGP level second-level detection? How are you going to react to the failures found by BFD. Rahul -- The answer is the same as with LSP ping. The operator can take the same action. Alex -- We need to think throught the case where IGPs are notified. Yakov -- One possible scenario. When bypass tunnels go away, you can use the other one. [NNG] -- Since you are doing this over multiple hops. How do you handle congestion in the network and variable delays? George -- BFD allows you to adjust your timers. Lets continue on list. 15. A Supplementary History Module for the MPLS LDP-MIB <draft-lai-mpls-ldp-hist-mib-00.txt> Wai Sum Lai Tom -- There have been scalability and other technical concerns raised on the list. I suggest that we hear from other SPs. Waisum -- Can you give an example? Tom -- PE with 800 directed LDP sessions. That seems to be a lot of memory/processing to keep track of this, especially over a long period of time. Waisum -- But we are only adding 5 counters. George -- Well, there is more to it than just 5 counters. You are asking us to hold informations forever on expired sessions. The long term implications for memory and CPU need to be considered. Craig White -- I would rather count packets/bytes than fwd packets. However, I don't want to eat all of the memory to do this. I don't want to have fewer VRFs on a PE to keep track of this stuff, for example. Bert -- If you want to look at the scalability of keeping the information needs to be seriously examined. George -- The sense of the room is that something along these lines is useful, but we need to refine the requirements on the list. 16. Hybrid data forwarding for Economy Class Services in MPLS <draft-hpark-hybrid-forwarding-00.txt> Hyeon Park George - We're out of time - discuss on the list. Meeting |