The MPLS WG Archive

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

George, 

ignore the question al the end of my last message, I answered it myself ;-)

rgds
Dave

> -----Original Message-----
> From: Allan, David [CAR:NS00:EXCH] 
> Sent: Thursday, November 07, 2002 4:35 AM
> To: George Swallow; Shahram Davari
> Cc: mpls@UU.NET
> Subject: RE: Decreasing TE-LSP bandwidth, "interoperability 
> issue" (fwd)
> 
> 
> 
> 
> 
> 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
> > 
> > 
>