The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <3ACB4841.4C92AA14@sandburst.com>, Eric Gray writes:
> Curtis,
> 
>     The discussion of whether or not a network operator would
> use LDP - with or without fault tolerance - as a mechanism
> for establishing LSPs for the purpose of transporting other
> LSPs is a side-track, down which I do not wish to proceed
> any farther.  I raised the point only to establish that there is
> another perspective and I believe I have accomplished that.

I agree.  Whether LDP or CR-LDP would ever be used on the outer tunnel
is a separate issue.

>     Back on the issue you raised.  As anyone who might have
> come close to correctly implementing LDP will know, routing
> drives LSP set-up and tear down.  If an LSR looses a peer in
> a routing protocol (pick one, any one),  routes are re-computed.
> For routes that have changed upon re-computation, LDP gives
> a rigorous set of procedures for determination of appropriate
> response with respect to existing LSPs (and - for the liberal
> retention case - validity of labels not even in use).
> 
>     Note that LDP procedures are defined indepedent from the
> specific _internal_ procedures that a router uses to determine
> that a route has changed.  If you do not feel that this is the
> case, then I suggest you raise this issue with the working
> group as an issue with LDP rather than with LDP FT.

If you have A-B-D-E and A-C-D-E and A-W-X-Y-Z-E and B just went down,
a topology change at D-E (D-E went down) may make the path A-B-C a
poor choice.  C may have decided that the best path is by way of A
since D-E is unavailable and is dutifully trying to inform B of the
situation with a Label Withdraw, who will take note of it and inform A
in due time after its finished rebooting.

In your example on page 24, C would play the role of P2 and queue the
label withdraw.  B would be P1.  A is on the other side of P1.  Maybe
I'm missing something.

>     In reading the current LDP FT specification, you probably
> discovered that it describes exactly how a fault tolerant LDP
> implementation is expected to deal with labels that are made
> invalid for the entire period during which it is unable to obtain
> confirmation that a peer has been informed of the invalidation.
> If there are details of this process that are not clear to you,
> please address those details.

Ok.  I just went through it again and I don't see how the above
example is handled.  Maybe I'm just dense but I missed it and I'd like
you to explain how the LDP-FT procedures handle the above example in
the event that it take B some 20-30 seconds to come back up.

>     If, as I assert, LDP procedures are independent of specific
> routing protocols and LDP FT defines procedures for ensuring
> that LDP procedures are adhered to across multiple sessions,
> then LDP FT is equally independent of specific routing protocols.
> 
>     Hopefully, this will clear up any fear, uncertainty or other
> doubts that this discussion may have raised. :-)
> 
> --
> Eric Gray

Your explanation will certainly clear things up.

Thanks in advance,

Curtis


> You wrote:
> 
> > In message <3ACA41AB.2A3ACB59@sandburst.com>, Eric Gray writes:
> > > Curtis,
> > >
> > >     As I understand it, LDP is the preferred protocol for use
> > > with MPLS BGP when BGP peers are not adjacent with
> > > respect to an MPLS domain.  Suppose that MPLS BGP is
> > > used to establish many VPN services which are possibly
> > > being used to provide a label switching service to enterprise
> > > customers.
> > >
> > >     For that matter, suppose that LDP is being used to signal
> > > and maintain <your favorite> VPN technology's LSPs.
> >
> > Eric,
> >
> > You wouldn't be using LDP on the outer tunnel, just the inner VPN
> > tunnel.  The outer tunnel is a RSVP-TE tunnel.  We are already lab
> > testing this at a customer and it interoperates nicely with other
> > people's BGP/VPN LDP implementations.
> >
> > Because the TE tunnel is rerouted around a failure the LDP adjacency
> > that ride inside the TE tunnels never go down.  The LDP TCP connection
> > sees some temporary loss at worst and then continues as if no topology
> > change occurred because the logical adjacency never went down.  This
> > works as long as there is a brief holddown on the TE tunnel and it
> > reroutes before the holddown expires.  In practice works great.
> >
> > Where you want to maintain LDP (and IGP) adjacency is where a router
> > is reloaded for something like software upgrade and nothing else in
> > the IGP changes during the reload time.  If you have two route
> > processors on the router that was reloaded, that should be a switch in
> > well under a second.  Rumor has it that some routers with one route
> > processor take a few minutes to reload so for those, if the topology
> > changes you'd rather route around them.
> >
> > So please remind me, exactly what was the point of your objection.
> > :-)
> >
> > Curtis
> >
> > > You wrote:
> > >
> > > > In message <3ACA3769.1E1C006F@sandburst.com>, Eric Gray writes:
> > > > >
> > > > >     I also suspect that you may be understating the advantages
> > > > > of maintaining session context.  Consider the impact to the
> > > > > network if LSPs are dropped lightly and these LSP are in turn
> > > > > being used to carry (stacked) LSPs.
> > > > >
> > > > > --
> > > > > Eric Gray
> > > >
> > > > You wouldn't be using LDP in that case.  ;-)
> > > >
> > > > Curtis
> 
>