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: Huub van Helvoort <[email-masked]>
Date: Thu, 29 Sep 2011 07:06:50 +0200

All,

I propose to completely remove section 5 of this draft.

The reason:

The IETF should *NOT* document any comment on any "multiple standards"
developed by other SDOs which are outside of the IETF's scope.

Especially standards like like SONET/SDH, CDMA/GSM.

The current text reflects the author's impressions, and since I don't
believe that the authors were involved in the debates when these
standards were developed, they *DO NOT KNOW ENOUGH* to comment
authoritatively on them.

The IETF should refrain from documenting things that might offend
other SDOs concerning standards issues in which IETF was or is not
involved.

Best regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 29 Sep 2011 08:00:13 +0200

All,

Why section 5.1 is an author's impression:

Statement:
"SONET and SDH were defined as competing standards"
Fact:
SONET was developed first by ANSI based on the 24 channel PDH hierarchy
existing in North America and Japan. The basic rate based on DS3.
Some time later ETSI developed SDH based on the 30 channnel PDH deployed
in Europe. The basic rate based on E4 (3x DS3).
To be able to deploy SONET and SDH worldwide the regional SDO experts
came together in ITU-T to define a frame structure and a frame-rate
that would allow interconnection of SONET and SDH.
A compromise was agreed and approved in an ITU-T meeting in Seoul
in 1988.

Statement:
"Significant confusion resulted from this situation."
Fact:
The result of the compromise is documented in ITU-T recommendation
G.707 which includes the frame definition and frame-rates, and
documents how SONET and SDH can interconnect.

Statement:
"Equipment manufacturers needed to select the market segment they
intended to address. The cost of chipsets for a limited market
increased.
Fact:
Most equipment vendors did/do sell their equipment in both regions.
I was involved in chip designs for SONET/SDH in several companies,
they all support SONET and SDH in a single chip, and the selection
is a matter of provisioning, the addition cost to support both was
minimal (single chip: higher volume = lower cost)

Statement:
"Service providers needed to consider the merits of the two standards
and their long-term role in the industry when examining their
investment options.
Fact:
Because the regions or applicability of SONET and SDH are well
known SPs do not have to make this consideration.

Statement:
"Only a limited number of equipment manufactures were available
for selection."
Question:
What do you consider a limited number?

Statement:
"As SONET was considered to be the variant, interworking had to be
performed before the SDH-based segment was reached."
Fact:
SONET is *NOT* a variant it is equivalent to SDH.
The reason for placing the interconnection functionality on the SONET
side was that in a previous agreement on interconnection the
functionality was placed on the European side.

Conclusion:
There is a single frame structure used by both SONET and SDH.
This is documented in ITU-T recommendation G.707 (ANSI and ETSI
still have their SONET resp. SDH standard available in their
own documentation, but they are aligned with G.707).
It depends on the application of the frame structure in an environment
with 24 channel legacy PDH to call it SONET and in an evironment
with 30 channel legacy PDH to call it SDH.
The meeting in Seoul in 1988 shows that SDOs can compromise to
find a common frame structure that can be used in different
regions/applications.

Best regards, Huub.

---

From: SM <[email-masked]>
Date: Thu, 29 Sep 2011 01:21:11 -0700

At 12:42 26-09-2011, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'The Reasons for Selecting a Single Solution for MPLS-TP OAM'
>   <draft-sprecher-mpls-tp-oam-considerations-01.txt> as an Informational
>RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2011-10-24. Exceptionally, comments may be

Given that previous discussions about MPLS-TP raised a few 
controversies, I wondered what this document was about and why it 
wasn't a working group document.  The document mentions that it is 
"intended to explain why it would be unwise to standardize multiple 
solutions for MPLS-TP OAM".  And the objective is to determine 
whether there is IETF Consensus for that.

According the shepherd write-up, this document is an analysis of 
wider IETF policy and process.  Could the document shepherd please 
clarify what he means by that?

In Section 4.3:

   "The application layer of the Internet is, however, predicated on a
    business model that allows for free or shared software (such as in
    open source developments), and is only possible with the existence of
    a royalty free codec."

I cannot parse the above sentence.

There were some arguments [1] from an IETF participant:

   "The IETF should *NOT* document any comment on any "multiple standards"
    developed by other SDOs"

   "The IETF should refrain from documenting things that might offend
    other SDOs"

I could not find anything offensive.  For example, Section 5.3 mentions that:

   "Sometimes, customers were obliged to obtain an additional device from
    their service providers in order to roam when travelling abroad (for
    example, when travelling from Europe to the U.S)."

There is a cost when the user has to work around such issues.

The IETF already has a policy about inter-SDO impact.  Quoting 
Section 2.2 of RFC 4041:

      "[The IETF] must allow for other moral frameworks and fully
       respect other people's right to subscribe to other belief
       systems.  Such people are, however, wrong and doomed to spend
       eternity in a dark corner with only dial-up access.  So it has
       been written."

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg69674.html

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 29 Sep 2011 07:48:32 -0400

> standards were developed, they *DO NOT KNOW ENOUGH* to comment

	Isn't that why this draft is targeted as an *individual and informational* draft?  Since that is the case, I don't see how your point is relevant to the document at hand.

> other SDOs concerning standards issues in which IETF was or is not

	That is your opinion. However, please observe that other SDOs document and cross-reference each others' works all the time often adding their "2 cents".  For example, take what the BBF does with many IETF standards.

	--Tom

> 
> Best regards, Huub.
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 29 Sep 2011 09:18:00 -0400

A few more thoughts on this thread.

> standards were developed, they *DO NOT KNOW ENOUGH* to comment

	Why do you suddenly think that it is important for only people with knowledge of a topic to contribute to standards? Where does that leave the ITU-T's input on MPLS?  I can give you many examples of where people who had no qualification as "experts" in a particular field have contributed to standards, but I will refrain from doing so so as to not "offend other SDOs" as you say below. 8)

> other SDOs concerning standards issues in which IETF was or is not

	Since when does offending other SDOs become a concern of any other SDO? Along these lines, let us take the flip-side of that example you give and ask ourselves why the ITU-T's comments on MPLS do not offend IETF folks (or other SDOs for that matter) and why there was not a concern of offending when those were made?

	--Tom

---

From: Andrew Feren <[email-masked]>
Date: Thu, 29 Sep 2011 10:04:06 -0400

> 	Why do you suddenly think that it is important for only people with knowledge of a topic to contribute to standards? Where does that leave the ITU-T's input on MPLS?  I can give you many examples…

I would say that having "knowledge of a topic" is a requirement, but 
that *expert* knowledge of a topic is not a requirement.

Just look at the IETF mailing lists.  There are plenty of people with 
something to say  who do not to have expert "knowledge of a topic".   
Almost certainly of us at one time or another.

Sometimes new ideas come from looking at a problem without the 
preconceptions that come with being "an expert".  Sometimes experts 
really do know better.  This is why we have discussions to build 
consensus as to which ideas should be kept or discarded.  Both experts 
and nonexperts can have valuable contributions and improve each others 
understanding.

-Andrew "Not an expert on standards or even  SONET/SDH, CDMA/GSM"

---

From: [email-masked]
Date: Thu, 29 Sep 2011 11:10:00 -0400

All,

 From my personal knowledge, the comments from Huub are accurate.  (I was 
an active participant at the 1988 ITU meeting in Seoul where the SDH frame 
format was agreed).

The IETF should not publish a consensus approved draft that contains 
inaccurate information about a standard that was developed outside the 
IETF.

The gross inaccuracy in the characterization of SONET/SDH leads me to 
question the validity of the document.

Regards,

Malcolm

Huub van Helvoort <[email-masked]> 
Sent by: [email-masked]
29/09/2011 02:00 AM
Please respond to
[email-masked]

To
[email-masked]
cc

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

All,

Statement:

Statement:

Statement:

Statement:

Statement:

Statement:

Conclusion:

Best regards, Huub.

---

From: [email-masked]
Date: Thu, 29 Sep 2011 11:11:08 -0400

Tom,

Please see in line below.

Regards,

Malcolm

Thomas Nadeau <[email-masked]> 
Sent by: [email-masked]
29/09/2011 07:48 AM

To
[email-masked]
cc
The IESG <[email-masked]>, [email-masked], IETF-Announce 
<[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

> standards were developed, they *DO NOT KNOW ENOUGH* to comment

                 Isn't that why this draft is targeted as an *individual 
and informational* draft?  Since that is the case, I don't see how your 
point is relevant to the document at hand.

[MB] The last call is for consensus approval by the IETF so this draft, if 
published, will be "the opinion of the IETF".  Therefore the point raised 
by Huub is relevant.

> other SDOs concerning standards issues in which IETF was or is not

                 That is your opinion. However, please observe that other 
SDOs document and cross-reference each others' works all the time often 
adding their "2 cents".  For example, take what the BBF does with many 
IETF standards.

[MB] Big difference between referencing the work of another SDO from a 
standard and issuing a standard that make inaccurate comments about a 
standard that was developed in another SDO.

                 --Tom

---

From: [email-masked]
Date: Thu, 29 Sep 2011 11:11:35 -0400

Tom,

Regards,

Malcolm

29/09/2011 09:18 AM

To
[email-masked]
cc

> standards were developed, they *DO NOT KNOW ENOUGH* to comment

                 Why do you suddenly think that it is important for only 
people with knowledge of a topic to contribute to standards? Where does 
that leave the ITU-T's input on MPLS?  I can give you many examples of 
where people who had no qualification as "experts" in a particular field 
have contributed to standards, but I will refrain from doing so so as to 
not "offend other SDOs" as you say below. 8)

[MB] This individual draft is now in IETF last call.  At this stage it 
should represent the opinion of those who are experts in the field. 
Clearly during the development of a draft all interested participants, 
expert or not, should provide input.

---

From: <[email-masked]>
Date: Thu, 29 Sep 2011 16:37:19 +0100

All,

First, let me say I have no absolutely desire to enter into debate into the substantive matter of this draft.

If the purpose of the draft is to be 'Informational' then the reader would have a reasonable expectation for the information to be correct, especially if it is referencing matters beyond its immediate scope. And the section 5.1 is simply factually wrong.

Huub's comments on SONET/SDH give an accurate critique.

If the authors did want to make meaningful reference to where two separate standards emerged, then the primary rates (T1 and E1), their associated voice coding (mu-law and A-law), and PDH multiplexing hierarchies might be a more meaningful place to start. With a great deal of hard work and good will on all sides, SONET/SDH achieved an single effective standard bridging these two largely incompatible worlds.

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 29 September 2011 16:10
To: [email-masked]
Cc: [email-masked]; [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

All,

 From my personal knowledge, the comments from Huub are accurate.  (I was an active participant at the 1988 ITU meeting in Seoul where the SDH frame format was agreed).

The IETF should not publish a consensus approved draft that contains inaccurate information about a standard that was developed outside the IETF.

The gross inaccuracy in the characterization of SONET/SDH leads me to question the validity of the document.

Regards,

Malcolm

Huub van Helvoort <[email-masked]<mailto:[email-masked]>>
Sent by: [email-masked]<mailto:[email-masked]>

29/09/2011 02:00 AM
Please respond to
[email-masked]<mailto:[email-masked]>

To

[email-masked]<mailto:[email-masked]>

cc

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

All,

Statement:

Statement:

Statement:

Statement:

Statement:

Statement:

Conclusion:

Best regards, Huub.

_______________________________________________
Ietf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Thu, 29 Sep 2011 10:48:00 -0500

Dear all,

As also being one of the participants directly involved in the SONET/SDH standardization process from its inception, I would like to echo Andy's sentiments.

Best regards,
Eve

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 29, 2011 11:37 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [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

All,

Andy

All,

Regards,

Malcolm

29/09/2011 02:00 AM
Please respond to

To

cc

Subject

All,

Statement:

Statement:

Statement:

Statement:

Statement:

Statement:

Conclusion:

Best regards, Huub.

---

From: Scott O Bradner <[email-masked]>
Date: Thu, 29 Sep 2011 12:30:11 -0400

I'm having a hard time understanding just what this document is trying to do

I understand from the title that it is supposed to be telling the reader why a single OAM 
solution is a good idea for MPLS-TP

if that is the case I'm not all that sure what the purpose of sections 4 and 5 are for - they seem
to be exploring land outside the reservation - how about just addressing the topic in the title?

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Sep 2011 08:52:44 +1300

Scott,

> to be exploring land outside the reservation - how about just addressing the topic in the title?

That goes a bit further than my own suggestion of moving them to
an Appendix, but they are indeed off the main track of the argument.
You're probably right; it would be more succinct and equally
powerful without them.

I think we all know that competing standards are a bad thing, without
having to get the historical details of SDH vs SONET right. Whatever
good work was done to fix the SDH/SONET case, the fact is that users were
seriously inconvenienced, exactly as they were earlier by the difference
between E1 and T1. [Anecdote about the first T1 link carrying IP across
the Atlantic deleted.]

   Brian

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 29 Sep 2011 16:27:31 -0400

> You're probably right; it would be more succinct and equally

	I personally liked your idea of moving to an appendix.  That keeps them in black and white and in a place that can be referenced.

	--Tom

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 30 Sep 2011 08:47:44 +0200

All,

Section 1.1 contains the following text:

    An analysis of the technical options for OAM solutions was carried
    out by a design team (the MEAD team) consisting of experts from both
    the ITU-T and the IETF.  The team reached an agreement on the
    principles of the design and the direction for the development of
    an MPLS-TP OAM toolset.

I was a member of the MEAD team, I do not support this conclusion.

    A report was subsequently submitted to the
    IETF MPLS Working Group at the Stockholm IETF meeting in July 2009.

Please provide a reference to the report. I would like to read it,
and see what my conclusion was.

    The guidelines drawn up by the design team have played an important
    role in the creation of a coherent MPLS-TP OAM solution.

The MEAD team was disbanded before the guidelines were finished and
agreed within the team.

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 30 Sep 2011 09:19:06 +0200

All,

Section 1,1 also contains the text:
    [RFC5317] includes the analysis that "it is technically feasible that
    the existing MPLS architecture can be extended to meet the
    requirements of a Transport profile, and that the architecture allows
    for a single OAM technology for LSPs, PWs, and a deeply nested
    network."

This is a quote from slide 113 in the PDF version of RFC5317 and should
be read in realtion to the statement on slide 12 of the same RFC:

"This presentation is a collection of assumptions, discussion points
  and decisions that the combined group has had during the months of
  March and April, 2008
  This represents the *agreed upon starting point* for the technical
  analysis of the T-MPLS requirements from the ITU-T and the MPLS
  architecture to meet those requirements"

So the quoted text in the draft is one of the assumptions.

The fact that there are currently *two* OAM mechanisms (and not a
*single*), i.e. one for PW and one for LSP proves that the assumption
was not correct.

Regards, Huub (member of the JWT).

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 01 Oct 2011 08:47:36 +1300

Huub,

> *single*), i.e. one for PW and one for LSP proves that the assumption

I'm sorry, I don't understand your logic. You seem to be saying that
the fact that two solutions have been designed proves that the assumption
that a single solution is possible was false. That doesn't follow at
all. The engineering profession has a long history of producing multiple
solutions where a single one was possible, and this seems to be just
another such case.

This isn't news. I quote from RFC 1958 (June 1996):

"  3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."

        Brian