The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Nov> msg00179



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

on documenting ECMP (was on the mpls oam framework)

  • From: Curtis Villamizar <curtis@workhorse.fictitious.org>
  • Date: Wed, 19 Nov 2003 11:05:55 -0500
  • cc: "'curtis@fictitious.org'" <curtis@fictitious.org>, "'tnadeau@cisco.com'" <tnadeau@cisco.com>, mpls@UU.NET


In message <FFFC48AEAA5F7447929F4F0D93FCC12D02B92816@zcard031.ca.nortel.com>, "
David Allan" writes:
> 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


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