The MPLS WG Archive

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

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. CV does not
need to have sufficient information to disambiguate ping flows from
arbitrary points in the network.

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?

thks
Dave



> -----Original Message----
> From: George Swallow [mailto:swallow@cisco.com]
> Sent: Wednesday, November 06, 2002 5:27 PM
> To: Shahram Davarion 
> Cc: mpls@UU.NET
> Subject: Re: Decreasing TE-LSP bandwidth, "interoperability 
> issue" (fwd)
> 
> 
> 
> Shahram -
> 
> Just realized that I mis-spoke when I said:
> 
> > > The LSP-ID defined in Y.1711 is essentially a combination 
> of LSP-ID + Tunnel-ID
> > > as defined in RSVP-TE.  
> > > 
> > > In the current version of Y.1711, 4 bytes are assigned to
> > > this. However the current version of Y.1711 sets the 
> first 2 octets of
> > > this field to zero for future use. Therefore two methods 
> are possible:
> > > 
> > > 1) Compress the LSP-ID + Tunnel-ID in to 2 bytes 
> > 
> > This uses up all the space.  If RSVP-TE is the only application for
> > Y.1711 then this would be acceptable.  But since it's 
> called MPLS OAM,
> > I assume there were other apps in mind as well.
> 
> This is not even sufficient for RSVP-TE.  When I set up backup paths,
> the means of identification is to keep the same 
> Session_Object, and the
> same LSP-ID.  The source_IP address is set to the router setting up
> the backup tunnel.  Thats the only change.  
> 
> So suppose (a most common situation)
> 
> router A has tunnel number 1, LSP number 1.
>   this tunnel passes through some other router B
> 
> router B has its own tunnel number 1, LSP number 1.
> 
> router B sets up a backup to protect tunnel A,1,1.
> 
> it would like to ping (i.e. verify connectivity) the backup tunnel
> after it is set up to make certain that it is working
> 
> It can't set the TTSI to B,1,1 - since that is the ID for his own
> tunnel.  He can't set it to A,1,1 because that is the working path and
> he wants to check the protect path.
> 
> So the TTSI does not seem to be sufficient even for RSVP-TE!
> 
> ...George
> 
> ==================================================================
> George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824
> 
>