Current Meeting Report
Slides


2.6.6 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 11-Oct-01
Chair(s):
George Swallow <swallow@cisco.com>
Vijay Srinivasan <vijay@cosinecom.com>
Sub-IP Area Director(s):
Scott Bradner <sob@harvard.edu>
Bert Wijnen <bwijnen@lucent.com>
Sub-IP Area Advisor:
Scott Bradner <sob@harvard.edu>
Technical Advisor(s):
Rob Coltun <rcoltun@movaz.com>
Mailing Lists:
General Discussion:mpls@uu.net
To Subscribe: mpls-request@uu.net
In Body: subscribe (unsubscribe)
Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html
Description of 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:

Informational:

(6/12) Applicability Statement for Extensions to RSVP for LSP-Tunnels (8/08) Applicability Statement for CR-LDP (6/12) LDP State Machine

Experimental:

(10/19/99) MPLS Loop Prevention Mechanism

Standards Track:

(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.

Goals and Milestones:
Done   Submit documents from original MPLS effort to IESG
Jan 01   Shepherd completed MPLS specifications through IESG review and RFC editor processing
Feb 01   MPLS-TE MIB ready for advancement to Proposed Standard
Mar 01   Framework for IP multicast over label-switched paths ready for advancement.
Jun 01   LDP fault tolerance specification ready for advancement to Proposed Standard.
Aug 01   Specification for MPLS-specific recovery ready for advancement.
Nov 01   Base MPLS Proposed Standard RFCs ready for advancement to Draft Standard.
Dec 01   LDP end-to-end LSP authentication ready for advancement to Proposed Standard.
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2702 Requirements for Traffic Engineering Over MPLS
RFC3031PSMultiprotocol Label Switching Architecture
RFC3032PSMPLS Label Stack Encoding
RFC3034PSUse of Label Switching on Frame Relay Networks Specification
RFC3035PSMPLS using LDP and ATM VC Switching
RFC3036PSLDP Specification
RFC3037PSLDP Applicability
RFC3038PSVCID Notification over ATM link for LDP
RFC3033PSThe 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
RFC3063E MPLS Loop Prevention Mechanism
RFC3107PSCarrying Label Information in BGP-4

Current Meeting Report

MPLS WG meeting minutes Salt Lake City 12/10/01
======================================================================

1. "MTU Signalling Extensions for LDP"
<draft-black-ldp-mtu-extensions-02.txt>

Kireeti Kompella

There was a very brief prsentation to update the workgroup on changes since the last document, concluding with a request to go to last call.

Discussion:

Brijesh: This draft only addresses a part of the problem: MTU discovery for LDP. What do we do for RSVP?
Kireeti: RSVP is done.
Brijesh: why do we have a separate draft?
Kireeti: 2 drafts are okay.
Lou: The RSVP info is in the original draft.

K: George, can we check the room for consensus for last call? What does the room think?

Room: More for than against, but George wants to see a little more enthusiasm. George will issue a WG last call shortly.

2. "TTL Processing in MPLS Networks"
<draft-agarwal-mpls-ttl-01.txt>

Puneet Agarwal

Puneet: Made a short presentation, followed by a request to adopt the draft as WG document.

George: Do people in the room believe this draft is a good idea. Do I see any nods for yet/no? Some clarifications on this would help for interoperability of this. There seems to be a consensus for such documents.

Anonymous:

Provides useful clarification, but would like to know how you know which model of TTL decrment to use?

Puneet: Signaling is out of the scope of this document. If the group wants to address this, the chair needs to address this.

Shahram Davari: as one of the authors of draft-MPLS-Diffserv-09, I feel that this work is needed as a supplement to draft-MPLS-Diffserv-09, which addresses practical uncertainties that have been observed during implementations of various tunneling modes.

Scott Bradner: The documents going into being WG documents need to be items that are in the charter, or the charter needs to be re-spun to change. We need more WG support short for this document before it can be accepted.

George: This document is just a document to clarify how things are being done. It does not represent new protocol work. We decided it would be informational in London.

The document was accepted as a WG document.

3. Restart/Recovery

Three drafts were presented on Restart/Recovery, adjudication was withheld until all were presented.

"Graceful Restart Mechanism for BGP with MPLS"
<draft-rekhter-bgp-mpls-restart-00.txt>

Yakov Rekhter

Yakov: Made a short presentation, followed by a request to adopt the draft as WG document.

Anonymous: What is the required restart time.

Yakov: User configurable.

Anonymous: BGP has a specific timer.

Y: You should look at the BGP proposal; whatever BGP does this does too.

Y: Any other questions?

"Graceful Restart Mechanism for LDP"
<draft-leelanivas-ldp-restart-01.txt>

Yakov Rekhter

Yakov: Made a short presentation, followed by a request to adopt the draft as WG document.

Anonymous: Why previous BGP restart should be done in IDR?

Y: Distribution of BGP labels has been done in this WG, so we should do this here.

"Graceful Restart Mechanism for LDP"
<draft-smith-mpls-ldp-restart-00.txt>

Andy Malis / Toby Smith

Toby: Presentation. Detailed difference between this proposal and Yakov's.

Anonymous: Discuss different proposals?

George: Drafts have not been accepted, so we need to get to the bottom of that. Lets discuss this for a few minutes.

Eric Gray: This draft does not compete with Yakov's draft. Yakov's is focused on BGP MPLS. This draft proposes a difference between what is in the IESG queue for a year now. The LDP fault tolerance draft had looked at stuff like this drafts. The problems are that these assumptions do not work in all deployments unless all LSRs agree to do this fault tolerant mode. It doesn't do any good to support any LSPs that are not supported in any other segments in the network.

Andy: First comment: this only goes on between LDP peers, so if you are running lDP throughout the network and you have an outage between two peers, those should come up okay and should not affect other peers elsewhere. Comment two: it is all or none.

Luca: I would like to see these approaches get together.

Andy: We already have plans to meet with the other authors.

Anonymous: The assumption that was made that checkpoint information can be kept can be a problem with regard to resources.

Andy: This is a problem with all of the approaches.

Phil: After querying about the number of implementations of the existing draft, I have not heard of any problems with this approach. There are apparently 2 implementations of the existing fault tolerant draft.

Andy: There is no problem with the difficulty to implement these or the new approaches; just the implementation complexity.

Kireeti: This draft is nice because it is light, but I am afraid that two end points of the connection can loose state. If you exchange control messages, you are assured that things are in sync. The IDR approach does exchange control messages. Just an important point to understand.

Anonymous: A few points. The BGP restart drafts pretty much learn their state from the network. With this approach, you have the possibility of loosing state. The main difference between the two approaches is that one approach caches state, and the other doesn't.

Andy: We considered that LDP runs over TCP, so we have a reliable and sequenced path. You know that the receiver knows that they received control messages. We are pretty clear that things should work pretty well. All should read the current draft, and send email to the list.

George: Requested that the group having lunch please send email to the list.

4. Fast Reoute

"Fast Reroute Techniques in RSVP-TE"
<draft-ping-rsvp-fastreroute-00.txt>

Ping Pan

Ping: Presentation

George: Would like this accepted as a WG document?

Ping: Yes.

Question: I could not figure out how one approach complements the others.

Ping: We would like to combine the request mechanism from all drafts, so that any router in the network based on local configuration can construct a back-up path. We haven't finished integrating these.

Question: I think the case when the backup path LSP fails behavior is not specified. There should be recommendations/considerations of what should be done. Now, if the backup LSP fails what do we do?

Question2: Generalizing the applicability for this (i.e.: bi-directional LSPs)?

Ping: I think in the case of GMPLS this is already done.

"MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute"
<draft-atlas-rsvp-local-protect-interop-02.txt>

Alia Atlas

Note: Alia is also one of the co-authors of the draft presented by Ping. Her draft is intended to allow some of the open issues in that draft to be aired before the workgroup.

Alia: Presentation

A lively discusion between Ping and Alia ensued, particularly over the issue of make-before-break on backup tunnels.

George: Any objection to accepting the Ping draft as a WG document? Note that the issues that Alia raised should contunied to be disussed on the mailing list. How many people think this should be added to the WG?

George: The I's have it.

5. "Multiprotocol Label Switching (MPLS) Management Overview"
<draft-ietf-mpls-mgmt-overview-00.txt>

Tom Nadeau

George: This draft was requested by ADs. It shows relationship of various MIBs.

Tom: Presentation

Kireeti: Include TE-MIB?

Tom: Yes.

George: WG draft?

Group: Lots of hands. No objections.

George: Draft will be last called after IESG process on MPLS LSR/TE/LDP/FTN MIBs has progressed and any changes that emerge from that process are inculded.

6. "IPv6 Traffic Engineering Tunnel"
<draft-ishii-ipv6-te-tunnel-00.txt>

Hiroki Ishibashi

George: This next presentation is out of the scope of the WG, and is more of an application of MPLS.

Hiroki: Presentation.

Francois: This work belongs to the NG-trans WG. There is a draft there for this work already. LSPs are constraint based routed. There is a lot of overlap between this draft and the draft being progressed there.

George: (to Hiroki) The point is that the discussion belongs in the other WG, not here.

7. Document Status

George: Presented drafts that are in IESG last call, are on IESG queue.

Yakov: There are some changes to the unnumbered draft for CR-LDP that need to be done.

George: Any comments on mpls-te-feedback-draft

Don Fedyk: We were looking to progress this document.

George: I will send it to last call.

We now want to shift gears and talk about which RFCs that can be progressed onto the standards track. Scott, please comment on architecture document.

Scott: Beats me. In general, architecture documents are not standards track documents.

George: Enaps draft. There are quite a few implementations of that that interoperate. What we need is for people to collect interop information.

Lou: a while back when this draft was coming out, there were MTU discovery interop issues. The discussion was that when it came time to advance the document until these issues are addressed.

George: Dig up old email and start a new discussion.

Lou: Hopefully it will be just what we agreed to 2 years ago and put it into the draft.

George: LDP draft. Has many different flavors. In order to progress, only those things for which there are 2 or more interop implementations can be progressed, and the rest removed. A survey effort needs to happen and documentation of what is there and what is not.

Joel Halpern: Are you going to make the list or is someone else?

George: I am not going to do it. Volunteers? Loa, you showed interest in this in the past.

Loa: I will help out if Bob Thomas doesn't have time.

George: Technology-specific drafts (ATM). There are multiple implementations, not sure about interop of them. Need to get to the bottom of this. The (FR) drafts: don't know of any implementations, so it will stay proposed (forever). BGP draft: there are interoperable implementations of this, so this can be progressed. I will send the list of these drafts/status to the list.

Slides

Graceful Restart for BGP with MPLS
LDP Graceful Restart
Graceful Restart for LDP
(MPLS) Management Overview