Subject: RE: on the mpls oam framework

From: "David Allan" <[email-masked]>
Date: Tue, 11 Nov 2003 11:58:26 -0500

If you want to trivialize the framework draft to the ITU stuff only, read
the Y.17fec-cv overview draft. 

IMHO You are persisting in ignoring what you don't want to see.

rgds
Dave

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]] 
> Sent: Tuesday, November 11, 2003 11:32 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]'; Shahram Davari; MPLS wg; George Swallow; Alex Zinin
> Subject: Re: on the mpls oam framework 
> 
> 
> 
> In message 
> <[email-masked]
> om>, " David Allan" writes:
> > 
> > > 
> > > But you are misrepresenting me when you say that the 
> differences is 
> > > not resolvable. In fact the proposal to start on a fresh 
> document is 
> > > intended jsut to achieve that. I guess that if there are 
> two people 
> > > representing two different ideas on a subject, the 
> requirement that 
> > > one of the has to accept the ideas of the other to be part work 
> > > seems to be counter-productive.
> > 
> > I think that cuts both ways. I'm certainly willing to enlarge the 
> > document to include both points of view. It is a framework document 
> > after all.....
> > ;-)
> > 
> > cheers
> > Dave
> 
> 
> Dave,
> 
> A measurement framework that only works for one case, RSVP/TE 
> not using PHP or ECMP, is of very limited use.  A more useful 
> measurement framework would work for RSVP/TE but also works 
> for LDP with its mp2p nature, works with ECMP used with LDP 
> (or RSVP/TE over hierarchical tunnels).  MPLS OAM defined in 
> the ITU only works for RSVP/TE, no PHP, no ECMP.  MPLS 
> ping/traceroute works for all of the above cases, provides 
> more information.  MPLS Ping is also infinitely more 
> practical because it can be implemented without change to the 
> high speed forwarding plane (because it involves only altered TTL
> processing) or at most minimal change.
> 
> As long as you are offering a framework in which MPLS OAM is 
> the solution and all network architectures for which MPLS OAM 
> doesn't work are described as "broken" or deficient, there is 
> no sense in the MPLS WG giving it serious consideration.
> 
> If on the other hand the document described an approach that 
> worked in all conditions that are of interest and also 
> mentioned a tool for a specific circumstance favored by some, 
> you'd have a document the WG could consider for advancement.  
> That is a very different document from what you now have and 
> it does require starting over.
> 
> Curtis
>

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 14 Nov 2003 22:47:09 -0800 (PST)

Hi Dave,

> IMHO You are persisting in ignoring what you don't want to see.

Speaking as a vendor:

On mp2p: at least 90% of the MPLS deployments I've seen use LDP.

On ECMP: many providers ask us explicitly for ECMP.  On the other
hand, no provider that I know (other than BT) of has complained
about ECMP and asked us to turn it off.

On PHP: two providers (one being BT) have complained about PHP, out
of all the providers I've talked to about MPLS (about 3%).

Kireeti.
-------

"Reality is a dagger in the heart of the starry-eyed." -- MP

---

From: Mark Seery <[email-masked]>
Date: Sat, 15 Nov 2003 00:49:13 -0800 (PST)

Hi Kireeti.

It's been a tough week eh. Flare ups all over the place! I like Minneapolis, so
I am not sure we can blame the city, of course if I find out that too many
people had a bunch Walleye, then I might have to rethink that ;-)

At any rate, hopefully we will all exit this downward cycle soon and both sides
will back of the rhetoric. It is definetly no fun to watch, and I imagine it is
even less fun to be one of the active combatants - hopefully I am not about to
experience that particular joy ;-)

Some comments below.

Hope you have a good weekend.

Best,
Mark

> On mp2p: at least 90% of the MPLS deployments I've seen use LDP.

Interesting stat for the L2VPN WG to consider ;-) BTW, 90% of carriers I talk
to think that LDP is used to create a connection-oriented service. Hopefully
one day we might all agree that MPLS has created some new modes that really
defy our pre-existing notions (for better and/or worse). My point of saying
that is I feel fairly confident in asserting that there is a lot about MPLS
that many people don't understand - that's not a license for obnoxious
behavior, but it is a potential for tuning/education in many areas, over time.

Also, over the last year I've had to stand politely before many operators (in
the U.S.) while they told me that they didn't even consider the IETF a real
standards body. I can assure that is not the kind of expression that I thought
boded well for any part of our industry and the organization we all enjoy
participating in so much. So while you might be in regular contact with people
at service providers that think everything is honky dory, its my impression
there are significant schisms to be worked on out there. I don't think the
result is in doubt, but I do wonder about the timing sometimes.

> about ECMP and asked us to turn it off.

ECMP is a natural thing to do with a SPF (non traffic-engineered) mode of
networking (IP or LDP/MPLS), that doesn't mean there were not some extra things
to be thought about when applying it in the MPLS context.

> of all the providers I've talked to about MPLS (about 3%).

As a person working at companies implementing PHP, I have to say I never
thought it made life easier for the implementors (but obviously you are better
to comment than me) - which is not a comment on its value, just an observation.
Its not clear to me also why at this stage, why a provider using the newest
equipment in a greenfield deployment would find much value in this feature -
but happy to be educated.

In the interest of my further education, I was wondering if you could point out
the errors in the below statement.

"Connectivity verification requires testing of connectivity between all
possible ingress/egress combinations. Frequently it will not be possible to
infer the ingress LSR and specific LSP directly at the egress as such
information may be lost at merge points in mp2p LSPs or due to PHP. This is
true for both OAM messaging, and normal data plane payloads. There may be
numerous reasons why an ingress-egress pair may have a plurality of LSPs
between them, so the ability to
distinguish the source and purpose of specific probes beyond mere knowledge of
the originating LSR is required.

The ability to distinguish the ingress can be achieved via modifying the OAM
protocol to carry such information, or may be achieved via modifications to
operational procedures such as overlaying p2p connectivity."

---

From: Loa Andersson <[email-masked]>
Date: Sat, 15 Nov 2003 17:04:05 +0100

Working group, Mark and Kireeti,

it is known that irony is an hard art to pursue.
Kireeti, Mark missed the irony in your mail.
Mark, after doing that you had a go on the same method.

I think I can understand both of your stating points, however
just now it is not helpful.

Let me put the wg chair hat on and try to sort some of the
issues out.

Two issues
----------

We are really trying to sort out two different issues at
the same time, one technical and one procedural.

On the technical side I've an opinion, on the procedural I'v also
an opinion. I've not voiced my opinion on the technical solution
for MPLS OAM so far, and will not in this mail either. I pointed
out some shortcommings to the draft-allan IDs, when I explained
why I wanted to start a fresh document.

Procedures
----------

We've a number of OAM drafts currently under discussion in the
MPLS-group, the OAM framework is one of them. lsp-ping, lsr-selftest,
bfd are others.

Now from a working group and ietf perspective there is a procedure to
follow, the decisions taken earlier stands until working group consensus
to change them is teached. And if and when such a consensus is we need to
go back and change the exisisting documents that is effected.

I guess that there are similar procedures in the ITU, if I were to tell
that they are not develop things according a particular document published
by the IETF, they would change their standards, I guess that I at least
would have to write a contribution to tell them why this would be a
good idea.

Debating style
--------------

So repeating "mpls has developed beyond that point" or "this is what 
mpls is"
is not getting us anywhere. Nor is assigning points of view to other 
people.
Or claiming perfection for once own work.
We are all for an healthy development of mpls, what we have are two 
different
opinions of what that development looks like. My task here is to find a path
that leads to wg consensus.

MPLS OAM
--------

MPLS OAM are on the mpls wg charter, to my understanding we need a framework
for this area. Looking into what is going on it was (and is) my 
conslusion that
neither of the documents so far written would have a chance to become a 
docment
that we would reach a wg consensus around.

I therefore (with the support of my co-chair and the ADs) asked one
Tom and Dave to:
- start a new OAM framework document
- taking all the known ongoing work in the mpls wg and elsewhere into
  consideration,
- look into what is going on elsewhere
- carefully build on our history
- indicate necessary changes to existing documents and specifications,
  work with the authors of the documents effected
- solicit the input from people that have documents published in the
  mpls OAM area and others that they know have an interest in the area
- carefully build this so we reach the wg consensus

I simply fail to understand why this has initiated this type of discussion
on the list.

Actions
-------

The last mail I got from Dave indicated that he were willing to "give it
a shot" and I know that Tom is willing to do the same.
So let us stop the quibling around this a get down to get the work done.

draft-allan
-----------

As for the draft-allan I do not see any problem to request that it is
published as an informational RFC, though I would suggest that it is
carefully reviewed and that an applicability statement is added, preferably
in the document.

/Loa

-- 

Loa Andersson

mobile +46 739 81 21 64

---

From: mark seery <[email-masked]>
Date: Sat, 15 Nov 2003 11:23:26 -0800

> Let me put the wg chair hat on and try to sort some of the
Loa, thankyou for putting on your wg chair hat. I appreciate and respect 
you doing so. I apologise to the group if my comments were not helpful, 
and specifically to Kireeti if he thought them to be of a personal 
nature, I have the highest respect for Kireeti.

I would like to observe that this mailing list has endured more than its 
fair share of "irony" this week, including some from at least one of the 
chairs. I would like to encourage both chairs to step on the "irony" 
brakes often, in a non-partisan way, and as soon as it appears. This, 
IMHO, will become particularly important as we move in to an era where 
chairs can suspend posting privilieges. It is great to have power, but 
power exercised in a non-partisan and impulsive way becomes tyranny. I 
would also like to encourage the chairs to consider that the IETF is a 
very open body - which many respect and believe is its fundamental 
strength (as I personally do). But all should keep in mind that it is 
open to everyone in our large community of people who believe in the 
power of networks; and that all are free to observe our comments and 
work when ever they desire. Some of these people are people who we have 
fundamental disagreements with, but none the less need to partner with 
to achieve our goals. Because of the way the structure or our industry 
evolved, it was innevitable that competitive forces would arise between 
major groups. As our industry structure continues to evolve, we 
(everyone in the industry) need to as well.

I agree with you Loa that is not helpful for anyone to assert they have 
perfect vision and would encourage all to not do this; but I would also 
observe few if any of us are free from this sin - it is the very nature 
of testing your ideas against those of your peers. It is the very nature 
of peer review. It is the very nature of having the courage of your 
convictions. Let's celebrate everyone's courage for their convictions 
while encouraging them to provide specific, relevant, and appropriate 
feedback.

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 15 Nov 2003 13:37:18 -0800 (PST)

Hi Loa,

> just now it is not helpful.

Sorry, didn't mean to make your life harder.

> would have to write a contribution to tell them why this would be a

It's nice to think that the ITU would change their standards.  Please,
please do write such a document (or Liaison) to the ITU.

> that leads to wg consensus.

I would like to point out (in case someone misreads Loa's email) that
MPLS development is *not* at issue here.  The issue is what we do with
the OAM framework and perhaps OAM direction.

> I simply fail to understand why this has initiated this type of discussion

It's too tempting :-)  But I promise to be good ... for a week, at least.

Kireeti.
-------