Subject: [mpls] draft-tsb-mpls-tp-ach-ptn

From: Rui Costa <[email-masked]>
Date: Fri, 11 Mar 2011 03:32:10 +0000

Hello,	

The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the allocation of an Associated Channel Type value that will allow ITU-T to develop OAM tools required to address the needs identified by some ITU-T members. Allocation of this value will make more efficient use of resources of both IETF and ITU-T. The use of this associated channel type fully complies with the framework and architecture for MPLS-TP.	

The draft also describes the cases where networks that run the ITU defined OAM tools are interconnected to networks that run the IETF defined OAM tools. In most cases it is a client/server relationship and no interworking is required. If a LSP or PW originates in one domain and terminates in the other domain then the IETF OAM tools must be used.	

This draft should be discussed in Prague.	

Best Regards,	
Rui

---

From: <[email-masked]>
Date: Fri, 11 Mar 2011 07:39:28 +0000

Hi Rui,

A couple of observations:

-	you are correct to say that a client/server relationship is the key one, because any layer network mode/technology that is not TOS (Top-Of-Stack), and thus does not directly support external message/file/stream applications, MUST always have at least one higher layer network above it that is a true TOS layer network (a true TOS layer is present in all networking cases).  It therefore trivially follows that any peer interworking of non-TOS layer networks (whether they are the same or different mode/technology) is an unnecessary exercise....one can simply terminate the non-TOS layer networks at an interworking point and pass the client layer network transparently.  

-	when we have client/server nesting of co-ps mode layer networks that use exactly the same traffic units (noting one can have the same or different functional semantics of fields and components in the client and server layer network cases, eg same/different addressing for forwarding, same/different OAM, same/different routing process, etc) then one should consider both intra-layer and inter-layer misconnectivity.  

regards, Neil

Neil Harrison
BT Design

Email: [email-masked]
Web: www.bt.com
This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rui Costa
> Sent: 11 March 2011 03:32
> To: [email-masked]
> Subject: [mpls] draft-tsb-mpls-tp-ach-ptn
> 
> Hello,
> 
> The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn requests the
> allocation of an Associated Channel Type value that will allow ITU-T to
> develop OAM tools required to address the needs identified by some ITU-
> T members. Allocation of this value will make more efficient use of
> resources of both IETF and ITU-T. The use of this associated channel
> type fully complies with the framework and architecture for MPLS-TP.
> 
> 
> The draft also describes the cases where networks that run the ITU
> defined OAM tools are interconnected to networks that run the IETF
> defined OAM tools. In most cases it is a client/server relationship and
> no interworking is required. If a LSP or PW originates in one domain
> and terminates in the other domain then the IETF OAM tools must be
> used.
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Jingrq" <[email-masked]>
Date: Mon, 14 Mar 2011 08:34:56 +0800

Hi Rui,

I support your proposal. It will good to both IETF and ITU-T if the
Associated Channel Type is allocated.

Best regards 
  
Ruiquan（Rick） Jing 

China Telecom CTBRI

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Rui Costa
> Sent: Friday, March 11, 2011 11:32 AM
> To: [email-masked]
> The draft provided by the TSB draft-tsb-mpls-tp-ach-ptn 
> requests the allocation of an Associated Channel Type value 
> that will allow ITU-T to develop OAM tools required to 
> address the needs identified by some ITU-T members. 
> Allocation of this value will make more efficient use of 
> resources of both IETF and ITU-T. The use of this associated 
> channel type fully complies with the framework and 
> architecture for MPLS-TP.	
> 
> The draft also describes the cases where networks that run 
> the ITU defined OAM tools are interconnected to networks that 
> run the IETF defined OAM tools. In most cases it is a 
> client/server relationship and no interworking is required. 
> If a LSP or PW originates in one domain and terminates in the 
> other domain then the IETF OAM tools must be used.	
>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Mon, 14 Mar 2011 06:24:16 -0500

Hey folks-

  Before we get all caught up in the support/nosupport contest, please remember that the time support/nosupport comes out is in response to a WG poll, that sort of thing.  We're not there yet (the draft is brand new), so now is not the right time to start casting votes.  It achieves nothing and just adds noise on top of signal.

eric

> Jingrq
> Sent: Sunday, March 13, 2011 8:35 PM
> To: 'Rui Costa'; [email-masked]
> Subject: Re: [mpls] draft-tsb-mpls-tp-ach-ptn
> 
> Hi Rui,
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Rui Costa
> > allocation of an Associated Channel Type value that will allow ITU-T
> > to develop OAM tools required to address the needs identified by some
> > ITU-T members.
> > Allocation of this value will make more efficient use of resources of
> > both IETF and ITU-T. The use of this associated channel type fully
> > complies with the framework and
> > defined OAM tools. In most cases it is a client/server relationship
> > and no interworking is required.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 14 Mar 2011 14:04:24 +0100

Hi Eric,

You wrote:

> Before we get all caught up in the support/nosupport contest, please
 > remember that the time support/nosupport comes out is in response to
 > a WG poll, that sort of thing.

You are right, this is not a WG poll.

If I read the initial email it proposes: "This draft should be
discussed in Prague" so I assume the 'support' is for this proposal.

And I agree with that proposal.

> We're not there yet (the draft is brand new),

Indeed, but the draft is concise and to the point.
It is based on advice from the IETF to progress work on MPLS-TP.
A presentation would be very useful.

Regards, Huub.

-- 
*****************************************************************
                          我爱外点一七三一

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 14 Mar 2011 16:04:02 +0200

Huub,
I assume that the author has asked for a timeslot on the agenda of the MPLS WG?

As for the draft itself: I have read it, and I do not share your opinion regarding its being "concise and to the point".

Just a couple of comments and questions:
- The draft discusses differences between packet switching networks (i.e., a data plane technology) and packet transport networks (i.e. a specific application). Such a comparison looks inappropriate to me
- The draft suggest that RFC 5659 (An Architecture for Multi-Segment Pseudowires) defines a new data plane. In fact, MPLS multi-segment PWs use MPLS data plane as defined in RFC 3031 and 3032
- The draft states that PTN application uses MPLS-TP to add packet transport capabilities to existing SONET/SDH networks. Does this imply that it will not be applied to packets carried over other data link technologies, e.g., Ethernet in all its forms? In particular, what is going to happen in a device that uses label switching between two ports, one of them using MPLS over GFP over SDH, and the other one - using, say, MPLS over native GE or 10GE? (This is not an imaginary case).
- The draft does not consider the possibility of peering between the "PTN application" and "MPLS-TP", but hits that such a peering is possible between Ethernet and MPLS-TP.
- Last but not least, the draft does not explain how allocation of a *single* code point in the ACH type registry for the PTN application meets *all* the needs of the PTN application (CC/CV, PSC, Lock, LDI, MSN, SSN etc) that have been identified as the ACH applications for MPLS-TP. 

My 2c,
     Sasha

> Huub van Helvoort
> Sent: Monday, March 14, 2011 3:04 PM
> To: [email-masked]
> Of
> Behalf

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Fri, 18 Mar 2011 15:22:41 +0100

Definitely it's worth to have a discussion on draft-tsb-mpls-tp-ach-ptn during the meeting in Prague. I support the request for a time slot allocation.

Best regards,
Alessandro

------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport & OPB Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Costa
Sent: venerdì 11 marzo 2011 4.32
To: [email-masked]
Subject: [mpls] draft-tsb-mpls-tp-ach-ptn

Hello,

Best Regards,
Rui

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: John E Drake <[email-masked]>
Date: Fri, 18 Mar 2011 08:08:59 -0700

What is the rush?  The ITU document for which this code point has been requested has just started a long and arduous approval process from which it may never emerge.  Wouldn't it make more sense to delay discussion of this draft until the fate of the ITU document is more certain?

I.e., why allocate a code point to an ITU document that may never get approved?

Sent from my iPhone

> D'Alessandro Alessandro Gerardo
> Sent: Friday, March 18, 2011 7:23 AM
> To: [email-masked]; Rui Costa
> Definitely it's worth to have a discussion on draft-tsb-mpls-tp-ach-ptn
> during the meeting in Prague. I support the request for a time slot
> allocation.
> 
> Best regards,
> Alessandro
> 
> 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: Thomas Nadeau <[email-masked]>
Date: Fri, 18 Mar 2011 12:22:27 -0400

I agree.

Tom

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Mon, 21 Mar 2011 10:05:22 +0100

Hi John,

This is a formal request from the ITU-T and therefore should be considered promptly. As you are aware, approval of the G.8113.1 is dependent on having an ACh code point assigned.

I would suggest having a very open discussion that can help making the right decision.
It is also worth because I think the majority of the participants at the IETF meeting were not present at the last ITU-T meeting and therefore it is appropriate to make them aware of the overall ongoing discussions... rationale, technical reasons, operational reasons, etc. to collect their feedback.

One further point worth noting is that the reason that approval process will be longer than normal is that some people wrongly asserted that the ACh code point (a protocol identifier) impact naming and numbering and therefore is a "regulatory concern". We should correct this error in classification.

Best regards,
Alessandro

-----Original Message-----
From: John E Drake [mailto:[email-masked]]
Sent: venerdì 18 marzo 2011 16.09
To: D'Alessandro Alessandro Gerardo; [email-masked]; Rui Costa
Subject: RE: draft-tsb-mpls-tp-ach-ptn

Sent from my iPhone

---

From: Adrian Farrel <[email-masked]>
Date: Fri, 25 Mar 2011 17:42:31 +0100

FYI

> > This draft should be discussed in Prague.

There is 30 minutes allocated to this topic in the Routing Area Open Meeting.
Wednesday 13:00

Adrian

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 27 Mar 2011 16:39:07 -0400

In message <[email-masked]>
Adrian Farrel writes:
> There is 30 minutes allocated to this topic in the Routing Area Open
> Meeting.  Wednesday 13:00
>  
> Adrian

Adrian,

I suggest that we approach this draft any liason but treating with its
contents at face value and pointing out how this sort of action would
not fit into the IETF process in general, the IETF process for MPLS
and MPLS-TP agreed to by ITU.

Curtis

draft-tsb-mpls-tp-ach-ptn-00, "Assignment of an Associated Channel
Type for Packet Transport Network Applications" is asking for an
identifier to address a perceived layering problem related to MPLS-TP
OAM being jointly defined by IETF and ITU.

MPLS-TP allows layering in the data plane using multiple labels, one
per layer, in addition to any link layer below MPLS.  Existing MPLS
and PW mechansisms support this layering and support an OAM instance
per layer.

In addition there are specific mechanisms being defined within the
IETF to provide interworking with PW associated channels of various
types.  This work is draft-ietf-pwe3-mpls-eth-oam-iwk-04, "PLS and
Ethernet OAM Interworking" and draft-ietf-pwe3-oam-msg-map-14
"Pseudowire (PW) OAM Message Mapping".  The latter covers most legacy
protocols such as ATM, FR, and low speed TDM, plus others and has
completed WG last call.

A key assertion of draft-tsb-mpls-tp-ach-ptn-00 is that more than one
OAM instance is needed per layer.

The following two paragraphs are in conflict with MPLS-TP RFCs
published to date.

   When MPLS-TP is deployed in PTN environment, application specific
   mechanisms (e.g., OAM) are required to allow service providers
   retaining the same operational experience in the MPLS-TP network as
   they had in their existing Synchronous Optical Network/Synchronous
   Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN)
   networks.

   When MPLS-TP is deployed in other environments, e.g. in a Packet
   Switched Network (PSN), application specific mechanisms (e.g., OAM)
   are required to allow service providers retaining the same
   operational experience in the MPLS-TP network as they had in their
   existing IP and MPLS networks.

The MPLS-TP OAM is defined as supporting the capabilities of existing
transport technologies, though using different protocol mechanisms
that are not specific to any particular link layer.

The following statement proposes to break existing agreements between
ITU and IETF and deviate from existing IETF standards.

   Allocation of one Associated Channel Type value will allow ITU-T
   to develop the tools required to address the unique needs of PTN
   application and will make more efficient use of the resources of
   both organizations while providing a mechanism to prevent the
   accidental interconnection between PTN and PSN application
   specific tools. The use of this code point fully complies with
   the framework and architecture for MPLS-TP.

This document proposes that there is a new requirement and proposes
that the IETF delegate the ITU to come up with a solution, with no
further input from IETF.

The normal process within IETF is to bring a protocol through the
standardization process to some level of standardization and in the
final steps of that process replace the IANA considerations section
with code points allocated by IANA.

Not only is this a deviation from this process but no completed
protocol is defined or referenced in this document for which to assign
a code point.

The distinction between a PTN and PSN is defined in this
draft-tsb-mpls-tp-ach-ptn-00 and there is in fact no concensus that
such a distinction exists.

Section 5 of draft-tsb-mpls-tp-ach-ptn-00 make the assertion that
separation is needed between a PTN and a PSN and provides no
justification other than figures which attempt to illustrate a
distinction.

Even assuming that the assertion that a distinction exists between a
PTN and a PSN, and that multiple instances of OAM are needed, this
does not justify multiple instances of different protocols, it would
if such a requirement existed, justify two instance, which could be of
the same protocol.

Regardless as to whether two instances were of the same protocol, the
same protocol with extension to address some yet unstated requirement
of PTN that differs from PSN, or whether some yet unstated requirement
of PTN that differs from PSN so greatly as to justify a different OAM
protocol, those requirements must be stated in IETF documents and any
protocol changes to MPLS made within the IETF process as per agreement
among IETF and ITU-T.

Finally, the motivation for this request from ITU is speculated to be
driven primarily by perceived compatibility issues with pre-standard
implementations of T-MPLS.  This motivation may be reflected in the
following statements in draft-tsb-mpls-tp-ach-ptn-00.

  1.1. PTN Application Description

   In this application MPLS-TP will be used to add packet transport
   capability to an existing circuit switched (SDH/OTN) transport
   network.  Note that in many such networks Ethernet technology has
   been deployed to address some of these needs, also that Ethernet is
   a primary packet transport service.  The primary requirements are
   driven by a desire for compatibility with the existing transport
   network operational processes and in particular compatibility with
   the existing OAM mechanisms.

Interworking with legacy ATM, FR, low speed TDM, and SONET is
addressed by draft-ietf-pwe3-oam-msg-map-14 "Pseudowire (PW) OAM
Message Mapping".  Interworking with Ethernet is addressed by
draft-ietf-pwe3-mpls-eth-oam-iwk-04, "PLS and Ethernet OAM
Interworking".

If the motivation behind draft-tsb-mpls-tp-ach-ptn-00 is to address
perceived compatibility issues with pre-standard implementations of
T-MPLS, then that requirement should be stated.  If so, perhaps a more
productive approach would be to document transition issues, and
propose any temporary interworking capability that would be needed to
accommodate a transition from pre-standards T-MPLS OAM to MPLS-TP OAM.

Work toward defining requirements for a transition from pre-standards
T-MPLS OAM to MPLS-TP OAM and work toward providing guidance or if
necessary transitional protocol interworking extensions required to
support such a transition can and should be undertaken in the IETF.

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 28 Mar 2011 10:24:41 +0200

Hi Curtis,

Thanks for your thoughts.

I agree that we must treat this draft as we would treat any other draft, and
that we should treat the associated liaison as we treat all liaisons.

Furthermore, we have no option but to treat drafts and liaisons at face value.

The slides for Wednesday's Routing Area Open Meeting have been posted.

Thanks,
Adrian

> From: [email-masked] [mailto:[email-masked]]
> Sent: 27 March 2011 22:39
> To: [email-masked]
> Cc: [email-masked]