Subject: RE: on documenting ECMP (was on the mpls oam framework)

From: "David Allan" <[email-masked]>
Date: Wed, 19 Nov 2003 03:52:33 -0500

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:[email-masked]] 
> Sent: Tuesday, November 18, 2003 12:53 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]'; [email-masked]'; [email-masked]
> Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> 
> 
> 
> In message 
> <[email-masked]
> 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:[email-masked]]
> > > Sent: Tuesday, November 18, 2003 11:56 AM
> > > To: Allan, David [CAR:NS00:EXCH]
> > > Cc: [email-masked]'; [email-masked]'; [email-masked]
> > > Subject: Re: on documenting ECMP (was on the mpls oam framework) 
> > > 
> > > 
> > > 
> > > In message
> > > <[email-masked]
> > > 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
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 19 Nov 2003 11:05:55 -0500

In message <[email-masked]>, "
> completely escapes me....

Dave,

I hadn't intended to send another message but you summarized your
position nicely above.

At this point both of us should agree to disagree and stop talking.

You beleive that every aspect of forwarding must be know exactly in
order to support OAM and therefor determinism is a requirement for
forwarding.  The longer summary is above.

I believe that in a (large) subset of the community it is a
requirement to that there be OAM tools that work in the presence of
ECMP where forwarding of any one packet is not deterministic from the
standpoint of the ingress.  I believe that both those tools that
require completely deterministic forwarding and those that don't
should be supported.

If you agree that both types of tools can exist and the architecture
should not describe either ECMP in the forwarding architecture or
tools that don't support ECMP as deficient, then we have already
reached compromise.  I thought that was the compromise that had been
suggested earlier.  If you agree that this is a reasonable compromise,
then we can move forward.

If not, I suggest that we both be quiet for a while and see what
consensus comes out of the WG.  I'll do my part (and be silent).

Curtis