Subject: Re: Last Call <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Oct 2011 15:41:00 -0400

I support this doc, and concur with Stewart's comments.

Contrary to what some have suggested, we sometimes (ofttimes?) have more than
one standard for no good technical reason. Sometimes very large, 
competing companies back different standards for parochial reasons, 
to the detriment of consumers, service providers, etc. This appears 
to be one of those cases. Moreover, not opposing a two-standard 
approach sends a bad message, and encourages similar, bad behavior in 
the future.

As the co-chair of PKIX, which has two standards for cert management 
(CMC and CMP), for exactly the bad reasons I cite above, I am 
intimately familiar with this sort of problem.  I failed, in my role 
as PKIX co-chair, to prevent this in that WG.  Let's not repeat that 
sort of mistake here.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Oct 2011 22:18:37 +0100

On 10/10/2011 08:41 PM, Stephen Kent wrote:
> (CMC and CMP), for exactly the bad reasons I cite above, I am intimately
> familiar with this sort of problem. I failed, in my role as PKIX
> co-chair, to prevent this in that WG. Let's not repeat that sort of
> mistake here.

As one of the more minor perpetrators of that CMP/CMC travesty,
I completely agree with Steve that the PKIX WG (and not just nor
even mainly the chairs) failed in this respect due to what some
of the then major players perceived as being in their commercial
interests.

We've all, including all the main CMP/CMC proponents afaik, been
regretting that outcome for over a decade at this stage and continue
to find the situation problematic. (What's the relevant plural
for mea cupla I wonder? ;-)

While I've not yet read the document in the subject line, the
CMP/CMC experience makes me at least generally opposed to
standardising two ways of doing the same thing.

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Oct 2011 11:37:13 +1300

On 2011-10-11 10:18, Stephen Farrell wrote:
...
>  (What's the relevant plural

Nostra culpa, if you want a single fault owned by "us".

It's nostrae culpae for multiple faults by all of us.

Perhaps it should be added to the Note Well.

  Brian

---

From: Rolf Winter <[email-masked]>
Date: Tue, 11 Oct 2011 07:50:56 +0000

Hi,

This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a history of going down this road. Nobody stood up to stop that. Nobody wrote such a document then. Why now? Turf war, not invented here syndrome? I think it doesn't really matter. What would make my opposition go away is if we could write a more general document in which we point our own failings in the past, take this current issue into consideration and make it clear - in general - that the IETF is committed to follow this general principle more strictly in the future. _That_ would be a useful document and one which I would support. And it would be good if we could have such kind of pushback for multiple solutions in the future. WG chairs can take this document, show it to their WG and say "Guys, this is a guiding IETF principle. Get your act together and come up with a single solution. We will not have two or more.". Just ranting about this particular case is not helpful with all the multi-solutions we have created ourselves.

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Kent
> Sent: Montag, 10. Oktober 2011 21:41
> To: [email-masked]
> Subject: Re: Last Call <draft-sprecher-mpls-tp-oam-considerations-
> 01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM)
> to Informational RFC
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Ross Callon <[email-masked]>
Date: Tue, 11 Oct 2011 12:13:26 -0400

This is not actually correct. The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. There are a great many cases of ADs, working group chairs, and others pushing quite hard to prevent multiple solutions when one would work fine. 

In the very many previous cases it was not necessary to write a document because the second (or third, or ...) solution was within the same standards body, and it was possible to either prevent publication, or publish the second solution as informational, or publish the second solution with a disclaimer up front saying some form of "we recommend this other solution [add normative reference] which is the agreed IETF standard". 

Ross

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf Winter
Sent: Tuesday, October 11, 2011 3:51 AM
To: Stephen Kent; [email-masked]
Subject: RE: Last Call <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

Hi,

This is good input and made me realize what I disliked in the document which made me oppose to its publication. People (rightfully) pressed on the significance of the document to be about a general principle - one solution to any given problem. The IETF, _without_ external help, has a history of going down this road. Nobody stood up to stop that. Nobody wrote such a document then. Why now? Turf war, not invented here syndrome? I think it doesn't really matter. What would make my opposition go away is if we could write a more general document in which we point our own failings in the past, take this current issue into consideration and make it clear - in general - that the IETF is committed to follow this general principle more strictly in the future. _That_ would be a useful document and one which I would support. And it would be good if we could have such kind of pushback for multiple solutions in the future. WG chairs can take this document, show it to their WG and say "Guy
 s, this is a guiding IETF principle. Get your act together and come up with a single solution. We will not have two or more.". Just ranting about this particular case is not helpful with all the multi-solutions we have created ourselves.

Best,

Rolf

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Oct 2011 12:47:40 -0400

> This is not actually correct. The IETF has a very long history of
> pushing back on multiple redundant solutions to the same problem.
> There are a great many cases of ADs, working group chairs, and others
> pushing quite hard to prevent multiple solutions when one would work
> fine.
> 
> In the very many previous cases it was not necessary to write a
> document because the second (or third, or ...) solution was within the
> same standards body, and it was possible to either prevent
> publication, or publish the second solution as informational, or
> publish the second solution with a disclaimer up front saying some
> form of "we recommend this other solution [add normative reference]
> which is the agreed IETF standard".

as ops ad, i had to do that with cops

randy

---

From: Rolf Winter <[email-masked]>
Date: Tue, 11 Oct 2011 17:41:05 +0000

Ross,

See inline.

> pushing back on multiple redundant solutions to the same problem. There
> are a great many cases of ADs, working group chairs, and others pushing
> quite hard to prevent multiple solutions when one would work fine.

I didn't mean to say that the IETF in general allows multiple solutions but I think it is accurate to say that the IETF has a less than 100% success rate of preventing multiple solutions.

> same standards body, and it was possible to either prevent publication,
> or publish the second solution as informational, or publish the second
> solution with a disclaimer up front saying some form of "we recommend
> this other solution [add normative reference] which is the agreed IETF
> standard".

You are making a point on which I picked earlier because it is stated in the document as well. In case there are multiple solutions, documenting, but at the same time discouraging the other one has happened before. Why is this not possible in this case? Make one the default, the other optional with a big red warning sign.

Best,

Rolf

---

From: Ross Callon <[email-masked]>
Date: Tue, 11 Oct 2011 16:53:36 -0400

> I didn't mean to say that the IETF in general allows multiple solutions but I think
> it is accurate to say that the IETF has a less than 100% success rate of preventing
> multiple solutions.

Correct. We are not perfect.

> You are making a point on which I picked earlier because it is stated in the
> document as well. In case there are multiple solutions, documenting, but at
> the same time discouraging the other one has happened before. Why is this not
> possible in this case? Make one the default, the other optional with a big
> red warning sign.
>
> Best,
> Rolf

This is indeed possible in this case. It has been privately suggested multiple times, but 
I agree that this should have been publicly suggested as well (and thus I guess that I am
publicly suggesting it now). 

Ross

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 12 Oct 2011 06:11:40 +0200

> Correct. We are not perfect.

I had four "proposals" for chat protocols when I was Apps AD. One of them was NOT XMPP which now later seems to be what people use.

My take is that:

- If there is one proposal for a standard, it is "enough" for that proposal to be "technically sound"

- If there are two proposals (or more), i.e. a situation where the market is to choose between the multiple proposals that more or less solve the same problem, there is an additional constraint, and that is that the proposals do not interfere with each other

So if one have more than one proposal on the table that all move forward, they must be technically sound AND also not interfere with each other.

This 2nd requirement is something that is not as easy to resolve as people might think.

And specifically (we see in the MPLS case), the "bandwidth" of the liaison connection between SDOs is not high enough to guarantee this. We learned that the hard way between W3C and IETF.

Because of that the liaison coordination is only to resolve what SDO is managing the multiple proposals. It can not handle the synchronization between proposals.

And this to me is a key issue the whole MPLS discussion. It is just plain wrong to try to manage all variants of multiple flavors of ice-cream across SDOs. And why I strongly have the view I have on what has gone wrong.

   Patrik

---

From: John E Drake <[email-masked]>
Date: Wed, 12 Oct 2011 05:08:27 -0700

Snipped, comment inline

> publicly suggesting it now).
[JD] 

How does the IETF put a big red warning sign on a document produced by another standards body?

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Oct 2011 22:00:56 -0400

+1
   john

--On Wednesday, October 12, 2011 06:11 +0200 Patrik Fältström
<[email-masked]> wrote:

>>> I didn't mean to say that the IETF in general allows
>>> multiple solutions but I think it is accurate to say that
>>> the IETF has a less than 100% success rate of preventing
>>> multiple solutions.
>> 
> I had four "proposals" for chat protocols when I was Apps AD.
> One of them was NOT XMPP which now later seems to be what
> people use.
> 
> My take is that:
> 
> - If there are two proposals (or more), i.e. a situation where
> the market is to choose between the multiple proposals that
> more or less solve the same problem, there is an additional
> constraint, and that is that the proposals do not interfere
> with each other
> 
> So if one have more than one proposal on the table that all
> move forward, they must be technically sound AND also not
> interfere with each other.
> 
> And specifically (we see in the MPLS case), the "bandwidth" of
> the liaison connection between SDOs is not high enough to
> guarantee this. We learned that the hard way between W3C and
> IETF.
> 
> Because of that the liaison coordination is only to resolve
> what SDO is managing the multiple proposals. It can not handle
> the synchronization between proposals.
> 
> And this to me is a key issue the whole MPLS discussion. It is
> just plain wrong to try to manage all variants of multiple
> flavors of ice-cream across SDOs. And why I strongly have the
> view I have on what has gone wrong.
> 
>    Patrik
>

---

From: Rolf Winter <[email-masked]>
Date: Thu, 13 Oct 2011 06:50:40 +0000

> How does the IETF put a big red warning sign on a document produced by

http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-07. Actual coloring of course is impossible.

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 16 Oct 2011 15:09:45 +0000

> The IETF has a very long history of pushing back on multiple redundant solutions to the same problem. 
> There are a great many cases of ADs, working group chairs, and others pushing quite hard 
> to prevent multiple solutions when one would work fine. 

I haven't seen this in the OAM work so far.

PWE's VCCV has 3 or 4 different channels (code named CC types)
and 3 or 4 different OAM mechanisms (code named CV types).
And each of these has several variants and most have several possible encapsulations.

Similarly in the MPLS-TP work we have a large number of options.
For example, draft-ietf-mpls-tp-on-demand-cv has 3 different encapsulations
(LSP-ping UDP/IP packet in MPLS, LSP-ping packet in UDP/IP in GACh, 
and "raw" LSP-ping packet in GACh with a new channel type).

Why is it that no-one seems to object to a plethora of possible options for anything
except the inner-most payload format?

Y(J)S

---

From: "t.petch" <[email-masked]>
Date: Tue, 18 Oct 2011 09:40:21 +0200

----- Original Message -----
From: "Yaakov Stein" <[email-masked]>
To: "Ross Callon" <[email-masked]>; "Rolf Winter" <[email-masked]>;
"Stephen Kent" <[email-masked]>; <[email-masked]>
Sent: Sunday, October 16, 2011 5:09 PM

> > There are a great many cases of ADs, working group chairs, and others
pushing quite hard
> except the inner-most payload format?

Yaakov

Because MPLS-TP is not really IETF work:-)

The processes of MPLS-TP have been IETF-like but diverging from IETF in a number
of small ways and it is this that has, for me, allowed the many different
solutions that you refer to to emerge.  Outside MPLS-TP, I rarely see this
occurring except in a very generic case of a protocol running over both UDP and
TCP, or TCP and SCTP.

Tom Petch

In other fields,