Last Modified: 2005-01-25
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) |
RFC3988 | E | Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol |
IETF 62 MPLS WG Meeting March 9, 2005
---------------------------------------------------------------- Chairs: George Swallow <swallow@cisco.com> Loa Andersson <loa@pi.se> Scribes: M.Morrow, M. Eubanks Agenda Bash I. WG Status New RFCs: RFC 3988 MTU Extensions for LDP RFC 4023 Encaps MPLS in IP or GRE In IESG Review: ietf-mpls-bundle ietf-mpls-rsvpte-attributes ietf-mpls-nodeod-subobject-05 ietf-mpls-bgp-mpls-restart ietf-mpls-explicit-null (approved) Comments: A. Farrel - Fast track for RFC process would be welcomed for the Bundle draft Working Group Drafts soft pre-emption (ver -04 in pipe) Comment: J-P Vasseur - Should publish -04 next week for pre-emption mpls over l2tpv3 (new) LSP-Ping - Last Call after this meeting LSR-Self-Test - Last Call after LSP Ping II. Incoming liaisons: G.motnni from ITU-T SG 15 (Steve Trowbridge) Loa: Apologized for chairs dropping the liaison by accident (thus no response) Steve: Genoa meeting, editor MPLS Transport - too much included; transport NNI aspects of MPLS itself as transport technology - was not purpose of the document - should be shorter document and narrower in scope Next meeting is in May (ITU-T) Monique: Cisco pointed out problems with draft and liaison needed to be done MFA: Liaison Relationship with IETF Loa: The IETF already has a liaison relationship with the ATM Forum. The IAB wants to await outcome of proposed merger of ATM Forum and MFA before responding. A. Malis: Merger has to be approved by written vote by both existing orgs and still in progress (end of Mar termination of voting period); III. LDP to Draft Standard (Ina Minei) New rev since last IETF draft-3036-bis-01 Removal of host address FEC proved to be a significant change - Thanks E.Rosen and A.Malis for resolution of issue There were a lot of responses from the operational survey. Thanks to the participants, and to Scott Bradener for being the anonymizer. A new draft based on the survey results is available: Draft-minei-ldp-opertal-exper-00.txt A new version of 3036 bis will be posted soon, and this should be ready for last call. There also needs to be an implementation survey, and we will be working on that. IV. Pt-to-MP Signalling Req Draft (S.Yakusawa), pt2mp-sig requirement Rev -04 Removed application scenarios Remove (and apologized for) offensive remarks about PIM Made the choice of signaling protocols less constrained Renamed draft "signalling" Resolved 3 of the 5 outstanding issues 1) Variation of LSP parameters is not allowed 2) transit LSR's can re-optimize a sub tree 3) clarified case of tree re-merger to prevent egress data duplication Two remaining questions and issues: 1) Can short-term data duplication be tolerated 2) Absolute limits and design targets number of recipients number of branch points rate of Join / prune rate of change of tree topology Seisho proposed that the remaining questions be resolved through discussion on the list. Draft to be complete for last call in May or June. Loa: Preferable to have ready in May so that a last call can be completed before Paris. V. Extensions to G/RSVP-TE for P2MP TE LSP's (D. Papadimitriou) draft-ietf-mpls-rsvp-re-p2mp-01 Terminology adapted to requirements doc; Document structure has been reorganized. Open Issues: 1) Style usage (SE vs FF style) 2) Review text for re-merge/cross-over conds 3) Re-optimization (requires consensus whether re-opt may be done on a P2P sub-LSP and / or sub-tree basis) 4) Pruning (deletion) and sub-ERO compression reorg 5) Stitching mechanism - c.f. CCAMP Discussion: George: Right now there are 3 different methods for tearing down an LSP. This seems unnecessarily complicated. Rahul: Point well taken. As you know, we had a huge number of authors. It needs to be pruned down on the mailing list. VI. Detecting P2MP Data Plane Failures (A.Farrell) yasukawa-mpls-p2mp-lsp-ping Need simple and efficient mechanisms to detect data plane failures in P2MP MPLS LSPs Reqs: Verification of reception at recipients Discovering p2mp topology Objective is to build on top of LSP Ping need to introduce RSVP P2MP session sub-TLV Revision 01 has not changed very much. The biggest was that we limited the choice of traceroute destinations to all, or one. Request for WG Rahul: The draft tries to limit the ping to a subset of the recipients? Adrian: Sub-set permitted in sub-set 1 or all (target individual recipient or whole tree) Rahul: If I have a tree with a thousand egresses then I am not sure that that solves my problem. Adrian: Issue is with problem statement - may be need to be a separate draft George: Leave it together for now - if it gets too big then separate VII. Component Link Recording and Resource Control for GMPLS Link Bundles (Zafar Ali) explicit-resource-control-bundle-04 This started in CCAMP at IETF 57. People found issues with link bundling. These were discussed and it was decided that this should be pursued by the MPLS WG. Motivation : TE Link Bundle resources are identified by TE Link ID, Component interface ID and Label value. RFC3209 allows for label recording, component recording would also be useful. RFC3473 allows for label selection; explicit component selection would be useful for applications like LSP splicing and SRLG diversity. Therefore the RRO and ERO should carry component IDs. We think that there is general agreement on the requirement and the solution, and would like to have it adopted as a WG doc. Loa: (after show of hands who read; who believe should be a WG doc) That's pretty good support, so we will take this to the list. Loa: Meeting adjourned - see you in Paris ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 |
None received.