The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Hi Eric:

> > You are misunderstanding some of the intent of Y.1711 CV in 
> your example.
> > It
> > is designed to do path availability measurement/path 
> failure detection for
> > the tunnel and possibly facilitate path based protection 
> switching. It
> > does
> > not do ad-hoc ping verification from arbitrary points in 
> the tunnel to
> > support FRR, that is a more complex function (see below).
> > 
> > So in your example lets add LSR 'E' which is where the tunnel 
> > terminates.  A,1,1 is working fine and CV flows from A to E. 
> > At some point B switches traffic to the backup path also 
> > terminating at E (or remerging with the original tunnel somewhere
> > downstream), ...
> 
> What does this mean?  Downstream of where?  Surely not downstream
> of E which is the egress for the tunnel...

No certainly not downstream of E. Re-merges somewhere between B and E is
more precise.

> 
> > ... and CV continues to flow from A to E (with a slight detour ;-). 
> > This assumes the protection works perfectly. If it did not, then 
> > CV would be interrupted, and the failed LSR-ID/Tunnel ID would be 
> > flagged to mgmt or for some other corrective action. CV does not
> > need to have sufficient information to disambiguate ping flows from
> > arbitrary points in the network.
> 
> This sounds like correct and expected behavior.  CV is interrupted
> as a result of a failure.  Is there something wrong with this?  :-)

Nope.

> 
> > 
> > This would bring to mind an interesting question which I wouldn't 
> > mind your answer for my education. In FRR, let's add 'D' which is 
> > a merge point for detours upstream of the egress.
> >               ST   SO
> > 		(A,1)(E,1)->
> > 	A------------B-----------D-------------E
> > 			  \_________/
> > 			   ST    SO
> > 			  (B,1)  (D or E,1)
> > 
> > A detour set up from B to D presumably only propagates the backup 
> > paths session object and sender template as far as 'D', so that 
> > the existence of the backup path B-D is not known to E. Any ping 
> > for ad-hoc verification of the backup path would flow B-E, so a 
> > change in the sender template that B would use when pinging for 
> > the path would not be known to E. So in this case E needs some 
> > extra logic to pry 'A' out of the extended tunnel ID and figure
> > out that this ping is from 'B' for the LSP originating at 'A'? 
> > In other words, if the extended tunnel ID is not zero then it 
> > effectively overrides the ID in the sender template for the 
> > purposes of identifying what is being tested and the sender 
> > template identifies who is doing the testing and some of the
> > LSP details? DO I have this correct?
> 
> Wouldn't you expect D - as the merge point - to convert the tunnel
> information to something known in common with its downstream E?

yes, I figured out the piece I was missing (reading and understanding being
unsynched).....it just took a second to grok when extended tunnel ID is zero
and when you use it. And how it would work with LSP PING (which except in
traceroute mode will not stop to sightsee at 'D' but then B can fix that).

rgds
Dave


>>