Last Modified: 2004-09-20
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 | |
Done | Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard | |
Done | 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 | |
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 | |
Jul 04 | Submit specification on LSP Ping to the IESG for publication as a Proposed Standard | |
Jul 04 | Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) | |
Aug 04 | Submit an OAM Framework Document to the IESG for publication as an Informational RFC | |
Oct 04 | Advance 'Extension to RSVP for LSP Tunnels' to Draft Standard | |
Nov 04 | Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs | |
Nov 04 | Submit a BCP on MPLS load sharing to the IESG |
RFC | Status | Title |
---|---|---|
RFC2702 | I | Requirements for Traffic Engineering Over MPLS |
RFC3031 | PS | Multiprotocol Label Switching Architecture |
RFC3032 | PS | MPLS Label Stack Encoding |
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 |
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 |
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) |
RFC3469 | I | Framework for MPLS-based Recovery |
RFC3477 | PS | Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) |
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) |
RFC3811 | Standard | Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management |
RFC3812 | Standard | Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base |
RFC3813 | Standard | Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base |
RFC3814 | Standard | Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information Base |
RFC3815 | Standard | Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP) |
MPLS WG Agenda for the Washington Meeting
November 2004, 9.00 - 11.30 1. Agenda bashing Agenda accepted as proposed. Scribes: Markus and Dimitri 2. Working group status (20 min) - liaison from MPLS & Frame Relay Alliance on RFC 3036 The MPLS working group has recieved a comunication from the MPLS & Frame Relay Alliance (MFA) on RFC 3036 as it is being progressed to draft standard. It was pointed out that IETF and/or its working groups do not enter liaision relationships with any other orgtanizations than Standards Development organizations. However, this will not stop us from having an open and trustful communication with indurial forums like MFA. The technical issue brought up in the communication will be discussed in this meeting, and based on that discussion a response to MFA will be sent. Note: This response were sent November 11 and will be found at http://www.cell-relay.com/mhonarc/mpls/current/msg00028.html - new RFCs / IESG reviews two drafts "draft-ietf-mpls-explicit-null-01.txt" and draft-ietf-mpls-rsvpte-attributes-04.txt have been in AD evaluation a long time, don't know why? Alex: they will be IETF last called pretty soon A number of docs has been moved to rfc ed queue: congrats to authors/editors. Since the dependencies on other documents are not that heavy they will go out as RFC soon The mpls bundle draft (draft-ietf-mpls-bundle-04) has been pulled from rfc queue, and taken back to wg for a (hopefully) quick respin, the reasons for this were discussed by Zafar at this meeting. A problem here is that several other documents depends on the bundle draft. - wg drafts <draft-ietf-mpls-lsr-self-test-03.txt> This draft is stuck waiting for the lsp-ping draft to progress <draft-raggarwa-mpls-rsvp-te-p2mp-01.txt> <draft-allan-nadeau-mpls-oam-frmwk-00.txt> These two draft did miss the the cut-off date to be published as working group documents, the working groups chairs have sent a mail to the mailing list saying that for "all practical purposes the two draft should be treated as working group documents. <draft-ietf-mpls-bgp-mpls-restart-03.txt> "Graceful Restart Mechanism for BGP with MPLS" needs re-spin <draft-ietf-mpls-nodeid-subobject-02.txt> RRO Node-ID subobject: Jean-Philippe told that an update has been submitted <draft-ietf-mpls-bundle-04.txt> Zafar Ali: Issues with link bundling draft After discussion among draft contributors, wg co-chairs and ADs it was decided decided that some issues with draft needed to be fixed. To tht end the draft was pulled from rfc queue. The scope of this presentation is to outline the issues, focusing on required functionality 1. scoping of component link id: node vs. bundled te link scope 2. equivalents of type 4/5 tlvs for ipv4 and ipv6 if_id_rsvp_hop and if_id error_spec objects 3. recording (and explicit controol) of component interface id Zafar described all three issues in more detail. Next step: would like wg to close on issues, then discuss solution space Adrian ("ccamp co-chair hat on"): Good to do this work in mpls, but it's blocking huge number of ccamp drafts in the rfc queue Loa: Just pulled the draft yesterday, don't know yet how long it will take to fix it Lou: Will submit update on draft as soon as drafts are accepted again George: authors should just circulate updated draft and solicit input Kireeti: No rewriting planned, only address specific issues and not open up the whole thing Yakov: Focus only on changes, not rest of document, wg chairs should structure discussion appropriately Lou: Don't add new things, don't reopen old issues, new functionality needs new draft Loa: The issues will be dealt with as wg last-call, limited to the issues outlined in Zafars slides slides: www.tla-group.com/~mpls/bundling.ppt 3. LDP to Draft Standards <draft-ietf-mpls-rfc3036bis-00.txt> Ina Minei Ina: Since the last IETF work has been done into two areas 1. produced first draft of the revised specification - editorial - areas not covered in the document: securing hellos, LDP MTU signaling - shutting down adjacencies - clarifications: corner cases not spelled out correctly in the original spec - errors/clarifications/changes in the pseudo-code (split horizon when doing ordered label control) 2. started the operator survey - deadline for reply after the ietf Next steps - feedback from the changes made in the document - re-submit a version Kireeti Kompella: We need to update the IANA section, will propose text to Ina to go into this part of the document. Slides: www.tla-group.com/~mpls/3036bis.ppt Liaison from MPLS & Frame Relay Alliance on RFC 3036 Andy Malis Andy presented a liaison from MPLS & Frame Relay Alliance regarding the LDP Host Address FEC. He described what the HA FEC is in comparison to the Address Prefix FEC. Ina's original email proposed to remove host addr fec due to non-use, changes to the Address Prefix FEC with a /32 prefix were alos proposed Andy summarized the liaison and stated that while the MFA could use the Address Prefix FEC with a /32 prefix, the MFA prefer to keep HA FEC as is due to implementation plans. Slides: www.tla-group.com/~mpls/mfa-communication.ppt Discussion on Host Address FEC Eric Rosen RFC3036 defines FEC element types used to bind labels to address prefixes in routing table the RFC define two FECs (Address Prefix (AP) and Host Address (HA)), other FEC element types will be defined by other protocols in early versiions of the LDP specification only AP FEC existed, the HA FEC were included because it was assumed that an LSR must be able to distinguish between locally delivered vs. forwarded packets (constraints of particular ATM based implementation). The HA FEC has not been used so far, the LDP specification is written so it is easy to remove it when we progress to Draft Standard. The MFA laim they use the HA FEC in their specification, a closer reading of the documents show that they are not using the FEC axactly as specified in RFC3036, in particular it violates section 3.5.7.1 in the LDP specification. The conclusion is that a new FEC has been specified and a new FEC type is needed. Slides: www.tla-group.com/~mpls/rosen-fec.ppt George: Does anybody object to keep the same number for new FEC? Andy: Keeping the same FEC type value is fine. But given it's all there in the doc, why take it out? Kireeti: A Draft Standard means that an implementation has existed for some time. New fec does not belong in ds std. George: Reusing the FEC type value implies that we first remove it from the LDP specification. Alex: Based on the discussion here, moving it to separate document is best idea Loa: As we don't have an implementation of the HA FEC, we can't move the LDP specification to Draft Standard. Move the new FEC into new doc and we will "reassign" same number. Andy: To reassign number requires wg draft accordig to iana allocation process (ietf consensus). Alex: Doesn't think proposed standard is required, but will need to check this. 4. P2MP TE (25 min) Requirements for Point to Multipoint Traffic Engineered MPLS LSPs <draft-ietf-mpls-p2mp-requirement-04.txt> Sheisho Yasukawa Sheisho stressed that the scope of the requirement specification is p2mp traffic enginered LSPs only, how the p2mp tree is co,puted is outside the scope of the requirment specification. Earlier revision -02 were working group last called, and revision -03 included updates accoring the last call comments. Revision -04 introduced new text to include requirements and clarification originating from the for all solution team issues. Thre are till some open issues: - variation of lsp parameters on different lsp branches? - can a transit (probably branch) re-optimize a sub-tree? - what should be the behavior if the tree "re-merges"? - can short-term data duplication be tolerated? - limits and design targets A new version is planned shortly and should be sent to working group last call. Slides: www.tla-group.com/~mpls/p2mp-reqs.ppt Eric: Because of the way some of the requirements and the motivation for the requirements are stated the requirement document becomes more controversial than the solution document. It could be discussed if we need this requirment document at all. Igor: Do we need to includ a requirmentfor leaf-initiated add/drop George: I'm opposed to it. Complete solution needs more work elsewhere. If such requirements exists, they need to be captured somewhere else. Rahul: The solution assumes that all leaves are known. Application use will be defined elsewhere. Yakov: The requirement document should state that some issues are outside the scope of the requirment document upfront. This needs to made very clear. Seisho: Will update the document according to the discussion of the scope of the document. Solution Extensions to RSVP-TE for Point to Multipoint TE LSPs <draft-raggarwa-mpls-rsvp-te-p2mp-01.txt> Dimtri, Rahul, Seisho The extensions to RSVP-TE for traffic engineered p2mp LSPs has progressed since the meeting in San Diego and a merged solutions document has been created. This document will be published as a working groupd ID after this meeting. The state management issue has been solved by means of <sub-group orig ID, sub-group ID>. Outstanding issues are: a) style usage b) p2mp sender_template obj and filter_spec obj encoding specifics c) review re-merge/cross-over conditions d) re-optimization e) sub-ero compression re-organisation f) stitching mechanism detail Next steps: revision -01 will be submitted after meeting as wg i-d; for revision -02 the organization of the document will be reviewed and a terminology section included. Slides: www.tla-group.com/~mpls/p2mp-solution.ppt 5. MPLS OAM (20) <draft-allan-nadeau-mpls-oam-frmwk-00.txt> Tom Nadeau and Dave Allan Tom: The first version of the document wer publsihed for the San Diego meeting and accepted as a working droup document. Will be published after this meeting. The document provides an overview of the FCAPS functionality and the required data plane tools. Authors asks for working group input. Slides: www.tla-group.com/~mpls/oam-frmwrk.ppt 6. P2MP LSP Ping (10 min) Detecting Data Plane Failures in Point-to-Multipoint MPLS TrafficEngineering - Extensions to LSP Ping <draft-yasukawa-mpls-p2mp-lsp-ping-00.txt> Adrian Farrel This document extends the techniques described in [LSP-PING] in order that they may be applied to P2MP MPLS TE LSPs. This document stresses the reuse of existing LSP Ping mechanisms as such reuse simplifies operations of the network. Since Traffic Engineered P2MP LSPs are at least as vulnerable to data plane failures a mechanism to verufy livesness of the data plane is needed. The P2MP tree brings new requirements for verifying data plane liveness. An obvious candidate to be used to create a tool for this is "LSP ping". The draft does not change the LSP ping as it exist, but describes extension to the LSP ping techniques so that they may be applied to P2MP MPLS TE LSPs Several issues needs to be discussed and questions need to be answered, e.g.: - is this the right approach, what are alternatives? - how to handle scaling - additional requirements? - what should happen to this draft? There is no consensus yet on this approach, we'll discuss on the mailing list until next meeting to see if we can make it a working group document. Slides: http://www.tla-group.com/~mpls/p2mp-lsp-ping.ppt 7. LDP/IGP Synchronization (10 min) <draft-jork-ldp-igp-sync-00.txt> Markus Jork In networks depending on edge-to-edge establishment of MPLS forwarding paths via LDP, blackholing of traffic can occur in situations where the IGP is operational on a link and thus the link is used for IP forwarding but LDP is not operational on that link for whatever reason. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This means that along the IP shortest path from one PE router to the other, all the links need to have operational LDP sessions and the necessary label binding must have been exchanged over those sessions. Reasons for the a missing LDP session could e.g. be a configuration error. The draft need to cover interaction with TE tunnels better and it need clarify that it is applicable to targeted LDP. The discussions focused on sorting out the concepts and the scope of the docuemnt. The differences between IGP and LDP convergence were discussed. It was concluded that we need to discuss both content and the purpose of this document if we are to accept it as a working group document. Slides: www.tla-group.com/~mpls/ldp-igp-sync.ppt 8. Encapsulation of MPLS over (10 min) Layer 2 Tunneling Protocol Version 3 <draft-townsley-l2tpv3-mpls-02.txt> Mark Townsley The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label or label stack and its payload over L2TPv3. Yakov Rekhter: there is no reason to accept this as a WG document, - because we have enogh methods to transport MPLS over an IP core Eric Rosen: This is really a no brainer - there is nothing specific here to do this and if this is just to make people being interested in the topic I don't see the reason to prefer one method or the other. Peter Lothberg: Speaking for isp using l2tp. Useful to add mpls into it as its just another l2. Jeff Young: Support in making this a standard of this to interoperate. Loa: Rename the draft-townsley-mpls-l2tpv3 to indicate it is intended to be mpls work item, take the discussion on the mailing list and come back with a resolution for the next meeting. Slides: www.tla-group.com/~mpls/mpls-over-l2tpv3.ppt 9. Meeting closes |