The MPLS WG Archive

[neil.2.harrison@bt.com]

Dave....small point, please in-line below.  regards, Neil

David Allan wrote 07 November 2002 09:35
> George:
> 
> 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) , 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.
NH=> This is quite correct.....in fact anything else would not be.  The
example shows subnetwork protection.  Further, all of the link-connections
between adajacent pairs of nodes will be served by lower layer trails (maybe
SDH VC4 say).  One would *not* require a client trail to go changing any of
its identifiers for topology changes in any lower server network
layers...and this case is architecturally no different.  Indeed, the only
thing that is relevant for the LSP fault management is the verification that
the correct source point is connected to the correct sink point....arbitrary
lower layer routing changes should not (and indeed must not) have any impact
on the client (unless any prot-sw therein fails to react in some time T,
after which the client trail will detect a failure (missing CV with correct
TTSI) and can take its own action....but *please* don't make T too small,
like <1s, else you will end up uncessarily switching on each/every error
event at the client level....compounded for those who think
bumping/pre-emption is a good idea).
<snipped to end NH>