NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01
George Swallow <firstname.lastname@example.org>
Vijay Srinivasan <email@example.com>
Fred Baker <firstname.lastname@example.org>
Fred Baker <email@example.com>
David Oran <firstname.lastname@example.org>
Bert Wijnen <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe (unsubscribe)
Note: this WG is one of a set of WGs that comprise the 'sub-IP' pseudo-area that the IESG recently created. All of the sub-IP WGs are temporarily being housed in the General Area until the IESG decides on a final management structure for managing these groups. The Area Directors for the following areas acting as a group will be the Area Advisors: INT, OPS, RTG and TSV. The name(s) listed above under "Technical Advisor(s)" are the the responsible Area Directors for the working group.
The MPLS working group has been responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various link-level technologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.). This includes procedures and protocols for the distribution of labels between routers, encapsulations and multicast considerations.
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.
Submit procedures for Host Behavior to IESG (Standards Track)
Submit documents from original MPLS effort to IESG
Shepherd completed MPLS specifications through IESG review and RFC editor processing
MPLS-TE MIB ready for advancement to Proposed Standard
Framework for IP multicast over label-switched paths ready for advancement.
LDP fault tolerance specification ready for advancement to Proposed Standard.
Specification for MPLS-specific recovery ready for advancement.
Base MPLS Proposed Standard RFCs ready for advancement to Draft Standard.
LDP end-to-end LSP authentication ready for advancement to Proposed Standard.
Requirements for Traffic Engineering Over MPLS
Multiprotocol Label Switching Architecture
MPLS Label Stack Encoding
Use of Label Switching on Frame Relay Networks Specification
MPLS using LDP and ATM VC Switching
VCID Notification over ATM link for LDP
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
MPLS Loop Prevention Mechanism
MPLS WG Meeting Thursday, March 22, 2001
I. George provided document status on existing documents which are in or near last call.
1. Carrying Label Information in BGP-4 (awaiting publication)
On RFC editor's queue
2. RSVP-TE (awaiting publication)
Applicability Statement for Extensions to RSVP for LSP-Tunnels
RSVP-TE: Extensions to RSVP for LSP Tunnels
Note: the latter draft needs some final edits. This will be handled as part of the RFC editors last authors comments.
3. LDP "boxed set" (awaiting publication)
LDP State Machine
Applicability Statement for CR-LDP
Constraint-Based LSP Setup using LDP
LSP Modification Using CR-LDP
These are awaiting a Table of Contents for LDP State machine. As of this writing, Eric Gray has supplied an updated draft.
4. MIBs (in IESG last call)
Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)
MPLS Label Switch Router Management Information Base Using SMIv2
Authors are in the process addressing comments from the IESG.
Another round of last calls may be required.
5. Framework for IP Multicast in MPLS
Will be sent to IESG for last call.
6. MPLS Support of Differentiated Services
Francois needs to turn a new draft incorporating updates from the recent WG last call after which it will go for IESG last call.
7. Generalized MPLS Signaling drafts
These drafts are nearly complete. They will be updated based on the results of CCAMP. Once updated they will be sent for joint CCAMP and MPLS WG last call. The sense of the room was that the drafts should go to a MPLS WG last call.
8. Unnumbered, Bundle, Hierarchy drafts
After the "sub IP" re-org, these drafts remain in MPLS.
Proposal: Accept draft-kompella-mpls-undle-05.txt as working group draft. Update the draft as draft-mpls-bundle-00.txt. Some of the other drafts will also be updated. Once updated a WG last call will be issued.
II. MPLS Recovery Framework Fifi Hellstrand
This document provides a high-level overview of protection mechanisms which could be employed by MPLS. The document was also presented to the TE wg. Many comments received on this document. Minor changes were required (editorial). Fifi requested that the document be sent to WG last call and move it to an informational RFC. No questions from crowd.
Within the sub IP area, the TEWG has the charter to come up with an overall recovery framework. George therefore asked the ADs if a WG last call for this document could be done at this time.
Scott: Wants to take a sense of the room, and then get comments from the mailing list for last call, but still wants the TE design team to make sure that they don't want to add to it. Don't want to wait for more than a month.
George: Any objections on moving to last call within a month? None were voiced. The document will be sent to the TE WG mailing list for comments to facilitate the process outlined by Scott.
III. RSVP Label Allocation for Backup Tunnels George Swallow
Objective is to do FRR in MPLS to allow for temporary routing around a failed link or node while the head-end is reoptimizing the lsp. The technique uses a bypass tunnel to the node two hops down the path. All tunnels between the current node and that node may share the same bypass tunnel. Rerouting is done locally and thus can be done in < 50ms.
In order to use this, a label needs be obtained for the hop across the bypass tunnel. Two mehanism are described in the draft. A separate RSVP Path message can be generated. This applies in all cases. If the tail of the bypass tunnel is a frame-based switch using the global label space, then labels can simply be recorded in the RRO.
The draft has been available for the past 1.5 years. It is purely informational; doesn't propose anything new. Would like to publish as a WG informational draft.
Scott (as chair): Is there support in the room for this. No objections. A WG last call will be issued after which it will be forwarded to Scott and Bert for IESG review.
IV. LDP Fault Tolerance Philip Matthews
Summarized draft. Discussed changes between last version and current version. Expect to ask for wg last call soon. Requested comments now or via mailing list.
George: Consensus to put this draft to a wg last call. Luca Martini opposes wg last call; no other objections.
Luca: Since ldp is not a controlling protocol, why bother making it fault tolerant?
Matthews: Enhance software upgrades and you don't want to disrupt the LSPs that are running over the network.
Luca: But other protocols need to be made redundant too.
Matt: OSPF etc. are being made fault tolerant. We stole this proposal from IDR.
A long discussion enused on the relationship of LDP recovery to recovery of information from other protocols. There is work in progress on this in OSPF and IDR. In fact the LDP recovery is based on BGP recovery. Details of this discussion can be found in the raw minutes sent by Tom Nadeau.
The result of all the discussion was that the issue of the relationship of LDP recovery to other stateful recovery will be handled in the last call. Scott commented that the applicability section of the document should be enhanced to reflect this.
George: We will do a last call, raise these issues and try to close them. If closed, then document is finished.
V. An Expanded ERO for RSVP-TE Vishal Sharma
Given the recent changes in the unnumber draft, the mechanism proposed in this draft is no longer necessary. The authors therefore propose to turn this draft into an informational document on how to form EROs and move it forward that way.
VI. TTL Processing in MPLS networks Puneet Agarwal
Draft covers different ways of processing TTL. Overview. Would like to update according to comments from list and move forward to last call.
Matt: Document is useful and technical content is good. Figures would be useful. Document is difficult to read. Pipe/Hose model are mixed in document. Put them in a their own places in the document?
Q1: I don't see how TTLs are specified in NTAPs draft.
A: Some models are not described in that document.
Q1: There might be some difficulty with your approach.
Rosen: There is already a document that specifies how TTL processing works. Lets just put pipe model in here only, otherwise we duplicate things explained in RFC 3032.
I think that we need to organize the discussion around the point of the organization of this document (what is not covered and what is).
E: You don=92t need a separate procedure for nested procedure; already covered in 3032. Discussion did not complete on mailing list. There is a lot that needs to be clarified.
A: What are you proposing?
E: I think that you are proposing changes and additions (specified and unspecified). Need to specified which is which. Need to reach consensus on whether or not they are necessary. Do we need a document that obsoletes pieces of rfc3033.
George: this is an information proposal. We cannot contradict something that is in a standard. Lets continue this discussion on the mailing list.
Egray: I was going to say what george just said. Define something in a standard specification and explain something in an informational.
George: Cannot contradict what was in the rfc. Take it to the list.
VII. TTL Processing expansion for 1-hop LSP Satoru Matsushima
Overview. Next steps: merge with Puneet's ttl draft. Would like to become a wg draft. Need signaling extensions for 1-hop lsp.
Eric Rosen: There are two schools of thought on TTL processing. Don't think there is a need to specify TTL on a per-lsp basis. I don't think that there is a problem that we need to solve here.
Luca: I agree with Eric's comments. I don't see the use of specifying the behavior on a per-lsp basis.
George: Continue discussion on mailing list.
VIII. LDP End-to-end Authorization Olivier Paridaens
Overview. Presented requirements. What we are asking is that this be adopted as a wg draft. This work is part of the charter, so it should be accepted.
Scott: What operators have expressed interest in this technology and have the security geeks looked at this?
A general discussion ensued on what was required and what had been discussed in San Diego.
Several carriers and vendors spoke up saying that the proposal on the table was expensive and over-kill. This was counter with a statement that the method was not all that expensive and that the feature is optional. It was also claimed that carriers voiced support in San Diego.
Another speaker pointed out that optional pertained to use and that vendors most likely would be required to implement. Before committing to such a course they would like to see the requirements document for this sort of work.
George: We need to figure out what providers want first. We don't have any consensus at this point. Lets get some carriers to give us some contributions for what they would like to see in this space. Continue discussion on this mailing list.
IX. Update on LDP Path MTU Ben Black
Overview. Simple extension to ldp to allow automatic signaling of mtu detection. Allows proper fragmentation of packets within the MPLS domain. Support RFC1191 too. Version 00 has been out for some time. Lots of comments received. Asked that this be accepted as a wg document.
Curtis: What happens if along the way, one hop is inside a hierarchtical tunnel or if bypass tunnels are used. In both cases, the router negotiating a hop is not aware that somewhere in the middle that a bypass exists.
Black: If hierarchtical, the outermost tunnel=92s mtu is used. There is an lsr somewhere that can see the bypass which can unsolicited signal the mtu change. It will pick the lesser of the two=92s path.
George: Anything that causes an impulse into signaling during a failure is bad.
Eric Rosen pointed out that in practice, firewalls often thwart Path MTU discovery by dropping ICMP messages.
Ben Black said that simply because it wouldn't work in some cases, was no reason not to work on solving the problem where it would work.
Curtis: There are places where this is necessary: no NATs and high performance IP.
Matt: I haven't seen demands from the carriers for this functionality, eventhough I like it.
Scott: Process point: is this in the charter?
George: Gray area. We should work to get MPLS to work.
Scott: WG can change charter if necessary. Charter is description of what we should be doing within a certain time period.
Q1: Carriers are interested in this.
Black: RSVP has this functionality.
Discussion will be continued on the list.
George: We now have three presentations that are not in the gray area. They are outside of the current charter. We are going into "BOF" mode to see if there is interest to expand the charter.
X. Secure MPLS Tissa Senevirath
Overview. Applications: Most metro applications use MPLS.
Q1: In your first slide, you stated that most MPLS Metro carriers use MPLS. Which country are you talking about?
Q1: Do you know which vendors are supporting MPLS in the metro area.
Q2: Most operators use f/r links. The law prohibits them from monitoring authentications. Can authentications be monitored on MPLS. Even if we have mpls security on a backbone. MPLS is an end-to-end problem. This does not seem to be useful unless it is end to end.
Bilel J: Where are you getting the requirements for this draft.
Sen: These requirements are coming from the optical development going on in the world.
George: Take the discussion to the mailing list.
XI. Multicast Traffic Engineering Dirk Ooms
George: This work was started a long time ago. There was no interest in this at that time. What has changed?
Dirk: Now there is SSMulticast.
George: Perhaps you should change the name of your document to "support for SSM".
Dirk: this is an alternative to SSM.
Rosen: As far as SSM, there are other solutions to the problem of knowing the source of a packet.
Dirk: There are other solutions, but they are undocumented as of yet.
Q1: I wasn't clear why SSM makes this more interesting. Also it isn't clear how you distribute the labels using TE. Where is the definition of TE is not clearly defined in the draft.
Dirk: Traffic engineering allows you to construct a tree, which deviates from the shortest path tree. Which is the same as TE for unicast.
George: Given the time, lets continue discussion on the mailing list.
XII. MPLS OAM Shahram Davari
Davari MPLS OAM draft-harrison-mpls-oam-00.txt Overview. Status of this document: ITU SG13-Q3. Requirements are defined. Availability is defined. OAM Packets are defined. Connectivity verification is worked out. Future work: LSP performance work. Summary: OAM is necessary for user-plane, independent of control-plane. This draft introduces OAM requirements and simple OAM functions. Determining connectivity/availability. What we have done is taken this from ATM and reduced most of what was there, and kept the best %1. MPLS OAM was previously defined in MPLS charter. If interested, it should be added to charter and document accepted as a work item.
Q: I think this work is very useful. It will increase the performance of the MPLS network. Recovery framework is applicable. Performance benchmarking applies. This is useful for fault-tolerance.
Curtis: How does this relate to the Bonica draft on tunnel trace? We should go to the TE Wg and see what there are requirements are for this.
Rosen: I think that some of the stuff in the beginning is important. I think this document is not a good piece of work. There are many terms that are not defined in the IETF. It has a very ATM-flavor. It does not handle a lot of stuff like multi-point-to-point. Even if we were to add measurement to charter, lets not accept this document to the charter.
Davari: This is optional. Carriers want this.
Q2: I don't think that this is useful. I think that it is not useful in an LSR. I can see this to be useful if GSMP is being used. Useful in detecting configuration errors, otherwise lets assume that the LSR works okay.
Q3: I second that. I don't buy the argument that software is broken, so we need to add more software.
Scott: My problem with the document is that it mixes light requirements with lots of suggestions. It would be useful to have a clear requirements document that specifies what it is that you are trying to accomplish with this approach. The requirements document should be taken to the TE WG.
Davari: is it in the charter of te?
Scott: Thinking is in the charter of te. Management of this kind is not in the charter. However, if requirements can come forward and hint at which tools they could have would be a good thing.
George: End of the agenda. See you in London.
IGMP Mixed Version Proxying
Domain Name Services for Source-Specific Multicast
OAM for MPLS Networks