Subject: RE: [mpls] FW: Last Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt> (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC

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

Hi,
 
1.

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.

MPLS-TP is subset of "MPLS", "MPLS" is old mpls developed before MPLS-TP in 2008 or include MPLS-TP developed this years and in the future?
MPLS-TP is for transport network, SDH/OTN/Etherent is transport network, it should be shown capability to transport network.

1.1
   The standardization process within the IETF allows for the continued
   analysis of whether the OAM solutions under development meet the
   documented requirements, and facilitates the addition of new
   requirements if any are discovered.  It is not the purpose of this
   document to analyze the correctness of the selection of specific OAM
   solutions.  This document is intended to explain why it would be
   unwise to standardize multiple solutions for MPLS-TP OAM, and to show
   how the existence of multiple solutions would complicate MPLS-TP
   development and deployment making networks more expensive to build,
   less stable, and more costly to operate.

According to JWT report, MPLS-TP is joint standardized by IETF and ITU-T, it is not right for someone decide solution for IETF and ITU-T.
      
     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.  A report was subsequently submitted to the
   IETF MPLS Working Group at the Stockholm IETF meeting in July 2009.
   The guidelines drawn up by the design team have played an important
   role in the creation of a coherent MPLS-TP OAM solution.

MEAD team's decision has never been send to ITU-T for comments, ITU-T have got nothing information about it.

1.2.  The Development of a Parallel MPLS-TP OAM Solution
   
The first of these was discussed within the IETF's MPLS working group
   where precedence was given to adherence to the JWT's recommendation
   to select a solution that reused as far as possible pre-existing MPLS
   tools.  Additionally, it was considered that consistency with
   encodings and mechanisms used in MPLS was of greater importance.

Many operators ask MPLS-TP OAM shown capacity to Ethernet, you can see draft-bhh-mpls-tp-oam-y1731. at least 9 provdiders support it.
JWT report don't said anything about one solution, it is a start point to develop solution, IETF and ITU-T don't explore to public, one solution should be taken.

3.6

It should be noted that, in the long-run, it is the end-users who pay
   the price for the additional development costs and any network
   instability that arises.

authors are come from vendors, they are not end users, which some venders want to push their own solutions.
we should hear opinons from providers? let providers show their consideration on OAM, there is a IETF providers' draft about OAM consideration, you can refer to draft-fang-mpls-tp-oam-considerations, it is a pure providers' draft, some considerations are listed there!

5.1 for SDH/SONET as example, it work well in the network, phone call between Europe to US work very well, I am wondering author should known some history about SDH and SONET. 

6.  Potential Models For Coexistence 

    In transport network, overlay model is usually used, it work very well.

B.R.

Feng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 2011年9月27日 5:58
To: [email-masked]
Subject: [mpls] FW: Last Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt> (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC

MPLS Working Group,

Please be aware of the IETF last call as shown below. The document was presented for publication as an individual RFC with IETF consensus and AD sponsorship.

This draft is clearly close and relevant to the work you do, but after discussing with the chairs I came to the conclusion that it does not comment on the technical or process decisions of the MPLS working groups, and it does not attempt to make any technical evaluations or definitions within the scope of the MPLS working group. It is more of a philosophical analysis of the way the IETF approaches the "two solutions" problem with special reference to MPLS-TP OAM.

Thus, I am accepting the document as AD Sponsored rather than running it through the MPLS working group. My reasoning is that the working group has got plenty to do working on technical issues without being diverted into wider IETF philosophy.

As an AD Sponsored I-D it is subject to a four week IETF last call. That is plenty of opportunity for everyone to comment and express their views. Please send your comments to the IETF mailing list as described below, or (in exceptional circumstances) direct to the IESG.

Thanks,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:ietf-announce- 
> [email-masked]] On Behalf Of The IESG
> Sent: 26 September 2011 20:43
> To: IETF-Announce
> Subject: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> 
> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to 
> Informational 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-considerati
> ons/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerati
> ons/
> 
> 
> 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

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 05 Oct 2011 11:24:27 +0100

On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote:
 > major unresolved technical concerns

Alessandro

Please can I suggest that you write an internet draft detailing
these "major unresolved technical concerns" so that we
can all understand them.

Such a draft needs to be technical, and describe the actions
that the network operator is unable to perform, or the fault
cases that they are unable to diagnose using the OAM defined
in the IETF RFCs, or late stage WG drafts.

Alternatively if you are referring to a bug in the MPLS-TP
OAM protocols, you need to tell the community what it is.

I believe that this request has been made  a number of
times, in various forums, and, as far as I know, no document
has yet been produced.

An argument of the form "you must standardize what I want"
will not fly. What is needed is a very clear technical definition
of the issue(s).

When we have the "major unresolved technical concerns"
on the table, we will be in a position to determine the best
disposition of those issues.

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: [email-masked]
Date: Wed, 5 Oct 2011 22:53:31 +0800

Dear All,

I do not support either.

In section 3.5:
If two MPLS OAM protocols were to be deployed we would have to consider
three possible scenarios:
1) Isolation of the network into two incompatible and unconnected islands.

Two OAM solutions have been discussed for a long time in both ITU-T and
IETF.
Each solution has their own supporters inculding carriers and vendors.
So I don't think there is any interworking issue between two OAM solutions.
Carrier will select one OAM solution, A or B, in their network.
No need to select A and B at one network at the same time.

Respect their own selection and listen to their requirements, please.

Best regards,

Jian

                                                                           
             Larry                                                         
             <larryli888@ya                                                
             hoo.com.cn>                                            收件人 
             发件人:                "[email-masked]"                  
             mpls-bounces@i         <[email-masked]>, "[email-masked]" 
             etf.org                <[email-masked]>, "[email-masked]"       
                                    <[email-masked]>, D'Alessandro          
                                    Alessandro Gerardo                     
             2011-10-05             <alessandro.dalessandro@telecomitalia. 
             19:51                  it>                                    
                                                                      抄送 
                                                                           
                                                                      主题 
                                    [mpls] 回复：  R: FW: Last Call:       
                                    <draft-sprecher-mpls-tp-oam-considerat 
                                    ions-01.txt> (The Reasons for          
                                    Selecting a Single Solution for        
                                    MPLS-TP OAM) to Informational RFC      

                                                                           

Dear all,

     So many multiple solution cases just show the way that the world and
technology works. Killing a solution roughly brings more damage to the
industry.

     Section 3.6 discusses the elements of the choice of solutions. Current
application and deployment should be considered. In China Mobile, more than
330,000 PTN box are/will based on G.8113.1.

     TDM PW gives a good example. G.8113.1 based OAM is relative simple and
mature and widely deployed and should be the standard.

Best regards,

         Han Li

--- 11年10月5日，周三, D'Alessandro Alessandro Gerardo
<[email-masked]> 写道：

> 发件人: D'Alessandro Alessandro Gerardo
<[email-masked]>
> 主题: [mpls] R: FW: Last Call:
<draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for
Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
> 收件人: "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
> 日期: 2011年10月5日,周三,下午5:38
> Dear all,
> I do not support.
>
> Basically I think it is superfluous dedicate an RFC to
> state it is better having one standard instead of two ones
> or many... for sure the lower are the variants the better is
> for the industry (one is the ideal).
>
> When two or more standards or de-facto standards exist it
> is because the problem they solve is not exactly the same,
> the way they solve the problem is optimized for different
> environments/boundary conditions (more efficient, more
> effective, etc). Therefore a single solution does not
> necessarily meet the different market requirements.
>
> It is fundamental to enter into the problem's details
> before making consideration about the best way to proceed
> (one solution, two solutions, multiple solutions) whilst the
> document clearly declares it does not want to make any
> technical evaluations.
>
> After more than three years of debates within the IETF and
> major unresolved technical concerns risen from some
> transport operators, the existence of this draft is by
> itself the sure sign that MPLS-TP OAM is a case where a
> single solution has not be found to meet all the different
> market requirements. Otherwise, why are we still discussing
> about it....?
>
> Therefore we must be realistic and the lessons learned from
> the past should guide our decisions: if a solution cannot be
> found for satisfying all the requirements it is better to
> have two standards and let the market decide how to exploit
> them. Are  we really sure the cost(many) / benefit
> (none) analysis done in section 7.5 is realistic?
>
> Best regards,
> Alessandro
>
> ------------------------------------------------------------------
> Telecom Italia
> Alessandro D'Alessandro
> Transport Innovation
> Via Reiss Romoli, 274 - 10148 Torino
> phone:  +39 011 228 5887
> mobile: +39 335 766 9607
> fax: +39 06 418 639 07
>
> -----Messaggio originale-----
> Da: [email-masked]
> [mailto:[email-masked]]
> Per conto di Adrian Farrel
> Inviato: lunedì 26 settembre 2011 23:58
> A: [email-masked]
> Oggetto: [mpls] FW: Last Call:
> <draft-sprecher-mpls-tp-oam-considerations-01.txt>
> (The Reasons for Selecting a Single Solution for MPLS-TP
> OAM) to Informational RFC
>
> MPLS Working Group,
>
> Please be aware of the IETF last call as shown below. The
> document was presented for publication as an individual RFC
> with IETF consensus and AD sponsorship.
>
> This draft is clearly close and relevant to the work you
> do, but after discussing with the chairs I came to the
> conclusion that it does not comment on the technical or
> process decisions of the MPLS working groups, and it does
> not attempt to make any technical evaluations or definitions
> within the scope of the MPLS working group. It is more of a
> philosophical analysis of the way the IETF approaches the
> "two solutions" problem with special reference to MPLS-TP
> OAM.
>
> Thus, I am accepting the document as AD Sponsored rather
> than running it through the MPLS working group. My reasoning
> is that the working group has got plenty to do working on
> technical issues without being diverted into wider IETF
> philosophy.
>
> As an AD Sponsored I-D it is subject to a four week IETF
> last call. That is plenty of opportunity for everyone to
> comment and express their views. Please send your comments
> to the IETF mailing list as described below, or (in
> exceptional circumstances) direct to the IESG.
>
> Thanks,
> Adrian
>
> > Subject: Last Call:
> <draft-sprecher-mpls-tp-oam-considerations-01.txt>
> > [email-masked]
> mailing lists by 2011-10-24. Exceptionally, comments may
> > be sent to [email-masked]
> instead. In either case, please retain the
> Questo messaggio e i suoi allegati sono indirizzati
> esclusivamente alle persone indicate. La diffusione, copia o
> qualsiasi altra azione derivante dalla conoscenza di queste
> informazioni sono rigorosamente vietate. Qualora abbiate
> ricevuto questo documento per errore siete cortesemente
> pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may
> contain privileged information intended for the addressee(s)
> only. Dissemination, copying, printing or use by anybody
> else is unauthorised. If you are not the intended recipient,
> please delete this message and any attachments and advise
> the sender by return e-mail, Thanks.
>

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 5 Oct 2011 11:38:14 +0200

Dear all,
I do not support.

Basically I think it is superfluous dedicate an RFC to state it is better having one standard instead of two ones or many... for sure the lower are the variants the better is for the industry (one is the ideal).

When two or more standards or de-facto standards exist it is because the problem they solve is not exactly the same, the way they solve the problem is optimized for different environments/boundary conditions (more efficient, more effective, etc). Therefore a single solution does not necessarily meet the different market requirements.

It is fundamental to enter into the problem's details before making consideration about the best way to proceed (one solution, two solutions, multiple solutions) whilst the document clearly declares it does not want to make any technical evaluations.

After more than three years of debates within the IETF and major unresolved technical concerns risen from some transport operators, the existence of this draft is by itself the sure sign that MPLS-TP OAM is a case where a single solution has not be found to meet all the different market requirements. Otherwise, why are we still discussing about it....?

Therefore we must be realistic and the lessons learned from the past should guide our decisions: if a solution cannot be found for satisfying all the requirements it is better to have two standards and let the market decide how to exploit them. Are  we really sure the cost(many) / benefit (none) analysis done in section 7.5 is realistic?

Best regards,
Alessandro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Adrian Farrel
Inviato: lunedì 26 settembre 2011 23:58
A: [email-masked]
Oggetto: [mpls] FW: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

MPLS Working Group,

Thanks,
Adrian

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 5 Oct 2011 13:01:30 +0200

Alessandro, Stewart and all,

I concur with Stewart: please write a draft detailing your major technical concerns.

I'd like to add a quote from Malcolm's presentation at the IETF meeting in Prague:

	"Differences <between the solution approved by the IETF and its ITU-T sponsored 	alternatives - Sasha> are close to invisible at the level of the requirements in RFC5860".

Just to remind you that RFC 5680 is the MPLS-TP OAM requirements document.

Malcolm has also said:

	"Many of the issues only become apparent when the protocol and equipment behavior is 	explored"

but, AFAIK, these issues have never been explicitly brought for the consideration. 

My 2c,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
> Sent: Wednesday, October 05, 2011 12:24 PM
> To: D'Alessandro Alessandro Gerardo
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] R: FW: Last Call: <draft-sprecher-mpls-tp-oam-
> considerations-01.txt> (The Reasons for Selecting a Single Solution for

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Larry <[email-masked]>
Date: Wed, 5 Oct 2011 19:51:06 +0800 (CST)

Dear all,

     So many multiple solution cases just show the way that the world and technology works. Killing a solution roughly brings more damage to the industry.

     Section 3.6 discusses the elements of the choice of solutions. Current application and deployment should be considered. In China Mobile, more than 330,000 PTN box are/will based on G.8113.1.

     TDM PW gives a good example. G.8113.1 based OAM is relative simple and mature and widely deployed and should be the standard.

Best regards,

         Han Li

--- 11年10月5日，周三, D'Alessandro Alessandro Gerardo <[email-masked]> 写道：

> 发件人: D'Alessandro Alessandro Gerardo <[email-masked]>
> 主题: [mpls] R: FW: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
> 收件人: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> 日期: 2011年10月5日,周三,下午5:38
> Dear all,
> I do not support.
> 
> as an

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Wed, 5 Oct 2011 18:47:44 +0200

Dear Stewart,
Many thanks for your answer that anyway I do not believe addresses the root concern I have on the proposed draft.

I would avoid  bringing technical discussions into this thread because it is a declared intent of the draft in the object to NOT touch such aspects. I'm therefore going to answer you on a different thread.
Best regards,
Alessandro

-----Messaggio originale-----
Da: Stewart Bryant [mailto:[email-masked]]
Inviato: mercoledì 5 ottobre 2011 12:24
A: D'Alessandro Alessandro Gerardo
Cc: [email-masked]; [email-masked]; [email-masked]
Oggetto: Re: [mpls] R: FW: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

Alessandro

Please can I suggest that you write an internet draft detailing these "major unresolved technical concerns" so that we can all understand them.

Such a draft needs to be technical, and describe the actions that the network operator is unable to perform, or the fault cases that they are unable to diagnose using the OAM defined in the IETF RFCs, or late stage WG drafts.

Alternatively if you are referring to a bug in the MPLS-TP OAM protocols, you need to tell the community what it is.

I believe that this request has been made  a number of times, in various forums, and, as far as I know, no document has yet been produced.

An argument of the form "you must standardize what I want"
will not fly. What is needed is a very clear technical definition of the issue(s).

When we have the "major unresolved technical concerns"
on the table, we will be in a position to determine the best disposition of those issues.

Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Oct 2011 09:16:02 +1300

Hi Jian,

> No need to select A and B at one network at the same time.

There are two large costs that you are ignoring:

a) all vendors wishing to bid for business from A and B will have to
   implement and support both solutions.

b) when A buys B or B buys A, the incompatible networks will have to
   be merged.

These are costs that run to hundreds of millions of USD, EUR or CNY.
They are costs caused directly by SDOs creating rival solutions.

I think it would be irresponsible of the IETF not to document this
situation. As engineers, we have an ethical responsibility here.

    Brian

---

From: David Sinicrope <[email-masked]>
Date: Wed, 5 Oct 2011 19:11:18 -0400

I concur with Dave's comment and support publication of the draft.
Dave

On Oct 5, 2011, at 7:06 PM, "David Allan I" <[email-masked]> wrote:

> I think it is unfortunate that we are in a situation where such a document has utility. But ultimately it does.
> 
> Therefore I support the publication of draft-sprecher...
> 
> D
> 
> 
> 
>> MPLS Working Group,
>> 
>> Please be aware of the IETF last call as shown below. The document was 
>> presented for publication as an individual RFC with IETF consensus and 
>> AD sponsorship.
>> 
>> This draft is clearly close and relevant to the work you do, but after 
>> discussing with the chairs I came to the conclusion that it does not 
>> comment on the technical or process decisions of the MPLS working 
>> groups, and it does not attempt to make any technical evaluations or 
>> definitions within the scope of the MPLS working group. It is more of 
>> a philosophical analysis of the way the IETF approaches the "two 
>> solutions" problem with special reference to MPLS-TP OAM.
>> 
>> Thus, I am accepting the document as AD Sponsored rather than running 
>> it through the MPLS working group. My reasoning is that the working 
>> group has got plenty to do working on technical issues without being 
>> diverted into wider IETF philosophy.
>> 
>> As an AD Sponsored I-D it is subject to a four week IETF last call. 
>> That is plenty of opportunity for everyone to comment and express 
>> their views. Please send your comments to the IETF mailing list as 
>> described below, or (in exceptional circumstances) direct to the IESG.
>> 
>> Thanks,
>> Adrian

---

From: Rui Costa <[email-masked]>
Date: Thu, 6 Oct 2011 04:02:19 +0100

I do not support this draft.	

a) Its "SONET and SDH" section is wrong. (Please refer to H. van Helvoort's, A. Reid's, M. Betts's comments.)	

b) It doesn't really add anything to RFC 1958. (Please refer to R. Winter's comments.) In RFC1958:	
"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".	
We didn't choose the elsewhere designs (ETH, T-MPLS; please check deployment numbers in other emails on this subject) on the grounds of backwards compatibility, but didn't choose the internet context design either, once the chosen IETF designs won't be backwards compatible with existing ones.	
(Please refer to the Jul2011 discussion regarding cc-cv-rdi draft)	

c) To the question "which requirement stated in the RFCs are not satisfied by the singe OAM solution defined in IETF?":	
For instance, RFC5860 2.2.3: " The protocol solution(s) developed to perform this function	
   proactively MUST also apply to [...] point-to-point unidirectional LSPs, and point-to-	
   multipoint LSPs."	
(Please refer f.i. to the Jul2011 discussion regarding cc-cv-rdi draft)	

d) I do agree with the supporters of this draft on "we are going in circles again". There are enough people supporting both solutions. Those supporting the ITU-T approach don't preclude the IETF's, although not subscribing it. Those supporting the IETF's do preclude ITU-T's. I don't understand the goal and time waste. As a final client, i don't understand why people want to preclude me of a valuable option.	

Regards,	
Rui

-----Original Message-----	
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: segunda-feira, 26 de Setembro de 2011 22:58
To: [email-masked]
Subject: [mpls] FW: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

MPLS Working Group,

Please be aware of the IETF last call as shown below. The document was presented
for publication as an individual RFC with IETF consensus and AD sponsorship.

This draft is clearly close and relevant to the work you do, but after
discussing with the chairs I came to the conclusion that it does not comment on
the technical or process decisions of the MPLS working groups, and it does not
attempt to make any technical evaluations or definitions within the scope of the
MPLS working group. It is more of a philosophical analysis of the way the IETF
approaches the "two solutions" problem with special reference to MPLS-TP OAM.

Thus, I am accepting the document as AD Sponsored rather than running it through
the MPLS working group. My reasoning is that the working group has got plenty to
do working on technical issues without being diverted into wider IETF
philosophy.

As an AD Sponsored I-D it is subject to a four week IETF last call. That is
plenty of opportunity for everyone to comment and express their views. Please
send your comments to the IETF mailing list as described below, or (in
exceptional circumstances) direct to the IESG.

Thanks,
Adrian

> Subject: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The
> Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
> 
> 
> The IESG has received a request from an individual submitter to consider
> the following document:
>   <draft-sprecher-mpls-tp-oam-considerations-01.txt> as an Informational
> RFC
> 
> [email-masked] mailing lists by 2011-10-24. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
> 
> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
> 
>

---

From: Rui Costa <[email-masked]>
Date: Thu, 6 Oct 2011 04:06:30 +0100

Sometimes when two worlds come together, you don't get common standards right away. For the SONET/SDH example, it has been pointed out that starting from digital voice, we had different regions of the world choosing A-law or mu-law encoding, then 24-channel vs 30-channel PDH hierarchies. SONET and SDH evolved originally as optimized transport for the 24-channel and 30-channel hierarchies, but we were able to push them into common physical layer interfaces for the various bit-rates, and today what we call SDH is really a superset of the two multiplexing hierarchies, so the same box can be sold anywhere in the world and can be configured to support the hierarchy of the local network. When "data friendly" features were added to SONET/SDH (VCAT, GFP, LCAS), these were defined once and not in multiple regional variants. When we finally reached OTN, we were able to agree to develop a single, global standard from the start.	

For MPLS-TP, we have the coming together of the transport world with the Internet world. We have succeeded in driving together many aspects of this technology, but we shouldn't be too surprised that we can't get down to one variant in the very first try at bringing these together.	

Regards,	
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: segunda-feira, 26 de Setembro de 2011 22:58
To: [email-masked]
Subject: [mpls] FW: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

MPLS Working Group,

Thanks,
Adrian

---

From: John E Drake <[email-masked]>
Date: Thu, 6 Oct 2011 04:10:38 -0700

As do I

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Sinicrope
> Sent: Wednesday, October 05, 2011 7:11 PM
> To: David Allan I
> Cc: [email-masked]; [email-masked]
> > I think it is unfortunate that we are in a situation where such a
> document has utility. But ultimately it does.
> >
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Thu, 6 Oct 2011 10:00:56 -0400

Brian,

The second solution already exists, (300,00+ nodes already deployed - see 
other emails on this thread).  We must acknowledge this and find the most 
cost effective way of allowing interconnection.  That is best achieved by 
recognizing the Ethernet tool set based solution and defining 
interconnection such that an interworking function is not required.  This 
has already been proposed and documented in draft revised Recommendation 
G.8110.1 (now in ITU-T last call) and is described in 
draft-tsb-mpls-tp-ach-ptn.

Regards,

Malcolm

Brian E Carpenter <[email-masked]> 
Sent by: [email-masked]
05/10/2011 04:16 PM

To
[email-masked]
cc
"[email-masked]" <[email-masked]>, D'Alessandro Alessandro Gerardo 
<[email-masked]>, "[email-masked]" 
<[email-masked]>, [email-masked], [email-masked], 
"[email-masked]" <[email-masked]>
Subject
Re: 答复: [mpls] 回复：  R: FW: 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 Jian,

    Brian

---

From: [email-masked]
Date: Thu, 6 Oct 2011 10:03:38 -0400

Rui,

Excellent point, I fully agree, we need to focus on the 99% that is 
identical and not cause the 1% that is different (for good reasons) to 
cause a rift that will drive further divergence.

Regards,

Malcolm

Rui Costa <[email-masked]> 
Sent by: [email-masked]
05/10/2011 11:06 PM

To
"[email-masked]" <[email-masked]>
cc

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

Sometimes when two worlds come together, you don't get common standards 
right away. For the SONET/SDH example, it has been pointed out that 
starting from digital voice, we had different regions of the world 
choosing A-law or mu-law encoding, then 24-channel vs 30-channel PDH 
hierarchies. SONET and SDH evolved originally as optimized transport for 
the 24-channel and 30-channel hierarchies, but we were able to push them 
into common physical layer interfaces for the various bit-rates, and today 
what we call SDH is really a superset of the two multiplexing hierarchies, 
so the same box can be sold anywhere in the world and can be configured to 
support the hierarchy of the local network. When "data friendly" features 
were added to SONET/SDH (VCAT, GFP, LCAS), these were defined once and not 
in multiple regional variants. When we finally reached OTN, we were able 
to agree to develop a single, global standard from the start. 

For MPLS-TP, we have the coming together of the transport world with the 
Internet world. We have succeeded in driving together many aspects of this 
technology, but we shouldn't be too surprised that we can't get down to 
one variant in the very first try at bringing these together. 

Regards, 
Rui

-----Original Message-----
Adrian Farrel
Subject: [mpls] FW: Last Call: 

MPLS Working Group,

Please be aware of the IETF last call as shown below. The document was 
presented
for publication as an individual RFC with IETF consensus and AD 
sponsorship.

This draft is clearly close and relevant to the work you do, but after
discussing with the chairs I came to the conclusion that it does not 
comment on
the technical or process decisions of the MPLS working groups, and it does 
not
attempt to make any technical evaluations or definitions within the scope 
of the
MPLS working group. It is more of a philosophical analysis of the way the 
IETF
approaches the "two solutions" problem with special reference to MPLS-TP 
OAM.

Thus, I am accepting the document as AD Sponsored rather than running it 
through
the MPLS working group. My reasoning is that the working group has got 
plenty to
do working on technical issues without being diverted into wider IETF
philosophy.

As an AD Sponsored I-D it is subject to a four week IETF last call. That 
is
plenty of opportunity for everyone to comment and express their views. 
Please
send your comments to the IETF mailing list as described below, or (in
exceptional circumstances) direct to the IESG.

Thanks,
Adrian

> Subject: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> 
(The
> [email-masked] mailing lists by 2011-10-24. Exceptionally, comments may 
be

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Oct 2011 23:59:15 +0900

the ietf, and i hope all sdos, are supposed to provide users with
interoperable multi-vendor choice, not non-interoperable multi-standard
incompatibility.

from a sic year old broadside <https://archive.psg.com/051000.ccr-ivtf.pdf>

    The IETF’s vendor/market approach has engendered a ‘let the market
    decide’ culture.  Instead of hard- thought, rigorous, and simple
    designs, every possible feature gets added and many competing
    proposals are approved.  This last is like throwing spaghetti at the
    wall to see what sticks, an amusing tactic to everyone but the wall.

    The operators are the wall.  And they pay capital cost and
    operational expense to deploy complex features which vendors market
    as needs to the users. And then everyone wonders why the margins
    went down and the prices stayed up.

randy

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 5 Oct 2011 15:20:58 -0500

Jian,

See in-line.

> Sent: Wednesday, October 05, 2011 10:54 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls] 答复: 回复： R: FW: Last Call: <draft-sprecher-mpls-tp-
> oam-considerations-01.txt> (The Reasons for Selecting a Single Solution
> for MPLS-TP OAM) to Informational RFC
> 
> Dear All,
> 
> I do not support either.
> 
> In section 3.5:
Repeating more times does not make the argument becoming correct. 
It wasted a lot of people a lot of time.

> No need to select A and B at one network at the same time.

Don't think anyone said they intended to keep each of their networks/islands stay forever isolated.
Two solutions bring in additional inter-op complications is a fact.

> Respect their own selection and listen to their requirements, please.

Fully respect individual provider's choice of technology, that is a separate matter from standards.
We are talking about IETF requirements here. Which requirement stated in the RFCs are not satisfied by the singe OAM solution defined in IETF?

> Jian
Thanks,
Luyuan
 
>              hoo.com.cn>
> 收件人
> ZTE Information Security Notice: The information contained in this mail
> is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated to
> maintain secrecy and are not permitted to disclose the contents of this
> communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the originator of the message. Any views expressed in this message are
> those of the individual sender.

---

From: David Allan I <[email-masked]>
Date: Wed, 5 Oct 2011 19:05:19 -0400

D

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 5 Oct 2011 19:14:23 -0400

Yes/support

Regards,
Jeff

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 6 Oct 2011 10:23:40 -0500

Same here. 
I support publication of the draft.
Luyuan

> John E Drake
> Sent: Thursday, October 06, 2011 7:11 AM
> To: David Sinicrope; David Allan I
> Subject: Re: [mpls] R: FW: LastCall: <draft-sprecher-mpls-tp-oam-
> considerations-01.txt> (TheReasons for Selecting a Single Solution for
> MPLS-TP OAM) toInformational RFC
> 
> As do I
> 
document
> > was
> > >> presented for publication as an individual RFC with IETF
consensus
> > and
> > >> definitions within the scope of the MPLS working group. It is
more
> > of

---

From: Dan Frost <[email-masked]>
Date: Thu, 6 Oct 2011 17:32:16 +0100

This document provides a factual and concise summary of work, events,
and points of view that have developed since the JWT, a summary that's
timely and sorely needed as few in the industry outside the project (or
even inside the project) can make sense of it.

It also provides a thorough and accessible analysis of the costs to
service providers, vendors, the market, and the end user that divergent
MPLS OAM solutions will create.

As such, I think the IETF has a duty to move forward with its
publication; the considerations it raises are of significant importance
to the Internet community.

It's also noteworthy that the proponents of a non-IETF MPLS OAM
technology have been unwilling thus far to document the supposed
technical problems with standard MPLS/MPLS-TP OAM in an Internet draft.
If one didn't know better, one might be tempted to suppose their
concerns were more political than technical.

Following are LC comments/suggestions on the draft, all minor and
editorial.

---
Suggest adding a reference to RFC 5921 in first paragraphs of
abstract/introduction.

---
The terms "inter-working" and "interworking" both appear repeatedly
throughout; it would be good to pick one.

---
Section 1.1, 4th paragraph:
s/which are applicable/that are applicable/

---
Section 1.1, last sentence:
s/development and deployment making/development and deployment, making/

---
Section 1.2, 2nd paragraph:
s/it was considered/it was judged/

---
Section 1.2, 3rd paragraph:
OLD
   Indeed, one of the key differences between the two environments is
   the choice of MPLS-TP OAM solution which makes a circular argument.
NEW
   Indeed, one of the key differences cited between the two allegedly
   distinct environments is the choice of MPLS-TP OAM solution, which
   makes a circular argument.
END

---
Section 1.2, next-to-last paragraph:
s/normal IETF, consensus-driven/normal consensus-driven IETF/

---
Section 3.1, first paragraph:
OLD
   In MPLS-TP, MPLS was extended to satisfy the transport network
   requirements in a way that was both compatible with MPLS as has
   already been deployed, and MPLS and with the IETF envisioned it would
   develop in the future.
NEW
   In MPLS-TP, MPLS was extended to satisfy the transport network
   requirements in a way that was compatible both with MPLS as has
   already been deployed, and with MPLS as the IETF envisioned it would
   develop in the future.
END

---
Section 3.1, 2nd paragraph:
s/philosophies that have lead/philosophies that have led/

---
Section 3.2, 2nd paragraph:

OLD
   MPLS has been deployed in operational networks for approximately a
   decade, with the existing MPLS OAM techniques widely deployed in
   operational networks.
NEW
   MPLS has been deployed in operational networks for approximately a
   decade, and the existing MPLS OAM techniques have seen wide
   deployment.
END

s/MPLS based/MPLS-based/

---
Section 3.3, first paragraph:
s/can transition/can cross/

---
Section 3.3, 2nd paragraph:
s/exiting network layer/existing network layer/
s/fast connectivity protocol/fast connectivity verification protocol/

---
Section 3.4, first paragraph:
Second sentence needs rephrasing; maybe:

OLD
   In an isolated system this may be the case, however when, as is
   usually case with communications technologies, simplification in one
   element of the system introduces a (possibly non-linear) increase in
   complexity elsewhere.
NEW
   In an isolated system this may be the case.  In an interconnected
   system such as a communications network, however, simplification in
   one element of the system may increase complexity elsewhere, and this
   increase may be non-linear.
END

---
Section 3.4, 2nd paragraph:

OLD
   However, when we drive OAM complexity out of one network element at
   the cost of increased complexity at a peer network element we loose
   out economically and, more importantly, we loose out in terms of the
   reliability of this important network functionality.
NEW
   However, when we drive OAM complexity out of one network element at
   the cost of increased complexity at a peer network element, there is
   no economic benefit and, more importantly, the reliability of the
   network is compromised.
END

---
Sections 4.1-5.3:
Suggest expanding acronyms and adding references.

---
Section 4.3, first paragraph:

OLD
   Every time a new codec is deployed, translation between it and all
   other deployed codecs must be performed available within the network,
   each participating node must be able to handle the new codec.
   Translation between codec is expensive and can lead to reduced
   quality.
NEW
   Every time a new codec is deployed, translation between it and all
   other deployed codecs must be performed within the network; codec
   translation is expensive and can lead to reduced quality.  In
   addition, each participating node must be able to handle the new
   codec.
END

---
Section 4.3, 3rd paragraph:

OLD
   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.  This, together with the specific
   characteristics of transmission over lossy packet networks comprised
   requirements equivalent to a major difference in functionality, and
   led to work in the IETF to specify a new codec.
NEW
   The application layer of the Internet is, however, predicated on a
   business model that allows for the use of shared, free, and
   open-source software; this model requires the existence of a
   royalty-free codec.  This, together with the specific characteristics
   of transmission over lossy packet networks, comprised requirements
   equivalent to a major difference in functionality, and led to work in
   the IETF to specify a new codec.
END

---
Section 5.2:
This paragraph talks about 802.16 d/e and then mentions 802.16a; is this
intentional?

---
Section 6.1, 2nd paragraph:
s/the protocols rules/the rules/

---
Section 6.1, 3rd paragraph:
s/the protocols rules/the rules/

---
Section 6.1, 4th paragraph:
s/These are obvious issues/There are obvious issues/

---
Section 6.3.1.1, last paragraph:
s/route trace function/route trace functions/

---
Section 6.3.2:
s/Sections/sections/

---
Section 6.3.2.1, 4th paragraph:
s/in is necessary/it is necessary/

---
Section 6.3.2.1, last paragraph:
s/working and is protection/working and protection/

---
Section 7.1, 2nd paragraph:
s/will not will/will/

---
Section 7.1, last paragraph:
This paragraph is a bit vague.  It should probably be recast to be
specific about the phase of work that's nearing completion and how this
phase relates to the overall requirements and joint work plan.

---
Section 7.3, 2nd paragraph:
s/One of stated/One of the stated/

---
Section 7.4, last paragraph:
s/family, makes/family makes/

---
Section 7.5, first paragraph:
s/as in the in the/as in the/

---

Cheers,
-d

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Oct 2011 08:47:48 +1300

Malcolm,

I'm technically incompetent to comment on draft-tsb-mpls-tp-ach-ptn.
However, if we reframe the debate as "how to reconcile OaM for
Ethernet-based PTN with OaM for MPLS-TP-based PTN", we might have
a more productive discussion.

Regards
   Brian Carpenter

---

From: [email-masked]
Date: Thu, 6 Oct 2011 17:57:09 -0400

Brian,

Thank you for your constructive suggestion.

I will attempt to start a discussion on a new thread in a few days - I am 
currently travelling with very limited time windows when I can access the 
Internet.

Regards,

Malcolm

06/10/2011 03:47 PM

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

Malcolm,

Regards
   Brian Carpenter

---

From: "GT RAMIREZ, Medel G." <[email-masked]>
Date: Fri, 7 Oct 2011 09:59:51 +0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David Allan I
Sent: Thursday, October 06, 2011 7:05 AM
To: [email-masked]; [email-masked]
Cc: Adrian Farrel
Subject: R: FW: Last
Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons
forSelecting a Single Solution for MPLS-TP OAM) to Informational RFC

D

This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately.

---

From: Rolf Winter <[email-masked]>
Date: Fri, 7 Oct 2011 13:38:41 +0000

Dave,

could you be more precise about what you think the utility of this document is in this particular situation. I mean, what will its effect be in the current situation. What will change after this document has been published. It seems everybody believes the "situation" will be resolved once this document receives its RFC number. I cannot see that. Could you give me more detail?

Best, 

Rolf

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

> Sent: Donnerstag, 6. Oktober 2011 01:05
> Subject: [mpls] R: FW: Last Call: <draft-sprecher-mpls-tp-oam-

---

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Oct 2011 12:35:05 -0400

While it is not perfect, I too support publication...

W

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 6 Oct 2011 20:53:48 +0200

Hi all,
I concur with both parts of Dave's message :-( and support publication of the draft.

I have an editorial/factual comment regarding Section 4.2 of the draft.

Let's begin with the fact that SAToP (i.e. RFC 4553) is not a Draft Standard, it is a Proposed Standard RFC.

Further, I am not sure that the relationship between SAToP and other TDM PW modes - CESoPSN (RFC 5086) and TDMoIP (RFC 5087) - is correctly described in Section 4.2 of the draft. At least neither RFC 5086 not RFC 5087 contain any explicit statements about SAToP as the "MUST to implement" protocol.  

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of David Allan I [[email-masked]]
Sent: Thursday, October 06, 2011 1:05 AM
To: [email-masked]; [email-masked]
Subject: [mpls] R: FW: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

D

---

From: David Allan I <[email-masked]>
Date: Fri, 7 Oct 2011 11:21:23 -0400

IMO it is a statement of principle going forward. As such it does not "fix" or "make go away" the current situation, but it would be an IETF consensus position on a way forward. And I agree with that position.

Lots of folks do proprietary deployments, squat on code points etc. That cannot be "fixed" either, but I do not believe in rewarding it.

Dave 

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: Friday, October 07, 2011 6:39 AM
To: David Allan I; [email-masked]; [email-masked]
Subject: RE: [mpls] R: FW: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

Dave,

Best, 

Rolf

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of David Allan I
> considerations-01.txt> (The Reasons for Selecting a Single Solution 
> > definitions within the scope of the MPLS working group. It is more 
> > of a philosophical analysis of the way the IETF approaches the "two 
> > Thus, I am accepting the document as AD Sponsored rather than 
> > running it through the MPLS working group. My reasoning is that the 
> > working group has got plenty to do working on technical issues 
> > without being diverted into wider IETF philosophy.
> >

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Oct 2011 05:51:20 +0900

> IMO it is a statement of principle going forward. As such it does not
> "fix" or "make go away" the current situation, but it would be an IETF
> consensus position on a way forward. And I agree with that position.
> 
> Lots of folks do proprietary deployments, squat on code points
> etc. That cannot be "fixed" either, but I do not believe in rewarding
> it.

or aiding or abetting it.

+1

randy

---

From: Russ Housley <[email-masked]>
Date: Sat, 8 Oct 2011 11:02:56 -0400

I support publication of this draft, although the SONET discussion could be discarded.  Also, I would like to see a reference to RFC 5921 in the introduction.

RFC 5317 calls for one, and only one, protocol solution.  At least that is how I read JWT Agreement.  The most relevant text seems to be in Section 9:

  They stated that in their view, 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.

Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard.

Russ

---

From: HUANG Feng F <[email-masked]>
Date: Sun, 9 Oct 2011 10:07:53 +0800

Dear Russ Housley,
    RFC5317 said:" a single OAM technology for LSPs, PWs, and a deeply nested network". it means LSA OAM and PW OAM should be same, it means the OAM solution should be apply on both LSP and PW layer. From RFC5317 will not educe to one solution standard for mpls-tp oam conclusion.
B.R.
Feng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: 2011年10月8日 23:03
To: IETF
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

Russ

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 09 Oct 2011 12:58:23 +0200

Hello Russ,

You write:

> RFC 5317 calls for one, and only one, protocol solution.
 > At least that is how I read JWT Agreement.

How the JWT report should be read is written on slide 9 in the PDF:

"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"

> The most relevant text seems to be in Section 9:

This text is one of the assumptions, that is why we wrote:
"*They stated that in their view*":

>    it is technically feasible that the

The "OAM technology" in this text refers to to way the OAM frames can be
detected in a data-stream.

The text you quote is from the summary section, it summarizes the
slides 19 - 22: "*MPLS-TP Major Solution Constructs*" which address
the GAL-GAch solution.

We now have the GAL-GAch technology (RFC5586) to detect OAM frames
and this technology will be used in PW and LSP, and enables the use
of OAM in deeply nested networks.

> Since the publication of RFC 5317, the MPLS WG consensus continues
 > to be that only one OAM solution should become a standard.

All MPLS-TP OAM tools should comply with RFC5586.

A service provider can now pick any set or sub-set of the available
OAM tools and use them without fear to disrupt the internet.

Looking at the current discussions, there is no consensus (yet)
on whether we need a comprehensive set of OAM tools, or a very
limited set of OAM tools.

Best regards, Huub (JWT, Ad-Hoc, MEAD member).

---

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

Hello Russ,

You wrote:

> although the SONET discussion could be discarded.

It is not only the SDH/SONET discussion that should be removed.

I have very strong doubts about all the issues mentioned in
sections 4 and 5, none of them are factual.

Regards, Huub.

---

From: [email-masked]
Date: Sun, 9 Oct 2011 09:36:30 -0400

Russ,

You may not be fully aware of the context of the statement in RFC 5317:

As the co-chair of the JTW and co-editor of the JWT report I must point 
out the context of the text that you have quoted:

First, the text is on slide 113, slide 12 states:
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

Second:  The discussion point that drove the text on slide 113 was the 
consideration that PWs and LSPs may have different OAM.  The reality is 
that the solution standardized uses different encapsulations for the PW 
(no GAL) and LSP (uses the GAL).

Regards,

Malcolm

Russ Housley <[email-masked]> 
Sent by: [email-masked]
08/10/2011 11:02 AM

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

I support publication of this draft, although the SONET discussion could 
be discarded.  Also, I would like to see a reference to RFC 5921 in the 
introduction.

RFC 5317 calls for one, and only one, protocol solution.  At least that is 
how I read JWT Agreement.  The most relevant text seems to be in Section 
9:

Since the publication of RFC 5317, the MPLS WG consensus continues to be 
that only one OAM solution should become a standard.

Russ

On Oct 5, 2011, at 11:02 PM, Rui Costa wrote:

> c) To the question "which requirement stated in the RFCs are not

---

From: HUANG Feng F <[email-masked]>
Date: Mon, 10 Oct 2011 10:36:47 +0800

Hi, 

>      Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard.
 
As I said in my previous email, it means use same architecture (GACH) for LSP and PW OAM not deduce only one OAM solution should become a standard, and this is no consensus in mpls group. for OAM analysis, which is captured in draft-ietf-mpls-tp-oam-analysis, it is still a draft.

and in section 2 of RFC 5860 (Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks):

>The way in which those protocols are operated and the way
>in which a network operator can control and use the MPLS-TP OAM
>functions SHOULD be as similar as possible to the mechanisms and
>techniques used to operate OAM in other transport technologies.

this requirement is not satisfied by RFCs published.

I fully agree  "All MPLS-TP OAM tools should comply with RFC5586" and should satisfy with RFC5860, and provider can pick up subset of them.

finally, I still don't support publish draft-sprecher-mpls-tp-oam-considerations-01.txt as RFC.

B.R.
Feng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: 2011年10月9日 18:58
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

Hello Russ,

>    OAM technology for LSPs, PWs, and a deeply nested network.

The "OAM technology" in this text refers to to way the OAM frames can be detected in a data-stream.

The text you quote is from the summary section, it summarizes the slides 19 - 22: "*MPLS-TP Major Solution Constructs*" which address the GAL-GAch solution.

We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks.

A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet.

Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools.

---

From: Ross Callon <[email-masked]>
Date: Mon, 10 Oct 2011 00:09:42 -0400

Speaking only as an individual, I also support publication of this document as an informational RFC.

I agree with many comments that the SONET discussion in section 5.1 should be deleted, and I would suggest that all of sections 4 and 5 be deleted. 

I was involved in the controversy that created both IS-IS and OSPF (as well as in the significant cooperation on protocol details that was going on in the background at the same time) and I think that the section on IS-IS and OSPF is mostly correct (even if I would have worded some of it a bit differently). One change I would make to this section is changing "more than doubles the cost of link state IGP maintenance and deployment" to be "doubles the cost of link state IGP maintenance". Also "derive from the same root document" should be "derive from the same root technology". Of course if sections 4 and 5 are deleted then there is no need to make these minor corrections to section 4.1.  

Regarding Russ's comment "...only one OAM solution should become a standard". I might note that there is considerable precedent in the IETF for publishing one standard, but also publishing informational RFCs that document other solutions that were considered in the IETF effort and that have been deployed. There certainly are many cases of pre-standard or non-standard solutions being deployed (often before IETF standards were finished) and in these cases I have long felt that it is desirable to document what has been deployed. 

Ross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, October 08, 2011 11:03 AM
To: IETF
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

Russ

---

From: Ross Callon <[email-masked]>
Date: Mon, 10 Oct 2011 00:39:43 -0400

> detected in a data-stream.

During the JWT effort, I did not interpret the term "OAM technology" to be strictly limited to just the manner in which OAM frames are detected in the data-stream. I interpreted this in a broader sense. 

> limited set of OAM tools. 

I don't understand this comment. We have requirements documents that have been agreed and published, and that carefully lay out a list of capabilities that need to be available. We need tools that fulfill these requirements. Perhaps I am not sure what distinction you make between "comprehensive set of OAM tools" versus "limited set of OAM tools".

Ross

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Oct 2011 11:54:51 +0200

Hi, 

Same here: Yes/Support.

Cyril

> ext John E Drake
> Sent: Thursday, October 06, 2011 1:11 PM
> Subject: RE: [mpls] R: FW: Last Call:<draft-sprecher-mpls-tp-oam-
> considerations-01.txt> (The Reasons forSelecting a Single Solution for
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of David Sinicrope
document
consensus
> > >> discussing with the chairs I came to the conclusion that it does
> > >> not comment on the technical or process decisions of the MPLS
> > >> working groups, and it does not attempt to make any technical
> > >> evaluations or definitions within the scope of the MPLS working
> > >> group. It is more
> > of
> > running
> > >> group has got plenty to do working on technical issues without
> > >> being diverted into wider IETF philosophy.
> > >>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 11 Oct 2011 12:28:11 +0200

Huub,

you are partly right - slide 9 says that there are open issues.

But at the last meeting with the JWT consensus on the *summary*
was the issue. The questions was put explicitly. At that time no one
voiced another opinion!

/Loa

-- 

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: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 11 Oct 2011 16:05:01 +0200

Hi,

I support publication of this document, 
although I do have some comments on the composition of sections 4 & 5
that I will privately provide the editors.

Yaacov Weingarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Luyuan Fang (lufang)
Sent: Thursday, October 06, 2011 5:24 PM
To: John E Drake; David Sinicrope; David Allan I
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls] R: FW:LastCall:
<draft-sprecher-mpls-tp-oam-considerations-01.txt>(TheReasons for
Selecting a Single Solution for MPLS-TP OAM)toInformational RFC

Same here. 

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Of
document
consensus
more

---

From: [email-masked]
Date: Thu, 13 Oct 2011 22:31:37 -0400

Below are my comments on this draft, these are in addition to the comments 
that I have provided previously.  I also support the comments that propose 
the deletion of sections 4, 5 and 6.

I have numbered my comments (1-12) to simplify identification for those 
who wish to respond.

I do not support approval of this draft in its current form.

Regards,

Malcolm

1) Two encapsulations for PW OAM

The draft provides the Reasons for Selecting a Single Solution for MPLS-TP 
OAM.  However, two different encapsulations have been defined for OAM 
messages in the MPLS-TP PW.  One uses just the ACh the other uses both the 
GAL and ACh.  These two encapsulations must be identified and rationalized 
in the context of selecting a single solution.  Particular attention 
should be paid to the text from RFC5317 quoted in section 1.1 “…the 
architecture allows for a single OAM technology for LSPs, PWs…”

2) Quote from RFC5317

Section 1.1 includes the following:
   [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."

The context of this quote from slide 113 should be clarified; slide 12 
states of RFC 5317 states:

Proposal: Insert the following text before the quoted text:

[RFC 5317] provides a collection of assumptions, discussion points and 
decisions that the JWT 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.  Included in this analysis is the statement 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."

3) Section 1.2 The Development of a Parallel MPLS-TP OAM Solution

The section should be deleted or rewritten since it includes a number of 
assertions that have not been substantiated and are not supported by a 
significant number of participants.

4) Consistent with existing MPLS OAM

Section 3.3 states:
   Given this intention for compatibility, it follows that the MPLS-TP
   OAM protocols should be consistent with the existing, deployed MPLS
   OAM

This statement requires further clarification and justification since:
a) The existing MPLS OAM tools use an IP encapsulation, the MPLS-TP OAM 
tools use a GAL/ACh encapsulation; and:
b) The only existing deployed OAM tools were BFD and LSP Ping, all the 
other OAM tools are new so it is difficult to understand the concept of 
compatible.

5) MPLS as a Convergence Technology

Section 3.2 includes the statement:

“When we arrive at our destination of TCP/IP/MPLS running directly over 
fiber, the operators will use MPLS OAM tools to make this work.”

This statement is technically incorrect; MPLS must be encapsulated in a L2 
and L1 protocol before it can be transmitted over a physical media. 
Further I have seen no evidence that network operator will use MPLS to 
maintain the optical network infrastructure e.g. amplifiers, WDM couplers 
etc.

The section is based on the assumption that the network will rapidly 
converge to being just IP/MPLS.  This is not a universally accepted view. 
Section 3.2 should be deleted.

6) Section 3.3 End to end OAM

I agree that end to end OAM is important for maintaining a service. 
However, we also need OAM to maintain the transport infrastructure that is 
independent of the services (or even the presence of a service).

Section 3.3 also states:
   This is a design paradigm that has guided the IETF in the development
   of its exiting network layer connectivity OAM protocols.  For each
   network layer protocol there is only one ping, trace route, or fast
   connectivity protocol, and amongst these there is a common design
   approach.
 
This is not correct the IETF have defined multiple protocols for PWs.

Section 3.3 should be deleted or rewritten

7) Section 3.5 Interworking

I agree that interworking adds complexity and should be avoided.  However 
this section includes a large amount of general considerations that are 
not relevant to MPLS-TP OAM for example:
   Universal deployment of both OAM protocols … introduces additional 
testing
   requirements to ensure there are no conflicts when both protocols are
   run on a common platform.

The use of the ACh to distinguish between protocols avoids the possibility 
of conflicts.

Section 3.5 should be deleted or rewritten

8) Section 3.6.  Selection of a Single OAM Solution When There is a 
Choice.

This section includes only general considerations; it does not reflect the 
reality of the current situation where we already have extensive (300,000+ 
nodes) and growing deployment of an Ethernet based OAM tool set.  The 
section should be rewritten to provide guidance given the current 
situation.

9) Section 3.7.  Migration Issues

This section includes a large number of unjustified assumptions about 
implementations (e.g. hardware vs. software).  The use of field 
programmable hardware is also an “implementer’s choice”.  A standard 
should not dictate or make assumptions about implementations.  Also 
network migration is normally considered to be a business decision for a 
network operator and not the subject of debate in standards.

Section 3.7 should be deleted.

10) Section 6.  Potential Models For Coexistence

This section provides only generalized statement, many of which are not 
relevant to the case of MPLS-TP OAM that uses a GAL/ACh encapsulation.

As proposed on email this section should be deleted.  Or it should be 
rewritten to address the case of MPLS-TP OAM using the GAL/ACh 
encapsulation and the analyse the impact of the widespread deployment of 
Ethernet based OAM and propose strategies to mitigate any adverse 
interactions. 

Proposal Delete all text except section 6.3.1 (note 6.3.1.1 and 6.3.1.2 
should be deleted).

Also text to describe the rules for the interconnection of domains that 
use the MPLS OAM tools and domains that use the Ethernet based OAM tools 
should be added e.g.:

“Any LSP or PW that interconnects between a domain that uses the MPLS tool 
set defined in [I-D.ietf-mpls-tp-oam-analysis] and a domain that normally 
uses the Ethernet tools must use the MPLS tool set.”

11) Section 7.  The Argument For Two Solutions

This section should be deleted, or those who are proposing the second 
solution should be invited to provide text.  See the detailed comments 
11a) – 11e)

11a) - The IETF solution is taking too long to standardize

This statement and section 7.1 should be deleted. Or Section 7.1 should be 
updated to include the actual time line:
January 2008 the ITU had an OAM solution that was based on Ethernet OAM. 
However the IETF stated that the encapsulation used violated the MPLS 
architecture.  On this basis the ITU decided not to approve the 
Recommendation.
In March and April the JWT evaluated the possible solutions and set the 
expectation that a solution would be standardized in 2009.
In March 2009 the first version of draft-bhh-mpls-tp-oam-y1731 “MPLS-TP 
OAM based on Y.1731” was posted.
In February 2011 the approval process on draft new Recommendation G.8013 
“Operations, Administration and Maintenance mechanisms for MPLS-TP 
networks using the tools defined in G.8013/Y.1731” (as updated at the 
Beijing experts meeting) was initiated.

11b)  - Commonality with Ethernet solutions is beneficial.

7.2.  Commonality with Ethernet OAM misses the point that commonality is 
desirable not for peer interworking but to simplify translation of defects 
in a server to a client.

Section 7.2 also states:
   While this might be a valid discussion point when selecting the
   single OAM solution for MPLS-TP, it is countered by the need to
   achieve OAM consistency between MPLS and MPLS-TP networks.  One might
   make the counter argument that if there is a strong need to make
   MPLS-TP as similar as possible to Ethernet, it would be better to go
   the full distance and simply deploy Ethernet.

Two points must be noted:
a) The IETF should be encouraging the widespread deployment of MPLS not 
encouraging the deployment of another technology.
b) As identified in the comments on section 3.3 the only existing MPLS 
tools are BFD and LSP ping, so compatibility for new functions such as 
loss or delay is not a valid consideration. 
Further, at a higher level most networks include both MPLS and Ethernet 
and having consistent behaviour will simplify network operations.

11c)   - There are two different application scenarios

I do not agree with the assertions made in section 7.3.

11d)   - There is no risk of interaction between the solutions

The text in 7.4 does not make it clear how “interaction” will occur given 
the use of the ACh to distinguish between protocols.  Further current 
Transport OSS configure OAM when a connection is established, work is 
underway in ccamp to provide signaling extensions to also configure OAM 
when a connection is established.

11e)   - The market should be allowed to decide between competing 
solutions.

It must be noted that 300,000+ nodes using an Ethernet based OAM solution 
have already been deployed.  These deployments will continue to exist and 
grow, this reality should be acknowledged.

12) Section 8.  Security Considerations

All text except the first line should be deleted since it contains general 
information that is not relevant to the use of a second solution for 
MPLS-TP OAM.  For example the text:
   - One OAM protocol may be used as a vector to attack the other.
     Inserting an OAM message of the other OAM protocol onto a link may
     cause the service to be disrupted and, because some nodes may
     support both OAM protocols, it may be possible to cause the
     disruption at a remote point in the network.
 How is this possible when the use of the ACh to distinguish between 
protocols allows the “other” protocol to be silently discarded.

---

From: Loa Andersson <[email-masked]>
Date: Fri, 14 Oct 2011 08:15:59 +0200

All,

juat one small comment on how "slide 12" of the JWT report is (mis)used
in this debate.

The text says:

" 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."

The paragraph is correct and it says that the presentation includes
- assumptions
- discussion points
- decisions

The statement on "one OAM solution" from section 1.1 of RFC5317 clearly
falls into the *decision* category. As such it rather support
publishing the draft rather than indicating that we shouldn't.

/Loa

On 2011-10-14 04:31, [email-masked] wrote:
> Below are my comments on this draft, these are in addition to the
> comments that I have provided previously. I also support the comments
> that propose the deletion of sections 4, 5 and 6.
>
> The draft provides the Reasons for Selecting a Single Solution for
> MPLS-TP OAM. However, two different encapsulations have been defined for
> OAM messages in the MPLS-TP PW. One uses just the ACh the other uses
> both the GAL and ACh. These two encapsulations must be identified and
> rationalized in the context of selecting a single solution. Particular
> attention should be paid to the text from RFC5317 quoted in section 1.1
> “…the architecture allows for a single OAM technology for LSPs, PWs…”
>
> 2) Quote from RFC5317
>
> architecture to meet those requirements
>
> decisions that the JWT has had during the months of March and April,
> 2008. This represents the agreed upon starting point for the technical
> architecture to meet those requirements. Included in this analysis is
> the statement 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 statement is technically incorrect; MPLS must be encapsulated in a
> L2 and L1 protocol before it can be transmitted over a physical media.
> maintain the optical network infrastructure e.g. amplifiers, WDM
> couplers etc.
>
> However, we also need OAM to maintain the transport infrastructure that
> is independent of the services (or even the presence of a service).
>
> Section 3.3 also states:
> Universal deployment of both OAM protocols … introduces additional testing
> The use of the ACh to distinguish between protocols avoids the
> possibility of conflicts.
>
> 8) Section 3.6. Selection of a Single OAM Solution When There is a Choice.
>
> This section includes only general considerations; it does not reflect
> the reality of the current situation where we already have extensive
> (300,000+ nodes) and growing deployment of an Ethernet based OAM tool
> set. The section should be rewritten to provide guidance given the
> current situation.
>
> “Any LSP or PW that interconnects between a domain that uses the MPLS
> tool set defined in [I-D.ietf-mpls-tp-oam-analysis] and a domain that
> normally uses the Ethernet tools must use the MPLS tool set.”
>
>
> This statement and section 7.1 should be deleted. Or Section 7.1 should
> be updated to include the actual time line:
> desirable not for peer interworking but to simplify translation of
> defects in a server to a client.
>
> Section 7.2 also states:
> The text in 7.4 does not make it clear how “interaction” will occur
> given the use of the ACh to distinguish between protocols. Further
> current Transport OSS configure OAM when a connection is established,
> work is underway in ccamp to provide signaling extensions to also
> configure OAM when a connection is established.
>
> 11e) - The market should be allowed to decide between competing solutions.
>
> It must be noted that 300,000+ nodes using an Ethernet based OAM
> solution have already been deployed. These deployments will continue to
> exist and grow, this reality should be acknowledged.
>
> All text except the first line should be deleted since it contains
> general information that is not relevant to the use of a second solution
> for MPLS-TP OAM. For example the text:

--

---

From: [email-masked]
Date: Fri, 14 Oct 2011 09:59:01 -0400

Loa,

I have added - comment 2 to the subject line and deleted all the other 
comments.

I cannot find section 1.1 or the text "one OAM solution" in the PDF 
version of RFC 5317.

The last paragraph of section 1 states:

In the case of a conflict between the summary and the
slides, the slides take precedence. Since those slides were the
basis of an important agreement between the IETF and the ITU-T, it
should further be noted that in the event that the PDF version of the
slides differs from those emailed to ITU-T and IETF management on 18
April 2008 by the co-chairs of the JWT, the emailed slides take
precedence.

> architecture to meet those requirements

I must also remind you that the JWT did not have the power to make 
decision for the ITU or IETF as stated in TD515/PLEN that established the 
ad group on MPLS-TP and the JWT:
"The Joint Working Team is the union of the ad hoc and design teams.  It 
has no official affiliation or status with either the ITU-T or the IETF 
but will provide a forum for open communication and cooperative work"

This is aligned with normal process in the IETF where a design team cannot 
make decisions for a Working Group.

Therefore, my proposed clarification of the context of the "one solution" 
statement should be included in draft-sprecher-mpls-tp-oam-considerations.

Regards,

Malcolm

Loa Andersson <[email-masked]> 
14/10/2011 02:15 AM

To
[email-masked]
cc
[email-masked]
Subject

All,

The text says:

/Loa

--

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 14 Oct 2011 16:36:53 +0200

All,

I agree with the reply from Malcolm below and support his
suggested text insertion.

And repeat that slide 113 is a *summary*.
The *single* refers to the GAL - G-Ach discussion
with the *solution* on slides 19 and 20
and the observations in slides 21 and 22.

Regards, Huub.

===============

Malcolm replied:

>  > This represents the **agreed upon starting point** for the technical
> decision for the ITU or IETF as stated in TD515/PLEN that established
> the ad group on MPLS-TP and the JWT:
>
> This is aligned with normal process in the IETF where a design team
> cannot make decisions for a Working Group.
>
> Therefore, my proposed clarification of the context of the "one
> solution" statement should be included in
> draft-sprecher-mpls-tp-oam-considerations.
>
>
> Regards,
>
> Malcolm
>
>
>
> *Loa Andersson <[email-masked]>*
>
> 14/10/2011 02:15 AM
>
> 	
> To
> 	[email-masked]
> cc
> 	[email-masked]
> Subject

---

From: Loa Andersson <[email-masked]>
Date: Fri, 14 Oct 2011 16:37:49 +0200

Malocolm,

there is no conflict - the one OAM solution was and is a decision.

/Loa

--

---

From: [email-masked]
Date: Fri, 14 Oct 2011 20:37:33 -0400

Loa,

I still do not understand how you can claim that the words from slide 113 
of RFC 5317 and quoted in section 1.1 of 
draft-sprecher-mpls-tp-oam-considerations-01:

"It is technically feasible that the existing MPLS architecture can be
extended to meet the requirements of a Transport profile
The architecture allows for a single OAM technology for LSPs, PWE
and a deeply nested network"

Represent a decision or even a recommendation.

However, if as you insist it was a "decision" can you explain why the IETF 
chose to ignore this "decision" and initially defined different 
encapsulations for the PW and LSP OAM and subsequently defined a second 
encapsulation for PW OAM.  So that now we have two encapsulations for OAM 
in MPLS-TP PWs.

Regards,

Malcolm

14/10/2011 10:37 AM

To
[email-masked]
cc
[email-masked]
Subject
RFC - comment 2

Malocolm,

/Loa

On 2011-10-14 15:59, [email-masked] wrote:
>                Re: Last Call: 
<draft-sprecher-mpls-tp-oam-considerations-01.txt> (The

--

---

From: Loa Andersson <[email-masked]>
Date: Sat, 15 Oct 2011 12:12:27 +0200

Malcolm,

seems that you have  the problem claiming text refers to "assumptions" 
or "discussion points", especially since the format of the text is
clearly "decision".

/Loa

On 2011-10-15 02:37, [email-masked] wrote:
> Loa,
>
> I still do not understand how you can claim that the words from slide
> 113 of RFC 5317 and quoted in section 1.1 of
> However, if as you insist it was a "decision" can you explain why the
> IETF chose to ignore this "decision" and initially defined different
> Informational RFC - comment 2
>
>
> 	
>
>
>
>
>
> Malocolm,
>

--

---

From: Yaakov Stein <[email-masked]>
Date: Sun, 16 Oct 2011 10:12:53 +0000

> I have very strong doubts about all the issues mentioned in sections 4 and 5

I have comments on 
  4.2 TDM PWs, 
  4.3 Codecs, and 
  4.4 MPLS signaling protocols.

For TDM PWs the IETF followed its tao of requiring one MUST mode (RFC 4553)
and allowing 2 MAY modes (RFCs 5086 and 5087). However, far from being a resounding
triumph, this meant that a method considered inadequate by all who really understood the issues 
was mandated, while too equally adequate alternatives became optional.
So this example actually shows a negative aspect of the procedure.

Regarding the Code issue, multiple proposals were submitted,
and the resolution was to mold two of them into a new combined codec with pieces of each.
So this example is not relevant at all.

Regarding CR-LDP vs. RSVP, once again there were two pre-existing solutions,
and it was decided not to do any new work on one of them.
But this left us with 2 mandatory to implement protocols (LDP and RSVP-TE)
rather than a decision for CR-LDP which would have left a single mandatory protocol.
So this actually a counter-example to the tao of having a single mandatory mode.

Y(J)S