The MPLS WG Archive

["Gray, Eric" <egray@celoxnetworks.com>]

David,

	Some questions/comments below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
egray@celoxnetworks.com
508 305 7214


> -----Original Message-----
> From: David Allan [mailto:dallan@nortelnetworks.com]
> 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), ...

What does this mean?  Downstream of where?  Surely not downstream
of E which is the egress for the tunnel...

> ... 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?  :-)

> 
> 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?

> 
> 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
> >
> >