Current Meeting Report
Jabber Logs

2.7.5 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/20/2002

George Swallow <>
Loa Andersson <>
Sub-IP Area Director(s):
Scott Bradner <>
Bert Wijnen <>
Sub-IP Area Advisor:
Scott Bradner <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe (unsubscribe)
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:


(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

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.
  • - draft-ietf-mpls-ldp-mib-08.txt
  • - draft-ietf-mpls-te-mib-08.txt
  • - draft-ietf-mpls-multicast-08.txt
  • - draft-ietf-mpls-lsr-mib-08.txt
  • - draft-ietf-mpls-te-feed-04.txt
  • - draft-ietf-mpls-lsp-hierarchy-07.txt
  • - draft-ietf-mpls-recovery-frmwrk-06.txt
  • - draft-ietf-mpls-ftn-mib-04.txt
  • - draft-ietf-mpls-ldp-ft-04.txt
  • - draft-ietf-mpls-lsp-query-04.txt
  • - draft-ietf-mpls-rsvp-unnum-07.txt
  • - draft-ietf-mpls-crldp-unnum-07.txt
  • - draft-ietf-mpls-tc-mib-03.txt
  • - draft-ietf-mpls-bundle-04.txt
  • - draft-ietf-mpls-bundle-mib-03.txt
  • - draft-ietf-mpls-mgmt-overview-02.txt
  • - draft-ietf-mpls-ldp-restart-03.txt
  • - draft-ietf-mpls-ttl-03.txt
  • - draft-ietf-mpls-bgp-mpls-restart-00.txt
  • - draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt
  • - draft-ietf-mpls-lsp-ping-00.txt
  • - draft-ietf-mpls-fastreroute-mib-00.txt
  • - draft-ietf-mpls-ldp-mtu-extensions-00.txt
  • Request For Comments:
    RFC2702 I Requirements for Traffic Engineering Over MPLS
    RFC3034 PS Use of Label Switching on Frame Relay Networks Specification
    RFC3035 PS MPLS using LDP and ATM VC Switching
    RFC3031 PS Multiprotocol Label Switching Architecture
    RFC3036 PS LDP Specification
    RFC3032 PS MPLS Label Stack Encoding
    RFC3037 PS LDP Applicability
    RFC3038 PS VCID Notification over ATM link for LDP
    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
    RFC3063 E MPLS Loop Prevention Mechanism
    RFC3107 PS Carrying Label Information in BGP-4
    RFC3210 I Applicability Statement for Extensions to RSVP for LSP-Tunnels
    RFC3209 PS RSVP-TE: 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

    Current Meeting Report

    MPLS Working Group minutes
    Chairs: George Swallow <>, Loa Andersson 
    1.  Agenda bashing
    2.  Fast Reroute
    2a. Fast Reroute Extensions to RSVP-TE for LSP Tunnels
        Alia Atlas
    This document defines extensions to and describes the use of RSVP-TE to 
    establish backup LSP tunnels for local repair of LSP tunnels.  It is a 
    "consensus" draft that resulted from the combination of multiple prior 
    Since the -00 version the draft was reorganized to describe LER/LSR 
    behavior for each role in fast-reroute.  Details were combined which were 
    the same, regardless of technique used (one-to-one or facility backup) and 
    removed redundancy.  Behavior was clarified to facilitate 
    interoperability between techniques.  A number of technical 
    modifications were made as well (see the presentation in the 
    The authors believe the draft is ready for working group last call.  
    Multiple implementations currently exist.  The have resolved the issues 
    found in interoperability testing at Isocore and elsewhere.  There was 
    consensus in the room, and last call will be issued following the IETF 
    2b. Sven Van den Bosch
        Backup Record Route for Fast Reroute Techniques in RSVP-TE
    MPLS fast reroute is considered as a solution to protect traffic against 
    link and node failures by re-directing the traffic locally to a backup LSP. A 
    backup LSP can be either a detour LSP or a bypass tunnel. This document 
    describes two methods to optimize the routing of detour LSPs such that they 
    merge faster, a distributed method and a centralized method. The 
    distributed method uses the Backup Record Route Object (BRRO) and the 
    centralized method uses the Backup Explicit Route Object (BERO).
    There were several issues raised about the draft that were addressed in 
    this revision.  The first was support of distributed detour 
    computation by allowing BERO to use loose hops, and the second was 
    regarding the object length - messages could become very long.  The BERO may 
    now be "compressed" by only specifying relevant nodes.  The third issue was 
    operation with inter-area LSPs, and that was addressed with a change to the 
    BRRO procedures.  The next steps are implementation, future 
    investigation of performance gain and label state for different network 
    topologies.  Further comments are invited on the list.  They requested that 
    this become a working group document.  Scott Bradner, SUB-IP Area 
    Director, said that any call for a working group draft in this WG must 
    mention what in the charter it is addressing.  The response is that it 
    enhances the fast reroute extensions, which is in the charter.  There was 
    little interest in this draft expressed in the room; it will be further 
    discussed on the list.
    2c. Distinguishing link and node failures using RSVP Hellos 
        Jean-Phillipe Vasseur
    The aim of this draft is to provide a method to distinguish a link 
    failure from a node failure using RSVP hello extensions.  The ability to 
    make this distinction is important when re-using link bandwidth to 
    provide multiple protection paths (assuming that only one failure will 
    occur at a time), which results in significant bandwidth savings.  See the 
    presentation in the proceedings for an animated tutorial on the draft's 
    It also fits in the charter as a part of the fast reroute work item.  The 
    draft was requested to be accepted as a working group document.  George 
    asked if there are new procedures, or if this would be an 
    informational draft.  The answer is that it would be an information 
    draft.  Lou Berger asked how this is related to the work in GMPLS to 
    detect node and link failures - it seems that this duplicates that work.  JP 
    said that they are complementary - you can run one or the other.  It's an 
    alternative.  Scott said that given that we already have something that 
    does this, there should be only one.  Scott also said that 
    complicated technology proposals shouldn't be made in a short 
    presentation - people should read the draft and discuss it on the list.  He 
    would like to see discussion on the list first.
    Yakov Rekhter said that hello mechanisms have been overloaded to detect the 
    liveness of both control and data planes, and he is concerned by such 
    overloading - he feels that they should be unbundled into separate 
    There was a question on how fast link or node failure can be detected.  
    There's no way to do it faster than a round trip time, so you can't 
    always guarantee 50 ms or any other particular time.
    Further discussion will be taken to the list.
    3.  Encapsulation
        Encapsulating MPLS in IP or GRE
        Eric Rosen
    In various MPLS applications, label stacks with multiple entries are used.  
    In some cases, it is possible to replace the top label of the stack with an 
    IP-based encapsulation, thereby enabling the application to run over 
    networks which do not have MPLS enabled in their core routers.  This draft 
    specifies two IP-based encapsulations, MPLS-in-IP, and MPLS-in-GRE.  Each of 
    these is applicable in some circumstances.
    This allows two LSRs to be "adjacent" when they are separated by an 
    MPLS-less IP backbone.  It servers a clear need for network 
    Eric noted that the WG charter allows work in "MPLS-in-foo", so it fits in 
    the charter.
    The issues are the IP encapsulation does require a "scarce" protocol 
    number, and the GRE encapsulation doesn't use the key field or the 
    checksum.  For both, there are also MTU, TTL, QoS, and DSCP issues that are 
    discussed.  There has been support expressed on the list, and no 
    objections.  Eric proposed that it be moved forward for Proposed 
    Standard.  Scott complemented him on his presentation and said it should go 
    ahead.  We had strong consensus to make it a WG item.
    4.  OAM
    4a. A Framework for MPLS User Plane OAM
        Dave Allan
    This draft discusses many of the issues associated with user plane OAM for 
    MPLS. The goal is to provide tools to perform "in service" 
    maintenance of LSPs. Included in this discussion is some of the 
    implications of the MPLS architecture on the ability to support fault, 
    diagnostic and performance management OAM applications, potential 
    solutions for distinguishing user plane OAM, and a summary of what the 
    authors believe can be achieved in addressing all aspects of the MPLS 
    In his presentation, he replaced the words "user plane" with "data 
    plane".  The motivations for the draft were to explore all issues 
    associated with instrumenting MPLS LSPs.  The document outcome is to see 
    what can be done in any given MPLS "level", and what can be done by 
    leveraging the entire architecture.  Topics covered include 
    mechanisms for distinguishing OAM flows, return path, 
    multi-provider issues, and OAM applications.  The changes since the last 
    version are a new section on OAM probe state association, new section on the 
    use of hierarchy to simplify OAM, enhanced security section, and minor 
    editorial changes.
    The current state of the document is that the authors feel it is largely 
    complete.  They proposed that it be adopted as a WG draft - it contains 
    common MPLS WG input into both WG and ITU-T SG 13 efforts, and is a 
    useful survey of the space.  It would be even better with additional WG 
    input, then it can be put to bed.  Tom Nadeau said that it's a pretty 
    reasonable document.
    4b. IP-based Tool Requirements for MPLS Networks
        Tom Nadeau
    This memo describes requirements for operations and management based on 
    IP-based tools for MPLS networks. The document scope is 
    requirements for IP-based tools for fault detection, diagnostics, 
    statistic reporting, and security management.
    The motivation is that providers have been coming to the authors with OAM 
    requirements that differed from those that were available from both the 
    IETF and the ITU-T, and there was a concern that current 
    requirements did not reflect real operational environments.  There were 
    also disparately located requirements for MPLS-related OAM scattered 
    about, and they felt it would be best to put these together into one 
    place.  The base message from providers is that they wanted an 
    evolutionary approach rather than a revolutionary approach that might have 
    new hardware requirements and require fork-lift upgrades in their 
    networks (sensitive to both OPEX and CAPEX).  Since they published the 
    draft, they have received comments that will result in revisions, and they 
    would like to move the requirements from Dave Allan's framework 
    document, and make it a WG document.  Tom asked Scott if he agreed that the 
    requirements be combined in one place, and Scott agreed that sounded like a 
    good idea.  Jerry Ash said that some service providers have provided 
    requirements against MPLS MIBs, and should those requirements also be 
    applied to OAM?  Tom said that some of the requirements were specific to MIB 
    changes, but some of the others were overall requirements that do apply 
    here as well.  Dimitri Papadimitriou would like a discussion of how data 
    plane OAM interacts with control plane mechanisms like fast reroute.  Dave 
    Allan supports getting all of the requirements in one place.
    4c. Detecting MPLS Data Plane Liveness
        Kireeti Kompella
    This document describes a simple and efficient mechanism that can be used to 
    detect data plane failures in MPLS LSPs.  There are two parts to this 
    document: information carried in an MPLS "echo request" and "echo reply" for 
    the purposes of fault detection and isolation; and mechanisms for 
    reliably sending the echo reply.
    Changes from the last revision were the packet format was changed and a 
    version number field was added, a "Don't Reply" reply mode was added, the 
    reply flags were removed, and return codes were extended.  RSVP session 
    formats were modified, VPN IPv4/v6 formats were defined, L2 VPN 
    endpoint and L2 circuits were defined, downstream mapping format was 
    changed, and PAD and Error Code TLVs were introduced.
    The next step is that the base document is done for base MPLS tunnels as 
    well as applications such as VPNs, and it is time to get it out and go to WG 
    last call.  Tom Nadeau had two questions - there's no reference in the 
    document for the encapsulation type, and the document needs clarified on 
    what is required to be implemented and what is optional - what's the base 
    implementation?  Kireeti said that the draft already does that, and it will 
    be improved.  Shahram Davari asked if there were requirements for this 
    work, and Kireeti said they were implied in the draft, and there is a real 
    problem in that we need to know if our MPLS networks are working.  Tom 
    Nadeau said the requirements draft he discussed previously also covers this 
    draft.  Kireeti also said that if something is missing, we can add it 
    later. There was consensus for last call, and it will be issued 
    following the meeting.
    George said that for the framework and requirements, he would not want them 
    to become WG documents yet; rather, the authors should get together and see 
    what information should go into each document and produce new higher 
    quality revisions that can then become WG drafts.  We agreed that will be 
    the plan.
    5.  Load Balancing
        Guidelines for MPLS Load Balancing
        Dave Allan
    RFC 3031 permits MPLS load balancing while making no specific 
    representations as to implementation requirements. This has 
    subsequently become an issue with respect to the reliability of path test 
    mechanisms. Load balancing algorithms may separate path test probes from the 
    path of interest. This draft proposes guidelines for 
    implementation of load balancing such that path test mechanisms are not 
    The motivation is that it is desirable that when multiple NHLFEs exist, 
    that both the user traffic and any OAM probes follow the same path 
    through the network.  The goal is consistency in monitoring and fault 
    The draft requires that for next hop selection, you not use reserved 
    labels, don't include the "S" bit, and don't include TTL.
    The proposal is to obtain the sense of the WG that some solution is 
    required, and to adopt the draft as a WG starting point.
    Kireeti said that this violates the principal of reproductive freedom 
    what's in my body is mine, and don't tell me what to do with it.  This is 
    similar to allowing implementations to do what they want for SPF.  You can 
    tell me what to put on the wire, but not how to implement it in my box.  
    Dave agreed that what's in your box is your business, but the 
    externally observable behavior of your box IS the issue here and is 
    important to service providers.  Kireeti said that this should be 
    information if it is published at all, but certainly not standards track or a 
    BCP.  Dave said that anything that bounds detection time of problems in the 
    network is good, and carriers want bounded detection times.  Kireeti kept 
    arguing that this is a paradigm change to the forwarding path.  We have 
    ECMP and it works, and it's up to each vendor to decide how they 
    implement it.  Dave said that is going to be important for PWE3 as well, 
    since you need to bound the detection time for failures on 
    pseudo-wires as well as for the transport LSPs.  Kireeti also doesn't want 
    any limits on label depth that were discussed in the draft.  Not looking at 
    the S bit is also bogus.
    Eric Rosen agrees with Kireeti's comments.  While its a good OAM 
    requirement that OAM packets need to follow the data packets, he doesn't 
    agree with the way the document tries to do it by imposing the 
    restrictions it does.
    Alia Atlas also agreed - this is a revolutionary approach rather than 
    evolutionary approach due to the required changes in the forwarding path.  
    It's bad to adversely affect ECMP in order to support OAM.  In some 
    cases, you don't know that length of the label stack.  Dave said that the 
    only reason he discussed label stack depth in the draft was an attempt to 
    keep it simple.  He also wanted measurement consistency on a per-node 
    basis rather than a per-LSP basis.
    Shahram Davari said that this probably breaks MPLS ping.
    Kireeti asked the ADs at what point do we stop intruding into boxes?  This 
    came up not just here, but also in the routing area discussion on SPF 
    implementation.  He suggested that this just be published as an 
    information RFC saying "this is a good idea".  Scott said that this is 
    really an IAB/IESG plenary discussion rather than something that should be 
    discussed here.  If the WG believes that something is wrong with the way 
    something was done in the boxes, and the WG consists of box builders, than 
    that's the consensus.  Be he hasn't seen a consensus at the 
    microphone for this point.
    There was considerable opposition to this being a WG document.  Further 
    comments will be taken to the list.
    6.  Bi-directional LSPs
        Bi-directional LSPs for Classical MPLS
        Rohit Dube
    This draft proposes extensions to support bi-directional LSPs for 
    classical MPLS. Specifically, RSVP-TE is extended with objects similar to 
    those in GMPLS to allow establishment of bi-directional LSPs.  It's a 
    pretty simple protocol extension to make this work.
    Kireeti disagrees that GMPLS is different from MPLS - it is a superset of 
    MPLS, and bidirectional as defined in GMPLS works in MPLS as well, so this 
    draft is unnecessary.  Kireeti and Rohit discussed some the 
    differences between the two approaches, but Kireeti felt that the GMPLS 
    approach is sufficient for the requirements.
    Rahul Aggarwal had a second comment along the same lines - just use what was 
    already done for GMPLS.
    George added that while it's simple to do an extension for 
    bidirectional, it's harder to make sure it works for fast reroute and 
    make-before-break.  So he wants some though on how these other 
    mechanisms would be supported for bidirectional as well as just the data 
    flow.  Rohit agreed that these could require some additional work.  
    Discussion will be continued on the list.
    7.  MPLS Security
        Analysis of the Security of the MPLS Architecture 
        Michel Behringer
    This document analyses the security of the BGP/MPLS VPN 
    architecture as described in RFC 2547, especially in comparison with other 
    VPN technologies such as ATM and Frame Relay. The document consists of two 
    main parts: the requirements for security in VPN services are defined, and 
    MPLS is examined with respect to these requirements. The analysis shows 
    that MPLS VPN networks can be equally secured as traditional layer-2 VPN 
    networks such as ATM and Frame Relay.
    This was originally written as a white paper for customer 
    consumption, and he decided to also make it available as an internet 
    The question being answered by the draft is can you operate an MPLS 
    backbone in a secure manner.  What secure means here is address space and 
    routing separation, hiding the MPLS core structure, resistance to 
    attacks, and impossibility of VPN spoofing.  This allows MPLS to be a 
    replacement for L2 services, like ATM and Frame Relay.  It does NOT 
    address the security of the operations of RFC 2547, such as 
    misconfiguring VPNs and security of the implementations due to bugs.  He was 
    concentrating on the security of the architecture, but it's still 
    possible to shoot yourself in the foot.
    It does not yet include Inter-AS operations.  It's pretty stable.  There is 
    one open issue - during rerouting, one label too many might get popped for a 
    short time.  He's still researching this to see if it's a bug in the 
    implementation, or a bug in the protocol.
    Questions: Is this useful?  What is missing?  Does it fit in this WG?  His 
    goal is to publish it as an informational RFC.
    Eric Rosen said that this addresses the issue as to whether a VPN 
    implementation fits the requirements, and he feels it belongs in the PPVPN 
    working group.  Michael asked if this document could become a security 
    section for RFC 2547?  Eric wasn't sure if he would take that 
    approach, but in any event, he still thinks it should be in the PPVPN WG.
    Dave McDysan said that this draft was used to help with the PPVPN 
    requirements document, and he also would like to see it in the PPVPN WG - 
    it's already been referenced.  Michael said that he's already 
    presented it there, and the answer was no at that time.  Dave said that 
    it's already been included in the PPVPN requirements.
    Loa said that a question heard from customers is - Is the MPLS 
    architecture, and VPNs on top of it, secure enough to replace L2 VPN 
    networks?  Loa feels that this work is important and needed.
    Yakov said that this document would be a great replacement for the 
    security section in rfc2547bis - that security section should just be a 
    pointer to this document.
    Ananth Nagarajan said that this needs to be expended to cover the 
    carriers of carriers case.
    Marco Carugi (PPVPN co-chair) agreed with Yakov's comments, and that it 
    should be generalized into a complete security framework for all of the 
    PPVPNs technologies, not just rfc2547.
    Scott agreed with Marco.  But George feels that when it comes to 
    security, it's better to be specific than general.
    George said that discussion of this document should be moved to the PPVPN 
    email list.
    8.  Multicast 
        Extended RSVP-TE for Multicast LSP Tunnels
        Allan Kullberg
    This document specifies extensions and mechanisms to RSVP-TE in order to 
    support MPLS point-to-multipoint LSPs.
    The changes from -01 were:
     - All tree modifications via changed TERO
     - Always from sender node via Path message
       - Avoids race conditions
     - Supports Graft/Prune
       - Leaf Initiated Join/Leave
       - Leaf node sends Join/Leave message directly to sender node
       - Sender node sends changed TERO
       - Looks like single node Graft/Prune
     - Sequence number in TERO hop (Saves comparing entire TERO)
     - Terminating node flag in TERO hop
       - Allows node to be branch and leaf
     - MulticastNotify message for error indications
     - Error handling description
    The future directions are:
     - Add sequence # to TRRO (Saves compare of entire TRRO)
     - GMPLS Notify instead of McastNotify? (Reuse is good)
    Allan requested that this become a WG draft.
    Rahul said that there is a draft that describes how to do multicast in 
    tunnels using PIM, and seems less complex.  Allan said that this draft 
    doesn't require the use of a multicast routing protocol.
    George asked what's the driving need that this is trying to satisfy?  
    Allan said that this to support multicast without requiring the use of an IP 
    multicast address as the destination.
    Discussion will continue on the list.
    9.  LDP FT/Restart
        Adrian Farrell
    There are two drafts for recovery of LDP sessions after failures, 
    draft-ietf-mpls-ldp-ft-06.txt and 
    draft-ietf-mpls-ldp-restart-05.txt. These drafts have completed WG last 
    call and have moved forward to IESG review.  There is a need for 
    information indicating which draft should be implemented and when.  In 
    addition, draft-ietf-mpls-ldp-ft also has options.  
    Implementation choices are complex, so this draft was written to give 
    guidance on when it is advisable to implement a LDP restart mechanism and 
    which approach might be more suitable.  The draft has expanded to 
    contain additional background information. The draft is stable, but has a 
    few updates still needed - in particular, Yakov had some comments that 
    Adrian is working on.
    Adrian requested that this become a WG document with a view to moving 
    forward as an informational draft.
    George spoke in favor of the draft.  But it was a late addition to the 
    agenda, and people need more time to read it.  So people are 
    encouraged to read it and discuss it on the list.
    10.  Workgroup Status
    10a. LDP to Draft Standard status
         Loa Andersson
    Loa presented the current results from the LDP implementation survey.
    The full presentation appears in the proceedings.  Some highlights 
    12 Responses
    - 10 Public, 2 Anonymous.
    - 10 Product; 2 Beta
    - 11 On sale; 1 Other
    - Implementation Approach
    7 From spec;
    4 Purchased/free code + additions;
    1 Purchased code.
    - Every item in survey questionnaire implemented by at least 2 
    - Each of the 8 Label Distribution Modes implemented and tested;
      T	Tested against another independent implementation
      I	Implemented by not tested against another independent 
      N	Not implemented.
     T  I  N				 T  I  N
     =======                                 =======
     8  2  2   DU, Ord Cntl, Lib Reten       6  1  5   DU, Ord Cntl, Con Reten
     7  1  4   DU, Ind Cntl, Lib Reten	 6  0  6   DU, Ind Cntl, Con Reten
     7  1  4   DoD Ord Cntl, Cons Reten	 4  3  5   DoD, Ord Cntl, Lib Reten
     6  1  5   DoD, Ind Cntl, Cons Reten	 4  2  6   DoD, Ind, Cntl, Lib Reten
    - Platform and Interface Label Spaces both widely supported.
     T  I  N				 T  I  N
     =======                                 =======
    12  0  0   Per Platform	                 7  1  4   Per Interface
    - Basic and Targeted Sessions both widely supported.
     T  I  N				 T  I  N
     =======                                 =======
    12  0  0   Basic/Directly Connected	11  1  0   Targeted
    - TCP MD5 Option not widely implemented.
     T  I  N				
     3  1  8
    - Interface Types
     T  I  N				
    12  0  0   Packet
     6  2  4   ATM
     2  3  7   Frame Relay
    This will continue to be updated as responses come in, and a draft will be 
    written summarizing how LDP is being used and if anything should be 
    removed in order for it to become a Draft Standard.
    10b. MPLS MIB review meeting report
         Joan Cucchiara & Tom Nadeau
    There was an open MPLS MIB meeting held this past Saturday in Atlanta.
    The agenda was:
    - Review of  Final Changes for MIBs requested by MIB Doctors
    - Review Interaction between MIBs:
    LINK-BUNDLING, MPLS MIB Overview draft
    - FINAL ACTION Items for Authors
    Complete detail of changes are recorded at the IETF ID Tracker Site:  
    - Many minor changes
       DESCRIPTION clauses
       Clarification of examples
       Editorial in nature (split REFS, IPR statement)
    - Very few significant changes
    See the presentation in the proceedings for the complete list of changes to 
    each of the MIBs.
    Next steps:
    - Goal is to update MIBs and Overview by 12/15  (MIB co-authors) 
    - Depends on
      - IESG Comments on latest MIBs
      - Resolution of issues on email list
      - Additional Working Group "LAST, LAST, LAST Call" at that time?  
    Tom asked for clarification from the chairs on whether we need another WG 
    last call.  Loa said yes, but it would only be on the changes since the 
    last WG last call, and on the MIBs as a group.  So all six MIBs need to be 
    ready at the same time.  The overview document will be last called at the 
    same time.
    If there are any additional comments that people have, please make them 
    this week so that the MIBs can be updated by the above deadline.
    Loa thanked everyone that participated in the MIB review, and the MIB 
    authors, for all of their hard work in getting the MIBs done.
    10c. Status of MPLS WG Internet Drafts 
         George Swallow
    George presented the status of all MPLS wg documents.  The 
    presentation is included in the proceedings.
    Among the drafts awaiting updates from authors was:
       MTU Signalling Extensions for LDP
    Kireeti said that the draft needs to be redone based on received 
    comments.  There should be a new version by the second week of 
    George also note that it's time to move forward on draft status for the 
    architecture, encapsulation, ATM VC switching, and RSVP-TE RFCs.
    Loa said that the CR-LDP decision was documented in an individual draft, was 
    reviewed by the IESG (which returned comments), and there was a general 
    comment on grammar.  Scott will be reviewing it for grammar, after which it 
    will be sent to the RFC Editor.


    MPLS Workgroup Status
    Detecting MPLS Data Plane Liveness
    Distinguish a link from a node failure using RSVP Hellos extensions
    IP-based Tool Requirements for MPLS Networks
    MPLS MIB Review Summary
    LDP Implementation Survey Results