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
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
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
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
Believe that draft has been stable for some time - so would like a
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
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
P2MP FEC element contains the root address (source address from LSP
point of view). Tree identifier serves as way to merge things
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
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
Jean Louis - LDP upstream draft showed simple procedure to avoid
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
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
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
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
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
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).
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
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
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
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
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
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.
P2MP-IMPORTED_BRANCH (e c) - indicates the upstream branch (i.e. join)
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.
We have a MPLS network deployed and co-existing with this to
validate the attributes/behavior.
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
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,