Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation between IETF and ITU-T on MPLS-TP

From: <[email-masked]>
Date: Sat, 14 Feb 2009 09:41:26 -0000

Thanks Malcolm,

Your mail has prompted me to list some key requirements that I believe
are important for both ITU-T and IETF to consider as we develop the
standards for MPLS-TP.  In no particular order:

1	 Transparent client/server relationship:

If MPLS-TP is to succeed in a transport role it will essential that it
can provide a transparent client/server relationship between different
instances of MPLS-TP layer networks owned by the same or different
parties, ie MPLS-TPoverMPLS-TP.  One way this could be achieved is by
the use of special label for this purpose only.  However, if we want a
more general client/server solution (which I believe is the case) then
we should consider how to implement a generic adaptation function that
provides a client PID capability.

Aside=> Current co-cs generation transport networks (based on PDH, SDH
and OTN) use GFP as the common/generic adaptation function for their
clients.  GFP has a PID function (in the UPI field) that already
identifies important SAN clients, and it also has values for Ethernet,
IP and MPLS clients.  Since the ease of migration/interworking of
current and next generation transport networks is important for network
operators, then the use of GFP in MPLS-TP should be given serious
consideration.

2	MPLS-TP OAM:

MPLS-TP OAM functions must be client layer network agnostic and appear
as identical as possible to MPLS-TP traffic units at the MPLS-TP layer
network under consideration.  From technical considerations a TTL field
is not required in any co-ps/co-cs mode layer network (the CP/MP can
ensure there are no loops before establishing a LSP) and thus the
existing MPLS TTL field could be used for other important functions such
as an OAM indicate function (this would only require 1 bit, noting that
the TTL field consumes 25% of a scarce resource in the MPLS-TP header).
However, if this is deemed not possible (for whatever reason, but which
clearly cannot be technical) then some other way must be found to ensure
this.  

3	PWs and MPLS-TP:

We must be very clear that PWs are a consequence of the way MPLS was
originally specified;  in particular the different way in which IP and
all other clients were handled, and the consequences of LDP merging and
ECMP load spreading.  For MPLS-TP to take on a transport role however,
its design must be changed such that it treats all clients equally (ie
point 1 above) and merging behaviour is removed.

We should also note that when PWs were only a 1-hop entity in MPLS they
could be considered as an adaptation-like function.  However, when PWs
became multi-segment constructs (ie MS-PWs) then they underwent a very
significant change in behaviour and became a co-ps layer network in
their own right above MPLS.

Now given MPLS-TP is supposed to be a transport network, then it would
make no sense whatsoever for it to create a further co-ps mode (PW)
layer network above it.  Indeed, this would be completely at odds with
the requirement for a generic transparent client/server relationship
noted in 1 above.

>From purely technical considerations it is therefore quite clear that
MPLS-TP has no need to have PWs.  However, they could be kept (at least
in name) providing they reverted back to their original 1-hop
adaptation-like functionality and did not generate a co-ps layer network
above MPLS-TP.

regards, Neil

> -----Original Message-----
> From: Malcolm Betts [mailto:[email-masked]] 
> Sent: 12 February 2009 14:13
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [T15Q12] FW: Liaison on the cooperation between IETF 
> and ITU-T on MPLS-TP
> 
> All, attached is a liaison statement from the IETF MEAD team. 
>  The most
> critical items are listed below:
> 
> "However, in order to foster communication between the two bodies, we
> believe that the following items need to be agreed on and or
> communicated from the ITU-T to the IETF:
> 1.	First, we need to understand when we have received all the
> relevant MPLS-TP requirements from ITU-T, if this date is 
> pressed to far
> into the future this will have an impact on the target date for the
> MPLS-TP RFCs.
> 2.	Second, we need to have a clear understanding of which documents
> we need to have approved as RFCs for the SG15 meeting in October 2009.
> 3.	Third, we see a need to further define the process, regarding
> ITU-T review of our Internet-Drafts as well as IETF review of ITU-T
> Draft Recommendations before they are published as RFCs or Approved
> Recommendations.
> 4.	Fourth, we see that there is a need to coordinate between our
> two organizations so that T-MPLS related contributions to the 
> ITU-T are
> not accepted into SG or Question meetings.
> 5.	Finally, we need the OAM deployment scenarios that we were
> promised at the SG15 meeting in Geneva."
> 
> The IETF have requested a complete response by March 31st.
> 
> With respect to point 1:  I believe that the ITU has identified all of
> the current requirements and we are in the process of providing
> clarifications as the IETF drafts are developed.
> 
> To respond to point 2, I request the editors of the revised MPLS-TP
> Recommendations to identify which drafts they plan to make normative
> references to.
> 
> With respect to point 5:  I request that those interested in the work
> provide input as soon as possible so that we can deliver this as
> promised.
> 
> For points 3 & 4 I will work with the SG 15 leadership team 
> to develop a
> response.
> 
> 
> Malcolm Betts
> Co chair Ad Hoc on MPLS-TP
> Phone: +1 613 763 7860 (ESN 393)
> email: [email-masked]
> 
> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Friday, February 06, 2009 11:52 AM
> To: Yoichi Maeda; Greg Jones; Ghani Abbas; Huub Van Helvoort; Betts,
> Malcolm (CAR:X632); Hing-Kam Lam; [email-masked]; [email-masked]
> Cc: David Ward; Ross Callon; Mark Townsley; Jari Arkko; Scott Bradner;
> Russ Housley; Olaf Kolkman; IETF MEAD team
> Subject: Liaison on the cooperation between IETF and ITU-T on MPLS-TP
> 
> All,
> 
> please find a liaison on the cooperation between IETF and ITU-T on
> MPLS-TP included.
> 
> /Loa
> -- 
> 
> 
> Loa Andersson
> 
> Sr Strategy and Standards Manager
> Ericsson ///                          phone:  +46 8 632 77 14
> 
>                                        email:
> [email-masked]
>                                                
> [email-masked]
>                                                [email-masked]
> 
> 
>

---

From: "Drake, John E" <[email-masked]>
Date: Sun, 15 Feb 2009 11:48:58 -0800

Hi,

Neil and I have been discussing how to address the requirements he lists
in his e-mail, below, and we would like to propose the following.

We would add the PPP PID of the associated client payload as the
bottom-most label, with the 'bottom of stack' bit set, in the server
MPLS stack.  (We would also define a new PPP PID value for dataplane OAM
payloads.) 

So, the 'bottom of stack' entry in the server MPLS stack would look as
follows:

-	When carrying client payloads:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0|       PPP client PID          |0 0 0|1|0 0 0 0 0 0 0 1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                              EXP  S      TTL
-	When carrying OAM payloads:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0|       PPP OAM (TBD)           |0 0 0|1|0 0 0 0 0 0 0 1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                              EXP  S     TTL

-	When carrying inband control plane/management plane payloads: 

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0|       GAL                     |0 0 0|1|0 0 0 0 0 0 0 1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                              EXP  S     TTL 

	I.e., the GAL (label 13) is specifically reserved for carrying
CP/MP protocols 	between logically adjacent MPLS-TP layer network
nodes.  (The S bit is essentially 	'don't care' as it is the
globally unique GAL that is the key identifier.)  The GAL 	is never
associated with the DP and is never propagated beyond 2 logically
adjacent 	MPLS-TP layer network nodes.  The GAL is always
immediately followed by the G-ACH 	and this identifies the specific
CP or MP protocol/functions being carried in the 	payload.

The server MPLS stack entries with S=0 have normal traffic forwarding
semantics (including the normal use of EXP and TTL fields) for label
values > 15.

If a control plane is used to establish the server LSP, there would
presumably be a capabilities exchange to ensure that both ends of that
LSP will understand the significance of the botom-most label in this
context.

We think that this proposal is consistent with RFC 3032, which states:

"2.2. Determining the Network Layer Protocol

   When the last label is popped from a packet's label stack (resulting
   in the stack being emptied), further processing of the packet is
   based on the packet's network layer header.  The LSR which pops the
   last label off the stack must therefore be able to identify the
   packet's network layer protocol.  However, the label stack does not
   contain any field which explicitly identifies the network layer

Rosen, et al.               Standards Track                     [Page 5]

RFC 3032               MPLS Label Stack Encoding            January 2001

   protocol.  This means that the identity of the network layer protocol
   must be inferable from the value of the label which is popped from
   the bottom of the stack, possibly along with the contents of the
   network layer header itself.

   Therefore, when the first label is pushed onto a network layer
   packet, either the label must be one which is used ONLY for packets
   of a particular network layer, or the label must be one which is used
   ONLY for a specified set of network layer protocols, where packets of
   the specified network layers can be distinguished by inspection of
   the network layer header.  Furthermore, whenever that label is
   replaced by another label value during a packet's transit, the new
   value must also be one which meets the same criteria.  If these
   conditions are not met, the LSR which pops the last label off a
   packet will not be able to identify the packet's network layer
   protocol."

Thanks,

Neil and John

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Saturday, February 14, 2009 1:41 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the 
> cooperation between IETFand ITU-T on MPLS-TP
> 
> Thanks Malcolm,
> 
> Your mail has prompted me to list some key requirements that 
> I believe are important for both ITU-T and IETF to consider 
> as we develop the standards for MPLS-TP.  In no particular order:
> 
> 
> If MPLS-TP is to succeed in a transport role it will 
> essential that it can provide a transparent client/server 
> relationship between different instances of MPLS-TP layer 
> networks owned by the same or different parties, ie 
> MPLS-TPoverMPLS-TP.  One way this could be achieved is by the 
> use of special label for this purpose only.  However, if we 
> want a more general client/server solution (which I believe 
> is the case) then we should consider how to implement a 
> generic adaptation function that provides a client PID capability.
> 
> Aside=> Current co-cs generation transport networks (based on 
> PDH, SDH and OTN) use GFP as the common/generic adaptation 
> function for their clients.  GFP has a PID function (in the 
> UPI field) that already identifies important SAN clients, and 
> it also has values for Ethernet, IP and MPLS clients.  Since 
> the ease of migration/interworking of current and next 
> generation transport networks is important for network 
> operators, then the use of GFP in MPLS-TP should be given 
> serious consideration.
> 
> 
> 2	MPLS-TP OAM:
> 
> MPLS-TP OAM functions must be client layer network agnostic 
> and appear as identical as possible to MPLS-TP traffic units 
> at the MPLS-TP layer network under consideration.  From 
> technical considerations a TTL field is not required in any 
> co-ps/co-cs mode layer network (the CP/MP can ensure there 
> are no loops before establishing a LSP) and thus the existing 
> MPLS TTL field could be used for other important functions 
> such as an OAM indicate function (this would only require 1 
> bit, noting that the TTL field consumes 25% of a scarce 
> resource in the MPLS-TP header).
> However, if this is deemed not possible (for whatever reason, 
> but which clearly cannot be technical) then some other way 
> must be found to ensure this.  
> 
> 
> 3	PWs and MPLS-TP:
> 
> We must be very clear that PWs are a consequence of the way 
> MPLS was originally specified;  in particular the different 
> way in which IP and all other clients were handled, and the 
> consequences of LDP merging and ECMP load spreading.  For 
> MPLS-TP to take on a transport role however, its design must 
> be changed such that it treats all clients equally (ie point 
> 1 above) and merging behaviour is removed.
> 
> We should also note that when PWs were only a 1-hop entity in 
> MPLS they could be considered as an adaptation-like function. 
>  However, when PWs became multi-segment constructs (ie 
> MS-PWs) then they underwent a very significant change in 
> behaviour and became a co-ps layer network in their own right 
> above MPLS.
> 
> Now given MPLS-TP is supposed to be a transport network, then 
> it would make no sense whatsoever for it to create a further 
> co-ps mode (PW) layer network above it.  Indeed, this would 
> be completely at odds with the requirement for a generic 
> transparent client/server relationship noted in 1 above.
> 
> From purely technical considerations it is therefore quite 
> clear that MPLS-TP has no need to have PWs.  However, they 
> could be kept (at least in name) providing they reverted back 
> to their original 1-hop adaptation-like functionality and did 
> not generate a co-ps layer network above MPLS-TP.
> 
> regards, Neil
> 
> 
> > Subject: [T15Q12] FW: Liaison on the cooperation between IETF and 
> > ITU-T on MPLS-TP
> > 
> pressed to 
> > far into the future this will have an impact on the target date for 
> > the MPLS-TP RFCs.
> > two organizations so that T-MPLS related contributions to the ITU-T 
> > are not accepted into SG or Question meetings.
> to develop 
> > a response.
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: [email-masked]
Date: Mon, 16 Feb 2009 10:54:47 +0800

John:
 I have a question of your solution. if adding PPP PID of the associated 
client payload as the bottom-most label, there are two different traffic 
that are both the same type i.e ETH, needing to be transported by MPLS-TP 
layer network. if using  your solution, the two traffic must be 
encapsulated by the same PW label and maybe be tranported by the same 
MPLS-TP LSP. so how to identify the two different traffic in sink MEP of 
mpls-tp LSP?
regards 
liu

"Drake, John E" <[email-masked]> 
发件人:  [email-masked]
2009-02-16 03:48

收件人
<[email-masked]>, <[email-masked]>, <[email-masked]>
抄送

主题
Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation between   IETFand 
ITU-T on MPLS-TP

Hi,

     0                   1                   2                   3

     0                   1                   2                   3

-                When carrying inband control plane/management plane 
payloads: 

     0                   1                   2                   3

                 I.e., the GAL (label 13) is specifically reserved for 
carrying
CP/MP protocols                  between logically adjacent MPLS-TP layer 
network
nodes.  (The S bit is essentially                'don't care' as it is the
globally unique GAL that is the key identifier.)  The GAL is never
associated with the DP and is never propagated beyond 2 logically
adjacent                 MPLS-TP layer network nodes.  The GAL is always
immediately followed by the G-ACH                and this identifies the 
specific
CP or MP protocol/functions being carried in the                 payload.



Thanks,

Neil and John

--------------------------------------------------------
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: "Drake, John E" <[email-masked]>
Date: Mon, 16 Feb 2009 07:22:14 -0800

There are no PW headers in this proposal. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, February 15, 2009 6:55 PM
> To: Drake, John E
> Cc: [email-masked]
> cooperation between IETFandITU-T on MPLS-TP
> 
> 
> John: 
>  I have a question of your solution. if adding PPP PID of the 
> associated client payload as the bottom-most label, there are 
> two different traffic that are both the same type i.e ETH, 
> needing to be transported by MPLS-TP layer network. if using  
> your solution, the two traffic must be encapsulated by the 
> same PW label and maybe be tranported by the same MPLS-TP 
> LSP. so how to identify the two different traffic in sink MEP 
> of mpls-tp LSP? 
> regards
> liu 
> 
> 
> 
> 2009-02-16 03:48 收件人
> Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation between 
>        IETFand ITU-T on MPLS-TP
> 
> 	
> 
> 
> 
> 
> Hi,
> 
> > 
> 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: <[email-masked]>
Date: Mon, 16 Feb 2009 15:58:26 -0000

John is correct.  You to remember Liu that PWs only came about because of the way MPLS was originally specified.  For MPLS-TP to assume a  transport role then (i) the conditions which gave rise to the need for PWs in MPLS have to be removed and (ii) we have to treat all clients equally/transparently.  Furthermore, and of even greater importance, is the fact that the MS-PWs that are now being considered in MPLS cannot have any place in MPLS-TP.  This is because a MS-PW represents a co-ps mode layer network above MPLS, and clearly a transport network such as MPLS-TP should never require unnecessary layer networks to be created above it.   

regards, Neil
PS - I am away on leave for a week now so will not be able to respond to any further questions until I get back.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: 16 February 2009 15:22
> To: [email-masked]
> Cc: [email-masked]
> cooperation betweenIETFandITU-T on MPLS-TP
> 
> > > >

---

From: [email-masked]
Date: Tue, 17 Feb 2009 10:16:26 +0800

thank John and Neil for quick reply, I am sorry for not clarifying my 
question. my question is not whether or not need PWs. for example as the 
below figure:
 
              ETH AC1 and ETH AC2 traffic can be encapsulated at the first 
MEP by pushing a lable into mpls stack. if according to your solution. 
maybe ETH AC1 and ETH AC2 traffic use the same label in mpls stack because 
both traffic type is the same .and both taffic will be transported by the 
same MPLS-TP LSP. so the outside forward label is also the same. when 
arriving at the sink MEP.
the bottom-label will be poped off, though sink MEP may indentify the 
traffic type ,ie.ETH by PPP PID field in the bottom-label, but how to know 
this both traffic will be forwarded by ETH AC1(output) port or by ETH 
AC2(output)?
   regards
   liu

<[email-masked]> 
2009-02-16 23:58

收件人
<[email-masked]>, <[email-masked]>
抄送
<[email-masked]>
主题
RE: [mpls-tp] [T15Q12] FW: Liaison on the cooperation betweenIETFandITU-T 
on MPLS-TP

John is correct.  You to remember Liu that PWs only came about because of 
the way MPLS was originally specified.  For MPLS-TP to assume a  transport 
role then (i) the conditions which gave rise to the need for PWs in MPLS 
have to be removed and (ii) we have to treat all clients 
equally/transparently.  Furthermore, and of even greater importance, is 
the fact that the MS-PWs that are now being considered in MPLS cannot have 
any place in MPLS-TP.  This is because a MS-PW represents a co-ps mode 
layer network above MPLS, and clearly a transport network such as MPLS-TP 
should never require unnecessary layer networks to be created above it. 

regards, Neil
PS - I am away on leave for a week now so will not be able to respond to 
any further questions until I get back.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 17 Feb 2009 07:45:08 +0100

As per MPLS-TP requirements draft, MPLS-TP will need to have the following
layers:
1) transport service layer
2) transport path layer
3) section layer
4) physical media layer.

My understanding is that so far we were discussing to use the following
layer technologies for those four layers:
1) ETH and optional MS-PW
2) Path LSP
3) Section LSP or ETH Section
4) 802.3, SDH, OTN.

If we remove the MS-PW from the set above, does this imply that the
transport service layer is provided by an ETH (i.e. Ethernet VLAN) layer for
all services? I.e. following the case that I have found in some of the
european networks today.

Or, will the removal of the MS-PW imply that the p2p and p2mp services are
supported by a new "Service LSP" layer?

The deployment of a Service LSP layer (instead of a MS-PW layer) will not
change the packet formats as far as I can see.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: maandag 16 februari 2009 16:58
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the
cooperationbetweenIETFandITU-T on MPLS-TP

John is correct.  You to remember Liu that PWs only came about because of
the way MPLS was originally specified.  For MPLS-TP to assume a  transport
role then (i) the conditions which gave rise to the need for PWs in MPLS
have to be removed and (ii) we have to treat all clients
equally/transparently.  Furthermore, and of even greater importance, is the
fact that the MS-PWs that are now being considered in MPLS cannot have any
place in MPLS-TP.  This is because a MS-PW represents a co-ps mode layer
network above MPLS, and clearly a transport network such as MPLS-TP should
never require unnecessary layer networks to be created above it.   

regards, Neil
PS - I am away on leave for a week now so will not be able to respond to any
further questions until I get back.

> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation 
> betweenIETFandITU-T on MPLS-TP
> 
> > Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation 
> > between IETFandITU-T on MPLS-TP
> > 
> > 
> > John: 
> > associated client payload as the bottom-most label, there are two 
> > different traffic that are both the same type i.e ETH, needing to be 
> > transported by MPLS-TP layer network. if using your solution, the 
> > two traffic must be encapsulated by the same PW label and maybe be 
> > tranported by the same MPLS-TP LSP. so how to identify the two 
> > different traffic in sink MEP of mpls-tp LSP?
> > regards
> > liu
> > 
> > 
> > 
> > Neil and I have been discussing how to address the requirements he 
> > lists in his e-mail, below, and we would like to propose the 
> > following.
> > 
> > > Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation 
> > > between IETFand ITU-T on MPLS-TP
> > > 
> > > Thanks Malcolm,
> > > 
> > > Your mail has prompted me to list some key requirements that I 
> > > believe are important for both ITU-T and IETF to consider as we 
> > > develop the standards for MPLS-TP.  In no particular order:
> > > 
> > > 
> > > If MPLS-TP is to succeed in a transport role it will essential 
> > > that it can provide a transparent client/server relationship 
> > > between different instances of MPLS-TP layer networks owned by the 
> > > same or different parties, ie MPLS-TPoverMPLS-TP.  One way this 
> > > could be achieved is by the use of special label for this purpose 
> > > only.  However, if we want a more general client/server solution 
> > > (which I believe is the case) then we should consider how to 
> > > implement a generic adaptation function that provides a client PID 
> > > capability.
> > > 
> > > Aside=> Current co-cs generation transport networks (based on PDH, 
> > > SDH and OTN) use GFP as the common/generic adaptation function for 
> > > their clients.  GFP has a PID function (in the UPI field) that 
> > > already identifies important SAN clients, and it also has values 
> > > for Ethernet, IP and MPLS clients.  Since the ease of 
> > > migration/interworking of current and next generation transport 
> > > networks is important for network operators, then the use of GFP 
> > > in MPLS-TP should be given serious consideration.
> > > 
> > > 
> > > 2                 MPLS-TP OAM:
> > >

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 17 Feb 2009 08:43:10 +0100

Liu,
 
There is still a need for a "transport service layer" above the "transport
path layer (LSP)". When multiplexing two "transport service layer" signals
into an LSP, you will need two "transport service layer" label values, one
to identify signal 1, another one to identify signal 2. These labels will be
carried in a Label Stack Entry header, but this LSE header will not longer
be called "PW label". It could be called "Transport Service"  or "Channel"
label.
 
The proposed bottom-of-stack entry is providing only a Protocol Type on
every packet, and becomes an additional LSE header in the label stack. This
Protocol Type LSE header is not longer a normal label stack entry, and the
interpretation of the bits 4 to 19 must follow different rules then today.
The S-bit seems to be used to differentiate between a regular LSE header
(S=0) and a Protocol Type LSE header (S=1).
 
An alternative means to provide a Protocol Type on every packet is to
specify that the ACH is present on every packet, and that the Channel Type
field carries the protocol type identifier. This ACH would then be located
between the CW and the "Transport Service layer" LSE header.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: dinsdag 17 februari 2009 3:16
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] 答复: RE: [T15Q12] FW: Liaison on the cooperation
betweenIETFandITU-T on MPLS-TP

              ETH AC1 and ETH AC2 traffic can be encapsulated at the first
MEP by pushing a lable into mpls stack. if according to your solution. maybe
ETH AC1 and ETH AC2 traffic use the same label in mpls stack because both
traffic type is the same .and both taffic will be transported by the same
MPLS-TP LSP. so the outside forward label is also the same. when arriving at
the sink MEP. 
the bottom-label will be poped off, though sink MEP may indentify the
traffic type ,ie.ETH by PPP PID field in the bottom-label, but how to know
this both traffic will be forwarded by ETH AC1(output) port or by ETH
AC2(output)? 
   regards 
   liu 

<[email-masked]> 

2009-02-16 23:58 

收件人

抄送
<[email-masked]> 

主题
RE: [mpls-tp] [T15Q12] FW: Liaison on the cooperation betweenIETFandITU-T on
MPLS-TP

regards, Neil

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: Stewart Bryant <[email-masked]>
Date: Tue, 17 Feb 2009 09:13:28 +0000

Liu

The industry standard method of carrying an Ethernet frame over an MPLS LSP
is to use a pseudowire. I would be a great dis-service to abandon this
widely
deployed design that has been designed into a lot of silicon.

The issue that I thought that we were discussing on this list is how best to
carry IP/MPLS over MPLS-TP. In this case we have the problem of how
a router forms an adjacency, transports its control traffic in an IP/MPLS
context and it's various OAM traffic. A lot of this traffic is encapsulated
at the datalink.

There are two issue that seem to have been conflated and this is confusing
the situation:

1) The encapsulation design
2) Whether multi-segment pseudowires are needed or should be prohibited

I think that we should solve problem (1) and leave problem (2) to
a separate WG discussion. Even if we think the answer to (2) is that we
do not need MS-PW now, I would note that we also thought that when we
started the PW project.

Carrying all types of client traffic over a PW provides a consistency in the
design and the following structure has those features:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN LSP label stack (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label with EOS set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |FRG| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP PID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
~ User Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

We know that the PW approach will correctly carry all of the L2
types that are needed. If we move to any other format we need
to figure out whether the length will ever be needed.

A PID taken from a p2p protocol makes sense, because a router
adjacency operates differently (greater complexity) over a
mp2mp connection (i.e. classic Ethernet), and this would
make it unambiguous that a p2p adjacency is being formed here.

The Sequence number is useful for verifying delivery sequence
and (absence of) packet loss. Verison were interested in retaining
the FRG. OAM packets are identical to data packets over the LSP.

Stewart

[email-masked] wrote:
> question. my question is not whether or not need PWs. for example as
> the below figure:
>
> ETH AC1 and ETH AC2 traffic can be encapsulated at the first MEP by
> pushing a lable into mpls stack. if according to your solution. maybe
> ETH AC1 and ETH AC2 traffic use the same label in mpls stack because
> both traffic type is the same .and both taffic will be transported by
> the same MPLS-TP LSP. so the outside forward label is also the same.
> when arriving at the sink MEP.
> traffic type ,ie.ETH by PPP PID field in the bottom-label, but how to
> know this both traffic will be forwarded by ETH AC1(output) port or by
> ETH AC2(output)?
> regards
> liu
>
>
>
> *<[email-masked]>*
>
> 2009-02-16 23:58
>
> 	
> 收件人
> 	RE: [mpls-tp] [T15Q12] FW: Liaison on the cooperation
> John is correct. You to remember Liu that PWs only came about because
> of the way MPLS was originally specified. For MPLS-TP to assume a
> transport role then (i) the conditions which gave rise to the need for
> PWs in MPLS have to be removed and (ii) we have to treat all clients
> the fact that the MS-PWs that are now being considered in MPLS cannot
> have any place in MPLS-TP. This is because a MS-PW represents a co-ps
> mode layer network above MPLS, and clearly a transport network such as
> MPLS-TP should never require unnecessary layer networks to be created
> above it.
>
> regards, Neil
> PS - I am away on leave for a week now so will not be able to respond
> to any further questions until I get back.
>
> ZTEInformationSecurityNotice:Theinformationcontainedinthismailissolelypropertyofthesender'sorganization.Thismailcommunicationisconfidential.Recipientsnamedaboveareobligatedtomaintainsecrecyandarenotpermittedtodisclosethecontentsofthiscommunicationtoothers.
> Thisemailandanyfilestransmittedwithitareconfidentialandintendedsolelyfortheuseoftheindividualorentitytowhomtheyareaddressed.Ifyouhavereceivedthisemailinerrorpleasenotifytheoriginatorofthemessage.Anyviewsexpressedinthismessagearethoseoftheindividualsender.
> ThismessagehasbeenscannedforvirusesandSpambyZTEAnti-Spamsystem.
>   
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Tue, 17 Feb 2009 17:11:45 +0800

maarten:
   thank you for your interpretion. i can understand John and Neil's 
solution. whether antoher LSE header is adding the bottom of label stack 
to identify protocol type on every packet. if it is so, there maybe not 
have ACH in every traffic packet. is it true for my understanding? 
regards
liu

Maarten Vissers <[email-masked]> 
2009-02-17 15:43

收件人
[email-masked], [email-masked], [email-masked]
抄送
[email-masked]
主题
RE: [mpls-tp] 答复: RE:  [T15Q12] FW: Liaison on the cooperation 
betweenIETFandITU-T on MPLS-TP

Liu,
 
There is still a need for a "transport service layer" above the "transport 
path layer (LSP)". When multiplexing two "transport service layer" signals 
into an LSP, you will need two "transport service layer" label values, one 
to identify signal 1, another one to identify signal 2. These labels will 
be carried in a Label Stack Entry header, but this LSE header will not 
longer be called "PW label". It could be called "Transport Service"  or 
"Channel" label.
 
The proposed bottom-of-stack entry is providing only a Protocol Type on 
every packet, and becomes an additional LSE header in the label stack. 
This Protocol Type LSE header is not longer a normal label stack entry, 
and the interpretation of the bits 4 to 19 must follow different rules 
then today. The S-bit seems to be used to differentiate between a regular 
LSE header (S=0) and a Protocol Type LSE header (S=1).

Regards,
Maarten

      

<[email-masked]> 
2009-02-16 23:58 

收件人

regards, Neil

--------------------------------------------------------
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: "Drake, John E" <[email-masked]>
Date: Tue, 17 Feb 2009 05:48:17 -0800

Liu,

In the scenario you describe, the bottom of stack entry in the server MPLS stack would indicate that the client is MPLS.  The client payload would then contain its own MPLS stack and PW header, both set for either ETH ACH1 or ETH ACH2.

Thanks,

John
> Sent: Monday, February 16, 2009 6:16 PM
> To: [email-masked]; Drake, John E
> Cc: [email-masked]
> Subject: 答复: RE: [mpls-tp] [T15Q12] FW: Liaison on the 
> thank John and Neil for quick reply, I am sorry for not 
> clarifying my question. my question is not whether or not 
> need PWs. for example as the below figure: 
>       
>               ETH AC1 and ETH AC2 traffic can be encapsulated 
> at the first MEP by pushing a lable into mpls stack. if 
> according to your solution. maybe ETH AC1 and ETH AC2 traffic 
> use the same label in mpls stack because both traffic type is 
> the same .and both taffic will be transported by the same 
> MPLS-TP LSP. so the outside forward label is also the same. 
> the bottom-label will be poped off, though sink MEP may 
> indentify the traffic type ,ie.ETH by PPP PID field in the 
> bottom-label, but how to know this both traffic will be 
> forwarded by ETH AC1(output) port or by ETH AC2(output)? 
>    regards 
>    liu 
>       
> 
> 
> 
> <[email-masked]> 
> 
> 2009-02-16 23:58 收件人
> John is correct.  You to remember Liu that PWs only came 
> about because of the way MPLS was originally specified.  For 
> MPLS-TP to assume a  transport role then (i) the conditions 
> which gave rise to the need for PWs in MPLS have to be 
> removed and (ii) we have to treat all clients 
> equally/transparently.  Furthermore, and of even greater 
> importance, is the fact that the MS-PWs that are now being 
> considered in MPLS cannot have any place in MPLS-TP.  This is 
> because a MS-PW represents a co-ps mode layer network above 
> MPLS, and clearly a transport network such as MPLS-TP should 
> PS - I am away on leave for a week now so will not be able to 
> respond to any further questions until I get back.
> 
> > > > > >

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 17 Feb 2009 05:56:40 -0800

Stewart,

Please see my e-mail to Liu.  For the case of a PW transported over MPLS, I don't think Niel's and my proposal is that different than yours.  I.e.,  the bottom of stack entry in the server MPLS stack would indicate that the client payload is MPLS, and the client payload would start with its own MPLS stack followed by a PW header. 

Thanks,

John 

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Tuesday, February 17, 2009 1:13 AM
> Cc: [email-masked]; Drake, John E; [email-masked]
> Subject: Re: [mpls-tp] 答复: RE: [T15Q12] FW: Liaison on the 
> The industry standard method of carrying an Ethernet frame 
> over an MPLS LSP is to use a pseudowire. I would be a great 
> dis-service to abandon this widely deployed design that has 
> been designed into a lot of silicon.
> 
> The issue that I thought that we were discussing on this list 
> is how best to carry IP/MPLS over MPLS-TP. In this case we 
> have the problem of how a router forms an adjacency, 
> transports its control traffic in an IP/MPLS context and it's 
> various OAM traffic. A lot of this traffic is encapsulated at 
> the datalink.
> 
> There are two issue that seem to have been conflated and this 
> is confusing the situation:
> 
> I think that we should solve problem (1) and leave problem 
> (2) to a separate WG discussion. Even if we think the answer 
> to (2) is that we do not need MS-PW now, I would note that we 
> also thought that when we started the PW project.
> 
> Carrying all types of client traffic over a PW provides a 
> consistency in the design and the following structure has 
> those features:
> 
> 0                   1                   2                   3
> We know that the PW approach will correctly carry all of the 
> L2 types that are needed. If we move to any other format we 
> need to figure out whether the length will ever be needed.
> 
> mp2mp connection (i.e. classic Ethernet), and this would make 
> it unambiguous that a p2p adjacency is being formed here.
> 
> and (absence of) packet loss. Verison were interested in 
> retaining the FRG. OAM packets are identical to data packets 
> over the LSP.
> 
> Stewart
> 
> 
> 
> 
> 
> 
> 	              ETH AC1 and ETH AC2 traffic can be 
> encapsulated at the first MEP by pushing a lable into mpls 
> stack. if according to your solution. maybe ETH AC1 and ETH 
> AC2 traffic use the same label in mpls stack because both 
> traffic type is the same .and both taffic will be transported 
> by the same MPLS-TP LSP. so the outside forward label is also 
> the same. when arriving at the sink MEP. 
> <[email-masked]> <mailto:[email-masked]>  
> 
> 2009-02-16 23:58 
> 
> 收件人
> <[email-masked]> <mailto:[email-masked]> 
> , <[email-masked]> <mailto:[email-masked]>  	
> 抄送
> <[email-masked]> <mailto:[email-masked]>  	
> 主题
> 	John is correct.  You to remember Liu that PWs only 
> came about because of the way MPLS was originally specified.  
> For MPLS-TP to assume a  transport role then (i) the 
> conditions which gave rise to the need for PWs in MPLS have 
> to be removed and (ii) we have to treat all clients 
> 	PS - I am away on leave for a week now so will not be 
> able to respond to any further questions until I get back.
> 	
> <mailto:[email-masked]>  
> <mailto:[email-masked]> , <[email-masked]> 
> <mailto:[email-masked]> , <[email-masked]> 
> <mailto:[email-masked]>  
> 	> > 抄送
> 	> > 主题
> 	> >     0                   1                   2       
>             3
> 	> >     0                   1                   2       
>             3
> 	> >     0                   1                   2       
>             3
> 	> > globally unique GAL that is the key identifier.)  
> The GAL     
> 	> >              is never
> 	> > CP or MP protocol/functions being carried in the    
>           
> 	> >     payload.
> 	> > 
> 	> > Rosen, et al.               Standards Track         
>           
> 	> >   [Page 5]
> 	> > > > > 
> 	> >   ONLY for a specified set of network layer 
> protocols, where 
> 	> > packets of
> 	> > > > "However, in order to foster communication 
> between the two 
> 	> > > bodies, we 
> 	> > > > we need to have approved as RFCs for the SG15 
> meeting in 
> 	> > > October 2009.
> 	> > > > 3.                 Third, we see a need to 
> further define 
> 	> > the process, regarding
> 	> > > > 4.                 Fourth, we see that there is 
> a need to 
> 	> > coordinate between our
> 	> > > > two organizations so that T-MPLS related 
> contributions to 
> 	> > the ITU-T 
> 	> > > > Recommendations to identify which drafts they 
> plan to make 
> 	> > > normative 
> 	> > > > references to.
> 	> > > > 
> 	> > > > With respect to point 5:  I request that those 
> interested 
> 	> > > in the work 
> 	> > > > Subject: Liaison on the cooperation between 
> IETF and ITU-T 
> 	> > > on MPLS-TP
> 	> > > > 
> 	> > > > All,
> 	> > > > 
> 	> > > > please find a liaison on the cooperation 
> between IETF and 
> 	> > ITU-T on 
> 	> > > > MPLS-TP included.
> 	> > > > 
> 	> > > > /Loa
> 	> > > > --
> 	> > > > 
> 	> > > > 
> 	> > > > Loa Andersson
> 	> > > > 
> 	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 
> 	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: "Drake, John E" <[email-masked]>
Date: Tue, 17 Feb 2009 06:06:54 -0800

Stewart,

I just read your e-mail more closely and what you seem to be proposing is to have a single MPLS stack, containing both server and client defined labels.  From what I have heard, this is definitely a non-starter.

However, as I indicated in my other e-mails, in Neil's and my proposal, the server stack would end with an MPLS PID, indicating that the client payload is MPLS, and then the client payload would look nearly as you described:  an MPLS header followed by a PW header and the payload.

Thanks,

John
> From: Drake, John E 
> Sent: Tuesday, February 17, 2009 5:57 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp]答复: RE: [T15Q12] FW: Liaison on the 
> Please see my e-mail to Liu.  For the case of a PW 
> transported over MPLS, I don't think Niel's and my proposal 
> is that different than yours.  I.e.,  the bottom of stack 
> entry in the server MPLS stack would indicate that the client 
> payload is MPLS, and the client payload would start with its 
> own MPLS stack followed by a PW header. 
> 
> Thanks,
> 
> John 
> 
> > The industry standard method of carrying an Ethernet frame over an 
> > MPLS LSP is to use a pseudowire. I would be a great dis-service to 
> > abandon this widely deployed design that has been designed 
> into a lot 
> > of silicon.
> > 
> > The issue that I thought that we were discussing on this 
> list is how 
> > best to carry IP/MPLS over MPLS-TP. In this case we have 
> the problem 
> > of how a router forms an adjacency, transports its control 
> traffic in 
> > an IP/MPLS context and it's various OAM traffic. A lot of 
> this traffic 
> > is encapsulated at the datalink.
> > 
> > There are two issue that seem to have been conflated and this is 
> > confusing the situation:
> > 
> > (2) to a separate WG discussion. Even if we think the 
> answer to (2) is 
> > that we do not need MS-PW now, I would note that we also 
> thought that 
> > when we started the PW project.
> > 
> consistency 
> > in the design and the following structure has those features:
> > 
> > 0                   1                   2                   3
> > L2 types that are needed. If we move to any other format we need to 
> > figure out whether the length will ever be needed.
> > 
> > adjacency operates differently (greater complexity) over a mp2mp 
> > connection (i.e. classic Ethernet), and this would make it 
> unambiguous 
> > that a p2p adjacency is being formed here.
> > 
> > The Sequence number is useful for verifying delivery sequence and 
> > (absence of) packet loss. Verison were interested in retaining the 
> > FRG. OAM packets are identical to data packets over the LSP.
> > 
> > Stewart
> > 
> > 
> > 
> > 
> > 
> > 
> clarifying my 
> encapsulated at the 
> > first MEP by pushing a lable into mpls stack. if according to your 
> > solution. maybe ETH AC1 and ETH
> traffic type 
> > is the same .and both taffic will be transported by the 
> same MPLS-TP 
> > LSP. so the outside forward label is also the same. when 
> arriving at 
> > the sink MEP.
> indentify the 
> > 	> > > > > > 
> > contained in 
> > confidential

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 17 Feb 2009 10:20:20 -0500

All, I think that we need to distinguish between what must be defined in the context of a "complete" network and what must be specified for the MPLS-TP layer network that provides co-ps "transport service" in the context of a "complete" network.

I think the issue that Neil raise in his 3rd point is that if we have client server independence (as identified by Neil in point 1) then in the context of the MPLS-TP layer network what do we need to specify about the client or the server layer networks.

I suggest that for the client we only need to define the supported adaptations and the "transport service" offered by MPLS-TP.  i.e. definition of the PW layer should not be in scope for the MPLS-TP RFCs or Recommendations.  I see good rational for reuse of the PW mapping that are already defined and deployed.  We can debate if SG15 should develop Recommendations describing PWs, (single or multi segment) but that is a separate issue.  

For the server layer, as discussed on the lists we should only define the transport service that must be provided in order for the MPLS-TP layer to be able to guarantee the service that it is offering to its client. 

I hope that this approach (reduction of scope) will allow us to focus on getting MPLS-TP defined.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Tuesday, February 17, 2009 1:45 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperationbetweenIETFandITU-T on MPLS-TP

My understanding is that so far we were discussing to use the following layer technologies for those four layers:
1) ETH and optional MS-PW
2) Path LSP
3) Section LSP or ETH Section
4) 802.3, SDH, OTN.

If we remove the MS-PW from the set above, does this imply that the transport service layer is provided by an ETH (i.e. Ethernet VLAN) layer for all services? I.e. following the case that I have found in some of the european networks today.

Or, will the removal of the MS-PW imply that the p2p and p2mp services are supported by a new "Service LSP" layer?

The deployment of a Service LSP layer (instead of a MS-PW layer) will not change the packet formats as far as I can see.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: maandag 16 februari 2009 16:58
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperationbetweenIETFandITU-T on MPLS-TP

John is correct.  You to remember Liu that PWs only came about because of the way MPLS was originally specified.  For MPLS-TP to assume a  transport role then (i) the conditions which gave rise to the need for PWs in MPLS have to be removed and (ii) we have to treat all clients equally/transparently.  Furthermore, and of even greater importance, is the fact that the MS-PWs that are now being considered in MPLS cannot have any place in MPLS-TP.  This is because a MS-PW represents a co-ps mode layer network above MPLS, and clearly a transport network such as MPLS-TP should
never require unnecessary layer networks to be created above it.   

regards, Neil

> > > MPLS-TP OAM functions must be client layer network agnostic and 
> > > appear as identical as possible to MPLS-TP traffic units at the 
> > > MPLS-TP layer network under consideration.  From technical 
> > > considerations a TTL field is not required in any co-ps/co-cs mode 
> > > layer network (the CP/MP can ensure there are no loops before 
> > > establishing a LSP) and thus the existing MPLS TTL field could be 
> > > used for other important functions such as an OAM indicate 
> > > function (this would only require 1 bit, noting that the TTL field 
> > > consumes 25% of a scarce resource in the MPLS-TP header).
> > > However, if this is deemed not possible (for whatever reason, but 
> > > which clearly cannot be technical) then some other way must be 
> > > found to ensure this.
> > > 
> > > 
> > > 3                 PWs and MPLS-TP:
> > > 
> > > We must be very clear that PWs are a consequence of the way MPLS 
> > > was originally specified;  in particular the different way in 
> > > which IP and all other clients were handled, and the consequences 
> > > of LDP merging and ECMP load spreading.  For MPLS-TP to take on a 
> > > transport role however, its design must be changed such that it 
> > > treats all clients equally (ie point
> > > We should also note that when PWs were only a 1-hop entity in MPLS 
> > > they could be considered as an adaptation-like function.
> > > MS-PWs) then they underwent a very significant change in behaviour 
> > > and became a co-ps layer network in their own right above MPLS.
> > > 
> > > Now given MPLS-TP is supposed to be a transport network, then it 
> > > would make no sense whatsoever for it to create a further co-ps 
> > > mode (PW) layer network above it.  Indeed, this would be 
> > > completely at odds with the requirement for a generic transparent 
> > > client/server relationship noted in 1 above.
> > > 
> > > From purely technical considerations it is therefore quite clear 
> > > that MPLS-TP has no need to have PWs.  However, they could be kept 
> > > (at least in name) providing they reverted back to their original 
> > > 1-hop adaptation-like functionality and did not generate a co-ps 
> > > layer network above MPLS-TP.
> > > 
> > > regards, Neil
> > > 
> > > 
> > 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: "Drake, John E" <[email-masked]>
Date: Tue, 17 Feb 2009 07:47:23 -0800

Stewart,

In my e-mails to Liu and you, I was describing how an MPLS PW would be carried as a client of an MPLS TP server network in our proposal.  This is not to imply that an MPLS PW is required to transport non-IP payloads in MPLS TP, but rather that this is allowed in our proposal.

Thanks,

John
> Sent: Tuesday, February 17, 2009 6:07 AM
> To: Drake, John E; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp]答复: RE: [T15Q12] FW: Liaison on the 
> I just read your e-mail more closely and what you seem to be 
> proposing is to have a single MPLS stack, containing both 
> server and client defined labels.  From what I have heard, 
> this is definitely a non-starter.
> 
> However, as I indicated in my other e-mails, in Neil's and my 
> proposal, the server stack would end with an MPLS PID, 
> indicating that the client payload is MPLS, and then the 
> client payload would look nearly as you described:  an MPLS 
> header followed by a PW header and the payload.
> 
> Thanks,
> 
> John
> > Please see my e-mail to Liu.  For the case of a PW transported over 
> > MPLS, I don't think Niel's and my proposal is that different than 
> > yours.  I.e.,  the bottom of stack entry in the server MPLS stack 
> > would indicate that the client payload is MPLS, and the 
> client payload 
> > would start with its own MPLS stack followed by a PW header.
> > 
> > Thanks,
> > 
> > John
> > 
> > > 	John is correct.  You to remember Liu that PWs only came about 
> > > because of the way MPLS was originally specified.
> > > For MPLS-TP to assume a  transport role then (i) the conditions 
> removed and 
> > > (ii) we have to treat all clients equally/transparently.  
> > > Furthermore, and of even greater importance, is the fact that the 
> > > MS-PWs that are now being considered in MPLS cannot have 
> any place 
> > > in MPLS-TP.  This is because a MS-PW represents a co-ps 
> mode layer 
> > > network above MPLS, and clearly a transport network such 
> as MPLS-TP 
> > > should
> > > 	> > We would add the PPP PID of the associated client 
> payload as 
> > > the
> > > 	> > bottom-most label, with the 'bottom of stack' bit 
> set, in the 
> > > server
> > > 	> > If a control plane is used to establish the server 
> LSP, there 
> > > would
> > > 	> > LSP will understand the significance of the 
> botom-most label in 
> > > this
> > > 	> > context.
> > > 	> > 
> > > 	> >> > > > > 
> > > 	> > > as we develop the standards for MPLS-TP.  In no 
> particular 
> > > order:
> > > 	> > > 
> > > 	> > > 
> > > 	> > > > believe that the following items need to be 
> agreed on and 
> > > or
> 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.
> confidential and

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 17 Feb 2009 08:02:44 -0800

Malcom,

I agree that MPLS PWs are a reasonable payload for MPLS TP but they are not part of the definition of MPLS TP.

Thanks,

John
> Sent: Tuesday, February 17, 2009 7:20 AM
> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on 
> thecooperationbetweenIETFandITU-T on MPLS-TP
> 
> All, I think that we need to distinguish between what must be 
> defined in the context of a "complete" network and what must 
> be specified for the MPLS-TP layer network that provides 
> co-ps "transport service" in the context of a "complete" network.
> 
> I think the issue that Neil raise in his 3rd point is that if 
> we have client server independence (as identified by Neil in 
> point 1) then in the context of the MPLS-TP layer network 
> what do we need to specify about the client or the server 
> layer networks.
> 
> I suggest that for the client we only need to define the 
> supported adaptations and the "transport service" offered by 
> MPLS-TP.  i.e. definition of the PW layer should not be in 
> scope for the MPLS-TP RFCs or Recommendations.  I see good 
> rational for reuse of the PW mapping that are already defined 
> and deployed.  We can debate if SG15 should develop 
> Recommendations describing PWs, (single or multi segment) but 
> that is a separate issue.  
> 
> For the server layer, as discussed on the lists we should 
> only define the transport service that must be provided in 
> order for the MPLS-TP layer to be able to guarantee the 
> service that it is offering to its client. 
> 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> My understanding is that so far we were discussing to use the 
> following layer technologies for those four layers:
> If we remove the MS-PW from the set above, does this imply 
> that the transport service layer is provided by an ETH (i.e. 
> Ethernet VLAN) layer for all services? I.e. following the 
> case that I have found in some of the european networks today.
> 
> Or, will the removal of the MS-PW imply that the p2p and p2mp 
> services are supported by a new "Service LSP" layer?
> 
> The deployment of a Service LSP layer (instead of a MS-PW 
> layer) will not change the packet formats as far as I can see.
> 
> Regards,
> Maarten
> 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> > > MPLS stack.  (We would also define a new PPP PID value 
> for dataplane 
> > > OAM
> > > payloads.)
> > > 
> > >   of a particular network layer, or the label must be one 
> which is 
> > > used
> > >   ONLY for a specified set of network layer protocols, 
> where packets 
> > > of
> above are

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Feb 2009 16:14:08 +0000

I disagree. MPLS-TP at least needs to call up PWs as the required
adaptation mechanism.

Stewart

Drake, John E wrote:
>>>> different traffic that are both the same type i.e ETH, 
>>>>         
>> needing to be 
>>     
>>>> two traffic must be encapsulated by the same PW label and 
>>>>         
>> maybe be 
>>     
>>>> Neil and I have been discussing how to address the 
>>>>         
>> requirements he 
>>     
>>>> bottom-most label, with the 'bottom of stack' bit set, in 
>>>>         
>> the server 
>>     
>>>> So, the 'bottom of stack' entry in the server MPLS stack
>>>>         
>>> would look as
>>>       
>>>> follows:
>>>>
>>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
>>>>         
>> 7 8 9 0 1
>>     
>>>>    
>>>>         
>>>>    |0 0 0 0|       PPP client PID          |0 0 0|1|0 0 0 
>>>>         
>> 0 0 0 0 1|
>>     
>>>>    
>>>>         
>>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
>>>>         
>> 7 8 9 0 1
>>     
>>>>    
>>>>         
>>>>    |0 0 0 0|       PPP OAM (TBD)           |0 0 0|1|0 0 0 
>>>>         
>> 0 0 0 0 1|
>>     
>>>>    
>>>>         
>>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 
>>>>         
>> 7 8 9 0 1
>>     
>>>>    
>>>>         
>>>>    |0 0 0 0|       GAL                     |0 0 0|1|0 0 0 
>>>>         
>> 0 0 0 0 1|
>>     
>>>>    
>>>>         
>>>> The server MPLS stack entries with S=0 have normal traffic
>>>>         
>>> forwarding
>>>       
>>>> semantics (including the normal use of EXP and TTL 
>>>>         
>> fields) for label 
>>     
>>>> values > 15.
>>>>
>>>> If a control plane is used to establish the server LSP, 
>>>>         
>> there would 
>>     
>>>> presumably be a capabilities exchange to ensure that both
>>>>         
>>> ends of that
>>>       
>>>> LSP will understand the significance of the botom-most 
>>>>         
>> label in this 
>>     
>>>> context.
>>>>
>>>> We think that this proposal is consistent with RFC 3032,
>>>>         
>>> which states:
>>>       
>>>>   When the last label is popped from a packet's label stack
>>>>         
>>> (resulting
>>>       
>>>>   based on the packet's network layer header.  The LSR
>>>>         
>>> which pops the
>>>       
>>>>   packet's network layer protocol.  However, the label
>>>>         
>>> stack does not
>>>       
>>>>   must be inferable from the value of the label which is 
>>>>         
>> popped from
>>     
>>>>   packet, either the label must be one which is used ONLY
>>>>         
>>> for packets
>>>       
>>>>   the specified network layers can be distinguished by 
>>>>         
>> inspection of
>>     
>>>>   replaced by another label value during a packet's 
>>>>         
>> transit, the new
>>     
>>>>> To: [email-masked]; [email-masked]; 
>>>>>           
>> [email-masked]
>>     
>>>>> between different instances of MPLS-TP layer networks 
>>>>>           
>> owned by the 
>>     
>>>>> could be achieved is by the use of special label for 
>>>>>           
>> this purpose 
>>     
>>>>> only.  However, if we want a more general client/server 
>>>>>           
>> solution 
>>     
>>>>> implement a generic adaptation function that provides a 
>>>>>           
>> client PID 
>>     
>>>>> capability.
>>>>>
>>>>> Aside=> Current co-cs generation transport networks 
>>>>>           
>> (based on PDH, 
>>     
>>>>> SDH and OTN) use GFP as the common/generic adaptation 
>>>>>           
>> function for 
>>     
>>>>> already identifies important SAN clients, and it also 
>>>>>           
>> has values 
>>     
>>>>> networks is important for network operators, then the 
>>>>>           
>> use of GFP 
>>     
>>>>> considerations a TTL field is not required in any 
>>>>>           
>> co-ps/co-cs mode 
>>     
>>>>> establishing a LSP) and thus the existing MPLS TTL 
>>>>>           
>> field could be 
>>     
>>>>> function (this would only require 1 bit, noting that 
>>>>>           
>> the TTL field 
>>     
>>>>> However, if this is deemed not possible (for whatever 
>>>>>           
>> reason, but 
>>     
>>>>> We must be very clear that PWs are a consequence of the 
>>>>>           
>> way MPLS 
>>     
>>>>> which IP and all other clients were handled, and the 
>>>>>           
>> consequences 
>>     
>>>>> of LDP merging and ECMP load spreading.  For MPLS-TP to 
>>>>>           
>> take on a 
>>     
>>>>> We should also note that when PWs were only a 1-hop 
>>>>>           
>> entity in MPLS 
>>     
>>>>> MS-PWs) then they underwent a very significant change 
>>>>>           
>> in behaviour 
>>     
>>>>> Now given MPLS-TP is supposed to be a transport 
>>>>>           
>> network, then it 
>>     
>>>>> completely at odds with the requirement for a generic 
>>>>>           
>> transparent 
>>     
>>>>> From purely technical considerations it is therefore 
>>>>>           
>> quite clear 
>>     
>>>>> that MPLS-TP has no need to have PWs.  However, they 
>>>>>           
>> could be kept 
>>     
>>>>> (at least in name) providing they reverted back to 
>>>>>           
>> their original 
>>     
>>>>> 1-hop adaptation-like functionality and did not 
>>>>>           
>> generate a co-ps 
>>     
>>>>>> Subject: [T15Q12] FW: Liaison on the cooperation
>>>>>>             
>>> between IETF and
>>>       
>>>>>> ITU-T on MPLS-TP
>>>>>>
>>>>>> "However, in order to foster communication between the two
>>>>>>             
>>>>> bodies, we
>>>>>           
>>>>>> 1.                 First, we need to understand when we 
>>>>>>             
>>>> have received all the
>>>>         
>>>>>> far into the future this will have an impact on the
>>>>>>             
>>>> target date for
>>>>         
>>>>>> the MPLS-TP RFCs.
>>>>>> 2.                 Second, we need to have a clear 
>>>>>>             
>>>> understanding of which documents
>>>>         
>>>>>> we need to have approved as RFCs for the SG15 meeting in
>>>>>>             
>>>>> October 2009.
>>>>>           
>>>>>> 3.                 Third, we see a need to further define 
>>>>>>             
>>>> the process, regarding
>>>>         
>>>>>> ITU-T review of our Internet-Drafts as well as IETF
>>>>>>             
>>>> review of ITU-T
>>>>         
>>>>>> Draft Recommendations before they are published as RFCs
>>>>>>             
>>>> or Approved
>>>>         
>>>>>> Recommendations.
>>>>>> 4.                 Fourth, we see that there is a need to 
>>>>>>             
>>>> coordinate between our
>>>>         
>>>>>> two organizations so that T-MPLS related contributions to
>>>>>>             
>>>> the ITU-T
>>>>         
>>>>>> 5.                 Finally, we need the OAM deployment 
>>>>>>             
>>>> scenarios that we were
>>>>         
>>>>>> With respect to point 1:  I believe that the ITU has
>>>>>>             
>>>>> identified all of
>>>>>           
>>>>>> the current requirements and we are in the process of 
>>>>>>             
>> providing 
>>     
>>>>>> To respond to point 2, I request the editors of the
>>>>>>             
>>>> revised MPLS-TP
>>>>         
>>>>>> Recommendations to identify which drafts they plan to make
>>>>>>             
>>>>> normative
>>>>>           
>>>>>> references to.
>>>>>>
>>>>>> With respect to point 5:  I request that those interested
>>>>>>             
>>>>> in the work
>>>>>           
>>>>>> provide input as soon as possible so that we can
>>>>>>             
>>> deliver this as
>>>       
>>>>>> promised.
>>>>>>
>>>>>> To: Yoichi Maeda; Greg Jones; Ghani Abbas; Huub Van
>>>>>>             
>>>>> Helvoort; Betts,
>>>>>           
>>>>>> Malcolm (CAR:X632); Hing-Kam Lam; [email-masked];
>>>>>>             
>>>>> [email-masked]
>>>>>           
>>>>>> Cc: David Ward; Ross Callon; Mark Townsley; Jari Arkko;
>>>>>>             
>>>>> Scott Bradner;
>>>>>           
>>>>>> Subject: Liaison on the cooperation between IETF and ITU-T
>>>>>>             
>>>>> on MPLS-TP
>>>>>           
>>>>>> All,
>>>>>>
>>>>>> please find a liaison on the cooperation between IETF and
>>>>>>             
>>>> ITU-T on
>>>>         
>>>>>> MPLS-TP included.
>>>>>>
>>>>>> /Loa
>>>>>> --
>>>>>>
>>>>>>
>>>>>> Loa Andersson
>>>>>>
>>>> obligated to maintain secrecy and are not permitted to 
>>>>         
>> disclose the 
>>     
>>>> intended solely for the use of the individual or entity 
>>>>         
>> to whom they 
>>     
>>>> This message has been scanned for viruses and Spam by ZTE 
>>>>         
>> Anti-Spam 
>>     
>>>> system.
>>>>
>>>>

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 17 Feb 2009 08:21:28 -0800

*required*?  I would think MPLS TP should be payload agnostic. 

> Sent: Tuesday, February 17, 2009 8:14 AM
> To: Drake, John E
> Cc: Malcolm Betts; [email-masked]; [email-masked]
> thecooperationbetweenIETFandITU-Ton MPLS-TP
> 
> I disagree. MPLS-TP at least needs to call up PWs as the 
> required adaptation mechanism.
> 
> Stewart
> 
> 
> 
> Drake, John E wrote:
> > Malcom,
> >
> > I agree that MPLS PWs are a reasonable payload for MPLS TP 
> but they are not part of the definition of MPLS TP.
> >
> > Thanks,
> >
> > John
> >   
> >> All, I think that we need to distinguish between what must 
> be defined 
> >> in the context of a "complete" network and what must be 
> specified for 
> >> the MPLS-TP layer network that provides co-ps "transport 
> service" in 
> >> the context of a "complete" network.
> >>
> >> I think the issue that Neil raise in his 3rd point is that 
> if we have 
> >> client server independence (as identified by Neil in point 
> 1) then in 
> >> the context of the MPLS-TP layer network what do we need 
> to specify 
> >> about the client or the server layer networks.
> >>
> >> I suggest that for the client we only need to define the supported 
> >> adaptations and the "transport service" offered by MPLS-TP.  i.e. 
> >> definition of the PW layer should not be in scope for the MPLS-TP 
> >> RFCs or Recommendations.  I see good rational for reuse of the PW 
> >> mapping that are already defined and deployed.  We can 
> debate if SG15 
> >> should develop Recommendations describing PWs, (single or multi 
> >> segment) but that is a separate issue.
> >>
> only define 
> >> the transport service that must be provided in order for 
> the MPLS-TP 
> >> layer to be able to guarantee the service that it is 
> offering to its 
> >> client.
> >>
> >> I hope that this approach (reduction of scope) will allow 
> us to focus 
> >> on getting MPLS-TP defined.
> >>
> >> Malcolm Betts
> >> Nortel Networks
> that the 
> >> transport service layer is provided by an ETH (i.e.
> case that I 
> >> have found in some of the european networks today.
> >>
> >> because of the way MPLS was originally specified.  For MPLS-TP to 
> >> assume a  transport role then (i) the conditions which 
> gave rise to 
> >> the need for PWs in MPLS have to be removed and (ii) we 
> have to treat 
> >> all clients equally/transparently.  Furthermore, and of 
> even greater 
> considered 
> >> in MPLS cannot have any place in MPLS-TP.  This is because a MS-PW 
> >> represents a co-ps mode layer network above MPLS, and clearly a 
> >> transport network such as MPLS-TP should
> >>>>                 I.e., the GAL (label 13) is specifically 
> reserved 
> >>>> for carrying

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 17 Feb 2009 11:48:30 -0500

Agree, MPLS-TP should be payload agnostic.  We should define/identify the set of supported client adaptations and the PW adaptation should be included.

My point is that we do not need to define/specify the PW architecture. 

Malcolm Betts
Nortel Networks

---

From: Loa Andersson <[email-masked]>
Date: Tue, 17 Feb 2009 17:49:45 +0100

All,

this discussion has gone way beyond what is in the subject line - could
you please change subject line to reflect the ongoing discussion!

/Loa

-- 

Loa Andersson

                                      email:  [email-masked]
                                              [email-masked]
                                              [email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 17 Feb 2009 20:10:37 +0100

John,

I disagree with your assertion that the transport service layer is not part
of the MPLS-TP defintion. Without transport service layer MPLS-TP is an
incomplete solution.

As far as I understand MPLS-TP has the following two options for its
transport service layer:
1) Ethernet VLAN (ETH) for all services
2) Ethernet VLAN (ETH) for rmp and mp2mp services plus MPLS-TP MS-PW for p2p
and p2mp services.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Drake, John E
Sent: dinsdag 17 februari 2009 17:03
To: Malcolm Betts; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [T15Q12] FW: Liaison
onthecooperationbetweenIETFandITU-T on MPLS-TP

Malcom,

I agree that MPLS PWs are a reasonable payload for MPLS TP but they are not
part of the definition of MPLS TP.

Thanks,

John
> All, I think that we need to distinguish between what must be defined 
> in the context of a "complete" network and what must be specified for 
> the MPLS-TP layer network that provides co-ps "transport service" in 
> I think the issue that Neil raise in his 3rd point is that if we have 
> client server independence (as identified by Neil in point 1) then in 
> the context of the MPLS-TP layer network what do we need to specify 
> definition of the PW layer should not be in scope for the MPLS-TP RFCs 
> or Recommendations.  I see good rational for reuse of the PW mapping 
> that are already defined and deployed.  We can debate if SG15 should 
> develop Recommendations describing PWs, (single or multi segment) but 
> For the server layer, as discussed on the lists we should only define 
> the transport service that must be provided in order for the MPLS-TP 
> layer to be able to guarantee the service that it is offering to its 
> client.
> 
> Ethernet VLAN) layer for all services? I.e. following the case that I 
> Or, will the removal of the MS-PW imply that the p2p and p2mp services 
> are supported by a new "Service LSP" layer?
> 
> equally/transparently.  Furthermore, and of even greater importance, 
> is the fact that the MS-PWs that are now being considered in MPLS 
> cannot have any place in MPLS-TP.  This is because a MS-PW represents 
> a co-ps mode layer network above MPLS, and clearly a transport network 
> such as MPLS-TP should

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 17 Feb 2009 20:12:01 +0100

Malcolm,

We do need to define the architecture of the MPLS-TP transport service
layer.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Malcolm Betts
Sent: dinsdag 17 februari 2009 17:49
To: Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [T15Q12] FW: Liaison
onthecooperationbetweenIETFandITU-Ton MPLS-TP

Agree, MPLS-TP should be payload agnostic.  We should define/identify the
set of supported client adaptations and the PW adaptation should be
included.

Malcolm Betts
Nortel Networks

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 17 Feb 2009 11:18:26 -0800

Maarten,

I haven't seen anyone other than you describe Ethernet VLAN as being part of MPLS TP, but I think you are making my point, viz, MPLS TP should be client agnostic.  I.e., you can run Ethernet VLAN on top of your MPLS TP network, and (many) others may choose MPLS PW to provide Ethernet VLAN services.  

MPLS TP shouldn't care.

Thanks,

John
> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Tuesday, February 17, 2009 11:11 AM
> To: Drake, John E; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp] [T15Q12] FW: Liaison 
> I disagree with your assertion that the transport service 
> layer is not part of the MPLS-TP defintion. Without transport 
> service layer MPLS-TP is an incomplete solution.
> 
> As far as I understand MPLS-TP has the following two options 
> for its transport service layer:
> 2) Ethernet VLAN (ETH) for rmp and mp2mp services plus 
> MPLS-TP MS-PW for p2p and p2mp services.
> 
> Regards,
> Maarten
> 
> about because 
> importance, 
> payload as the 
> > > >                 I.e., the GAL (label 13) is 
> specifically reserved 
> > > > for carrying
> essential

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 17 Feb 2009 15:41:16 -0500

Maarten, if we have client/server independence with MPLS-TP why is it necessary to burden MPLS-TP with the task of defining its client layer network(s). 

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2009 2:12 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW: LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP

Malcolm,

We do need to define the architecture of the MPLS-TP transport service layer.

As far as I understand MPLS-TP has the following two options for its transport service layer:
1) Ethernet VLAN (ETH) for all services
2) Ethernet VLAN (ETH) for rmp and mp2mp services plus MPLS-TP MS-PW for p2p and p2mp services.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm Betts
Sent: dinsdag 17 februari 2009 17:49
To: Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [T15Q12] FW: Liaison onthecooperationbetweenIETFandITU-Ton MPLS-TP

Malcolm Betts
Nortel Networks

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 17 Feb 2009 23:53:30 +0100

John,

MPLS-TP must provide a complete packet transport network solution. As such
it must support the transport service layer. Without support for such layer
MPLS-TP can not support any service at all.

MPLS-TP can use the MPLS PW technolgy to support p2p and p2mp service
connectivity types; alternatively a number of operators are using the ETH
technology for those services today. But as MPLS technology does not support
mp2mp and rmp service connectivity types, MPLS-TP must deploy the ETH
technology as transport service layer technology for those services.

It is extremely important to define a complete solution; not doing so will
result in suboptimal solutions and increased complexities of the MPLS-TP
equipment. It will also result in more complex network management.
But it might be that it is your objective to create more complex equipment
and network management.

Regards,
Maarten

-----Original Message-----
From: Drake, John E [mailto:[email-masked]] 
Sent: dinsdag 17 februari 2009 20:18
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW: Liaison

Maarten,

I haven't seen anyone other than you describe Ethernet VLAN as being part of
MPLS TP, but I think you are making my point, viz, MPLS TP should be client
agnostic.  I.e., you can run Ethernet VLAN on top of your MPLS TP network,
and (many) others may choose MPLS PW to provide Ethernet VLAN services.  

MPLS TP shouldn't care.

Thanks,

John
> I disagree with your assertion that the transport service layer is not 
> part of the MPLS-TP defintion. Without transport service layer MPLS-TP 
> is an incomplete solution.
> 
> I agree that MPLS PWs are a reasonable payload for MPLS TP but they 
> are not part of the definition of MPLS TP.
> 
> Thanks,
> 
> John

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Feb 2009 00:44:38 +0100

Malcolm,

If we define MPLS-TP as a complete solution, then we will be able to
minimize complexity of the MPLS-TP equipment and we will be able to minimize
the complexity of the network management of the Ethernet and MPLS-TP based
packet transport network. What we need is to maximize commonality.

Because the MPLS technology (LSP, PW) does not support mp2mp and rmp
transport service paths, it is required that MPLS-TP equipment and MPLS-TP
network management supports an ETH layer. The ETH layer requires that Y.1731
OAM is supported and that Y.1731 MEG Level based TCM is supported in MPLS-TP
equipment interface ports. If those interface ports support MPLS-TP PW MEPs
and MIPs on those interface ports, then the complexity of those interface
ports is minimized when MPLS-TP PW OAM reuses the Y.1731 OAM PDU formats as
much as possible.

For the carrier-carrier case, it is typical to carry the transport path
layer path signal of carrier A as a transport service layer path signal
thorugh the network of carrier B. This implies that the MPLS-TP transport
service layer switching equipment will see the ETH, MPLS-TP PW and MPLS-TP
LSP layers are client of the MPLS-TP LSP (i.e. transport path) layer. If the
MPLS-TP LSP OAM also reuses the Y.1731 OAM PDU formats as much as possible,
we minimize the complexity of MPLS-TP interface ports. 

Worst case would be when the OAM PDUs and TCM level identification for ETH,
MPLS-TP PW and MPLS-TP LSP are different. This would maximize the complexity
of those interface ports and of its network management.

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]] 
Sent: dinsdag 17 februari 2009 21:41
To: Maarten Vissers; Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:
LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP

Maarten, if we have client/server independence with MPLS-TP why is it
necessary to burden MPLS-TP with the task of defining its client layer
network(s). 

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 2:12 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:
LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP

Malcolm,

Regards,
Maarten

-----Original Message-----

Malcolm Betts
Nortel Networks

---

From: [email-masked]
Date: Wed, 18 Feb 2009 14:46:51 +0800

all 
   firstly thank all for replying to my email and describing your 
solutions. according to what you said, here I make a brief conlusion for 
the solution, is my understanding true? 
   1 IP/MPLS traffic packet over MPLS-TP network, the encapsulation packet 
structure is as the following:
 
  2 LSP OAM packet structue is as the following:
 
  3 MCC/SCC packet struture is as the following:

   thanks 
    liu

2009-02-17 23:47

收件人
"Drake, John E" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
抄送
<[email-masked]>
主题
RE: [mpls-tp]答复: RE:  [T15Q12] FW: Liaison on the cooperation 
betweenIETFandITU-T on MPLS-TP

Stewart,

In my e-mails to Liu and you, I was describing how an MPLS PW would be 
carried as a client of an MPLS TP server network in our proposal.  This is 
not to imply that an MPLS PW is required to transport non-IP payloads in 
MPLS TP, but rather that this is allowed in our proposal.

Thanks,

John
> > > <[email-masked]> <mailto:[email-masked]>
about 
> > >            PS - I am away on leave for a week now so will not be 
able to 
> > >            > > requirements he lists
> > >            > > in his e-mail, below, and we would like to propose 
the 
> > >            > > MPLS stack.  (We would also define a new PPP PID 
value for 
> > >            > > dataplane OAM
> > >            > >                                              EXP  S   
TTL
> > >            > >                                              EXP  S  
TTL
> > >            > >                                              EXP  S  
TTL 
> > >            > >                 I.e., the GAL (label 13) is 
specifically 
> > >            > > reserved for carrying
> > >            > > CP/MP protocols                  between logically 
adjacent 
> > >            > > MPLS-TP layer network
> > >            > > associated with the DP and is never propagated beyond 
2 
> > > logically
> > >            > > adjacent                  MPLS-TP layer network 
nodes.  The 
> > >            > > GAL is always
> > >            > >   protocol.  This means that the identity of the 
network 
> > >            > > layer protocol
> > >            > > which is used

> > >            > > > generic adaptation function that provides a client 
PID 
> network, then
> > >            > > > > All, attached is a liaison statement from the 
IETF MEAD 
> > > team.
meeting in
> > >            > > views expressed in this message are those of the 
individual 
> > >            > > Anti-Spam system.

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 18 Feb 2009 08:34:10 +0100

Malcolm,

When I look into the MEF activities I notice that our colleagues are
developing an E-NNI specification in which the transport service layer is an
ETH layer, in which the section layer is also an ETH layer and in which the
physical media layer is the ETY layer.

Last month MEF has initiated the work on an E-NNI which supports a
carrier-carrier application, in which a transport path layer signal will be
crossing the carrier-carrier network.

With the work on E-NNI progressing in the direction of an Ethernet based
E-NNI, it suggests to me that the operators involved in this work have
networks with an ETH based transport service layer which supports p2p, p2mp,
rmp and mp2mp services. A MPLS-TP network that deploys a MPLS-TP MS-PW based
transport service layer for p2p and p2mp services will have to translate its
MS-PW characteristic information into equivalent ETH characteristic
information in order to cross this E-NNI.

Such translation is not necessary when the MPLS-TP network deploy an ETH
layer as its transport service layer. The "PW" would in this case be a SS-PW
and this SS-PW represents an ETH link connection supported by an MPLS-TP
LSP. Now there is no need to define any MPLS-TP PW OAM, as the PW is not
becoming a layer network.

If we would decide to use an ETH layer as the only transport service layer
technology in MPLS-TP, then we need to develop the mapping of ATM, FR, HDLC,
PPP, etc into Ethernet. For commonality with today's mappings (e.g. ATM into
LSP using PWE3 encapsulation), I have proposed to put an ethernet header
with TYPE/SA/DA fields between the CW and PW label stack entry header.

This approach also resolves the protocol type issue, as the TYPE field will
carry an EtherType value that uniquely identifies the client signal. It
furthermore prevents that we need to develop an ETH to MPLS-TP MS-PW
interworking function. The transport service layer in all packet transport
network technologies will now be the ETH layer.

In the figure below I have tried to illustrate in the top part the current
situation in MPLS in which ATM, TDM, FR, ETH, .. p2p services are directly
supported by the MPLS LSP. PWE3 encapsulation of those p2p service clients
is combined with PW labelling. In the bottom part of the figure I have
illustrated that it is possible to separate the PWE3 encapsulation processes
from the PW labelling process and add an ETH based transport service layer
between these two sets of processes.

If we follow this approach, then we only need to develop MPLS-TP LSP OAM and
protection switching and we need to get EtherType values for the PWE3
encapsulated clients. We already have the ETH OAM and protection switching
available and can simply reuse this in the MPLS-TP UNI-N, I-NNI and E-NNI
ports. This reduced work load will significantly reduce the time we need to
complete the MPLS-TP specifications.

Regards,
Maarten

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: woensdag 18 februari 2009 0:45
To: 'Malcolm Betts'; 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison
onthecooperationbetweenIETFandITU-Ton MPLS-TP]

Malcolm,

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 17 februari 2009 21:41
To: Maarten Vissers; Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 2:12 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm,

Regards,
Maarten

-----Original Message-----

Malcolm Betts
Nortel Networks

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 18 Feb 2009 05:12:01 -0800

Snipped

> But it might be that it is your objective to create more 
> complex equipment and network management.

JD:  No, as I understand it, that's your job.

> I haven't seen anyone other than you describe Ethernet VLAN 
> as being part of MPLS TP, but I think you are making my 
> point, viz, MPLS TP should be client agnostic.  I.e., you can 
> run Ethernet VLAN on top of your MPLS TP network, and (many) 
> others may choose MPLS PW to provide Ethernet VLAN services.  
> 
> MPLS TP shouldn't care.
> 
> Thanks,
> 
> John
> layer is not 
> supported 
> network layer 
> > > > > protocol

---

From: "Drake, John E" <[email-masked]>
Date: Wed, 18 Feb 2009 05:12:01 -0800

Snipped

---

From: "Malcolm Betts" <[email-masked]>
Date: Wed, 18 Feb 2009 16:27:54 -0500

Maarten, I think we have similar objectives but different approaches:

Note: I have added Q12 to the distribution since I think this topic is of direct interest.

>From my perspective we need to minimize complexity and allow the network to continue to evolve.  This evolution involves the addition of new (transport) technologies to existing networks.  This includes the network support infrastructure (e.g. OSS).  Once a "new" technology has been deployed it becomes a part of the "existing" network.  History has demonstrated that technologies have a finite life and will eventually be replaced.

With that in mind I am advocating the definition of a set of (client/server) independent layer networks (e.g. MPLS-TP).  This is the approach that has been taken for a number of years by SG 15 when defining the transport network.  The application of a common approach to the definition of these layer networks (based on G.805 and G.800) allows us to recognize the aspects that are common from the perspective of network operation.  It is this approach that has allowed the TMForum to develop and deploy the MTNM interface (for SDH, ATM, OTN, Ethernet, ASON....) over the last 10 years.  Good engineering practice indicates that we should, where appropriate, reuse the implementation of some functions in multiple technologies.  This reuse enable simplicity without incurring dependency.

The key to sustainable "simplicity" as the network evolves is the minimization of dependencies - i.e. retention of client server independence.  As has been stated many times it is much easier to achieve independence (and hence simplicity) with client/server relationships than with peer to peer relationships, particularly when the technologies offer different capabilities.

Some concerns that I have with your approach are:
 - I suspect that it will require a significant amount of time to reach full consensus on the technology selection to support the services that you mention.
 - Since we only consider specific technologies we will create dependencies that will impede deployment in existing networks and evolution to accommodate new technologies and services.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, February 17, 2009 6:45 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison onthecooperationbetweenIETFandITU-Ton MPLS-TP]

Malcolm,

If we define MPLS-TP as a complete solution, then we will be able to minimize complexity of the MPLS-TP equipment and we will be able to minimize the complexity of the network management of the Ethernet and MPLS-TP based packet transport network. What we need is to maximize commonality.

Because the MPLS technology (LSP, PW) does not support mp2mp and rmp transport service paths, it is required that MPLS-TP equipment and MPLS-TP network management supports an ETH layer. The ETH layer requires that Y.1731 OAM is supported and that Y.1731 MEG Level based TCM is supported in MPLS-TP equipment interface ports. If those interface ports support MPLS-TP PW MEPs and MIPs on those interface ports, then the complexity of those interface ports is minimized when MPLS-TP PW OAM reuses the Y.1731 OAM PDU formats as much as possible.

For the carrier-carrier case, it is typical to carry the transport path layer path signal of carrier A as a transport service layer path signal thorugh the network of carrier B. This implies that the MPLS-TP transport service layer switching equipment will see the ETH, MPLS-TP PW and MPLS-TP LSP layers are client of the MPLS-TP LSP (i.e. transport path) layer. If the MPLS-TP LSP OAM also reuses the Y.1731 OAM PDU formats as much as possible, we minimize the complexity of MPLS-TP interface ports. 

Worst case would be when the OAM PDUs and TCM level identification for ETH, MPLS-TP PW and MPLS-TP LSP are different. This would maximize the complexity of those interface ports and of its network management.

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 17 februari 2009 21:41
To: Maarten Vissers; Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 2:12 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm Betts
Sent: dinsdag 17 februari 2009 17:49
To: Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [T15Q12] FW: Liaison onthecooperationbetweenIETFandITU-Ton MPLS-TP

Malcolm Betts
Nortel Networks

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 18 Feb 2009 22:02:49 +0000

Malcolm,

Absolutely agree with what you write below.

Ben

> Maarten, I think we have similar objectives but different approaches:

Note: I
> have added Q12 to the distribution since I think this topic is of direct
> interest.

>From my perspective we need to minimize complexity and allow the
> network to continue to evolve.  This evolution involves the addition of new
> (transport) technologies to existing networks.  This includes the network
> support infrastructure (e.g. OSS).  Once a "new" technology has been deployed
> it becomes a part of the "existing" network.  History has demonstrated that
> technologies have a finite life and will eventually be replaced.

With that in
> mind I am advocating the definition of a set of (client/server) independent
> layer networks (e.g. MPLS-TP).  This is the approach that has been taken for a
> number of years by SG 15 when defining the transport network.  The application
> of a common approach to the definition of these layer networks (based on G.805
> and G.800) allows us to recognize the aspects that are common from the
> perspective of network operation.  It is this approach that has allowed the
> TMForum to develop and deploy the MTNM interface (for SDH, ATM, OTN, Ethernet,
> ASON....) over the last 10 years.  Good engineering practice indicates that we
> should, where appropriate, reuse the implementation of some functions in
> multiple technologies.  This reuse enable simplicity without incurring
> dependency.

The key to sustainable "simplicity" as the network evolves is the
> minimization of dependencies - i.e. retention of client server independence.
> As has been stated many times it is much easier to achieve independence (and
> hence simplicity) with client/server relationships than with peer to peer
> relationships, particularly when the technologies offer different
> capabilities.

 - I suspect
> that it will require a significant amount of time to reach full consensus on
> the technology selection to support the services that you mention.
 - Since we
> only consider specific technologies we will create dependencies that will
> impede deployment in existing networks and evolution to accommodate new
> technologies and services.

Malcolm Betts
Nortel Networks
Phone: +1 613 763
> 7860 (ESN 393)

-----Original Message-----
From:
> Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, February
> 17, 2009 6:45 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E';
> [email-masked]
Subject:
> MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison

Malcolm,

If we define MPLS-TP
> as a complete solution, then we will be able to minimize complexity of the
> MPLS-TP equipment and we will be able to minimize the complexity of the
> network management of the Ethernet and MPLS-TP based packet transport network.
> What we need is to maximize commonality.

Because the MPLS technology (LSP,
> PW) does not support mp2mp and rmp transport service paths, it is required
> that MPLS-TP equipment and MPLS-TP network management supports an ETH layer.
> The ETH layer requires that Y.1731 OAM is supported and that Y.1731 MEG Level
> based TCM is supported in MPLS-TP equipment interface ports. If those
> interface ports support MPLS-TP PW MEPs and MIPs on those interface ports,
> then the complexity of those interface ports is minimized when MPLS-TP PW OAM
> reuses the Y.1731 OAM PDU formats as much as possible.

For the
> carrier-carrier case, it is typical to carry the transport path layer path
> signal of carrier A as a transport service layer path signal thorugh the
> network of carrier B. This implies that the MPLS-TP transport service layer
> switching equipment will see the ETH, MPLS-TP PW and MPLS-TP LSP layers are
> client of the MPLS-TP LSP (i.e. transport path) layer. If the MPLS-TP LSP OAM
> also reuses the Y.1731 OAM PDU formats as much as possible, we minimize the
> complexity of MPLS-TP interface ports. 

Worst case would be when the OAM PDUs
> and TCM level identification for ETH, MPLS-TP PW and MPLS-TP LSP are
> different. This would maximize the complexity of those interface ports and of
> its network management.

Regards,
Maarten

-----Original Message-----
From:
> Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 17 februari 2009
> 21:41
Cc:
> [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12]
> FW:

Maarten, if we have
> client/server independence with MPLS-TP why is it necessary to burden MPLS-TP
> with the task of defining its client layer network(s). 

Malcolm Betts
Nortel
> Networks
email:
> [email-masked]

-----Original Message-----
From: Maarten Vissers
> [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 2:12
> PM
Cc:
> [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12]
> FW:

Malcolm,

We do need
> to define the architecture of the MPLS-TP transport service layer.

As far as
> I understand MPLS-TP has the following two options for its transport service
> layer:
1) Ethernet VLAN (ETH) for all services
2) Ethernet VLAN (ETH) for rmp
> and mp2mp services plus MPLS-TP MS-PW for p2p and p2mp
> services.

Regards,
Maarten

-----Original Message-----
From:
> [email-masked] [mailto:[email-masked]] On Behalf Of
> Malcolm Betts
To: Drake, John E;
> [email-masked]
Subject: Re:
> [mpls-tp] [T15Q12] FW: Liaison onthecooperationbetweenIETFandITU-Ton
> MPLS-TP

Agree, MPLS-TP should be payload agnostic.  We should define/identify
> the set of supported client adaptations and the PW adaptation should be
> included.

My point is that we do not need to define/specify the PW
> architecture. 

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN
> 393)

-----Original Message-----
From: Drake, John E
> [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 11:21
> AM
To: [email-masked]
Cc: Betts, Malcolm (CAR:X632);
> [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:
> Liaison on thecooperationbetweenIETFandITU-Ton MPLS-TP

*required*?  I would
> think MPLS TP should be payload agnostic. 

> >> Cc:
> >> RFCs
> that are already defined and deployed.  We can
> debate if SG15
> >> should
> >> As per MPLS-TP requirements draft, MPLS-TP will need to have the 
> >>
> following
> >> layers:
> >> 2) transport path
> layer
> >> My
> understanding is that so far we were discussing to use the 
> >> following
> >> [mailto:[email-masked]] On Behalf Of
>
> [email-masked]
> >> To:
> [email-masked]; [email-masked]
> >> Cc: [email-masked]
> >>
> able
> to respond
> >>> Cc:
> >>>> Subject: Re:
> [mpls-tp] [T15Q12] FW: Liaison on the cooperation 
> >>>> between IETFandITU-T
> on MPLS-TP
> >>>>
> >>>>
> >>>> John: 
> >>>> associated client payload as the
> bottom-most label,
> there are two
> >>>> two
> traffic must be encapsulated by the same PW label and
> >>>>         
> >>
> maybe be
> >>     
> >>>> <[email-masked]>, <[email-masked]>,
>
> <[email-masked]>
> >>>> 抄送
> >>>> 主题
> >>>>     0                   1
> 2                   3
> >>>> nodes.  (The S bit is
> essentially                  'don't 
> >>>> care' as it is the
> >>>> globally
> unique GAL that is the key identifier.)  The GAL     
> >>>>              is
> never
> >>>> adjacent                  MPLS-TP layer network nodes.  The
> 
> >>>> GAL is always
> >>>> immediately followed by the G-ACH
> and this 
> >>>> identifies the specific
> >>>> The
> server MPLS stack entries with S=0 have normal traffic
> >>>>         
> >>>
> forwarding
> >>>       
> >>>> LSP
> will understand the significance of the botom-most
> >>>>         
> >> label
> in this
> >>     
> >>>> context.
> >>>>
> >>>>   When the
> last label is popped from a packet's label stack
> >>>>         
> >>>
> (resulting
> >>>       
> >>>>   in the stack being emptied), further
> processing of the
> packet is
> RFC 3032               MPLS Label Stack Encoding            
> >>>> January
> 2001
> >>>>
> >>>>
> bottom of the stack, possibly along with the
> contents of the
> >>>>
> a particular network layer, or the label must be one
> >>>>         
> >>
> which is
> >>     
> >>>> used
> >>>>   value must
> also be one which meets the same criteria.  If these
> >>>>   conditions are
> not met, the LSR which pops the last label off a
> >>>>   packet will not be
> able to identify the packet's network layer
> >>>>   protocol."
> >>>>
> >>>>
> Thanks,
> >>>>
> >>>> Neil and John
> >>>>
> >>>>         
> >>>>>
> >>>>> same or
> different parties, ie MPLS-TPoverMPLS-TP.  One way this 
> >>>>> could be
> achieved is by the use of special label for
> >>>>>           
> >> this
> purpose
> >>     
> >>>>> (which I
> believe is the case) then we should consider how to 
> >>>>> implement a
> generic adaptation function that provides a
> >>>>>           
> >> client
> PID
> >>     
> >>>>> capability.
> >>>>>
> >>>>> Aside=> Current co-cs
> >>>>> MPLS-TP OAM functions
> must be client layer network agnostic and 
> >>>>> appear as identical as
> >>>>> found
> to ensure this.
> >>>>> they
> significant change
> >>>>> and
> became a co-ps layer network in their own right above MPLS.
> >>>>>
> >>>>>
> >> could be
> kept
> >>>>>> From:
> Malcolm Betts [mailto:[email-masked]]
> >>>>>> Sent: 12 February 2009
> 14:13
> >>>> have received all
> >>>>>> The IETF
> have requested a complete response by March 31st.
> >>>>>>
> >>>>>> With
> respect to point 1:  I believe that the ITU has
> >>>>>>             
> >>>>>
> identified all of
> >>>>>           
> >>>> revised
> >>>>>> For
> points 3 & 4 I will work with the SG 15 leadership team
> >>>>>>
> 
> >>>>> to develop
> >>>>>           
> >>>>>> a response.
> >>>>>>
>
> >>>>>>
> >>>>>> Malcolm Betts
> >>>>>> please
> find a liaison on the cooperation between IETF and
> >>>>>>             
>
> >>>> ITU-T on
> >>>>         
> >>>>>> MPLS-TP included.
> >>>>>>
> >>>>>>
> /Loa
> >>>>>> --
> >>>>>>
> >>>>>>
> >>>>>> Loa Andersson
> >>>>>>
> >>>>>> Sr
> >>>> ZTE
> Information Security Notice: The information
> >>>>         
> >> contained in
> this
> >>     
> >>>> 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.
> >>> mpls-tp mailing
> list
> > mpls-tp mailing
> list
mpls-tp
> mailing 
> list
[email-masked]

_________
> ______________________________________
mpls-tp mailing
> list
[email-masked]

---

From: [email-masked]
Date: Thu, 19 Feb 2009 11:18:20 +0800

John
  for the scenaio I described last time, why both ETH AC1 and ETH AC2 
firstly need to be encapsulted into MPLS packet, then this mpls packet 
will be encapsulated into MPLS-TP to transport in MPLS-TP network? why 
both ETH AC1 and ETH AC2 may be encapsulated by pw directly over MPLS-TP? 
why?
thanks 
liu

2009-02-17 21:48

收件人
<[email-masked]>, <[email-masked]>
抄送
<[email-masked]>
主题
RE: RE: [mpls-tp] [T15Q12] FW: Liaison on the cooperation 
betweenIETFandITU-T on MPLS-TP

Liu,

In the scenario you describe, the bottom of stack entry in the server MPLS 
stack would indicate that the client is MPLS.  The client payload would 
then contain its own MPLS stack and PW header, both set for either ETH 
ACH1 or ETH ACH2.

Thanks,

John
> > > January 2001
> particular order:

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 19 Feb 2009 10:39:22 -0800

Liu,

Because of the client and server layers are operating indepedently, so that each has its own MPLS label stack.

Thanks,

John
> Sent: Wednesday, February 18, 2009 7:18 PM
> To: Drake, John E
> Cc: [email-masked]
> Subject: 答复: RE: RE: [mpls-tp] [T15Q12] FW: Liaison on the 
>   for the scenaio I described last time, why both ETH AC1 and 
> ETH AC2 firstly need to be encapsulted into MPLS packet, then 
> this mpls packet will be encapsulated into MPLS-TP to 
> transport in MPLS-TP network? why both ETH AC1 and ETH AC2 
> may be encapsulated by pw directly over MPLS-TP? why? 
> thanks
> liu 
> 
> 
> 
> 2009-02-17 21:48 收件人
> In the scenario you describe, the bottom of stack entry in 
> the server MPLS stack would indicate that the client is MPLS. 
>  The client payload would then contain its own MPLS stack and 
> PW header, both set for either ETH ACH1 or ETH ACH2.
> 
> Thanks,
> 
> John

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 19 Feb 2009 22:28:07 +0100

Malcolm,

Transport networks are amongst others succesful due to the standardisation
of the NNI frame formats. Such standardisation is mandatory to allow
equipment from different vendors and/or operators to be interconnected
without problems. For MPLS-TP to be a succesful transport netowrk technology
we will have to agree what its I-NNI frame formats will be. The revised
version of G.8112 will specify these MPLS-TP I-NNI frame formats; i.e. will
define the MPLS-TP Transport Module (MTM-n). 

To progress the revision of G.8112 we must asap agree on the I-NNI frame
formats, and thus on the MPLS-TP layer stack.

A possible layer stack for such MTM-n is depicted below:

The MPLS-TP transport service layer is the ETH layer, the transport path
layer is the MPLS-TP LSP layer, the section layer is the ETH layer and the
physical media layer is the ETY layer. When carried over the OTN, the
1GE/10GE/40GE/100GE 802.3 ETY signal is carried in a timing transparent
manner in their ODU0/2e/3/4 (as per G.709 amendment 3) over an OTU.

MPLS-TP domains operating with the above layer stack will interoperate with
the Ethernet domains already present in the packet transport networks
without any problems (no need for any peer interworking). Interconnecting
two MPLS-TP domains via the MEF E-NNI will be possible without any problems
(no need for any peer interworking between MPLS-TP and MEF E-NNI).
 
The ATM, FR, TDM, HDLC, PPP, SDH clients deploy the PWE3 encapsulation, and
the Ethernet TYPE field will carry the Protocol Type identifier. The ETH
transport service layer signals will deploy the PWE3 encapsulation and PW
label stack entry header when transported over an MPLS-TP LSP.
 
Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: woensdag 18 februari 2009 22:28
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison

Note: I have added Q12 to the distribution since I think this topic is of
direct interest.

>From my perspective we need to minimize complexity and allow the network to
continue to evolve.  This evolution involves the addition of new (transport)
technologies to existing networks.  This includes the network support
infrastructure (e.g. OSS).  Once a "new" technology has been deployed it
becomes a part of the "existing" network.  History has demonstrated that
technologies have a finite life and will eventually be replaced.

With that in mind I am advocating the definition of a set of (client/server)
independent layer networks (e.g. MPLS-TP).  This is the approach that has
been taken for a number of years by SG 15 when defining the transport
network.  The application of a common approach to the definition of these
layer networks (based on G.805 and G.800) allows us to recognize the aspects
that are common from the perspective of network operation.  It is this
approach that has allowed the TMForum to develop and deploy the MTNM
interface (for SDH, ATM, OTN, Ethernet, ASON....) over the last 10 years.
Good engineering practice indicates that we should, where appropriate, reuse
the implementation of some functions in multiple technologies.  This reuse
enable simplicity without incurring dependency.

Some concerns that I have with your approach are:
 - I suspect that it will require a significant amount of time to reach full
consensus on the technology selection to support the services that you
mention.
 - Since we only consider specific technologies we will create dependencies
that will impede deployment in existing networks and evolution to
accommodate new technologies and services.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 6:45 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison

Malcolm,

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 17 februari 2009 21:41
To: Maarten Vissers; Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 2:12 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm,

Regards,
Maarten

-----Original Message-----

Malcolm Betts
Nortel Networks

---

From: "Malcolm Betts" <[email-masked]>
Date: Fri, 20 Feb 2009 09:16:19 -0500

Maarten, 
 
I agree that we need to define these layer stacks in the context of the
NNI defined G.8112.  Given client server independence I don't think that
this has any impact on the definition of the MPLS-TP layer network other
than the identification of its client and server layer networks.  I
suspect that the IETF participants will only have an interest in the
clients that are supported.
 
I therefore suggest that we agree the client list via the MEAD team list
then develop the details primarily by discussion on the Q10 email list.
As the proposals mature they should be communicated to the MEAD team for
review.
 
Loa, Dave, any concerns with my proposal?

Malcolm Betts 
Co chair MPLS-TP ad hoc 

Co chair hat off:

I thought we had agreed in the MEAD team that MPLS-TP will directly
support PW as a client, I don't see that in the figures below.  I will
make more comments on the actual structure once we have some initial
agreement on the clients.
 
Malcolm

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Thursday, February 19, 2009 4:28 PM
To: Betts, Malcolm (CAR:X632)
Cc: [email-masked]; [email-masked]; [email-masked];
tsg15q10
Subject: MPLS-TP layer stack and MTM-n Type I, II, IIIa, IIIb for
revised G.8112 [was: RE: MPLS-TP transport service layer]

Malcolm,

Transport networks are amongst others succesful due to the
standardisation of the NNI frame formats. Such standardisation is
mandatory to allow equipment from different vendors and/or operators to
be interconnected without problems. For MPLS-TP to be a succesful
transport netowrk technology we will have to agree what its I-NNI frame
formats will be. The revised version of G.8112 will specify these
MPLS-TP I-NNI frame formats; i.e. will define the MPLS-TP Transport
Module (MTM-n). 

The MPLS-TP transport service layer is the ETH layer, the transport path
layer is the MPLS-TP LSP layer, the section layer is the ETH layer and
the physical media layer is the ETY layer. When carried over the OTN,
the 1GE/10GE/40GE/100GE 802.3 ETY signal is carried in a timing
transparent manner in their ODU0/2e/3/4 (as per G.709 amendment 3) over
an OTU.

MPLS-TP domains operating with the above layer stack will interoperate
with the Ethernet domains already present in the packet transport
networks without any problems (no need for any peer interworking).
Interconnecting two MPLS-TP domains via the MEF E-NNI will be possible
without any problems (no need for any peer interworking between MPLS-TP
and MEF E-NNI).
 
The ATM, FR, TDM, HDLC, PPP, SDH clients deploy the PWE3 encapsulation,
and the Ethernet TYPE field will carry the Protocol Type identifier. The
ETH transport service layer signals will deploy the PWE3 encapsulation
and PW label stack entry header when transported over an MPLS-TP LSP.
 
Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: woensdag 18 februari 2009 22:28
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: MPLS-TP transport service layer [was: RE: [T15Q12] FW:
Liaison onthecooperationbetweenIETFandITU-Ton MPLS-TP]

Note: I have added Q12 to the distribution since I think this topic is
of direct interest.

>From my perspective we need to minimize complexity and allow the network
to continue to evolve.  This evolution involves the addition of new
(transport) technologies to existing networks.  This includes the
network support infrastructure (e.g. OSS).  Once a "new" technology has
been deployed it becomes a part of the "existing" network.  History has
demonstrated that technologies have a finite life and will eventually be
replaced.

With that in mind I am advocating the definition of a set of
(client/server) independent layer networks (e.g. MPLS-TP).  This is the
approach that has been taken for a number of years by SG 15 when
defining the transport network.  The application of a common approach to
the definition of these layer networks (based on G.805 and G.800) allows
us to recognize the aspects that are common from the perspective of
network operation.  It is this approach that has allowed the TMForum to
develop and deploy the MTNM interface (for SDH, ATM, OTN, Ethernet,
ASON....) over the last 10 years.  Good engineering practice indicates
that we should, where appropriate, reuse the implementation of some
functions in multiple technologies.  This reuse enable simplicity
without incurring dependency.

The key to sustainable "simplicity" as the network evolves is the
minimization of dependencies - i.e. retention of client server
independence.  As has been stated many times it is much easier to
achieve independence (and hence simplicity) with client/server
relationships than with peer to peer relationships, particularly when
the technologies offer different capabilities.

Some concerns that I have with your approach are:
 - I suspect that it will require a significant amount of time to reach
full consensus on the technology selection to support the services that
you mention.
 - Since we only consider specific technologies we will create
dependencies that will impede deployment in existing networks and
evolution to accommodate new technologies and services.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 6:45 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison

Malcolm,

If we define MPLS-TP as a complete solution, then we will be able to
minimize complexity of the MPLS-TP equipment and we will be able to
minimize the complexity of the network management of the Ethernet and
MPLS-TP based packet transport network. What we need is to maximize
commonality.

Because the MPLS technology (LSP, PW) does not support mp2mp and rmp
transport service paths, it is required that MPLS-TP equipment and
MPLS-TP network management supports an ETH layer. The ETH layer requires
that Y.1731 OAM is supported and that Y.1731 MEG Level based TCM is
supported in MPLS-TP equipment interface ports. If those interface ports
support MPLS-TP PW MEPs and MIPs on those interface ports, then the
complexity of those interface ports is minimized when MPLS-TP PW OAM
reuses the Y.1731 OAM PDU formats as much as possible.

For the carrier-carrier case, it is typical to carry the transport path
layer path signal of carrier A as a transport service layer path signal
thorugh the network of carrier B. This implies that the MPLS-TP
transport service layer switching equipment will see the ETH, MPLS-TP PW
and MPLS-TP LSP layers are client of the MPLS-TP LSP (i.e. transport
path) layer. If the MPLS-TP LSP OAM also reuses the Y.1731 OAM PDU
formats as much as possible, we minimize the complexity of MPLS-TP
interface ports.

Worst case would be when the OAM PDUs and TCM level identification for
ETH, MPLS-TP PW and MPLS-TP LSP are different. This would maximize the
complexity of those interface ports and of its network management.

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 17 februari 2009 21:41
To: Maarten Vissers; Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 2:12 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm,

As far as I understand MPLS-TP has the following two options for its
transport service layer:
1) Ethernet VLAN (ETH) for all services
2) Ethernet VLAN (ETH) for rmp and mp2mp services plus MPLS-TP MS-PW for
p2p and p2mp services.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Malcolm Betts

Malcolm Betts
Nortel Networks

---

From: <[email-masked]>
Date: Sat, 21 Feb 2009 18:09:01 -0000

Thanks Stewart,

Yes, you are quite within your rights to note this, ie a PW (specifically the CW) can be considered an adaptation function even in MPLS-TP.  Whether one considers it a good generic adaptation function is a separate issue (I don't, but that is only IMO based on experience of what is a good/bad adaptation function for a transport network...where I would have to identify GFP as an example of a good adaptation function for a transport network).

The one thing we cannot sanction however is that this entity is 'networked'.  I could never agree to this (indeed I have no choice in this matter, and this is most definitely not IMO) as we never network an adaptation function.

regards, Neil 

> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: 17 February 2009 16:14
> To: Drake, John E

---

From: <[email-masked]>
Date: Sat, 21 Feb 2009 18:09:00 -0000

Hi guys....catching up on mail after leave, so apologies for late response.....

Just wanted to say here that the key thing we *must* come to terms with is that MS-PWs cannot have a role in MPLS-TP.  This is for the simple reason that MPLS-TP will look a joke as a transport network if we allow it to create another co-ps mode layer network above it.

Now this is not to say we can't have the CW carried across into MPLS-TP..... we can do this, *but* the CW must only take-on an adaptation role, which in simple terms means a 1-hop non-networked entity.  Though if you want my honest technical opinion I don't think the CW is a good adaptation function for a transport network, eg a transport network worthy of the name should never re-order client traffic units, so things like sequence numbers and the 1st nibble ECMP avoidance hack have no place here....but this is just my opinion.  What is not my opinion however (and is simply just a technical statement of fact) is that we do not 'network' adaptation functions.

Aside=> Fixing this issue in MPLS-TP still leaves the MS-PW problem in MPLS.  And it is a real problem.  Not only will the PW layer network thus created have to assume it own full set of functional components (which by definition *cannot* be common with its MPLS server layer, eg a different instance of addressing and routing will be required for the PW connections thus created...so no 'common CP' here), but it will also mean that the PW label (which currently performs an important demerging role in MPLS to recover source information which has been lost by any lower merging due to the use of LDP (or PHP)) needs to change its semantic from a 'source semantic' to one of a 'forwarding (DA proxy) semantic'.  I did go through this issue in some detail in a mail to the PWE3 list back in November 2008 (Sat 29/11/2008 09:43 on thread "RE: [PWE3] draft-ietf-pwe3-ms-pw-arch-05.txt" to be exact) and I refer readers interested in the detail to that mail.

regards, Neil

> Sent: 17 February 2009 14:07
> > > the following.
> > > set, in the server
> > > LSP, there would
> > > botom-most label in this
> > > client PID capability.
> > > IETF MEAD team. 
> > > agreed on and or

---

From: <[email-masked]>
Date: Sat, 21 Feb 2009 18:09:02 -0000

Of course I agree with Malcolm and John here....indeed, looking at the issue as a disapassionate engineer I have absolutely no choice in the matter, this is simply how networks work.  Sure we can screw things up, but why would you want to when there is no need to?  How many transport networks does anyone know that create another layer network above them?  The answer is none.

So the simple question before us is 'do we want MPLS-TP to have a chance of suceeding as a transport network?'  If yes, then the direction is black/white, ie there can be no MS-PWs in MPLS-TP....it's a simple as that.  

regards, Neil

> [mailto:[email-masked]] On Behalf Of Malcolm Betts
> Sent: 17 February 2009 16:49
> Subject: Re: [mpls-tp] [T15Q12] FW: Liaisonon 
> Agree, MPLS-TP should be payload agnostic.  We should 
> define/identify the set of supported client adaptations and 
> the PW adaptation should be included.
> 
> 2 logically

---

From: <[email-masked]>
Date: Sat, 21 Feb 2009 18:09:04 -0000

Hi Maarten,

Maarten Vissers wrote 17 February 2009 22:54
 
> John,
> 
> MPLS-TP must provide a complete packet transport network 
> solution.
NH=> Not sure what this means.  Networks can be be classified as:
-	those that support external message/file/stream applications, ie top-of-stack like IP, PSTN
-	those that provide a transport service for building the topology of (possibly) top-of-stack networks....MPLS/MPLS-TP, Eth, PDH, SDH, OTN all currently fit here.

> As such
> it must support the transport service layer.
NH=> I have no idea what this means....but I suspect you mean a network builder service....and if so this constrains itself to providing p2p (the only truly recursive construct) or p2mp (only a top-of-stack viable construct) connections *if* one wants to control resource management...which I have to take as a given if we are talking about a transport network service. 

> Without support 
> for such layer
NH=> Hmmm.....  MPLS-TP is transport network.  It will provide a network builder service for other layer networks (whether or not top-of-stack) but it does not support end-end external message/file/stream services.  
> 
> MPLS-TP can use the MPLS PW technolgy
NH=> 'PW technology'? What does this mean....do you mean support the generic CW adaptation?  Not for debate here, but the whole PW issue is an artefact of the original MPLS specification.....PWs have no need to even exist in a proper transport network like MPLS-TP is supposed to be.  If the CW and 'PW badge' stay they must revert back to an adaptation role, we for sure cannot be seen to be creating yet another co-ps mode network above MPLS-TP or we would look very silly.

> to support p2p and p2mp service
NH=> Anything but p2p is not recursive as a transport/topology construct...so p2mp, mp2p or mp2mp constructs can only ever be a 1-off top-of-stack manifestation.  You would like these in Ethernet...OK, understood.  But then we have the problem that Ethernet is not itself top-of-stack.  Can't you see the problem here (when we are discussing the role of transport networks for MPLS-TP...hint=> they have no role here)?
> But it might be that it is your objective to create more 
NH=> No.  I am not wanting to put words in John's mouth here, but IMO both John/I are trying to look quite dispassionately at what architectural properties we need MPLS-TP to adopt if we want to see it suceed as a transport network, and we are trying to propose a best-case solution to such.  We are not even considering Ethernet here....as it is totally irrelevant to the the issue at hand, ie all clients are treated equally in MPLS-TP...this is exactly what today's transport networks do (PDH, SDH, OTN).  I really don't think MPLS-TP can afford to look at one particular client such as Ethernet like this.  You could however argue that Ethernet has no need of MPLS-TP.....now that would be a valid argument, but it is different to the one you are trying to put forward that I personally think is not right.

regards, Neil
> as being part of

---

From: <[email-masked]>
Date: Sat, 21 Feb 2009 18:09:02 -0000

Maarten,

I am not understanding your point here at all.  All networks are there to ultimately allow *external* CPE/humans to have message/file/stream communications (networks have no value if this is not true).  The ones that do this however are the top-of-stack networks that have such message/file/streasm adaptation functions, like IP has.  Neither MPLS/MPLS-TP nor Ethernet is a top-of-stack layer network.  Non top-of-stack layer networks only perform a 'network builder' transport network service (to create the topologies of those layer network that do support the real end-end top-of-stack communications).

So it is not right to presume that MPLS-TP supports only Ethernet "services" .....whatever that means, ie yet another transport network if we are honest.  Or indeed that Ethernet VLAN services are something special here.  They may indeed be so, but this is only because of the pervasive nature of Ethernet, and so this is down to market choice of technology which is not least motivated by the fact that Ethernet has a real physical layer specification.....but it is not an architectural issue, at least as seemingly raised here.  Indeed if MPLS-TP is to assume a generic next gen transport network role it must be able to carry *any* clients and not just Ethernet (inc recursive instances of MPLS-TP).

So MPLS-TP must be judged in its own right as a transport network, not simply how it relates to carrying (or being carried by) Ethernet.

Aside=> I am ignoring the obvious question here of whether Ethernet can offer a better transport network solution to MPLS-TP.  If I look at MPLS-TP and PBB-TE with objective/technical eyes then I have to say that the case for PBB-TE is far stronger.

regards, Neil 

> Sent: 17 February 2009 19:11
> To: 'Drake, John E'; [email-masked]
> Cc: [email-masked]
> layer is not part

---

From: <[email-masked]>
Date: Sat, 21 Feb 2009 18:09:03 -0000

Quite!

regards, Neil 

> Sent: 17 February 2009 20:41
> Subject: Re: [mpls-tp] [T15Q12] 
> FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP
> 
> Maarten, if we have client/server independence with MPLS-TP 
> why is it necessary to burden MPLS-TP with the task of 
> defining its client layer network(s). 
> 
> 
> Malcolm Betts
> Nortel Networks

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 23 Feb 2009 00:39:43 +0100

Malcolm,
 
> I thought we had agreed in the MEAD team that MPLS-TP will directly
support PW as a client, 
> I don't see that in the figures below.
 
http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00848.html describes
that the MPLS-TP LSP still supports the SS-PW. This PW is now always an
Ethernet PW. The initial LSP/Multi-Client adaptation function (depicted in
the top half of the figure) has been expanded, creating an ETH layer with
individual ETH/Client adaptation functions. Those ETH/clietn adaptation
functions support the existing set of PWE3 encapsulations. There is no
proposal to extend this set. The proposal is to carry those PWE3
encapsulations over an Ethernet based MPLS-TP transport service layer.
 
With this approach the SS-PW (providing encapsulation and labelling) has
similarities with GFP. GFP is also single segment and supports encapsulation
and labelling. GFP is not illustrated in our SDH, OTN and PDH layer stack
figures; similar we should not find the SS-PWs indicated in our MPLS-TP
layer stack.

> Given client server independence I don't think that this has any impact on
the definition of the MPLS-TP
> layer network other than the identification of its client and server layer
networks.
 
The definition of the MPLS-TP LSP layer network 9in Q.12/15) is a small part
of the total MPLS-TP definition. The MPLS-TP LSP Characteristic Information
(including MPLS-TP LSP OAM) is a much more important piece. Also the
definition of the MPLS-TP Transport Module (MTM-n), including the
encapsulated client characteristic information, encapsulated MPLS-TP
transport service characteristic information, encapsulation MPLS-TP
transport path characteristic information and section layer characteristic
information is much more important. Furthermore, MPLS-TP equipment
complexity and packet transport network management complexity are more
important then the (abstract) description of the MPLS-TP LSP layer network.
The real complexity is as such to be addressed by Q.9/15, Q.10/15 and
Q.14/15.
 
The MPLS technology is not a complete packet transport network technology.
MPLS technology is lacking a physical media layer and is lacking support for
mp2mp and rmp transport service layer instances. Those shortcomings have
resulted in the addition of Ethernet as physical media layer technology in
MPLS networks and the addition of ethernet technology in the transport
service layer to support mp2mp and rmp services.
 
Furthermore, MPLS is not the default technology of choice in the metro and
access parts of the packet transport network; the default choice is the
Ethernet technology.
 
Packet transport networks include as such a combination of ethernet and
MPLS. Equipment must support NNI ports that can connect to an Ethernet
domain and NNI ports that can connect to an MPLS domain. Furthermore, packet
transport networks must support services that have endpoints in ethernet and
mpls domains.
 
The client/server independence between an MPLS-TP LSP layer and its client
layers is as such not the main concern. The main concern is the co-existence
of and interoperability between ethernet and mpls parts in the packet
transport network. I.e. MPLS-TP specifications can not be developed in
isolation, ignoring the environment in which it has to operate.
 
The proposed MPLS-TP layer stack and the proposed Y.1731 PDU based MPLS-TP
OAM address both main concerns. 
It also resolves the MPLS protocol type issue and the ETH to MPLS-TP peer
interworking issue.
 
The choice of the ETH layer as the only MPLS-TP transport service layer
technology we prevent that peer interworking between ETH and MPLS-TP PW is
necessary, plus we introduce a true protocol type field (Ethernet TYPE field
with client specific EtherType values). Furthermore it limits the number of
MPLS-TP LSP clients to just Ethernet.
 
The choice of Y.1731 PDUs as MPLS-TP OAM PDUs will help to reduce the
complexity of the transport path layer functions on the NNI ports. Those NNI
ports can now be designed as dual mode NNI ports, supporting both the MTM-n
and ETM-n interface.
 
Regards,
Maarten

  _____  

From: Malcolm Betts [mailto:[email-masked]] 
Sent: vrijdag 20 februari 2009 15:16
To: Maarten Vissers; [email-masked]; David Ward
Cc: [email-masked]; [email-masked]; [email-masked];
tsg15q10
Subject: [T15Q12] RE: MPLS-TP layer stack and MTM-n Type I, II, IIIa, IIIb
for revised G.8112 [was: RE: MPLS-TP transport service layer]

Maarten, 
 
I agree that we need to define these layer stacks in the context of the NNI
defined G.8112.  Given client server independence I don't think that this
has any impact on the definition of the MPLS-TP layer network other than the
identification of its client and server layer networks.  I suspect that the
IETF participants will only have an interest in the clients that are
supported.
 
I therefore suggest that we agree the client list via the MEAD team list
then develop the details primarily by discussion on the Q10 email list.  As
the proposals mature they should be communicated to the MEAD team for
review.

Malcolm Betts 
Co chair MPLS-TP ad hoc 

Co chair hat off:

I thought we had agreed in the MEAD team that MPLS-TP will directly support
PW as a client, I don't see that in the figures below.  I will make more
comments on the actual structure once we have some initial agreement on the
clients.

Malcolm
  _____  

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Thursday, February 19, 2009 4:28 PM
To: Betts, Malcolm (CAR:X632)
Cc: [email-masked]; [email-masked]; [email-masked];
tsg15q10
Subject: MPLS-TP layer stack and MTM-n Type I, II, IIIa, IIIb for revised
G.8112 [was: RE: MPLS-TP transport service layer]

Malcolm,

 
 
Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: woensdag 18 februari 2009 22:28
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 6:45 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison

Malcolm,

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 17 februari 2009 21:41
To: Maarten Vissers; Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 2:12 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm,

Regards,
Maarten

-----Original Message-----

Malcolm Betts
Nortel Networks

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 23 Feb 2009 01:10:17 +0100

Neil, Malcolm,

I assume that you refer to the MPLS-TP LSP layer, which provides a transport
path layer role in the packet transport network. 

Of all the layers in a packet transport network (transport service,
transport path, section, phy media) the transport path layer is the least
important layer (just a scalability measure). The reason is that the p2p
(and optional p2mp) transport entities in this layer are domain bound, i.e.
exist between nodes at the edge of an aggregation domain. Those p2p/p2mp
transport path layer transport entities can be supported by every packet
technology; e.g. Ethernet VLAN, MPLS-TP LSP and PBB-TE TESI; main difference
is their label sizes: 12-bit, 20-bit, 108-bit. And the number of transport
path layer trnasport entities is much smaller then the number of transport
service layer transport entities.

The most important layer is the transport service layer. The p2p, p2mp, rmp,
mp2mp transport entities in this layer carry the customer services, may
cross through different admin domains, may be protected and provide
information to verify the SLAs.

For me, MPLS-TP is as such not just the definition of **yet another**
transport path instance; i.e. of a MPLS-TP LSP layer, MPLS-TP LSP
characteristic information and MPLS-TP LSP OAM. MPLS-TP for me is the
definition of a complete transport solution, including as well all the
aspects of the transport service layer, section layer and physical media
layer.

To prevent that we continue to have discussions related to the envisaged
scope of the MPLS-TP work in IETF, I would like to understand if the scope
of this work is limited to either the definition of a MPLS-TP LSP layer that
will be used as a transport path layer in the emerging packet transport
network, or the definition of a packet transport network solution including
a MPLS-TP LSP layer as transport service layer.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: zaterdag 21 februari 2009 19:09
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12]
FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP

Quite!

regards, Neil

> the set of supported client adaptations and the PW adaptation should
> be included.
>
> > >> transport network such as MPLS-TP should never require
> > >> unnecessary layer networks to be created
> above it.  
> > >>
> > >> regards, Neil

---

From: <[email-masked]>
Date: Mon, 23 Feb 2009 12:05:29 -0000

Maarten,

I am only referring to the fact that MPLS-TP must treat all its clients equally, ie a transparent client/server relationhip....where the word *transparent* has a very important meaning for a transport network:
-	all clients symbols treated equally
-	client symbol ordering preserved
-	no attempt to infer the meaning of client symbols nor change them.
.....but to which I would add for completeness wrt performance inheritance considerations
-	the traffic behaviour of client X should have no impact of the performance experienced by client Y

And this then has some important implications wrt to what constructs are viable/practical in transport networks.

regards, Neil

> Sent: 23 February 2009 00:10
> To: Harrison,N,Neil,CXM R; [email-masked]
> Subject: Scope of IETF MPLS-TP developments? [was: RE: 
> [mpls-tp] [T15Q12] 
> FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]
> 
> Neil, Malcolm,
> 
> why is it
> define/identify

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 24 Feb 2009 08:13:59 -0500

Maarten, my understanding of the scope of work on MPLS-TP that has been agreed between the ITU-T and the IETF is the definition of the MPLS-TP layer network.

To address your other points - for consideration by Q12/15:

If we (in SG 15) decide to advance work on a "top to bottom" definition of a packet transport network then that definition must be based on a stack of independent layer networks.  This approach allows us to minimize complexity (i.e. minimizes the interactions between layer networks) and therefore allows the network to continue to evolve.  This evolution involves the addition of new (transport) technologies to existing networks.  This includes the network support infrastructure (e.g. OSS).  Once a "new" technology has been deployed it becomes a part of the "existing" network.  History has demonstrated that technologies have a finite life and will eventually be replaced.

In the last study period work on a "packet transport network" was initiated in Q12 but was not advanced due to lack of interest and contributions. If we intend to revive this activity we should first agree on the network scenarios and business boundaries that we are attempting to address so that we can understand the scope of the work.

Malcolm Betts
Co chair ad hoc on MPLS-TP
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Sunday, February 22, 2009 7:10 PM
To: [email-masked]; Betts, Malcolm (CAR:X632)
Cc: [email-masked]; [email-masked]
Subject: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp] [T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]

Neil, Malcolm,

I assume that you refer to the MPLS-TP LSP layer, which provides a transport path layer role in the packet transport network. 

Of all the layers in a packet transport network (transport service, transport path, section, phy media) the transport path layer is the least important layer (just a scalability measure). The reason is that the p2p (and optional p2mp) transport entities in this layer are domain bound, i.e.
exist between nodes at the edge of an aggregation domain. Those p2p/p2mp transport path layer transport entities can be supported by every packet technology; e.g. Ethernet VLAN, MPLS-TP LSP and PBB-TE TESI; main difference is their label sizes: 12-bit, 20-bit, 108-bit. And the number of transport path layer trnasport entities is much smaller then the number of transport service layer transport entities.

The most important layer is the transport service layer. The p2p, p2mp, rmp, mp2mp transport entities in this layer carry the customer services, may cross through different admin domains, may be protected and provide information to verify the SLAs.

For me, MPLS-TP is as such not just the definition of **yet another** transport path instance; i.e. of a MPLS-TP LSP layer, MPLS-TP LSP characteristic information and MPLS-TP LSP OAM. MPLS-TP for me is the definition of a complete transport solution, including as well all the aspects of the transport service layer, section layer and physical media layer.

To prevent that we continue to have discussions related to the envisaged scope of the MPLS-TP work in IETF, I would like to understand if the scope of this work is limited to either the definition of a MPLS-TP LSP layer that will be used as a transport path layer in the emerging packet transport network, or the definition of a packet transport network solution including a MPLS-TP LSP layer as transport service layer.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: zaterdag 21 februari 2009 19:09
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12]

Quite!

regards, Neil

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 24 Feb 2009 08:30:48 -0500

Maarten, I still don't see a PW directly on over MPLS-TP.....

Malcolm Betts 
Nortel Networks 

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Sunday, February 22, 2009 6:40 PM
To: Betts, Malcolm (CAR:X632); [email-masked]; 'David Ward'
Cc: [email-masked]; [email-masked]; [email-masked];
'tsg15q10'
Subject: RE: MPLS-TP layer stack and MTM-n Type I, II, IIIa, IIIb for
revised G.8112 [was: RE: MPLS-TP transport service layer]

Malcolm,
 
support PW as a client, 
> I don't see that in the figures below.
 
http://www.ietf.org/mail-archive/web/mpls-tp/current/msg00848.html
describes that the MPLS-TP LSP still supports the SS-PW. This PW is now
always an Ethernet PW. The initial LSP/Multi-Client adaptation function
(depicted in the top half of the figure) has been expanded, creating an
ETH layer with individual ETH/Client adaptation functions. Those
ETH/clietn adaptation functions support the existing set of PWE3
encapsulations. There is no proposal to extend this set. The proposal is
to carry those PWE3 encapsulations over an Ethernet based MPLS-TP
transport service layer.
 
With this approach the SS-PW (providing encapsulation and labelling) has
similarities with GFP. GFP is also single segment and supports
encapsulation and labelling. GFP is not illustrated in our SDH, OTN and
PDH layer stack figures; similar we should not find the SS-PWs indicated
in our MPLS-TP layer stack.

> Given client server independence I don't think that this has any
impact on the definition of the MPLS-TP
> layer network other than the identification of its client and server
layer networks.
 
The definition of the MPLS-TP LSP layer network 9in Q.12/15) is a small
part of the total MPLS-TP definition. The MPLS-TP LSP Characteristic
Information (including MPLS-TP LSP OAM) is a much more important piece.
Also the definition of the MPLS-TP Transport Module (MTM-n), including
the encapsulated client characteristic information, encapsulated MPLS-TP
transport service characteristic information, encapsulation MPLS-TP
transport path characteristic information and section layer
characteristic information is much more important. Furthermore, MPLS-TP
equipment complexity and packet transport network management complexity
are more important then the (abstract) description of the MPLS-TP LSP
layer network. The real complexity is as such to be addressed by Q.9/15,
Q.10/15 and Q.14/15.
 
The MPLS technology is not a complete packet transport network
technology. MPLS technology is lacking a physical media layer and is
lacking support for mp2mp and rmp transport service layer instances.
Those shortcomings have resulted in the addition of Ethernet as physical
media layer technology in MPLS networks and the addition of ethernet
technology in the transport service layer to support mp2mp and rmp
services.
 
Furthermore, MPLS is not the default technology of choice in the metro
and access parts of the packet transport network; the default choice is
the Ethernet technology.
 
Packet transport networks include as such a combination of ethernet and
MPLS. Equipment must support NNI ports that can connect to an Ethernet
domain and NNI ports that can connect to an MPLS domain. Furthermore,
packet transport networks must support services that have endpoints in
ethernet and mpls domains.
 
The client/server independence between an MPLS-TP LSP layer and its
client layers is as such not the main concern. The main concern is the
co-existence of and interoperability between ethernet and mpls parts in
the packet transport network. I.e. MPLS-TP specifications can not be
developed in isolation, ignoring the environment in which it has to
operate.
 
The proposed MPLS-TP layer stack and the proposed Y.1731 PDU based
MPLS-TP OAM address both main concerns. 
It also resolves the MPLS protocol type issue and the ETH to MPLS-TP
peer interworking issue.
 
The choice of the ETH layer as the only MPLS-TP transport service layer
technology we prevent that peer interworking between ETH and MPLS-TP PW
is necessary, plus we introduce a true protocol type field (Ethernet
TYPE field with client specific EtherType values). Furthermore it limits
the number of MPLS-TP LSP clients to just Ethernet.
 
The choice of Y.1731 PDUs as MPLS-TP OAM PDUs will help to reduce the
complexity of the transport path layer functions on the NNI ports. Those
NNI ports can now be designed as dual mode NNI ports, supporting both
the MTM-n and ETM-n interface.
 
Regards,
Maarten

From: Malcolm Betts [mailto:[email-masked]] 
Sent: vrijdag 20 februari 2009 15:16
To: Maarten Vissers; [email-masked]; David Ward
Cc: [email-masked]; [email-masked]; [email-masked];
tsg15q10
Subject: [T15Q12] RE: MPLS-TP layer stack and MTM-n Type I, II, IIIa,
IIIb for revised G.8112 [was: RE: MPLS-TP transport service layer]

Maarten, 

 

Malcolm Betts 
Co chair MPLS-TP ad hoc 

Co chair hat off:

Malcolm

Malcolm,

 
 
Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: woensdag 18 februari 2009 22:28
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: MPLS-TP transport service layer [was: RE: [T15Q12] FW:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 6:45 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison

Malcolm,

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 17 februari 2009 21:41
To: Maarten Vissers; Drake, John E; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, February 17, 2009 2:12 PM
To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12] FW:

Malcolm,

Regards,
Maarten

-----Original Message-----

Malcolm Betts
Nortel Networks

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 25 Feb 2009 09:52:16 +0100

Malcolm,

> my understanding of the scope of work on MPLS-TP that has been agreed
between
> the ITU-T and the IETF is the definition of the MPLS-TP layer network.

>From a T-MPLS layer network perspective, the "MPLS-TP layer network"
includes the MS-PW, LSP tunnel/path and LSP section layer network instances.
The MS-PW layer is essentially a LSP service/channel layer as illustrated in
the figure below, which operates "between the PWE3 encapsulation and the PW
label stack entry header". I.e. MS-PW is a transport service layer LSP, or
stated in an alternative manner "MS-PW = LSP".

Is the "MPLS-TP layer network" to be used as a the transport service layer
network for p2p and p2mp services, as indicated in the bottom part of the
figure below?

Regards
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 24 februari 2009 14:14
To: Maarten Vissers; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp]
[T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]

Maarten, my understanding of the scope of work on MPLS-TP that has been
agreed between the ITU-T and the IETF is the definition of the MPLS-TP layer
network.

If we (in SG 15) decide to advance work on a "top to bottom" definition of a
packet transport network then that definition must be based on a stack of
independent layer networks.  This approach allows us to minimize complexity
(i.e. minimizes the interactions between layer networks) and therefore
allows the network to continue to evolve.  This evolution involves the
addition of new (transport) technologies to existing networks.  This
includes the network support infrastructure (e.g. OSS).  Once a "new"
technology has been deployed it becomes a part of the "existing" network.
History has demonstrated that technologies have a finite life and will
eventually be replaced.

In the last study period work on a "packet transport network" was initiated
in Q12 but was not advanced due to lack of interest and contributions. If we
intend to revive this activity we should first agree on the network
scenarios and business boundaries that we are attempting to address so that
we can understand the scope of the work.

Malcolm Betts

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Sunday, February 22, 2009 7:10 PM
To: [email-masked]; Betts, Malcolm (CAR:X632)
Cc: [email-masked]; [email-masked]
Subject: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp] [T15Q12]

Neil, Malcolm,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: zaterdag 21 februari 2009 19:09
To: [email-masked]; [email-masked];

Quite!

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 25 Feb 2009 10:12:18 +0100

Malcolm,

> With that in mind I am advocating the definition of a set of
(client/server)
> independent layer networks (e.g. MPLS-TP).

I have the feeling that this is a point where our approaches differ.
As far as I understand your approach, you want to define a MPLS-TP layer
network in
isolation of its application. My approach is to define a MPLS-TP layer
network as 
part of a world wide packet transport network solution.

Layer network specifications developed in SG15 have been developed as part 
of a transport network solution (e.g. SDH, ATM, OTN). Development of just
another 
"layer network" outside the context of the transport network solution it is
to be used in seems wrong to me.

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]] 
Sent: dinsdag 24 februari 2009 14:14
To: Maarten Vissers; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp]

Malcolm Betts

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Sunday, February 22, 2009 7:10 PM
To: [email-masked]; Betts, Malcolm (CAR:X632)
Cc: [email-masked]; [email-masked]
Subject: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp] [T15Q12]

Neil, Malcolm,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: zaterdag 21 februari 2009 19:09
To: [email-masked]; [email-masked];

Quite!

regards, Neil

---

From: "Malcolm Betts" <[email-masked]>
Date: Wed, 25 Feb 2009 08:56:18 -0500

Maarten,  I think you are misunderstanding a subtle but very important point in the approach that  I am advocating, clearly MPLS-TP must be developed in the context of the transport network.  Indeed the original intention when we initiated work on T-MPLS (now MPLS-TP) and PBB-TE was to develop a packet switched equivalent to SDH/OTN.  To restate the approach I am advocating more explicitly:

MPLS-TP should be defined as an independent layer network in the context of the transport network.  

Layer independence (i.e. client/server independence) is important, as I have previously stated since it allows the continued evolution of the transport network. i.e. we can define new clients, or new servers without having to redefine (and upgrade) equipment that is already deployed in the core of the transport network since the upgrades are confined to the locations where the new adaptation functions are deployed.  It is this layer independence that will allow us to run MPLS-TP or PBB-TE over existing SDH/OTN networks.

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, February 25, 2009 4:12 AM
To: Betts, Malcolm (CAR:X632)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp] [T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]

Malcolm,

(client/server)

I have the feeling that this is a point where our approaches differ.
As far as I understand your approach, you want to define a MPLS-TP layer network in isolation of its application. My approach is to define a MPLS-TP layer network as part of a world wide packet transport network solution.

Layer network specifications developed in SG15 have been developed as part of a transport network solution (e.g. SDH, ATM, OTN). Development of just another "layer network" outside the context of the transport network solution it is to be used in seems wrong to me.

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 24 februari 2009 14:14
To: Maarten Vissers; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp] [T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]

If we (in SG 15) decide to advance work on a "top to bottom" definition of a packet transport network then that definition must be based on a stack of independent layer networks.  This approach allows us to minimize complexity (i.e. minimizes the interactions between layer networks) and therefore allows the network to continue to evolve.  This evolution involves the addition of new (transport) technologies to existing networks.  This includes the network support infrastructure (e.g. OSS).  Once a "new"
technology has been deployed it becomes a part of the "existing" network.
History has demonstrated that technologies have a finite life and will eventually be replaced.

With that in mind I am advocating the definition of a set of (client/server) independent layer networks (e.g. MPLS-TP).  This is the approach that has been taken for a number of years by SG 15 when defining the transport network.  The application of a common approach to the definition of these layer networks (based on G.805 and G.800) allows us to recognize the aspects that are common from the perspective of network operation.  It is this approach that has allowed the TMForum to develop and deploy the MTNM interface (for SDH, ATM, OTN, Ethernet, ASON....) over the last 10 years.
Good engineering practice indicates that we should, where appropriate, reuse the implementation of some functions in multiple technologies.  This reuse enable simplicity without incurring dependency. 

Malcolm Betts

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Sunday, February 22, 2009 7:10 PM
To: [email-masked]; Betts, Malcolm (CAR:X632)
Cc: [email-masked]; [email-masked]
Subject: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp] [T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]

Neil, Malcolm,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: zaterdag 21 februari 2009 19:09
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] [T15Q12]

Quite!

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 26 Feb 2009 00:39:06 +0000

Colleagues,

I completely agree with Malcolm.

Furthermore layer independence enables us to define the solution in
manageable chunks, definition of a complete top to bottom solution in one go
is likely to lead to much discussion and take an enormous amount of time to
reach consensus on.

As an example look at the discussion on MPLS(-TP) over MPLS(-TP) which is a
small (but important) part of the MPLS-TP layer network definition. Now
extrapolate that sort of discussion across an entire "packet transport
network solution" and IMO we will still be discussing aspects this time next
year (and probably the year after as well), we will have no documents
published and we will have made little progress in defining an entire
"packet transport network solution" such that pre-standard implementations
can be considered.

And that is assuming that the participants have the time and bandwidth to
continuously dedicate to such long and deep discussions. I suspect most of
us don't, especially as a number of us (myself included) are not employed to
work on MPLS-TP but are doing so for the good of the wider community.

Ben

On 25/02/2009 13:56, "Malcolm Betts" <[email-masked]> wrote:

> Maarten,  I think you are misunderstanding a subtle but very important point
> in the approach that  I am advocating, clearly MPLS-TP must be developed in
> the context of the transport network.  Indeed the original intention when we
> initiated work on T-MPLS (now MPLS-TP) and PBB-TE was to develop a packet
> switched equivalent to SDH/OTN.  To restate the approach I am advocating more
> explicitly:

MPLS-TP should be defined as an independent layer network in the
> context of the transport network.  

Layer independence (i.e. client/server
> independence) is important, as I have previously stated since it allows the
> continued evolution of the transport network. i.e. we can define new clients,
> or new servers without having to redefine (and upgrade) equipment that is
> already deployed in the core of the transport network since the upgrades are
> confined to the locations where the new adaptation functions are deployed.  It
> is this layer independence that will allow us to run MPLS-TP or PBB-TE over
> existing SDH/OTN networks.

Malcolm Betts
Nortel Networks
Phone: +1 613 763

-----Original Message-----
> Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, February
> 25, 2009 4:12 AM
To: Betts, Malcolm (CAR:X632)
Cc: [email-masked];
> [email-masked]; [email-masked]
Subject: RE: Scope of IETF MPLS-TP
> developments? [was: RE: [mpls-tp] [T15Q12]

Malcolm,

> With
> that in mind I am advocating the definition of a set of
(client/server)
> independent layer networks (e.g. MPLS-TP).

I have the feeling that this is a
> point where our approaches differ.
As far as I understand your approach, you
> want to define a MPLS-TP layer network in isolation of its application. My
> approach is to define a MPLS-TP layer network as part of a world wide packet
> transport network solution.

Layer network specifications developed in SG15
> have been developed as part of a transport network solution (e.g. SDH, ATM,
> OTN). Development of just another "layer network" outside the context of the
> transport network solution it is to be used in seems wrong to
> me.

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts
> [mailto:[email-masked]]
To: Maarten
> Vissers; [email-masked]
Cc: [email-masked]; [email-masked];
> [email-masked]
Subject: RE: Scope of IETF MPLS-TP developments? [was:
> RE: [mpls-tp] [T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton
> MPLS-TP]

Maarten, my understanding of the scope of work on MPLS-TP that has
> been agreed between the ITU-T and the IETF is the definition of the MPLS-TP
> layer network.

To address your other points - for consideration by
> Q12/15:

If we (in SG 15) decide to advance work on a "top to bottom"
> definition of a packet transport network then that definition must be based on
> a stack of independent layer networks.  This approach allows us to minimize
> complexity (i.e. minimizes the interactions between layer networks) and
> therefore allows the network to continue to evolve.  This evolution involves
> the addition of new (transport) technologies to existing networks.  This
technology has been deployed it becomes a part of the "existing"
> network.
History has demonstrated that technologies have a finite life and
> will eventually be replaced.

With that in mind I am advocating the definition
> of a set of (client/server) independent layer networks (e.g. MPLS-TP).  This
> is the approach that has been taken for a number of years by SG 15 when
> defining the transport network.  The application of a common approach to the
> definition of these layer networks (based on G.805 and G.800) allows us to
> recognize the aspects that are common from the perspective of network
> operation.  It is this approach that has allowed the TMForum to develop and
> deploy the MTNM interface (for SDH, ATM, OTN, Ethernet, ASON....) over the
> last 10 years.
Good engineering practice indicates that we should, where
> appropriate, reuse the implementation of some functions in multiple
> technologies.  This reuse enable simplicity without incurring dependency. 

In
> the last study period work on a "packet transport network" was initiated in
> Q12 but was not advanced due to lack of interest and contributions. If we
> intend to revive this activity we should first agree on the network scenarios
> and business boundaries that we are attempting to address so that we can
> understand the scope of the work.

Malcolm Betts
Co chair ad hoc on

-----Original Message-----
From: Maarten Vissers
> [mailto:[email-masked]]
Sent: Sunday, February 22, 2009 7:10
> [email-masked]; [email-masked]
Subject: Scope of IETF MPLS-TP
> developments? [was: RE: [mpls-tp] [T15Q12]

Neil, Malcolm,

I
> assume that you refer to the MPLS-TP LSP layer, which provides a transport

Of all the layers in a
> packet transport network (transport service, transport path, section, phy
> media) the transport path layer is the least important layer (just a
> scalability measure). The reason is that the p2p (and optional p2mp) transport
> entities in this layer are domain bound, i.e.
exist between nodes at the edge
> of an aggregation domain. Those p2p/p2mp transport path layer transport
> entities can be supported by every packet technology; e.g. Ethernet VLAN,
> MPLS-TP LSP and PBB-TE TESI; main difference is their label sizes: 12-bit,
> 20-bit, 108-bit. And the number of transport path layer trnasport entities is
> much smaller then the number of transport service layer transport
> entities.

The most important layer is the transport service layer. The p2p,
> p2mp, rmp, mp2mp transport entities in this layer carry the customer services,
> may cross through different admin domains, may be protected and provide

For me, MPLS-TP is as such not just the
> definition of **yet another** transport path instance; i.e. of a MPLS-TP LSP
> layer, MPLS-TP LSP characteristic information and MPLS-TP LSP OAM. MPLS-TP for
> me is the definition of a complete transport solution, including as well all
> the aspects of the transport service layer, section layer and physical media
> layer.

To prevent that we continue to have discussions related to the
> envisaged scope of the MPLS-TP work in IETF, I would like to understand if the
> scope of this work is limited to either the definition of a MPLS-TP LSP layer
> that will be used as a transport path layer in the emerging packet transport
> network, or the definition of a packet transport network solution including a
> MPLS-TP LSP layer as transport service
> layer.

Regards,
Maarten

-----Original Message-----
From:
> [email-masked] [mailto:[email-masked]]
Sent: zaterdag 21
> februari 2009 19:09
> [email-masked]; [email-masked]
Cc: [email-masked];
> [email-masked]
Subject: RE: [mpls-tp]
> [T15Q12]
FW:LiaisononthecooperationbetweenIETFandITU-Ton

Quite!

regards, Neil

> [email-masked]
> Maarten, if we
> have client/server independence with MPLS-TP why is it 
> necessary to burden
> MPLS-TP with the task of defining its client layer 
> network(s).
>
>
>
> Malcolm Betts
> Nortel Networks
> We
> do need to define the architecture of the MPLS-TP transport service 
>
> layer.
>
> 2)
> Ethernet VLAN (ETH) for rmp and mp2mp services plus MPLS-TP MS-PW 
> for p2p
> and p2mp services.
>
> Regards,
> Maarten
>
> Re: [mpls-tp] [T15Q12] FW: Liaison 
> Cc: Betts,
> Malcolm (CAR:X632); [email-masked]; 
> [email-masked]
> Subject:
> RE: [mpls-tp] [T15Q12] FW: Liaison on 
> > I disagree. MPLS-TP at
> least needs to call up PWs as the required 
> > adaptation mechanism.
> >
> >
> Stewart
> >
> >
> >
> > Drake, John E wrote:
> > > Malcom,
> > >
> > > I agree
> that MPLS PWs are a reasonable payload for MPLS TP
> > but they are not part
> Re: [mpls-tp] [T15Q12] FW: Liaison on 
> > >>
> layer network that provides co-ps "transport
> > service" in
> > >> the
> context of a "complete" network.
> > >>
> > >> client server
> independence (as identified by Neil in point
> > 1) then in
> > >> the context
> of the MPLS-TP layer network what do we need
> > to specify
> > >> about the
> > >> adaptations and the
> "transport service" offered by MPLS-TP.  i.e.
> > >> definition of the PW
> layer should not be in scope for
> the MPLS-TP
> > >> RFCs or Recommendations.
> I see good rational for reuse
> of the PW
> > >> mapping that are already
> > >> should develop
> Recommendations describing PWs, (single or multi
> > >> segment) but that is a
> separate issue.
> > >>
> [mpls-tp] [T15Q12] FW: Liaison on the 
> > >> 4)
> physical media layer.
> > >> If we remove the
> MS-PW from the set above, does this imply
> > that the
> > >> transport
> service layer is provided by an ETH (i.e.
> > >> John is correct.
> You to remember Liu that PWs only came about 
> > >> because of the way MPLS
> was originally specified.  For
> MPLS-TP to
> > >> assume a  transport role
> > >> all clients
> IETFandITU-T on MPLS-TP
> > >>>>  I have a
> question of your solution. if adding PPP PID of the 
> > >>>> associated
> client payload as the bottom-most label,
> > there are two
> > >>>> different
> traffic that are both the same type i.e ETH,
> > >>>>        
> > >> needing
> to be
> > >>    
> > >>>> transported by MPLS-TP layer network. if using
> your
> > solution, the
> > >>>> tranported
> by the same MPLS-TP LSP. so how to identify the two 
> > >>>> different
> > >> requirements
> he
> > >>>> -                 When carrying inband control
> > >>>>
> plane/management plane payloads:
> > >>>>
> > >>>>     0                   1
> 2         
>          3
> > >>>> CP/MP protocols                  between
> logically adjacent
> > >>>> nodes.  (The S bit
> is essentially                  'don't
> globally unique GAL that is the key identifier.)  The GAL    
> > >>>>
> is never
> > >>>> presumably
> be a capabilities exchange to ensure that both
> > >>>>        
> > >>> ends
> of that
> > >>>      
> botom-most
> > >>>>   in the stack being emptied), further processing of the
>
> > packet is
> > >>>>   last label off
> the stack must therefore be able to
> identify the
> > >>>>   packet's network
> > >>>>   contain any field which explicitly identifies the
>
> network layer
> > >>>>
> > >>>>
> > >>>>
> > >>>> Rosen, et al.
> Standards Track                  
> > >>>>   [Page 5]
> > >>>> > > > > >
> >
> > >>>>   protocol.  This means that the
> identity of the network layer 
> > >>>> protocol
> > >>>>   must be inferable
> > >>>>   the bottom of the stack, possibly along with the
> >
> contents of the
> > >>>>   value must also be one which meets
> the same
> criteria.  If these
> > >>>>   conditions are not met, the LSR
> which pops the last
> label off a
> > >>>>   packet will not be able to
> identify the packet's
> network layer
> > >>>>   protocol."
> > >>>>
> > >>>>
> Thanks,
> > >>>>
> > >>>> Neil and John
> > >>>>
> > >>>>        
> > >>>>>
> FW: Liaison on the
> > >>>>> Your mail has prompted
> me to list some key
> requirements that I
> > >>>>> believe are important for
> both ITU-T and IETF to
> consider as we
> > >>>>> same or different parties, ie MPLS-TPoverMPLS-TP. 
> One
> way this
> > >>>>> their
> clients.  GFP has a PID function (in the UPI
> field) that
> > >>>>> already
> identifies important SAN clients, and it also
> > >>>>>          
> > >> has
> values
> > >>    
> > >>>>> migration/interworking of current and next generation
>
> transport
> MPLS-TP OAM:
> > >>>>> MPLS-TP OAM functions must be client layer
> network
> agnostic and
> > >>>>> appear as identical as possible to MPLS-TP
> traffic
> units at the
> > >>>>> layer network
> (the CP/MP can ensure there are no loops before 
> > >>>>> establishing a LSP)
> > >>>>> which
> clearly cannot be technical) then some other
> way must be
> > >>>>> found to
> ensure this.
> > >>>>>
> > >>>>>
> > >>>>> 3                 PWs and
> MPLS-TP:
> > >>>>>
> > >>>>> was originally
> specified;  in particular the different way in 
> > >>>>> which IP and all
> > >>>>> transport role however,
> its design must be changed
> such that it
> > >>>>> and became
> a co-ps layer network in their own right
> above MPLS.
> > >>>>>
> > >>>>> Now
> given MPLS-TP is supposed to be a transport
> > >>>>>          
> > >>
> network, then it
> > >>    
> > >>>>> would make no sense whatsoever for it to
> create a
> further co-ps
> > >> quite
> clear
> > >> their
> original
> network above MPLS-TP.
> [email-masked]; [email-masked]; 
> > >>>>>>
> > >>> between IETF
> attached is a liaison statement from the IETF
> MEAD team.
> > >>>>>>  The
> most
> > >>>>>> believe that the
> following items need to be agreed on and or 
> > >>>>>> communicated from the
> ITU-T to the IETF:
> > >>>>>> far
> into the future this will have an impact on the
> > >>>>>>            
> >
> >>>> target date for
> > >>>>        
> > >>>>>> the MPLS-TP RFCs.
> > >>>>>>
> > >>>>>> we need to
> have approved as RFCs for the SG15 meeting in
> > >>>>>>            
> > >>>>>
> October 2009.
> > >>>>>          
> > >>>>>> 3.                 Third, we see
> a need to further define
> > >>>>>>            
> > >>>> the process,
> regarding
> > >>>>        
> ITU-T
> > >>>>>> the current 
> requirements and we are in the process of
> > >>>>>>            
> > >> 
> providing
> > >>    
> > >>>>> Scott 
> Bradner;
> mailing list
> > >>>> obligated to 
> maintain secrecy and are not permitted to
> > >>>>        
> > >> disclose 
> the
> > >>    
> > >>>> notify the originator of the message. Any 
> views
> > expressed in this
> mailing list
> mailing list

___________________________
> ____________________
mpls-tp mailing 
[email-masked]