2.6.8 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-20


George Swallow <swallow@cisco.com>
Loa Andersson <loa@pi.se>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: mpls@lists.ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/mpls
Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html

Description of Working Group:

The MPLS working group is responsible for standardizing a base
technology for using label switching and for the implementation of
label-switched paths over various packet based 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 and encapsulation.

The working group is also responsible for specifying the necessary
MIBs for the functionality specified in the base MPLS technology.

The first generation of the MPLS standards are largely complete,
and the current WG work items are:

- Define requirements, mechanisms and protocol extensions for
point-to-multipoint (P2MP) MPLS

- Define requirements, mechanisms and protocol extensions for
traffic engineered point-to-multipoint (P2MP) MPLS, including
soft preemption

- Define requirements and mechanisms for MPLS OAM

- Define an overall OAM framework for MPLS applications

- MPLS-specific aspects of traffic engineering for multi-areas/multi-AS
in cooperation with the CCAMP WG

- Determine (with CCAMP) what procedures are appropriate for evaluating
proposals to extend the MPLS and GMPLS protocols, and document these

- Document current implementation practices for MPLS load sharing

The Working Group chairs tracking of the working group documents can be
viewed at http://www.tla-group.com/~mpls/mpls-wg-docs.htm

Goals and Milestones:

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
Done  Submit specification on LSP Ping to the IESG for publication as a Proposed Standard
Done  Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS)
Done  Submit an OAM Framework Document to the IESG for publication as an Informational RFC
Done  Submit a BCP on MPLS load sharing to the IESG
Sep 2005  Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard
Dec 2005  Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard
Dec 2005  Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs
Apr 2006  Advance 'Extension to RSVP for LSP Tunnels' to Draft Standard
Apr 2006  Advance MPLS Architecture and MPLS encapsulation to Draft Standard


  • draft-ietf-mpls-icmp-04.txt
  • draft-ietf-mpls-mgmt-overview-09.txt
  • draft-ietf-mpls-bgp-mpls-restart-05.txt
  • draft-ietf-mpls-lsp-ping-10.txt
  • draft-ietf-mpls-lc-if-mib-08.txt
  • draft-ietf-mpls-fastreroute-mib-04.txt
  • draft-ietf-mpls-nodeid-subobject-06.txt
  • draft-ietf-mpls-oam-requirements-06.txt
  • draft-ietf-mpls-soft-preemption-06.txt
  • draft-ietf-mpls-telink-mib-07.txt
  • draft-ietf-mpls-lsr-self-test-06.txt
  • draft-ietf-mpls-rsvpte-attributes-05.txt
  • draft-ietf-mpls-rfc3036bis-03.txt
  • draft-ietf-mpls-ecmp-bcp-02.txt
  • draft-ietf-mpls-oam-frmwk-03.txt
  • draft-ietf-mpls-rsvp-te-p2mp-03.txt
  • draft-ietf-mpls-p2mp-sig-requirement-03.txt
  • draft-ietf-mpls-p2mp-lsp-ping-00.txt
  • draft-ietf-mpls-explicit-resource-control-bundle-00.txt
  • draft-ietf-mpls-ldp-experience-00.txt
  • draft-ietf-mpls-ldp-survey2002-00.txt

    Request For Comments:

    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
    RFC4023 Standard Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
    RFC4090 Standard Fast Reroute Extensions to RSVP-TE for LSP Tunnels
    RFC4182 Standard Removing a Restriction on the use of MPLS Explicit NULL
    RFC4201 Standard Link Bundling in MPLS Traffic Engineering
    RFC4206 Standard Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)

    Current Meeting Report

    MPLS Working Group        IETF 64     Vancouver            November 2005
    Loa - WG status:
    Three new RFC's:
    4182 Removing a Restriction on the use of MPLS Explicit NULL. E.
         Rosen. September 2005. (Format: TXT=14087 bytes) 
         (Updates RFC3032) (Status: PROPOSED STANDARD)
    4201 Link Bundling in MPLS Traffic Engineering (TE). K. Kompella, Y.
         Rekhter, L. Berger. October 2005. (Format: TXT=27033 bytes) 
         (Updates RFC3471, RFC3472, RFC3473) (Status: PROPOSED STANDARD)
    4206 Label Switched Paths (LSP) Hierarchy with Generalized
         Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE). 
         K. Kompella, Y. Rekhter. October 2005. (Format: TXT=31965 bytes)
         (Status: PROPOSED STANDARD)
    LSP Hierarchy set a new record for time in the queue.
    LDP spec going to draft standard.  procedure says protocol analysis
    needs to be done, but we don't think it's worth doing.
    Alex - based on recent discussion on RFC1264bis this should not be
    Three drafts are in the RFC editor's queue.  None of them are blocked -
    just waiting their turn.
    A number of drafts are in various stages of IESG review.  Two of them
    have now been approved - and will be sent to RFC editors (if-mib and
    George asked ADs about LSP ping.  ITU has been asking for six
    months if can get this expedited through IETF. Now in deferred
    Alex - is going to come up at next IESG tele-chat after IETF.
    George - updated LSR self-test based on comments and will issue last
    call soon.
    A request was made that yasukawa-mpls-p2mp-oam become a WG doc.
    Adrian will talk about it:
    Adrian - the OAM reqs was started. This should have been done before
    P2MP ping.  Mirrors P2P ping but adds considerations for P2MP.  I
    think we've caught most cases.  This was discussed in Paris and on the
    list.  based on feedback we added a few things.  Think it's
    requirement for the WG since we're doing P2MP we need to do OAM for
    it.  I think it's in-scope and is a good starting point for the WG.
    show of hands as to whether is a good starting point etc.  Will go to
    list after the meeting...
    Loa - At the last IETF we had a couple of drafts suggesting upstream
    label allocation for MPLS multicast.  A few concerns we raised, but
    not many at that point.  However when we asked the list for opinions
    got a note that there are IPRs in the area.  That's the reason we
    didn't take the decision to make a WG doc.  This is just a way of
    following procedure - need to give the IETF secretariat and ADs a note
    that there are IPRs.  So far I don't see a show-stopper with any of
    those IPRs.  Actually there is prior art - e.g. in the TDP spec from
    Paul Doolan at end of 96.  So can't see is really a problem - but need
    to follow procedures...
    Alex - The way the IETF normally deals with known IPR for a technology
    being considered is that the IETF or a WG doesn't take a formal stance
    on the validity of the IPR.  That said the way the WGs normally
    proceed is by the WG deciding whether to proceed with the technology
    given other choices and the IPR.  Don't form consensus about IPR, but
    form consensus about going ahead with a given technology given the IPR
    that's being claimed.
    Jean-Louis - Upstream Allocation
    The architecture is in Rahul's draft.  MPLS multicast encaps is
    defined in Eric's draft.
    Overview of upstream vs downstream.
    The upstream label is looked up in a context specific ILM.  Various
    applications - aggregation in multicast VPN, avoiding replication on
    multipoint interfaces (LAN/IP tunnel), efficient support of P2MP MPLS
    Minor extensions to signalling needed to support this.
    1) LSR needs to advertise its support to neighbors
    2) request/distribute upstream-assigned labels.
    3) need to signal the identifier of the underlying tunnel to identify
       the context.
    There are two new drafts - one for LDP, one for RSVP.  These are a
    split of a draft from Paris.
    1) new TLV for capability
    2) new TLVs for request and mapping/release/withdraw messages
    3) new sub-TLV to allow LDP P2MP LSP to be tunneled in RSVP P2MP LSP
       (identifies the RSVP-TE tunnel).
    1) new capability bit
    2) new object in path message
    3) new TLV to allow RSVP-TE P2MP LSP to be tunneled in RSVP-TE P2MP
       LSP (binds inner and outer LSPs - extends LSP hierarchy to P2MP)
    Next steps.  Want WG feedback, and to be a WG doc.
    show of hands.  Take to list.  More in favor than opposed.
    Eric Rosen - does this need to be supplemented with a scheme to ensure
    that the upstream label space is partitioned so that multiple devices
    on a LAN don't use the same label?
    Adrian Farrel - not opposed to this work, but to jumping into this
    work.  See a mixture in the requirements analysis.  Requirement is to
    operate efficiently on a MP network *not* to use upstream labels.
    Jean Louis - requirement is efficient replication.  Consider best
    approach is upstream allocation.
    Adrian - I understand.  But you're jumping from the requirements to
    the solution.  
    Alex - I agree with Adrian that need to separate reqs (functional reqs
    - i.e. don't want >1 copy of a packet on a LAN) and the solution.  Do
    the reqs and let the WG agree a solution.
    George - no decision until after the meeting (and do on the list).
    Loa - one further comment.  This is really important.  Jean Louis was
    asking for WG feedback.  Would like to see discussion on the mailing
    Zafar Ali - explicit resource controlled bundles
    first discussed at IETF57 (July '03) at CCAMP.  heavily debated in
    CCAMP and MPLS.  Finally agreed content at IETF61 (Nov '04).  Became
    WG doc.
    Believe that draft has been stable for some time - so would like a
    last call.
    George - will issue last call.  If you haven't read it then this
    should prompt you to read it...
    Ron Bonica - ICMP draft
    Draft was split into two pieces - general format for extensions and
    format for MPLS extensions.  Presented at Internet area at last IETF.
    Spoke to Margaret Wasserman.  First one will go to last call soon.
    Then can do second.
    Loa - so are we going to last call with a draft we can't really
    change?  (as formats out there for ages)
    Ron - so yeah, may be no reason to send second one to last call.
    George - need to follow procedure.
    Jean Louis - MPLS P2MP requirements for LDP
    LDP protocol deployed for unicast LSPs, mainly in MPLS VPN.  Emerging
    reqs. for multicast in those networks.  Relevant approach would be to
    use LDP.  So this draft focuses on requirements for that.
    Changes from last version:
    1) added an application scenario
    2) clarified routing requirements 
    3) clarified OAM reqs (extend P2MP LSP ping to LDP, need fast data
       plane failure detection, but detailed reqs out of scope - in P2MP
       MPLS OAM draft).
    4) added order of magnitude for expected numbers of trees/leaves per
       tree (from survey in L3VPN WG)
    5) added text on shared trees and MP2MP LSPs
    6) reworded for clarity.
    When there are multiple upstream LSRs on LAN need to select one of
    them for an LSP.  But we need to provide a means of balancing a set of
    LSPs across a set up upstream LSRs.
    We need to detail routing reqs for shared trees.  Should depend on
    unicast RIB - no need for multicast routing reqs. 
    Need to decide if MP2MP trees are optional or mandatory
    Next steps
    Need more feedback.
    WG poll in Paris showed interest.
    can this be a WG doc?  charter update to include P2MP?
    Alex - proceed with discussion.  will get back to you on milestones
    for charter update.
    George - suggest we discuss on list if this will become a WG document,
    assuming the charter will be updated.  It's important that we get this
    well into the pipe so we can decide whether to make the other drafts
    WG documents.  Need to evaluate them against requirements.
    Suresh Boddapati - last version of draft has additional requirement
    saying that the consensus amongst providers is that shouldn't require
    a multicast protocol.  Seems this reqs draft is pre-supposing a
    solution.  Requirements should be separate from the type of solution
    you're asking for.
    George - Jean Louis, would be helpful if you could recast the
    requirements in terms of operational simplicity and reducing the
    number of protocols.
    Kireeti Kompella - it's funny when if someone says it's a requirement
    you want to recast it.  A requirement is a requirement.  I don't
    really understand that point of Suresh's question.
    George - maybe Alex can help us.  We have providers standing up and
    saying "no way". Does that make it a requirement or not.
    Alex (with AD hat on) - it would not be a good idea to put something
    in the reqs document that limits the solution space.  From the
    operational perspective if you have reasons not to want a multicast
    protocol specified, don't tell the WG not to look at that
    approach. Just like the P2MP over LAN case - it's very correct to say
    you want to avoid duplication of traffic - but don't constrain the
    solution.  Leave that to the engineering process.
    Jean Louis - we'll put a list of operational issues in instead.
    Vach - responding to Kireeti.  If there's a statement in the reqs that
    says "you MUST not use X" - even though it doesn't specify a solution it
    limits the scope.  It's important for us not to say "don't use X" and
    limit the scope and then claim that as a requirement.  Might instead
    say "the reason we are doing this is because we find it adds to the
    complexity, changes the scaling etc."  Don't limit our ability to come
    up with solutions.
    George - in terms of scope a reqs document does 2 things:
    (1) focuses on the problem we're trying to solve
    (2) doesn't constrain the way we solve it.
    it doesn't mean make it general, but means we don't constrain it.
    Adrian - you're being hard on Jean Louis.  This is the same set of Qs,
    based on the same text, that we went through for P2MP TE.  This text
    does not say "you MUST NOT use", but it says "you MUST consider not
    Eric - there are several places in the requirements document where it
    is clear that the authors have preferred solutions and are pushing
    them.  Might as well avoid meaningless and subjective things such as
    "shouldn't be too complicated", or "shouldn't have too many
    protocols".  Some things in the document went over the bounds of
    requirements.  Just because the SPs think something is good doesn't
    make it a requirement...
    George - will continue discussion of whether this should become WG
    doc.  Discussion will include pointing out sections of the draft that
    are over-specifying the solution space.
    LDP for P2MP LSPs - Kireeti (standing in for Ina)
    This is joint work.  Merged the two documents presented in Paris.
    I'll talk on some then IJs(Ice) will take over.  How do you do P2MP
    LSPs with LDP...
    TLV to specify tree ID tweaked to make it easier for transit nodes.
    covers - P2MP LSPs, shared trees, MP2MP LSPs.
    why extend LDP?  Lots of people use LDP in their network for LSP
    tunnels.  If interesting for RSVP then should be for LDP also.  If
    you're only running LDP then it's nice to stick with it.
    use LDP only for multipoint LSPs
    bandwidth efficiency of one copy per link
    create single source trees.
    create MP2MP trees in one of two ways.
    do this with minimal changes to LDP protocol.
    P2MP LSPs are egress-initiated (so very different from RSVP)
    by means outside this document every egress is told that they need to
    join a tree, and what the tree root is.  New FEC element to identify
    tree and root.
    label distribution must go from egress towards root.  Traffic from
    root to egresses.
    each node that has two guys joining the same upstream with the same
    FEC has a merge operation.  In downstream path therefore have
    replication.  So need forwarding support to go from ingress label to
    >>=2 egresses.
    P2MP FEC element contains the root address (source address from LSP
    point of view).  Tree identifier serves as way to merge things
    together (opaque).
    Basic idea is unsolicited label distribution.  Ordered - i.e. from
    leaves to root.  Unlike regular LDP don't send mapping to all
    neighbors, but just to upstream (i.e. the guy on the shortest path to
    the root).  When a transit node gets two label mappings for the same
    FEC then it knows to create replication state.
    example showing how simple swap is replaced with replication state
    when second downstream node sends FEC.
    idea of shared trees is to enable mode where lots of guys talk to lots
    of guys (multiple ingress, multiple egress).  E.g. VPLS.  One solution
    is a single-source tree somewhere in the network and then get the
    leaves to join to it.  Then each ingress unicasts to shared root,
    which multicasts.  So reuses unicast and P2MP mechanisms.  Advantages
    - no new protocols, and reasonably efficient in terms of
    state/bandwidth.  Few things to consider - an ingress may receive its
    own packet if it's part of the set of leaves.  Also each link won't
    get just one copy of a packet (though two copies are usually in
    different directions).  So that's one approach.
    Loa - question on MP2MP.  Have you really seen any applications for
    MP2MP?  If so then are they documented?
    IJsbrand - clearly documented.  E.g. default MDT.
    Loa - would be good to document.  Not sure where.
    IJsbrand - in reqs doc?
    Loa - there are different types of MP2MP.  Kireeti talked about one
    set of LSRs sending to the same set of LSRs.  Then you have any to
    any.  Then things in between.  So text explaining what it is would be
    IJsbrand - MP2MP LSPs.  Have downstream and upstream LSPs.  Upstream
    is like P2P that inherits labels from downstream.  Downstream is same
    as P2MP.
    root of MP2MP can be edge or core.
    all leaves can send and receive to the tree.  useful for many-to-many.
    If we use LDP then no new protocol required.
    bandwidth efficiency - as packet only traverses a link once, and
    sender never sees its own traffic...
    protocol extensions - MP2MP upstream FEC element, and downstream FEC
    element. Same structure as P2MP FEC.  Need upstream label mapping in
    response to downstream mapping...
    Advantages of this merged draft:
    1. all done in LDP and the IGP that is running anyway for unicast.
    2. no need for synchronization with other protocols.
    3. fairly small protocol changes
    4. supports multiple ingress nodes sending to the same tree.
    Suresh - mentioned LAN procedures.  Ingress replication for LAN today.
    Can't see how that is even reasonably bandwidth efficient.  Works for
    P2P interfaces.  But need to make it work for all interfaces.
    IJsbrand.  Good point, but whether it is acceptable depends on number
    of downstream receivers.  Many Ethernet networks have P2P links.
    Suresh - sure, there is a set of networks where it works fine.  Don't
    want to assume a specific set of networks where it works.  We wouldn't
    have wanted to design OSPF and ISIS, for example, so that they only
    worked on P2P.
    Kireeti - you're micro-optimizing too early.  VPLS today ingress
    replicates from root.  This model does it the "right way" until we get
    to a LAN.  So that's a second order problem.
    Suresh - don't see these as different problems.  Also to extend LDP
    for LAN cases would be interesting - to see how many changes required.
    In fact your solution pretty much introduces the behavior of a
    multicast protocol (tracking sources etc.)
    Yakov - one benefit, the way of exchanging label bindings with LDP is
    incremental.  Most efficient way.  Procedures described in this doc
    don't preclude ones described in document on upstream label allocation
    on LAN.  the two could work together.
    Venu - requirement that only single copy should be forwarded on LAN.
    Doesn't meet it - so is non starter.  Upstream label allocation alone
    doesn't solve it (ECMP can cause multiple copies).  Problems not easy
    to solve.
    Jean Louis - LDP upstream draft showed simple procedure to avoid
    ingress replication.
    George - don't have a requirements doc, so can't evaluate this
    solution against the requirements.  Upstream label requirement can't
    be considered until we get it into the pipe.  Trying to get as far as
    they can without adopting that mechanism.  Much of this discussion is
    Vach - if you distribute LSAs in LDP then you don't need the IGP  ;-) 
    Kireeti - next version  ;-) 
    Suresh - if you've not solved the LAN case then it's premature to see
    how complex the LDP solution will be...
    Venu - if you keep extending protocol to be like multicast protocol
    then there are inter-AS considerations.  You have to keep adding
    things, and it becomes a routing protocol.
    IJsbrand - not a multicast protocol but a multipoint tree, which can
    be used for multicast.
    Kireeti - back to Loa's Q.  There are two requirements.  Two different
    solutions.  Should say "why do we want to do this in the first place".
    Then go back and do the trade-offs.
    Suresh - P2MP LSP setup with PIM-SSM and LDP
    PIM-SSM builds trees well.  LDP is good at label distribution.  So use
    them both to build P2MP LSPs.
    The advantage is minimal changes to PIM and LDP.  Works well for P2P and
    LAN cases.  PIM-SSM is simple (no shared trees, *,G states etc.)
    a P2MP LSP is mapped to an (S,G) state.  PIM-SSM joins used to build
    the (S,G) trees.  (S,G) in MRIB triggers LDP to advertise labels.  So
    just like the unicast case.
    Uses downstream unsolicited for P2P and upstream unsolicited for LAN.
    We also suggesting that you use independent control and liberal label
    retention (will explain why).
    ECMP issues - if multiple downstream requests from multiple upstreams.
    PIM already has mechanisms to detect this.  Can detect in control
    plane - not data plane.
    Example for LAN - showing how independent control solves the issue of
    blackholing traffic that you'd get with ordered control.  Also showing
    how PIM assert can be used to ensure that there's only one forwarder
    on a LAN.
    The changes to LDP and PIM are minimal:
    LDP - new P2MP FEC, interaction with MRIB (not URIB), upstream label
    PIM - improved assert (control plane not data plane).
    So use PIM-SSM to build trees, let LDP exchange labels, support LANs,
    keep it simple.
    Ijsbrand - what happens on LAN interface if an upstream misses the
    Suresh -   PIM joins are refreshed.  So once refreshed will stop
    Ijsbrand - how will you do upstream assignment?  Context-based
    Suresh -   that's why we use S,G joins to trigger assert instead of
    Ijsbrand - you will have duplicates for a minute, and will forward
               them everywhere.  Why not just add a label to PIM to make
               it easier?
    Suresh - we considered it.  3 ways:
    1) labels in PIM
    2) add mcast routing to LDP
    3) let each do its own job.
    (1) is tricky as PIM doesn't have upstream allocation, so more changes
        to PIM.
    Eric - maybe I've been working on MPLS too long.  Worried how people
    talk about the separation of LDP and IGP as if it's a good thing and
    is fundamental.  We considered putting labels in the IGP (OSPF and
    ISIS) to keep it synchronized.  The reason we didn't was because it
    was difficult to do it in a link-state RP.  If SPs had been using IGRP
    we'd have done it.  For BGP it seemed sensible to do it.  Some people
    said "BGP for routes, LDP for labels".  There's nothing fundamentally
    wrong with using one protocol rather than two. Quite the contrary.  If
    you use the same protocol you eliminate a bunch of synchronization
    problems (I just referred to some of them).  In the case of multicast
    we've ruled out label distribution in PIM (nobody wants to put stuff
    in PIM) and don't want soft-state stuff (it's unfashionable).  Haven't
    really explained why *not* to put this in LDP.
    Toerless Eckert - there are people saying don't run PIM in the
    core. it's a silly argument.  not sure if everyone should agree, but
    doing assert just to have single forwarder adds work. Simplification
    is not to do asserts, and to allow multiple forwarders.  Easy to do
    with label forwarding paradigm - but hard to do with native forwarding
    as would have to do RPF check against MAC address of source.  Keeping
    that complexity in is history from native forwarding limitations.  One
    problem with soft state protocols is congestion. So why do label
    binding with hard state and tree building with soft state.  As long as
    you do native forwarding you need to know rules for native packets.
    if you want to exploit the benefits of MPLS then you shouldn't stick
    with the existing tree building protocols.  There's no such thing as a
    PIM-SSM specification.  Take the 400 pages of PIM-SM and throw 80%
    away. I'd dare anyone to stand up and say they can do that.
    Suresh - in terms of interaction of soft state and TCP we already do
    that with IGPs and LDP.  So don't see an issue.  In terms of PIM-SSM
    simplicity, if you've done PIM-SM then you're only executing 20%.  As
    someone who has implemented PIM I can say SSM is simpler.
    Venu - PIM assert is complex as has data plane interaction.  Procedures
    here are simple and done in control plane.  Lots of PIM-SSM
    experience.  Multicast is not simple - if PIM-SSM has been there for
    all this time then why not use it?  If synchronization problems are
    not there with LDP and IGP then why are they there with LDP and PIM?
    Yakov - I find it amusing/amazing that I heard the same individuals
    saying yesterday how to avoid PIM and now saying how to do PIM and
    LDP.  Point 2 - asserts are complex.  The best solution is to get rid
    of them.  Previous presentation showed how on a LAN you can get rid of
    it by following simple rules.  Point 3 - funny that people say that
    the previous proposal doesn't show how to do LAN procedures when a
    previously presented draft did just that.
    Point 1 - not sure why yesterday's presentation is relevant.  With PIM
              snooping there are people say PIM snooping doesn't work.
    Point 2 - if you pick one upstream then you lose the benefits of ECMP.
    Yakov - there is no ECMP for multicast
    Suresh - if you always pick upstream based on IP then you lose
    distribution of multiple flows.
    Vach - that requirement is a SHOULD in the multicast drafts.  If
    PIM-SSM is such a crock and if MPLS is just the best thing for
    multicast then we should just stop doing PIM.  Seems it's so
    denigrated.  I don't understand why we put this in LDP.  Is it that
    you don't know how to implement PIM, or that it isn't implementable?
    Perhaps we should tell the PIM WG to shut down  ;-) . If that's not the
    case then I don't see why we need to reinvent everything.
    Alex (with AD hat off):
    1) regarding putting stuff in LDP.  This is not a religious topic at
       all.  This is solely about reusing what we have already.
    2) about soft state.  it works.  If it doesn't scale in some cases
       then we should fix it.
    3) it's not that the asserts are overwhelmingly complex.  But
       addressing LANs will involve complexity.  Whether you do it in LDP
       and pay price A, or in PIM and pay price B, the issue is that PIM
       already does it.
    Venu - funny that in L3WG are discussing PIM vs BGP.  This case
    requires much less scaling.
    Jean Louis - did you think about the amount of multicast state you're
    going to duplicate?  IP multicast state and LDP multicast state.  We
    may end up with a large number of trees to be maintained.
    Suresh - if your concern is that it doesn't scale then I'm not sure.
    Jean Louis - you are creating IP routing entries that will never be
    used for IP forwarding (since will forward based on MPLS).
    Suresh - that's a policy decision.  You don't need to populate your IP
    forwarding states.
    Jean Louis - but you will duplicate states in the control plane...
    What about the complexity of the synchronization.  LDP in the unicast
    case is a very static routing table.  For multicast is more dynamic.
    Think about the dynamicity and the size of the Multicast routing
    Alex - as Suresh said would be a policy decision not to install the
    (S,G) in the MRIB.  In terms of complexity - still in the same range.
    As far as dynamicity it doesn't depend on how you establish them (LDP
    or PIM + LDP). you have to deal with it.  not a function of the
    solution but of how often you do it.
    Toerless - the argument wasn't about the complexity, but about
    consistency.  If you have downstream routers with inconsistent policy
    then may be hard to get upstreams to decide it.  Let the downstreams
    decide which upstream to use.  This is specifically targeted at
    transit in the core.  PIM will always have a role at the edge.  Don't
    limit ourselves by sticking to a religious policy to use PIM.  Just
    like V4 and v6.  v4 won't be switched off, but v6 benefits will drive
    it forward.
    Suresh - there are deployments already of PIM with draft-rosen.
    Toerless - I'm not saying that, but I'm saying that mandating that
    extending PIM is the only way to approach things is wrong.
    Suresh - we're not mandating it.
    George - continue discussing on the list, we need to move ahead with
    the agenda.
    Adrian - Multicast LDP over P2MP LSP tunnels
    This is the second revision.  This was out six months ago, but fell
    off Paris agenda.
    Looking at options to expose problems/applicabilities and to address
    problems up-front.  Not our objective to favor one specific
    solution.  I We want to see the industry implement something that
    works (don't care what that is).  Not commenting on validity of
    upstream label allocation in other contexts.  If people want to use
    upstream labels in other contexts that's none of our business.
    We need to address sending packet with one label to multiple
    downstream devices.  This is an optimization.  Please see RFC3439 - in
    some cases optimization is harmful as introduces complexity.  P2MP
    tunnels present the same issues as multipoint media (since packets
    arrive at egress with the same label).
    Three models:
    1) upstream allocation
    2) upstream suggestion (co-ordinated by upstream, but
       allocated/advertised by downstream)
    3) LSP stitching.  Only works for P2MP tunnels (not multi-access
       media).  One-to-one association of Multicast LDP LSPs with P2MP LSP
    The aim is to build on Multicast LDP work, LDP sessions between "root"
    and "leaves".  Aim for wide applicability...
    1) essentially can do upstream on demand or unsolicited. Thing to note
       about on-demand is that label mapping goes the opposite way to what
       we're used to (but that's upstream allocation!)
    1. how to differentiate upstream/downstream labels.  Use Ethertypes on
       multi-access links.  On tunnels is simple as P2MP tunnels are
    2. correlating labels by advertiser.  Normally just know the interface
       as a context.  Now we have to look somewhere else for context
       (e.g. source MAC).
    3. back-to-front message flow.  Less confusing if the whole LSP used
    4. applicable to multi-access and P2MP tunnels.
    2) similar to upstream allocation - but mixed with RFC3471 on label
    suggestion.  send label mapping with a magic cookie - that causes a
    label request with a suggestion - then send label mapping with real
    label.  What is magic cookie?  (new object, special label value, ?)
    Again can do on-demand or unsolicited.  issues:
    1. increases message flow in unsolicited case (as have to solicit the
    2. but means don't have to distinguish upstream/downstream (as all
       allocated downstream)
    3. still may need de-correlation (per-neighbor label spaces).  In
       which case very similar to upstream (just different messages).
    4. also applicable to multi-access and P2MP tunnels.
    3) radical, but possible solution. for tunnels.  Doesn't work for
       multi-access.  If have P2MP LSP then may wish to do TE in part of
       the network. So stitch LDP LSP to RSVP LSP.  No label stack, so no
       issue of label resolution.  Stitching in CCAMP, but equally
       applicable here.
    1. not for multiaccess links
    2. no aggregation (1:1 stitching)
    3. no label space issues
    4. no upstream allocation
    5. allows TE.
    NOT saying make this a WG draft.  Here just to bring things to
    people's attention.  Don't jump into solutions when solutions have
    issues that we're pushing under the carpet.  Need to balance tradeoffs
    between complexity and optimality.
    Yakov - you say that have per-neighbor label space, but not upstream
    labels (in suggestion case).  In that case it isn't really a
    downstream label - since the label isn't assigned by the router.  So
    not downstream in the same sense that we mean it for unicast.
    Adrian - yes and no.  The optimization we're looking at is "how do I
    avoid any replication of packets".  If you want to avoid any
    replication then you must co-ordinate label.  If you are prepared to
    tolerate some replication (e.g. if some device can't do per-neighbor)
    then upstream allocation won't work - whereas suggestion will.
    Yakov - I think you are assuming that upstream allocation excludes
    ingress replication.  An upstream router could use upstream labels for
    some neighbors, and replication for those that can't support upstream
    Adrian - that's fair.  But would need to work on protocol exchanges
    for upstream allocation to ensure we support downstream nodes which
    reject upstream allocation.
    George - if you're going out to 100s or 1000s of endpoints then a
    suggested label is pretty much a non-starter.
    Adrian - with upstream allocation you are forcing people to use the
    same label.
    George - but you have a context in that case.
    Adrian - you have the same context - the person who's suggesting the
    label (same as the guy who allocates it in the upstream allocation
    George - if the hardware can handle that then why not use the
    Adrian - but what if the hardware can't handle it?  Duplicate it for
    the guys whose hardware can't handle it.
    Eric - the suggested label is authored as if to solve a problem with
    upstream allocation.  If the downstream guys can say "sorry - I can't
    support that label" then I can't see what this does.  (unless you want
    to send e.g. 2 copies to each of 5 downstreams).
    Adrian - fine.  If I seem to be favoring upstream suggestion it's
    because we've talked about upstream allocation a lot rather than
    upstream suggestion.
    Eric - I'm not saying there are no issues with upstream allocation,
    but suggestion seems to have some of the same issues.
    Adrian - allocation optimized for almost always having the same label.
    Suggestion for case where often get other label.
    Yakov - need to consider the non-LDP case.
    Yakov - would you be willing to split the document into two (or three?)
    Stitching has nothing to do with the first two points.
    George - if he's just feeding the group with info then it's OK to have
    it in one package, but if he wants to go to standards track then needs
    Adrian - not pushing draft towards RFC, just providing info.  If it
    would help to split the draft then will do that...
    Satoru - BGP P2MP LSP
    BGP P2MP-LSP enabled area to cover:
    1) non TE
    2) non MPLS area and interwork w/P2MP-LSP
    3) inter AS/domain P2MP LSP.
    BGP is applicable to all three of these.
    1) discover/notify branch/egress nodes.  Applicable for any P2MP
       signalling protocol.
    2) P2MP over P2P/MP2P.  Useful for migration/co-existence.
    3) policy-based P2MP tree decision.  BGP has policy based
       capabilities.  So use this per LSP.
    New BGP attribute:
    P2MP_ID (ext community) to identify the LSP
    P2MP_BRANCH_LIST (ext community) to identify the branches on the LSP.  
        (detects/prevents loops)
    P2MP-IMPORTED_BRANCH (e c) - indicates the upstream branch (i.e. join)
    data plane:
    P2MP instance.  BGP sets policy for upstream/downstream on each P2MP
    Other P2MP signalling can be used.  Separates data plane as P2MP
    instance.  RSVP/LDP may use BGP to find P2MP capable nodes.  Can
    interwork with BGP P2MP-LSP.
    current status: 
    We have a MPLS network deployed and co-existing with this to
    validate the attributes/behavior.
    next steps:
    good starting point for BGP - is there any interest in this?
    adopt as WG item?
    comments on list.
    Bruno Decraene - LDP extension for inter-area LSP
    The context is a Service Provider doing IP aggregation between areas
    and wanting to do LDP LSPs inter-area (i.e. without injecting /32
    loopbacks into the IGP areas).
    1K PEs (short term).  10K to 30K long term.
    problem is that LDP FEC needs to *exactly* match entry in the IP RIB.
    1) LDP is not a routing protocol
    2) LDP relies on routing protocols to advertise IP reachability
    3) this is not changed by this draft.
    New LDP label mapping that specifies a longest match rather than exact
    match when searching in the RIB.
    Optional behavior controlled by local policy (default is current
    Allows inter-area LSPs without /32 routes.
    no impact on LDP (still need all the FECs)
    big impact on IGP (reduces the size of IGP advertisements).  Could be
    10K routes in some deployments.
    in fact exact match is a SHOULD in RFC3036, not a MUST.
    so does this override RFC3036?
    and what should status be?
    conclusion - request feedback, and is this potential WG doc.
    Loa - agreement between CCAMP and MPLS that CCAMP does inter-domain.
    But CCAMP is not doing LDP.  So where do we take this?  Not entirely
    sure that this is within scope as stated?
    Eric - I see the problem that this is aimed at.  Not that happy with
    the solution though for two reasons:
    1) still have /32s in the forwarding table.  just saves the IP control
       plane a bit.
    2) presumptions here about how the LSPs get set up.  Hard to see how
       this would work, e.g. in independent mode.
    would like us to look at other possible solutions before going
    forward.  One reason LDP required an exact match was to prevent us
    having more LSPs than prefixes in the RIB.  Didn't want LDP to be used
    to de-summaries things.
    Alex - let's use this WG as the forum to discuss this.  If we get to
    the point where we want to do this then we can look at whether we need
    to change the charter.
    George - there's a proposed QoS BOF for inter-area stuff.  Would the
    IESG put that into CCAMP.  Don't think CCAMP is home for all
    inter-area stuff.
    Loa - agreement was that the things that are in CCAMP and MPLS then
    CCAMP does inter-domain and MPLS does multicast.
    Alex - for TE stuff.  This is the right WG for LDP.  I don't care
    where the discussion happens as long as the right people are doing it.
    this seems to be the right set of people.  Based on decision here
    we'll decide what to do.
    Adrian - you should possibly look at charter for MPLS.  Says
    multi-area/AS work is shared with CCAMP, not *in* CCAMP.
    Jean Louis - we have deployment scenarios with 10K or 20K routers.
    Want to improve IGP stability/convergence.  Since LDP relies on the
    IGP to converge this should improve LDP convergence.  Is a
    straightforward approach.  We want to aggregate at IGP boundaries.
    simple extension of LDP mapping procedure.
    Eric - you say this is simple but you've made something that is widely
    deployed (independent mode) not work.
    JL - before we made the change we tried to analyses this.
    George - We're out of time, continue the discussion on the list,
    meeting adjourned.


    MPLS signaling extensions for Upstream Label Assignment
    Component Link Recording and Resource Control for Link Bundles
    Requirements for P2MP Extensions to LDP
    BGP Point-to-Multipoint LSP
    LDP extension for Inter-Area LSP