The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B92810@zcard031.ca.nortel.com>, "
David Allan" writes:
> Curtis:
> 
> You misuderstand me, I lump all tools (including LSP-PING, BFD, VCCV, ITU
> efforts) together under the blanket of OAM.
> 
> enough for now
> Dave


Some of these tools *will* work with ECMP without apriori knowledge of
how the split is accomplished.  Therefore you've just negated your
emphatic assertion that "Vendors who want interoperable OAM MUST
publish the protocol specifics....!"

Unless in some situations you lump all of these monitoring tools as
OAM and in other cases are talking about ITU OAM.

I agree that this is enough for now.

Curtis



> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> > Sent: Tuesday, November 18, 2003 11:56 AM
> > To: Allan, David [CAR:NS00:EXCH]
> > Cc: 'curtis@fictitious.org'; 'tnadeau@cisco.com'; mpls@UU.NET
> > Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> > 
> > 
> > 
> > In message 
> > <FFFC48AEAA5F7447929F4F0D93FCC12D02B9280B@zcard031.ca.nortel.c
> > om>, " David Allan" writes:
> > > Curtis:
> > > 
> > > >From my perspective there is simply OAM.
> > 
> > Then withdraw as an author of the framework document.  That 
> > would be like Ohta writing the IP over ATM framework 
> > (Conventional IP or ATM advocate).
> > 
> > > To date a fundamental obstacle to progressing OAM has been 
> > the issue 
> > > of how OAM flows are distinguished, esp in the presence of 
> > ECMP. When 
> > > a packet needs to be IP, when it needs to not alias as IP, 
> > > restrictions on the use of reserved labels to distinguish flows and 
> > > where such labels can appear in the stack, yadda yadda 
> > yadda. This has 
> > > been an obstacle to discussing the actual functionality required or 
> > > any other relative merits as all solutions have been held 
> > up to this 
> > > problem first without the actual problem to be solved being 
> > documented 
> > > anywhere.
> > > 
> > > Taking ECMP off the table as an issue by documenting at a 
> > minimum the 
> > > protocol aspects so we can get on with the actual functionality 
> > > required would IMO be progress. The lack of information has 
> > been THE 
> > > obstruction all along.....
> > > 
> > > cheers
> > > Dave
> > 
> > See my prior email.  If OAM doesn't work with ECMP as it 
> > exists in the real world then it is just an applicability 
> > issue that needs to be documented.
> > 
> > Curtis