The MPLS WG Archive

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

Hi Curtis:

We have different interpretation of the requirements....and that seems to
see us talking past each other. If tools are to measure/test/verify the data
plane, then there needs to be some behavior target to shoot for. Using PING
to reverse engineer the network are devise a test plan is ONE solution but
one I (and apparently others) think can be improved upon. LSR-SELF test is
closer as we are starting to recognize that delegating responsibilty for
testing all perumations to all boxes results in a lot of useless traffic,
but IMO is still a bit heavyweight as a solution and requires ubiquitous
deployment, that its heavyweight is a personal option, that it requires
ubiquitous deployment is a fact. Does that mean I don't like ping, wrong, I
just do not see it as a universal panacea. I've already expressed that
opinion publically and in drafts. The emergence of BFD with more or less the
same technical justification as 1711 w.r.t. ping would seem to suggest I am
not alone.

As we have different expectations as to what degree of monitoring/auditing
network behavior is appropriate, it is no surprise we do not agree on the
degree of specification required and the appropriateness of all tools in all
applications. How you manage to covert this into an attitude that you are
interested in compromising in the interest of progress and I am not
completely escapes me....

cheers
Dave


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] 
> Sent: Tuesday, November 18, 2003 12:53 PM
> 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 
> <FFFC48AEAA5F7447929F4F0D93FCC12D02B92810@zcard031.ca.nortel.c
> om>, " 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
>