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: [email-masked]
Date: Mon, 3 Oct 2011 16:57:54 -0400

Brian,

I think that points that Huub is raising are:

a)  The text quoted from page 113 RFC 5317 "the architecture allows for a 
single OAM technology for LSPs, PWs" is being used as (part of) the 
rational for only having a single OAM solution, however page 12 of RFC 
5317 states that the subsequent slides represent an agreed starting point 
for the work.

b) The IETF have developed two different solutions, one for LSP and 
another for PWs and this confirms that the quoted text was just a starting 
point.

I agree with you that, in some cases for good reasons, more than one 
solution is developed and deployed.

Regards,

Malcolm

Brian E Carpenter <[email-masked]> 
Sent by: [email-masked]
30/09/2011 03:47 PM

To
[email-masked]
cc
[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

Huub,

On 2011-09-30 20:19, Huub van Helvoort wrote:
> 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.

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
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Rolf Winter <[email-masked]>
Date: Tue, 4 Oct 2011 09:16:57 +0000

Hi,

I think Brian makes an excellent point here. RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). I don't think we need this document as it doesn't really add anything to what RFC 1958 says. I'll provide a more detailed review later.

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
> Brian E Carpenter
> Sent: Freitag, 30. September 2011 21:48
> To: [email-masked]
> Cc: [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
> 
> Huub,
>

---

From: "t.petch" <[email-masked]>
Date: Tue, 4 Oct 2011 16:52:23 +0200

----- Original Message -----
From: "Scott O Bradner" <[email-masked]>
To: "IETF Discussion" <[email-masked]>
Sent: Thursday, September 29, 2011 6:30 PM

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

Scott

Provide another instalment in the long running and yet-to-be resolved
disagreement as to how additional OAM should be added to MPLS to bring it up to
the level required in a Transport Network by network operators.

Look at the archives of this list for a post by Russ 2Mar2011 for an earlier
instalment.

The MPLS-TP list has a thread
'Draft: Response to Updated draft Recommendation G.tpoam  [Ref043.02]'
in Jan 2011 which precedes that.

The same list has
' MPLS WG slides from CMCC'
in November 2010 which says
" Actually, China Mobile has introduced 38,000 PTN equipments based on
pre-standard G.8114 in 2009. China Mobile will introduce more than 110,000 PTN
equipments based on draft-bhh-MPLS-TP-OAM-Y1731 in 2010."
(draft-bhh being the proposal for OAM that the IETF did not adopt for Packet
Transport Networks).

and a thread at the same time
'How can ITU-T experts contribute to the work on MPLS-TP?'

which I think the crux of the problem.  IETF has a way of working, and IETF
claims technical control over MPLS code points, but those supporting draft-bhh
have failed to achieve agreement, in the way that the IETF defines agreement
(which is not the way in which other SDOs define agreement), that theirs should
be the way forward to add the necessary functionality to MPLS OAM.

So we have two technical solutions; perhaps they will coexist, perhaps the
marketplace will decide etc, as this I-D says.  It is not a happy state of
affairs, and there is no
technical solution.  Quite how this will play out is hard to see but in a few
years time, I fear we will look back and say 'if only'.

Tom Petch

>
> 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: "t.petch" <[email-masked]>
Date: Wed, 5 Oct 2011 10:01:15 +0200

I oppose publication of this I-D in its present form.

The idea of having an I-D that says two OAM solutions will cost is fine, but
there are too many technical errors, especially in sections 4 and 5 (better as
Brian suggested as appendices), for it to go forward as it stands.  Huub,
Malcolm and Andy have pointed out the errors in SONET/SDH, I would take issue
with OSPF/ISIS and IPv4/IPv6.  The errors aren't gross, but they add up to too
many.

The sponsoring AD has given his reasons why this is an individual submission but
I think that the consequence is that the document quality is too low to be
published.  It needs the review of a wider body of expertise, the routing area
perhaps, before it is published.

Tom Petch

----- Original Message -----
From: "The IESG" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
Sent: Monday, September 26, 2011 9:42 PM
Subject: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>
(TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
>
> 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
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>    The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology
>    for use in transport network deployments. That is, MPLS-TP is a set
>    of functions and features selected from the wider MPLS toolset and
>    applied in a consistent way to meet the needs and requirements of
>    operators of packet transport networks.
>
>    During the process of development of the profile, additions to the
>    MPLS toolset have been made to ensure that the tools available met
>    the requirements. These additions were motivated by MPLS-TP, but form
>    part of the wider MPLS toolset such that any of them could be used in
>    any MPLS deployment.
>
>    One major set of additions provides enhanced support for Operations,
>    Administration, and Maintenance (OAM). This enables fault management
>    and performance monitoring to the level needed in a transport
>    network. Many solutions and protocol extensions have been proposed to
>    address these OAM requirements, and this document sets out the
>    reasons for selecting a single, coherent set of solutions for
>    standardization.
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
>
>
> No IPR declarations have been submitted directly on this I-D.
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Loa Andersson <[email-masked]>
Date: Wed, 05 Oct 2011 12:47:55 +0200

Rolf,

are you saying that if we just liaise RFC1958 to the ITU-T they will
stop developing a competing OAM for MPLS?

Sometimes the life is simple, though I doubt that it is this simple.

My 2c's is that this a good draft and should be progressed.

/Lao

On 2011-10-04 11:16, Rolf Winter wrote:
>> Subject: Re: Last Call:<draft-sprecher-mpls-tp-oam-considerations-

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: HUANG Feng F <[email-masked]>
Date: Wed, 5 Oct 2011 19:29:39 +0800

Dear Loa,
   Life is not simple, mpls-tp is joint developed by IETF and ITU-T, so it is complicated, the decision should be done by two orgnizations.
   There are many errors about in this draft as many, for example, Rolf, Huub, Malcolm, Tom Petch and I, point out in emails, it is a bad draft, it should be stop.
B.R.
Feng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: 2011年10月5日 18:48
To: [email-masked]; Rolf Winter
Subject: Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC

Rolf,

are you saying that if we just liaise RFC1958 to the ITU-T they will stop developing a competing OAM for MPLS?

/Lao

On 2011-10-04 11:16, Rolf Winter wrote:
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
> London W3 6BL | Registered in England 2832014
>
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of Brian E Carpenter
>> 01.txt>  (The Reasons for Selecting a Single Solution for MPLS-TP 
>> OAM) to Informational RFC
>>
>> Huub,
>>
>>> *single*), i.e. one for PW and one for LSP proves that the 
>>> assumption was not correct.
>>
>> 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.
>>

-- 

                                              +46 767 72 92 13 _______________________________________________

---

From: Rolf Winter <[email-masked]>
Date: Wed, 5 Oct 2011 11:31:38 +0000

Hi Loa,

Let me answer with a counter-question. If the sole purpose of this document is to stop the development of two OAM solutions, do you think this RFC-to-be will achieve that? Seriously? The problem I see here is that we start a habit of writing "politically" motivated documents. We have this issue documented already all over the place in the form of minutes, web sites, press releases etc. I think this is enough and the right place. Let the I* and liaisons figure this out so that we all can go back to protocol design and development.

Best,

Rolf

> From: Loa Andersson [mailto:[email-masked]]
> Sent: Mittwoch, 5. Oktober 2011 12:48
> > I think Brian makes an excellent point here. RFC 1958 already
> contains exactly the same basic message (just with far less
> (unnecessary) words). I don't think we need this document as it doesn't
> really add anything to what RFC 1958 says. I'll provide a more detailed
> review later.
> >
> > Best,
> >
> > Rolf
> >
> >
> Of
> OAM)
> >>>     [RFC5317] includes the analysis that "it is technically
> feasible
> >> that
> >> assumption

---

From: Loa Andersson <[email-masked]>
Date: Wed, 05 Oct 2011 13:46:41 +0200

Tom,

I don't think there is any objections to improving the document, the
most straight-forward way of doing this is the time-honored IETF
method "supply the text!"

/Loa

On 2011-10-05 10:01, t.petch wrote:
> From: "The IESG"<[email-masked]>
> To: "IETF-Announce"<[email-masked]>
> Subject: Last Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt>

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 05 Oct 2011 13:50:53 +0200

Rolf,

I don't remember saying the "sole purpose", the IETF way is to document
requirements, specifications, processes and agreements in RFCs; this is
just another document in this tradition. ANd as such a very good
document.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Wed, 05 Oct 2011 13:53:06 +0200

Feng,

there were only one organization invbolved in the decision to develop
two OAM solutions!

/Loa

On 2011-10-05 13:29, HUANG Feng F wrote:
> Subject: Re: Last Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
>
> Rolf,
>

--

---

From: HUANG Feng F <[email-masked]>
Date: Wed, 5 Oct 2011 19:58:13 +0800

Loa,
   YES, but there are only someone (not organization-that's a individual draft and MEAD team-not ietf mpls group or ietf group, which has been disbanded by themselves one years ago) make decision to done a single solution!
B.R.
Feng

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: 2011年10月5日 19:53
To: HUANG Feng F
Cc: [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) toInformational RFC

Feng,

there were only one organization invbolved in the decision to develop two OAM solutions!

/Loa

On 2011-10-05 13:29, HUANG Feng F wrote:
> Of Loa Andersson
> Subject: Re: Last 
> Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons 
> for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
>
> Rolf,
>
>>> 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 

--

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 05 Oct 2011 13:01:49 +0100

Tom

"I would take issue with OSPF/ISIS and IPv4/IPv6. "

Please can you expand a little on this.

Stewart

---

From: "t.petch" <[email-masked]>
Date: Wed, 5 Oct 2011 14:34:37 +0200

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 05, 2011 1:46 PM
Subject: Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>

> method "supply the text!"

Which I think belongs in a Working Group with a chair or two and an AD or two,
with the relevant expertise in the members, perhaps rtgwg.

In such a setting, I might comment that with OSPF and ISIS, the second half of
the last paragraph is wrong.  They are an example of islands, as described in
s.6, but they are required to interwork, in a manner of speaking and do so via
BGP, that is we have OSPF-BGP interworking and ISIS-BGP interworking, neither of
which are specified outside proprietary solutions, but both of which need to
work for the Internet work.  Which is a cost of having two solutions.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Wed, 5 Oct 2011 14:47:22 +0200

---- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, October 05, 2011 2:01 PM

Stewart

See my reply to Loa for the first.

For IPv4/IPv6, we are not talking about two solutions which are concurrent in
any sense of the word.  When the limitations of IPv4 started to loom on the
horizon, work was started on a replacement, and there were several candidates,
of which - thankfully - one was chosen.  The issue that was not given enough
attention was how to migrate the world at large from IPv4 to IPv6.  As has been
clearly described on
the MPLS-TP list, interworking is impossible, the Characteristic Information is
too dissimilar, and with interworking being impossible, migration is naturally
difficult.

So it is an interesting problem, and the coexistence models of s.6 of this I-D
are relevant, but it is a poor fit for having two rival solutions being
developed
concurrently for the same problem.  I use video recorders, and latterly the DVD
replacement, as poster children for this issue - most people can relate to these
examples
without needing an in-depth knowledge of A-law or some such:-)

Tom Petch

---

From: Rolf Winter <[email-masked]>
Date: Wed, 5 Oct 2011 14:52:35 +0000

Hi Loa,

There actually are some nuggets in the document but you have to look hard for them. E.g. section 4.2 analyzes TDM PWs and states that even within the IETF the exact same situation has arisen before, and three solutions have been specified. However, the IETF made one of them the default solution, so at least there is a baseline type to use and interoperability is guaranteed. If the IETF has gone down that particular path, then I don't see a reason why we cannot do the same thing again (yes, yes I know it is not optimal, I wish life was simple but I was recently convinced of the opposite). The document makes another good point in this regard: the party that is not using the default needs to bear all the cost (operational and such) which is a good point to make. This whole situation right now feels like some sort of attrition warfare and I don't think it is efficient use of our time.

Best,

Rolf

> Sent: Mittwoch, 5. Oktober 2011 13:51
> To: Rolf Winter
> Cc: [email-masked]
> > Let me answer with a counter-question. If the sole purpose of this
> document is to stop the development of two OAM solutions, do you think
> this RFC-to-be will achieve that? Seriously? The problem I see here is
> that we start a habit of writing "politically" motivated documents. We
> have this issue documented already all over the place in the form of
> minutes, web sites, press releases etc. I think this is enough and the
> right place. Let the I* and liaisons figure this out so that we all can
> go back to protocol design and development.
> >
> > Best,
> >
> > Rolf
> >
> >
> >>>>>      requirements of a Transport profile, and that the
> architecture
> >>>> allows
> >>>>>    and decisions that the combined group has had during the
> months
> >> of
> >>>>>    March and April, 2008
> >>>>      successfully solved the same problem, choose the same
> solution
> >>>> unless

---

From: [email-masked]
Date: Wed, 5 Oct 2011 11:29:09 -0400

Rolf,

I agree with the points that you have raised, we need to make more 
efficient use of our time to address the real technical issues. 

To expand on this point, one major factor that has not been considered in 
this draft is that significant deployments (300,000+ nodes) of a second 
solution already exist. This second solution is based on the Ethernet tool 
OAM tool set, see draft-fang-mpls-tp-oam-considerations for further 
details. 

Given the current situation the pragmatic engineering approach is to:
 - Acknowledge these deployments:
 - Define a method for interconnecting between domains that deploy the 
tools identified in draft-ietf-mpls-tp-oam-analysis and the Ethernet based 
tool set that avoids the need for an interworking function:
 - Take steps to avoid a proliferation of further options (i.e. a third of 
fourth or nth solution).

I do not want to expend energy on debating how we arrived at this 
situation, its document on various email threads and in Internet drafts. 
History has shown that we all have our own interpretation of these events 
and repeating this debate is unlikely to cause the protagonists to change 
their opinions.  We need to focus on how we manage the situation in which 
we find ourselves.

Regards,

Malcolm

Rolf Winter <[email-masked]> 
Sent by: [email-masked]
05/10/2011 10:52 AM

To
Loa Andersson <[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

Hi Loa,

There actually are some nuggets in the document but you have to look hard 
for them. E.g. section 4.2 analyzes TDM PWs and states that even within 
the IETF the exact same situation has arisen before, and three solutions 
have been specified. However, the IETF made one of them the default 
solution, so at least there is a baseline type to use and interoperability 
is guaranteed. If the IETF has gone down that particular path, then I 
don't see a reason why we cannot do the same thing again (yes, yes I know 
it is not optimal, I wish life was simple but I was recently convinced of 
the opposite). The document makes another good point in this regard: the 
party that is not using the default needs to bear all the cost 
(operational and such) which is a good point to make. This whole situation 
right now feels like some sort of attrition warfare and I don't think it 
is efficient use of our time.

Best,

Rolf

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

---

From: Rolf Winter <[email-masked]>
Date: Wed, 5 Oct 2011 19:02:19 +0000

Hi,

Here's the review I promised earlier. I still think it would be best to not publish the draft for the reasons I mentioned earlier. In case the IETF wants to move this document forward I think at least a number of things need to change:

a) The document makes a number of assertions that I think are not correct. E.g. it states that the solutions must be implementable in software. I cannot recall that there was any assertion about whether some, all or none of the things that the requirements documents prescribe should be build in HW or SW. A vendor needs to build equipment that fulfills the requirements, the standard needs to specify mechanisms that fulfill the requirements. If a vendor can build it in SW fine, if it has to be done in HW fine. But the main point is that everything needs to fulfill the specs which fulfill the requirements.

b) The complexity sausage needs to go. The section does not help the goal of the document or the relevant parts are duplicated later in the text.

c) Some text passages are overly dramatic and could use a little down-toning (e.g. " (something that would inevitably drive all customers away!)"). Others use absolute figures for speculative things (like increases cost by a factor of two etc.). Yet others are not very polite to certain vendors like "forces all serious router vendors to implement both protocols". I am not sure the IETF wants to call router vendors to be "not serious" if they only implement either OSPF or ISIS. The basic message is the text needs a serious cleanup of language.

d) Section 6 needs to go. I do not think that these coexistence models are agreed by the wider IETF community and I don't think they help the message of the document. 

e) The document should provide more references for some of the statements that caused dispute on the list.

Best,

Rolf

> Rolf Winter
> Sent: Dienstag, 4. Oktober 2011 11:17
> To: Brian E Carpenter; [email-masked]
> Cc: [email-masked]
> Subject: RE: Last Call: <draft-sprecher-mpls-tp-oam-considerations-
> I think Brian makes an excellent point here. RFC 1958 already contains
> exactly the same basic message (just with far less (unnecessary) words).
> I don't think we need this document as it doesn't really add anything
> to what RFC 1958 says. I'll provide a more detailed review later.
> 
> Best,
> 
> Rolf
> 
>

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 6 Oct 2011 08:04:24 +0200

All,

I do not support this draft.

As Brian pointed out there is already RFC1958 which addresses the
same issues. So any more time spent on this draft is wasted.

>     of course using this argument to reject improvements."

Please note that the Y.1731 toolset already existed in 2006.
So when this toolset was adapted (using MPLS headers in stead
of Ethernet headers) it was already used and tested.

This is in line with section 3.14 in RFC1958:

    3.14 And perhaps most important: Nothing gets standardised until
    there are multiple instances of running code.

In the meantime there are multiple instances: more than 300.000 nodes
with equipment from different vendors.

Regards, Huub.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 06 Oct 2011 14:14:32 +0200

Feng,

I'm not sure how to parse this, but personal attacks on ietf mailing
should at least be substantiated with evidence.

Like been said before we discuss thing over and over and come to an
working group or IETF consensus call, and then the discussion starts
over again.

/Loa

--

---

From: HUANG Feng F <[email-masked]>
Date: Thu, 6 Oct 2011 22:40:26 +0800

Dear Loa,
    I am sorry if you regard my email is personal attacks, but I think I tell the truth, here are evidences.

1.  Draft-sprecher-mpls-tp-oam-considerations is a personal draft, it ask for comments in ietf, I have expressed my comments on my previous emails and I don't support it. ( You said it is a good draft, please provide the evidence!)

2.  For MEAD team's decision on OAM, it was recorded in draft-ietf-mpls-tp-oam-analysis as below, but some MEAD members don't agree it, so they quit from this draft, you can see change from draft-ietf-mpls-tp-oam-analysis-00 to draft-ietf-mpls-tp-oam-analysis-02. 

"This document reports the conclusions of the MPLS-TP design team
   discussions on the MPLS-TP OAM tools at IETF75 and the guidelines
   that were agreed.  The guidelines refer to a set of existing OAM
   tools that need to be enhanced to fully support the MPLS-TP OAM
   requirements and identify new tools that need to be defined.  The
   organizational structure of the documents on MPLS-TP OAM tools was
   also discussed and agreed at IETF75 and is described later in this
   document."

3. For MEAD team's disband, you can see liaison send to itu recorded in TD218-wp3 (2009-9).

B.R.
Feng

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: 2011年10月6日 20:15
To: HUANG Feng F
Cc: [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) toInformational RFC

Feng,

I'm not sure how to parse this, but personal attacks on ietf mailing should at least be substantiated with evidence.

Like been said before we discuss thing over and over and come to an working group or IETF consensus call, and then the discussion starts over again.

/Loa

On 2011-10-05 13:58, HUANG Feng F wrote:
>>>> From: [email-masked] [mailto:[email-masked]] On 
>>>> Behalf Of Brian E Carpenter
>>>> 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 
>>>> 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.
>>>>
>>>> solution unless

--

---

From: "t.petch" <[email-masked]>
Date: Fri, 7 Oct 2011 11:00:58 +0200

----- Original Message -----
From: "Huub van Helvoort" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 30, 2011 8:47 AM
> 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.

Huub

I appreciate that you were unhappy with the disbandment of the MEAD team, and
that that is still an issue for you; I would value understanding what set your
expectations for the MEAD team.

My background is from the IETF and that gives me different persective on the
MEAD team.  Design teams are a part of the IETF process, but run counter to the
open discussion that characterises most of the work of the IETF, so their scope
should be limited as should their duration.  When the MEAD team was disbanded, I
gave a sigh of relief as I saw it running counter to the processes of the IETF,
in both respects.  Clearly, you have different expectations which makes it
valuable to understand how those came about.

Tom Petch

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 09 Oct 2011 13:42:02 +0200

All,

I still do not support this draft.

Section 6 focusses on the interworking between two toolsets

In transport networks we *never* have peer-2-peer OAM interworking.
If it was required it would have explicitly been mentioned in
the MPLS-TP requirements RFC.

Why don't you simply read draft-tsb-mpls-tp-ach-ptn or Annex B
of G.8110.1 where it is documented how different toolsets can
be deployed in a network without any issues.

Section 6 is totally irrelevant.

Regards, Huub.

---

From: [email-masked]
Date: Sun, 9 Oct 2011 09:27:29 -0400

Huub,

I agree.

Regards,

Malcolm

Huub van Helvoort <[email-masked]> 
Sent by: [email-masked]
09/10/2011 07:42 AM
Please respond to
[email-masked]

To
IETF Discussion <[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,

Regards, Huub.

---

From: [email-masked]
Date: Mon, 10 Oct 2011 10:29:00 +0800

All,

I also agree with Huub.

As a consensus reached in Beijing meeting, mechanism using the tools 
defined for MPLS is a default tool set and another using the tools defined 
in G.8013/Y.1731 is an optional one. 

B.R.
Yuxia

[email-masked] 
发件人:  [email-masked]
2011-10-09 21:27

收件人
[email-masked]
抄送
[email-masked], IETF Discussion <[email-masked]>
主题
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

Huub, 

I agree. 

Regards, 

Malcolm 

Please respond to
[email-masked]

To

Subject

All,

Regards, Huub.

---

From: John E Drake <[email-masked]>
Date: Mon, 10 Oct 2011 06:58:49 -0700

Are we now going to be subject to daily updates? 

> Huub van Helvoort
> Sent: Sunday, October 09, 2011 7:42 AM
> To: IETF Discussion

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Oct 2011 10:27:26 -0400

> As a consensus reached in Beijing meeting, mechanism using the tools defined for MPLS is a default tool set and another using the tools defined in G.8013/Y.1731 is an optional one. 

This document is about the consequences of there being an optional OAM solution if it is implemented by anyone at all.

Russ

---

From: <[email-masked]>
Date: Tue, 11 Oct 2011 12:22:02 +0100

Huub van Helvoort wrote 09 October 2011 12:42

> the MPLS-TP requirements RFC.

Indeed, to have any peer to peer OAM simply removes the ability of the OAM to do its job.

regards, Neil

---

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

>Indeed, to have any peer to peer OAM simply removes the ability of the OAM to do its job.

Neither of these statements is completely accurate.

For example, the ITU produced Y.1712 that details the peer-peer interworking 
of ATM OAM per I.610 with the MPLS OAM described in Y.171.

I think that the accurate statement is that OAM interworking is perhaps undesirable
but trivial when the OAM semantics matches so that the interworking is syntactic translation,
but very challenging (and perhaps sometimes impossible) when the semantics are different.
(For "semantics to be different" it is enough for timer values to be different,
 let alone different fault states.)

However, there are many cases where several OAM types co-exist in a single deployment.
Perhaps the most relevant case is the widespread use of both EFM OAM (802.3 Section 57) with Y.1731 OAM.

Y(J)S

---

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

> I think Brian makes an excellent point here. 
> RFC 1958 already contains exactly the same basic message (just with far less (unnecessary) words). 
> I don't think we need this document as it doesn't really add anything to what RFC 1958 says. 

I too object to having too many politically motivated process drafts
(in addition to having questions about the specific examples in the present draft).

However, I am not sure that RFC 1958 helps to much here.

The relevant part of 1958 is :
   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.

That is fine, but what if there are already two solutions (which is the case here) ?

It don't see it in 1958, but the IETF tao has generally been to have one MUST mode
and perhaps one or more MAY modes. RFC 4835 is a good example of how this is done.

So I believe that this draft is stating something stronger than RFC 1958,
and indeed stronger than the IETF tao usually requires.

Y(J)S

---

From: <[email-masked]>
Date: Sun, 16 Oct 2011 14:27:40 +0100

Hi Yaakov,

You wrote 16 October 2011 10:46

> To: Harrison,N,Neil,DKQ7 R; [email-masked]; [email-masked]
> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon)

NH=> Actually the latter is if the OAM is to do its job to the most simple/optimal/reliable level....but we can of course ignore and overrule such a requirement.
> of ATM OAM per I.610 with the MPLS OAM described in Y.171.

NH=> Indeed so.  Dave Allan and I wrote Y.1712.  I only realised later what a waste of time it was...and on 2 counts:

-	Andy Reid made me aware of just what a bad and unnecessary idea an AIS/FDI signal was in a co-ps mode layer network (its obviously silly for a cl-ps mode layer network);

-	I sat down and thought much more deeply about what peer interworking really means... noting that DP OAM I/W is only one small facet of the whole DP/CP I/W vista anyway.  The key revelation for me was understanding that since the whole purpose of *all* networking scenarios is to allow message/file/stream applications that are external to the network(s) to communicate over large geographic distance, then the only place peer I/W is of any relevance is in the TOS layer networks (like IP, the PSTN and (potentially) ATM) that have the required message/file/stream external application adaptations functions.  Any non-TOS layer peer I/W (and this is for all the DP/CP components, not just the DP OAM bit) is just generating unnecessary work/problems/costs for the sake of it...because we still need to terminate the non-TOS layer network(s) and expose the real E2E TOS layer network case that must always be present!  Simple and blindingly obvious when pointed out.  I wrote a paper on this that goes into a little more detail.  I'll send you a copy of it if you like...just ask.

Note - The physical interconnection of BOS guided EM wave media (metallic or optical) components is *not* peer I/W.  This is how we physically plug together different boxes at the BOS.  Here we are only interested (for many reasons) in the transparent transfer of the DP symbols.
>  let alone different fault states.)

NH=> This is true.  When Dave/I penned Y.1712 our main thought was we could sensibly do this because of the close alignment of the OAM.  Only later did I fully realise what a waste of time doing this was anyway.

But you are right that peer interworking becomes even more daft/harder when we have (in increasing order of daftness/hardness):

(i) the same mode but quite different DP/CP functional specifications in each technology (wrt traffic unit structure and fields therein, addressing of access points, routing, signalling, OAM, etc...all these components must be interworked) or

(ii) different modes...here we can have very significant functional mismatch, and some functions simply don't exist or align at all, eg
-	co-cs/ps signalling (esp OOB) is not relevant to the cl-ps mode
-	co-cs DP AIS/FDI is obviously not relevant to the cl-ps mode and (less obviously so) to the co-ps mode
-	a cl-ps mode traffic unit TTL function should never appear in a co-cs or co-ps mode layer network traffic unit
-	the short-cuts in traffic unit labelling that can be applied to the co-ps and co-cs modes (they are not the same) cannot be applied at all to the cl-ps mode
-	etc.
> (802.3 Section 57) with Y.1731 OAM.

NH=> Of course we can this...just like we can do all sorts of wrong/unnecessary things.  The key issue with co-ps mode OAM of course is that when it arrives at any DP trail termination point that trail termination point must be able to make sense of it if we are not only to detect misconnectivity but diagnose the offending source.  If there are N spins of OAM in some layer network then each trail termination point needs to be able to handle N types of OAM arriving due to misconnectivity.  This is hardly a sensible situation to allow to happen however.

Aside=> The above is *per layer network*.  We never nested different layer network instances of the same (wrt DP/CP functions and traffic unit structures) co-ps technology before...so inter-layer misconnectivity was simply not possible.  In MPLS-TP we can have both cases of intra- and inter-layer misconnectivity...and that means we have to pay attention to the structure of the SA ID we use in the CV PDUs.

regards, Neil

---

From: Loa Andersson <[email-masked]>
Date: Sun, 23 Oct 2011 11:07:27 -0700

All,

I've taken time to re-read this draft over the weekend.

I still think it is well-written and extremely to the point;
it is in the interest of the IETF to publish. I support
publication of the draft.

Admittedly there are some issues around the e.g. the description of the
SDH/SONNET and the standardization of those technologies. Having
been involved in development of equipment that could run both
SDH and SONET, my understanding is that both when it comes to
chips and SW the split, even after the compromise, lead to higher
costs and longer schedules. we would have been in a better shape
with one standard also that time.

Maybe the authors should reflect the facts that Huub correctly point
out in his early mail on this thread, where he describes a situation
that was much worse than what is in the document.

/Loa

--

---

From: Shane Amante <[email-masked]>
Date: Sun, 23 Oct 2011 21:54:40 -0600

I have taken the time to read this document and support it's publication.

From an operational PoV, the discussion in the Section 3 (particularly Sections 3.5 & 3.6) really hit home in that the costs of deploying a protocol to the network _and_ maintaining that protocol in the network are non-trivial.  And, ultimately, for a function as critical as OAM it absolutely needs to "just work" *everywhere*.

-shane

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 21 Oct 2011 18:40:01 +0200

All,

I have read this draft and support the publication as an informational
RFC.

I believe the document is needed since it explains why it is not
beneficial to standardize two solutions for the same purpose. The
document also makes clear some of the aspects I was not aware of. 
It is obvious that two solutions would cause a lot of unnecessary effort
and costs. There are many examples which show that competing standards
are contra-productive for the goals of each party. 

I fully agree with one of the statements on this list.
"I think it would be irresponsible of the IETF not to document this
situation."

Mehmet

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of ext The IESG
> Sent: Monday, September 26, 2011 9:43 PM
> To: IETF-Announce
> (TheReasons for Selecting a Single Solution for MPLS-TP OAM)
toInformational
> The file can be obtained via
http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-consideration
s/
> IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-consideration
s/

---

From: [email-masked]
Date: Mon, 24 Oct 2011 12:44:34 -0400

Loa,

As per my previous email , I have only seen one response to the 12 points 
that I raised, I do not agree with your assessment of this document.

Just to remind you of the points made by myself and several others on 
SONET and SDH:

SONET is a true subset of SDH:
The SDH standard supports both the North American and Japanese 24 
channel/T1/T3 hierarchy and the European 30 channel/E1/E4 based hierarchy 
within a single multiplexing structure.
SDH has no options for payloads at VC-4 (150Mb/s) and above. This has 
provided the basis for common solutions for packet based clients (GFP).
SDH allows T1/T3 services to be delivered in Europe and E1 services to be 
delivered in North America using a common infra structure.

A single standard that supported either the T1/T3 hierarchy or the E1 
hierarchy would not have been successful.

Deployment of a E1 only standard in North America would have required the 
conversion of all of the 24 channel/T1 deployed equipment and services 
into the 30 channel/E1 format. Similarly deployment of a T1 only standard 
in Europe would have required the conversion of all of the 30 channel/E1 
equipment and services into 24 channel/T1 format.  Clearly given the 
existing network deployments (in 1988) this was not a practical 
proposition.

Regards,

Malcolm

23/10/2011 02:07 PM

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

All,

/Loa

--