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

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

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

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

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: 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: 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
> MPLS-TP OAM) to Informational RFC
> 

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.
> 
> 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
> 
> Da: [email-masked]
> [mailto:[email-masked]]
> Per conto di Adrian Farrel
> 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.
>

---

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]>
> as an

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

Jian,

See in-line.

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

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

---

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

Yes/support

Regards,
Jeff

---

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,

> 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: "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: 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: [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,

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: "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: "t.petch" <[email-masked]>
Date: Fri, 7 Oct 2011 08:27:59 +0200

----- Original Message -----
From: "Larry" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "D'Alessandro
Alessandro Gerardo" <[email-masked]>
Sent: Wednesday, October 05, 2011 1:51 PM

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

It is an impressive achievement and I would be interested in hearing more.

In particular, what are the manufacturers involved?  As you probably know, the
IETF looks for interoperability between independent implementations as a
condition for standardisation so I would like to know who the manufacturers are,
are the implementations independent, or are they all derived from a single code
source?
And you say 'will be based on G.8113.1' - what actually is the specification of
the existing boxes?  I seem to recall last year you saying that
draft-bhh-MPLS-TP-OAM-Y1731 was the basis with a plan to upgrade to G.8114.

Tom Petch

<cc list trimmed to mpls>

---

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: Thomas Nadeau <[email-masked]>
Date: Fri, 7 Oct 2011 10:40:33 -0400

I wanted to pass on some information regarding a BoF that is planned for Taipei that is relevant to 
participants of this mailing list/WG area.  

	The IAB and IESG met today to discuss BoFs for Taipei and agreed that we will hold a BoF
SDN with a goal of "discussing the technology and identifying work items". The BoF is nominally 
in the Routing Area, but we expect considerable involvement from the OPS Area as well. 

	The following is a link to the drafts and other documentation around the SDN effort
including some presentations, and a link to join the BoF mailing list. 
	
	http://trac.tools.ietf.org/bof/trac/

	We encourage you to join the list, review the materials and participate on the mailing
list as well as come to the BoF if you have an interest in this work.

	--Tom

---

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

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

W

---

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

Hi Jian,

    Brian

---

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

Malcolm,

Regards
   Brian Carpenter

---

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: Thomas Nadeau <[email-masked]>
Date: Thu, 13 Oct 2011 17:34:08 -0400

As an FYI, the initial schedule is out.  The SDN BoF is planned for Thursday afternoon from 1520-1720 in room 201 DEF.

http://tools.ietf.org/agenda/82/

	As usual, caveat emptor in that this is the initial schedule which often changes.  Please plan on being there M-F in case the schedule changes.

	--Tom