RE: [mpls] Comments on draft-decraene-mpls-ldp-interarea

Eric,

First, thank you for writing down your comments.

Let me start by summarizing my understanding of your mail.
You believe the draft should work but you have some concerns regarding:
- A potential significant impact on the implementation
- LDP interactions with the RIB
- Specific cases

Regarding these points I believe that:
- The complexity of the changes on the implementation depends on the
implementation itself. For some implementations there may be minor
impacts while for others there may be more impacts.
- The interactions with the RIB are very similar to the BGP and RIB
interactions where BGP need to find and maintain the best match for the
BGP next hop. AFAIK, these interactions are not specified in the BGP
specification (RFC 4271) and different implementations had different
strategies. Additionaly I believe the same kind of interactions are also
needed for PIM (RPF check) and mLDP. So is this draft the best place for
this discussion?
- The specific cases described are indeed valid technical points but
most -if not all- are not specific to the draft and also applies to RFC
3036.

As next steps, may I suggest that:
- LDP coders express their opinion regarding the draft. For example do
you think the draft would work? Can be implemented? How hard would it be
compared to the implementations of others drafts/RFC? (eg Gracefull
Restart, mLDP, ...).
- Service Providers express their opinion regarding the draft. For
example do you think it would be usefull that LDP be able to set up
inter area LSPs while performing IP aggregation on Area Border Router?
Would you use the hierarchical solution (using BGP plus LDP to set up
inter area LSPs) for all deploiments? Would you use a flat solution
(LDP) if available?
- You send some feebacks and possibly improve the text I proposed to add
in the draft to answer some of your concerns?

Following are more detailled answers to the points you raised.

Eric Rosen wrote:
> In  San  Diego  I  expressed some  concerns  about
> draft-decraene-mpls-ldp- interarea, and Loa asked me to write them up 
> for this list.
>
> I certainly can't say  at this time that the draft just  won't work, 
> but I'm not currently convinced that the complexity is fully 
> understood, or that the proposed procedures will really achieve all
> their goals.   
> 
> A summary of my concerns is the following:
>
> - The draft purports to be making a simple change to the LDP
>   procedures, but I believe  it's actually a  fairly involved change
>   to  the implementation.
>   In particular the interaction between
>   routing, LDP, and the maintenance of the forwarding  tables is made
>   more  complicated, but the  details are not fully specified.
>
> - The draft  has LDP put prefixes  into the forwarding table  that
>   would not otherwise  be there.   Currently, LDP  doesn't do  this,
>   it  just  puts in labels for prefixes that have  been installed by
>   routing.  This means that LDP would have  functionality that was
>   formerly in  the domain of routing. The  interactions of  LDP  with
>   the various  routing  algorithms under  a variety of circumstances
>   must therefore be carefully considered.  However, the draft has very

> little about this.

To be precise, we don't necessarily need the LSR to act as LER for this
FEC (ie "forward packets that arrive unlabeled, but which are to be
labeled before being forwarded"). We need this FEC be available to other
protocols; typically MP-BGP to have an LSP toward the BGP next-hop.
Nothing requires that LDP puts prefixes in the forwarding table. We need
to put these prefixes in the RIB and some implementations have some part
of the RIB which is not downloaded in the FIB.

To come to your point, agreed LDP now needs to put prefixes in the RIB.
But only for prefixes for a which routing protocols have already
advertised IP reachability (through a superset) and defined the route to
use to reach these prefixes. In others words, the advertisement of IP
reachability and the selection of the route to reach these IP prefixes
are still required to be done by routing protocols. LDP does not take
any routing decision and does not change at all the path that will be
followed for a given prefix. Hence it cannot be considered as a routing
protocol. Installing entries in the FIB is not a sufficient condition to
be a routing protocol. The routing protocol is in charge of determining
a route for a given prefix, which LDP does not do.

In short, the IGP already advertises IP reachability and the path to use
to reach the remote PE. IP is working just fine. What we are lacking for
MPLS to also be working are the labels for each remote PE. Isn't LDP the
good candidate for this task ?

Regarding the addition of a prefix in the RIB by a non routing protocol,
is this a real issue? Doesn't RSVP-TE also install the tunnel
destination prefix in the RIB?

> - The draft focuses on the use of the new procedures in a particular
>   sort of deployment scenario, and doesn't say much about the effects
>   on the network if the procedures were to be used in other
>   deployment scenarios, or if the procedures were misconfigured, etc.

The deployement scenario is the set up of inter area LSPs and the draft
describe procedure for this. 
Do you think of others deployement scenario for which this procedure
should be useful?

Regarding misconfiguration, in the general case, any protocol will not
behave as expected if the network operator makes a mistake.
If the procedure is misconfigured (activated by error or activated on
FECs which are normally advertised in the routing protocols and should
behave according to RFC 3036), in case of egress LER failure, the LSP to
this LER may not be immediately removed following the IGP convergence
because some IP aggregate prefixe may still match the FEC. In this case
the LSP will be removed by LDP when the withdraw messages are propagated
(cf draft section 6.2). 

Would this be fine for you if we add such text?

> - I think that the major purpose of the proposal is to facilitate the
>   use of LDP-based  node protection  for area  border routers.  
>   However, I  am not convinced that the proposal really achieves this 
> goal.

One goal is to be able to keep IP aggregation between IGP area. I
believe we both agree that this is a desirable goal.
To achieve this goal, some may favor a hierarchical solution. Others may
favor a flat solution. Regarding Orange/France Telecom, at least for one
deployement we favored the flat solution when we introduced IGP areas
because this is easier: PE routers in edge areas have the same
configuration and use the same protocols as existing routers in the
backbone areas. (more on this latter)

> Let  me start by  summarizing my  understanding of  the draft.   The
> problem
> addressed by the  draft is the following.  There are  a number of 
> situations in which an  ingress PE needs to send  a packet on an LSP 
> tunnel whose "LSP egress" is a PE router (the  "egress PE").  This
> requires the "tunnel label"   
> to be bound to a /32 prefix  for the egress, which in turn requires 
> that the ingress PE's forwarding table contain a /32 prefix for each 
> potential egress PE.
>
> The authors describe  a deployment scenario in which  the service 
> provider's backbone is a multi-area IS-IS or OSPF network, containing 
> tens of thousands of PE  routers distributed across the  areas.  The 
> usual way  of getting all the  /32s in each  ingress PE's  forwarding 
> table  is to  have all  IGP area border routers leak all the /32s into

> each area.  Then the IGP ensures that each ingress PE's
> forwarding table is populated with all the /32s.      
> 
> The problem is that the intra-area  IGP protocols don't scale up well 
> as the number of prefixes increases into the tens of thousands.
> Therefore it would be  desirable to  have  some other  way of getting 
> all the  /32s into  the forwarding tables of the ingress
> PEs.    
> 
> The proposal is to use LDP, rather  than the IGP, to distribute the 
> /32s and to ensure  that the  ingress PE's forwarding  tables are
> properly populated  with the /32s.   
> Note that this does not really reduce  the resources in the core 
> needed to  support the LSPs to the PEs, it  simply changes the 
> protocol which is used to allocate  some of those resources.

you don't change the protocol as you still use LDP. You use one protocol
instead of two. Instead of advertising the prefixes twice you advertise
them only once. 

> Resource consumption in the P routers of  a given area is still
> proportional to  the total number of PEs in all the areas.   

This allow to advertise the /32s only in LDP rather than both in LDP and
the IGP. This is an obvious significant gain for the IGP. Agreed there
is no gain (but no loss either) for LDP or the forwarding table.
Besides, this seems reasonable for me to put the burden on LDP rather
than the IGP because IP doesn't need these /32 whereas MPLS does.
Additionaly LDP uses incremental messages over TCP so seems better
suited than link state IGP. Not to mention that link states IGP are not
designed for advertising tens of thousands of prefixes, especially when
advertised by a single node (the ABR in our case). For instance with
IS-IS there is an hard limitation around 42K IPv4 prefixes (max LSP
fragment size = 1496 and max #fragments = 256) (and even less if IPv6 is
deployed). In return with LDP there is not such limitation.

> It might seem that a better solution  would be to use hierarchy, so 
> that the P routers do not  have to maintain an LSP for each  egress 
> PE. For instance, BGP between  the border routers could  carry the 
> /32s, without  any need for the  P routers to  maintain the  /32s are 
> all.  However,  I think  that the authors actually want  to the P 
> routers maintain an LSP  for each egress PE, because  they believe 
> this to  be a  necessary condition  of  applying node protection when 
> a border router fails.  So they frame the problem not as one of 
> reducing the resource  usage in the core, but as one  of finding a
> better protocol to allocate those resources in the core.         

The use of hierarchy is a perfectly valid solution. It has pro & con
compared to the use of LDP inter area.
As you said the advantage is that it does not require P routers to
maintain the /32. However, one may weight this advantage in regard to
the (usually) small numbers of P routers compare to the high number of
PE routers.
One disadvantage is that it requires BGP on ABR. Depending on some
engineering choice, it may also requires that ABRs be iBGP route
reflectors and change the BGP next hop to themselves. Another
disadvantage is that the set up of PE to PE LSP requires two protocols
(LDP plus BGP) and two labels instead of one. This may add complexity to
the monitoring and the troubleshooting.

> One could of course put IBGP in all the P routers and use IBGP to 
> distribute the /32s.  However, the authors  do not like the 
> operational implications of putting BGP in  the core.  I'm not sure 
> they've  considered a restricted use of BGP for distributing only the 
> egress PE addresses;

I believe we did. The use of BGP to carry labelled IPv4 unicast adresses
(as per RFC 3107) is only needed on ABR and PE (and probably iBGP route
reflector), not on P routers. I would not call this a "restricted use"
as is requires modifying BGP configurations (new AFI/SAFI, probably new
iBGP peers) on all PE and RR ie 90% of the network equipments in the
network.

To conclude on the hierarchical solution, do you think we should add a
section in the doc to present it and explain why this alternative does
not fit all deployments ? Personnaly I'm not sure this would fit well in
a solution draft. Such analysis should be part of an applicability
statement draft.

> often when we talk of a "BGP  free core", what 
> it really  important is that  the core be  free of     
> external routes,  rather than that it be  free of BGP protocol. 

I agree that removing the external routes really matter but if you can
also get rid of BGP on P routers that's an additional benefit. Some
service providers do have BGP free core and they did it on purpose.

> But in any event they propose to use LDP.
> 
> I think the proposed operational model is the following:
> 
> - A PE, say  PE1, is configured to bind  a label to its own address 
>   A (as a /32  prefix),a  and  to use  LDP  distribute  this  label
>   binding  to  its neighbors.
> 
> - If  P1 is  a neighbor  of PE1,  and PE1  is P1's  next hop  for A, 
>   and P1 receives a label binding for A from  PE1, then P1 must put
>   an entry in its FIB for A, with the label distributed by PE1.
> 
> - P1 must then assign a label of its  own to A, and use LDP to
>   advertise the binding A and that label to P1's neighbors.
> 
> - Using LDP  ordered mode,  this process  proceeds out to  the edges 
>   of the network.  However, it does not go beyond the edges.
> 
> This operational model  is not completely clear to me.   I surmise
> that each
> PE needs to  be configured to begin this process. 

I'm not sure to follow you. Especially I fail to see the difference
between your above text and the existing LDP ordered distribution mode.
This does not necessarily require any configuration, this can be done by
default (advertise FEC for which you're egress eg your loopback), this
is how many LDP implementations work today.

> I'm  less clear
> about how other nodes  know whether or not  they are on  the "edge"
> of the  network. 

They don't need to know that they are on the edge. FEC propagation stops
when there is no LDP session with the downstream (Typically on the edge
of the AS) or when the downstream has no IP route with the upstream for
the FEC. Just like today. The only change beeing the "match algorithm"
between FEC and RIB prefixes.

> I think the  authors have in mind  a deployment
> scenario in  which the "edges"   
> are inter-AS  interfaces and VRF  interfaces, but inter-area 
> interfaces are not considered to be edges.  But I'm  not sure what the

> model is supposed to
> be in general.   Are VRF interfaces always edges,  even if Carrier's
> Carrier is being  used? 

In section 5 "Application examples" of the draft, the authors have
described a deployment scenario in which the "edges" of the SP network
are the PE ("Provider Edge"). Regarding VRF Carrier's Carrier, even if
LDP is used to distribute MPLS labels to the VPN customer (rather than
BGP with RFC 3107), they advertise customers prefixes, not SP ones. So
there is no relation between the LDP in the core and the LDP in the VRF
carrier's carrier; Just like there is no relation between the routing
protocol in the core (the SP one) and the routing protocol in the VRF
(the customer one).

> Are inter-AS interfaces  always edges, even if  a single SP has broken

> his network into several  ASes.

If you refer to BGP confederation, I suppose it depends if you use one
IGP or multiple IGP. 
If have one IGP, you don't have IGP frontier or borders so you don't
have issue with LDP mandating a longest match.
If you have multiple IGPs,
- if ASBRs change the BGP next hop I don't see the need to leak the /32
in the IGP and LDP from one AS to the other.
- if ASBRs preserve the BGP next-hop, you need to advertise to the other
AS IP reachability for the routers next-hop and you typically have the
same use as in the inter area case described in the draft: either you
advertise all the /32 in the IGP, or you need a hiearchical solution, or
you need the LDP inter area draft.

If you refer to inter AS VPN model C, this is basically identical to the
last case described in the above text. (you can use a hiearchical
solution or the ldp-inter-area draft)

> Is it true that
> inter-area links are never  edges, or is this meant  to be 
> configurable?

Inter-area links are edge from the point of view of the link state IGP.
If you leak all /32, you don't have issue with LDP mandating the exact
match. If you don't, you need a solution (again, hierarchy or LDP inter
area). This is a matter of choice for the SP.

> If  the latter, are there deployment requirements  for
> all area border routers  to be configured the same?    

Currently, IGP policy allows you to have different rules (leaking or
aggregation) per ABR/area but usually SPs perform the choice once and
apply it globally. The draft does not change this.

(I'm not sure I got your point so please elaborate on this if I missed
it)

> In  any event,  the authors  note that  the  use of  LDP in  this 
> manner  is explicitly prohibited by the LDP  specification, which 
> requires that LDP not install a  label for any  prefix if that  exact 
> prefix has not  already been installed in  the forwarding table by 
> routing.  That is, LDP  cannot bind a label to a prefix  unless that
> prefix is an exact match  to one installed by routing.     
> 
> This  prohibition  didn't   get  there  by  accident.   It   was  put
there 
> deliberately to  ensure that LDP  cannot "second guess" routing  by 
> creating paths which differ  from the paths created by routing.

Could you provide any relevant reference where the exact reason(s) for
this limit is/are detailed ?

In the inter area draft, LDP entirely relies on the routing decisions
taken by the routing protocol.
LDP DOES NOT TAKE ANY ROUTING DECISION.

Could you please provide one example where the draft would have LDP
create path which would differ from the paths created by routing?

>  After all, LDP does
> not have  its own procedures for  deciding which path an  LSP should 
> follow, it depends upon routing for this.

Absolutely. This is definitely not changed by the draft and LSPs set up
by LDP still strictly follow the path chosen by routing protocols.

> The authors  propose to remove this  prohibition, and instead  impose 
> a more sophisticated restriction, which they express as follows:
> 
>    "This procedure  is similar to  the one defined  in [LDP] but 
>    performs a longest match when searching the FEC element in the RIB 
> ...
> 
>    With this new longest match label mapping procedure, a LSR
>    receiving a Label Mapping message from a neighbor LSR for a Prefix
>    Address FEC Element SHOULD use the label for MPLS forwarding if
>    its routing table contains an entry that matches the FEC Element
>    and the advertising LSR is a next hop to reach the FEC. If so, it
>    SHOULD advertise the FEC Element and a label to its LDP peers.
> 
>    By 'matching FEC Element', one should understand an IP longest 
> match."
> 
> The intention is to maintain the requirement that LDP not alter the 
> routing, while allowing  LDP to install prefixes  that are not 
> installed by routing.
> They propose  to allow LDP  to install a  prefix if and  only if there

> is a corresponding  less specific  prefix  that has  been installed by

> routing.
> Further, the next  hop of the LDP-installed prefix is  constrained to 
> be the same as the next hop of  the less specific prefix, as 
> determined by routing.
> This should ensure that labeled packets always follow the path that 
> has been determined by routing to be the best path.

I understand from your conclusion that removing the LDP requirement for
an *exact* match should be ok from a routing point of view. 

> It must  be understood that  this procedure adds considerable 
> complexity to the maintenance of the forwarding tables.
> 
> In  existing LDP deployments,  all LDP  does with  regard to  the 
> forwarding table  is to supply  the label  for a  given <prefix, next
> hop>  pair which routing has installed  in the forwarding table.
> In the  proposal, LDP has a number of additional jobs to do  with
> regard to the forwarding table.  Let's define some terminology:    
> 
> - Let RP be a prefix distributed by routing.
> - Let NH(RP) be the next hop for RP.
> - Let LP(i) be a prefix distributed by neighbor i using LDP.
> - Let RP(i) be the set of LDP-distributed prefixes from neighbor i
>   for which RP is the longest match.
> 
> If NH(RP) changes from  i to j, things aren't too hard,  as long as
> RP(i) is identical to RP(j).  Then you just  have to change the next 
> hop and outgoing label for each prefix in RP(i).

Agreed.
BTW this is basically the current LDP behavior. The difference being
that currently, at most one FEC have its next-hop change where as with
the ldp-interarea draft, multiple FECs can have their next-hop changed.

> It's a  bit more  complicated if  RP(j) is different  from RP(i).  
> Now some prefixes need to  get their nh and label changed, but  others

> need to either be put into or pulled out of the forwarding table
entirely.

IMHO, the difference is the same: with the draft multiple FECs may have
to be updated whereas currently the "set of LDP-distributed prefixes" is
limited to 1 (or 0) element.

In RFC 3036 (current LDP) for a given FEC three cases are possible
following a routing change
- nh and label changed
- new FEC put in
- FEC pulled out

We have the same cases with the draft. The difference is that the set is
not limited to 1 FEC and multiple FECs may need to be updated.

> It's even more  complicated if routing installs a new  prefix, RP2, 
> which is more specific than  an already installed prefix RP1,  but 
> less specific than some members of RP1(i).  (And possibly more
> specific than some other members   
> of RP1(i)).   Now one has  to figure out  which members of RP1(i) 
> remain in
> RP1(i) and which are now in RP2(i).  In fact, one has to figure this 
> out for each of the neighbors.

Indeed the case where the routing install a new prefix more specific
than the one used to match some FEC is a new behavior. Indeed for this
case the LSR need to detect that the new prefix is a better match. The
impact on the implementation is probably very implementation dependent
so its hard to discuss it from a general point of view. One
implementation strategy is that LDP ask the RIB the next hop to use for
its FEC (ie the IP best match) and ask to be notified of a change. In
this case, LDP only has to deal with three cases:
- next-hop change
- next-hop disappeared (there is no route for the FEC)
- next-hop appeared (routing advertised a new route which for a FEC
which had previously no route) 

These 3 cases would not be different from the existing cases from RFC
3036 so this would not "add considerable complexity".

You would probably argue that the complexity is pushed to the RIB but
BGP has exactly the same job to do to resolve its BGP Next Hop so this
is definitely doable and has been so for some years.

> Certainly this  could all be made to  work, but it's not  exactly the 
> simple change that  the draft suggests it  is.

The change is minimal from a specification point of view.
The impact on the implementation may be significant or not but this is
very implementation dependent.

> It would  be nice to
> see  section 4 replaced with  a much  more comprehensive treatment of 
> how  the interaction between routing events  and LDP events affects 
> the  forwarding tables.  I am not at all sure that I yet
> understand all the implications.     

Ok. What about adding something like:

"As per RFC 3036, LDP has already some interactions with the RIB. In
particular, it needs to be aware of the following events:
-	prefix UP when a new IP prefix appears in the RIB
-	prefix DOWN when an existing prefix disappears
-	next hop change when an existing prefix have new next hop
following a routing change.

With the longest match procedure, some LSR reactions following a RIB
event are changed:
-	When a new prefix appears in the RIB, the LSR MUST check if this
prefix is not a better match for some existing FECs. (Eg the FEC
elements 10.0.0.1/32 and 10.0.0.2/32 used the IP RIB entry 10.0/16 and a
new more specific IP RIB entry 10.0.0/24 appears). This may result in
changing the LSR used as next hop and hence a change of outgoing label
for this FEC.
-	When a prefix disappears in the RIB, the LSR MUST check all FEC
elements which were using this RIB prefix as best match. For each FEC,
if another RIB prefix is found as best match, LDP MUST use it which may
result in changing LSR used as next hop for this FEC and hence a change
of outgoing label for this FEC. Otherwise, the LSR MUST remove the FEC
binding and send a label withdraw message."

As your detailed comments shows you've started the analysis, your input
or comments on this would be welcomed.

However the following protocols already have similar interactions with
routing event: BGP (from BGP next hop resolution), PIM (for RPF check),
mLDP (to determine the 'upstream LSR') and probably others. They don't
specify this interaction so I'm not sure to understand why suddenly this
becomes needed for the inter area draft. 

> The draft also needs a lot more consideration of "corner cases".
> 
> For instance, what if BGP and LDP each distribute the same /32 prefix,

> while IGP  distributes  a less  specific  prefix?
>   It's  not immediately obvious
> whether the LDP-distributed prefix  is supposed to match the 
> IGP-distributed less  specific  prefix, thereby  replacing  the 
> BGP-distributed prefix,  or whether the LDP-distributed prefix  is
> supposed to match the BGP-distributed   
> prefix. 

This is not really specific to the draft.
I don't think that RFC 3036 specifies that the routing protocol
advertising the prefix in the RIB should be taken into account. This
should probably not be changed.

Do you think different implementations made different choice? Ie some
implementations consider the whole RIB whereas some other
implementations filter out the RIB prefixes learnt through BGP? 
In that case:
- which would be the correct behavior (originally intended by RFC 3036)?
- would both implementations be compliant with RFC 3036?
- that would create an interoperability issue for the ldp-interarea
draft because different implementation could select different prefixes
in the RIB and that could lead to permanent routing loops. So we would
need to mandate only one behavior. We will select it based on your and
the MPLS WG feedback.

>  It's  also   not  clear  just  what  you'd  have   to  do if  the 
> LDP-distributed prefix matched a BGP-distributed prefix, because the 
> notions of "next  hop" are different.

Not sure I fully got the point but it seems to me that the question is
not really specific to the draft and is also valid for RFC 3036 :
LDP: FEC 10.0.0.1/32
BGP NLRI 10.0.0.1/32 NH ABR
IGP: ABR -> interface I

> To  add a further
> complication, suppose that the BGP-distributed  prefix is  really a
> labeled-IPv4  prefix.  What  is the relation between  the
> BGP-distributed  label and the  LDP-distributed label?    
> Are they both used, or not?   Questions like these need to be
> addressed, and
> the implications of answering them one way or another need to be 
> considered.

This is definitely not specific to the draft. The same question is
already valid with the current LDP specification (RFC 3036).
Additionaly we have the same question with IPv4 unicast prefixes.
Usually implementations I'm aware of use some kind of administrative
distance / preference ranking protocols priorities.

> Here's another  case worth considering.  Consider an  intermediate P 
> router, P1, with neighbors P2 and P3.  Suppose:
> 
> - IGP distributes a route to prefix X.
> - Using LDP,  P2 distributes a label for  prefix Y, where X  is the
>   "longest match" for Y.
> - P3 does not use LDP to distribute a label for Y.
> - At time t0, the next hop at P1 for X is P2.
> - At time t1, the next hop at P1 for X is P3.
> 
> I think this means that at time  t1, any packets which P1 receives 
> that have been labeled for Y will be dropped  by P1.  Why?  The more 
> specific prefix Y will have to  be removed from the forwarding table 
> at  t1, as the conditions for having it in  the forwarding table no 
> longer seem to  hold, given the P3 has not  distributed a label  for 
> the longer  prefix.  Thus the  labels that correspond to  Y will also 
> be  removed, and packets which  have already been labeled for Y will 
> find that there is no outgoing label corresponding to the incoming
> label.  This means they must be dropped.        

This is not specific to the draft. We have exactly the same issue with
RFC 3036 (replacing "Y" by "X" and "longest match" by "exact match").

> One could dismiss this as a transient, but if the whole reason for 
> doing any of this is to  make node protection work, i.e., to avoid the

> bad effects of routing  transients, then  one presumably  is  not
> willing  to just  dismiss transient effects.   
> 
> This scenario could occur, e.g., if a given egress PE can be reached 
> via two different ABRs, where one of them is implementing the draft 
> but the other is not (or where one is configured to use the draft 
> procedures but the other is not). One could  dismiss this as an 
> operator error,

This is not specific to the draft.
This scenario can already occur with the current RFC 3036 if the
operator forgot to configure LDP on the backup P/path.

> but  it can also happen if  a new  ABR comes  up and 
> the distribution  of routing  info  across the     
> network proceeds faster  than the distribution of LDP info.  

This is not specific to the draft.
It also already occurs with RFC 3036 if a new P comes up and the
distribution  of routing  info  across the     
 network proceeds faster  than the distribution of LDP info. 
(BTW it also occurs with iBGP (IGP convergence precede iBGP sessions
going up and running. Hence customer traffic is dropped)

> Note that on a
> single link, we can implement procedures  which keep the link from 
> coming up to routing until LDP has distributed  labels over the link, 
> in order to keep things like this from happening.

This is not specific to the draft.
It's already implemented on some boxes to fixe the two above cases.

> That's  fine as
> long as LDP operations are per-link.  When  we start to  provide LDP 
> operations that  have edge-to-edge significance, such as using LDP to 
> build a path for X across the network, we don't have any similar way
> to synchronize the LDP and IGP info.   

I'm not sure to follow your point. Could you please be more specific? 

> There may be other corner cases as well.
> 
> If a  decision is  made to pursue  this draft,  I think it  needs to 
> have a fairly comprehensive treatment of  (a) all the possible 
> interactions between and routing, and (b) the behavior  of the scheme
> when deployed in other than   
> the  intended  manner. 
>  Also, if  the  main  purpose  of  the draft is  to facilitate an 
> LDP-based node protection scheme for border routers, it should provide

> a better  assurance that  it doesn't  leave a  number of transient 
> conditions unprotected.
> Without this additional  work, I think it is difficult  to tell 
> whether this is ultimately a direction worth pursuing.

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls