The MPLS WG Archive

[Giles Heron <giles@goneto.net>]

Hi Andy,

I'm not sure you're getting my point?

I agree 100% that there is no way to be sure that your peer has a valid
tunnel to you.

The point is that if you don't have a valid tunnel to your peer then you
should not advertise the VC label.

The intention is that this will keep the bidirectional VC "down" unless
both ends have valid tunnels to each other.

It may be worth rewording the text to make this clearer?

Giles

"Andrew G. Malis" wrote:
> 
> Giles,
> 
> > > >MPLS in IP or MPLS in GRE is a tunnel as far as I'm concerned - so you
> > > >shouldn't withdraw the labels.
> > > >
> > > >But yes, I take your case about backup tunnels.  Really this is the
> > > >standard issue of layering and holddown timers isn't it?  IF the backup
> > > >tunnel doesn't kick in within x seconds THEN withdraw the advertised
> > > >labels?
> > >
> > > It's not just that.  Another problem the current language is, for example,
> > > if A is advertising VC labels to B using DU, A needs to somehow figure out
> > > if B has a tunnel (of any sort) back to A before it can advertise the label
> > > to B.  I think that's impossible in the general case.
> >
> >I'm ahead of you here (I think!)
> >
> >Luca and I had just this debate - I was trying to persuade him to take
> >the text out on this very pretext.  Somehow he persuaded me that you
> >should still withdraw the label if you don't have a tunnel.  My memory
> >is rubbish, but I think the argument is that if A OR B doesn't have a
> >tunnel then it will withdraw its label and the (bidirectional) circuit
> >will go down.  Also of course in the (non-general) case of RSVP-TE
> >tunnels A and B should both know the status of tunnels in either
> >direction?
> >
> >Giles
> 
> I think it's impossible to make this check in the general case.  Here are
> some reasons:
> 
> 1. The IP addresses used in RSVP and LDP signaling may be
> different.  Imagine an LSR using a distributed architecture over a number
> of line cards.  The RSVP tunnels are anchored in the line cards of their
> associated interfaces, and use a unique IP address for each line card in
> the RSVP sender object.  However, the LDP signaling for VC labels is
> anchored in a central processor card, and uses its own IP address.
> 
> If you're using OSPF or ISIS within an area, then presumably you can look
> at the RSVP and LDP IP addresses and confirm in the link state database
> that the RSVP and LDP addresses are from the same router ID.  However, that
> is not possible across areas, between ASes, or when using non-link-state
> routing protocols.
> 
> 2. Even if an incoming TE tunnel's sender address matches that used for the
> LDP signaling, the receiving LSR has no way of knowing whether or not the
> sending LSR will choose to use that particular TE tunnel to carry the VCs;
> it may be restricted to IP traffic engineering.
> 
> So the sentence really has to go, since I think it's not implementable.
> 
> Cheers,
> Andy

-- 
============================================================
Giles Heron      Principal Network Architect      Gone2 Inc.
ph: +44 7880 506185         "if you build it they will yawn"
============================================================