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. George: Discussion? 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. George: discussion 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? Sen: US. 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 Overview. Questions. 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.