The MPLS WG Archive

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Curtis,


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Tuesday, December 18, 2001 11:28 AM
> To: Shahram Davari
> Cc: 'curtis@fictitious.org'; neil.2.harrison@bt.com; rbonica@mci.net;
> pingpan@juniper.net; gash@att.com; mpls@UU.NET
> Subject: Re: MPLSOAM BOF meeting draft minutes 
> 
> 
> 
> In message 
> <4B6D09F3B826D411A67300D0B706EFDE84A483@nt-exch-yow.pmc-sierra.bc.ca
> >, Shahram Davari writes:
> > Curtis,
> >  
> > > The rate should be configurable.  If you want to fix it 
> at one second
> > > in your network you can still do so.  
> > 
> > Being configurable is different than being variable ! You 
> were arguing
> > that the ingress should vary its rate.
> 
> Target rate should be configurable.  Actual rate should be fixed
> unless stability is threatenned.  Stability is alway more important
> than accurate measurement.
> 
> > It is fairly obvious that the BW usage in LSP-ping method 
> is double of the
> > Harrison's proposal. And as Dave McDyson mentioned BW usage 
> is an important 
> > factor. It seems redundant to me, to feedback the 
> information to the source, 
> > when there is no problem.
> 
> Dave was referring to the forward path BW on a strictly provisioned
> LSP, not the return path which is of a traffic class (IP control
> traffic) that should have plenty of excess bandwidth.

BW is BW, be it LSP BW or IP BW. You are consuming BW resources.

> 
> > > Current hardware does not remember the prior label after 
> it is popped,
> > > so there may be a problem identifying the LSP after 
> inspecting what is
> > > underneath it.  For that we made need to limit TTL, 
> recognize the the
> > > bottom label is special (whether MPLS-OAM or IPv4 
> Explicit Null) and
> > > process according to the banished TTL expired rules.
> > 
> > This problem is solved easily in Harrison's draft by using 
> a TTSI identifier.
> > 
> > -Shahram 
> 
> Both the TTSI and any identifier in a regularly sent UDP will require
> processing and therefore are undesirable except in checks run at a
> frequency lower than the basic connectivity check.

Actually there is no need for processing the identifier. The identifier is only
a pointer to the corresponding state machine. And in fact the Ping's draft requires
a similar identifier:


   "If there are multiple LSPs between the ingress and egress LSRs, the
   ECHO_REQUEST messages MUST be differentiated by using unique
   identifiers in the Identifier field of the ECHO_REQUEST message."

And I would say the Ping's proposal is more complex because not only you need to check the mentioned identifier but also you need to check both the source IP address in the ICMP ECHO response too.