The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Dec> msg00270



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLSOAM BOF meeting draft minutes

  • From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
  • Date: Tue, 18 Dec 2001 10:29:38 -0800
  • Cc: neil.2.harrison@bt.com, rbonica@mci.net, pingpan@juniper.net, gash@att.com, mpls@UU.NET

Curtis,

> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org]
> Sent: Tuesday, December 18, 2001 12:35 PM
> 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 
> <4B6D09F3B826D411A67300D0B706EFDE84A489@nt-exch-yow.pmc-sierra.bc.ca
> > > 
> > > 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.
> 
> I'm using BE not EF.
> 
> > > 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 on
> > ly
> > a pointer to the corresponding state machine. And in fact 
> the Ping's draft re
> > quires
> > 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.
> 
> 
> Implementation hint.  Since this is a unique 32 bit integer sent by
> the ingress and interpreted only by the ingress, a table index would
> be a good choice of number to stick in there.
> 
> I hope I don't have to argue with you about whether a table index
> lookup incurs excessive processing overhead.

No you don't need to argue that. But I clearly showed that the amount of
processing in Ping's proposal is not less than Harrison's proposal (if not more).

-Shahram

> 
> Curtis
>