Subject: Re: [mpls-tp] MPLS-TP transport service layer [was: RE: [T15Q12] FW: Liaison onthecooperationbetweenIETFandITU-Ton MPLS-TP]

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

Hi Feng,
 
Indeed in the proposed architecture we will have to develop a set of new
adaptation functions to carry the ATM, FR, PPP, HDLC, etc client signals
over the ETH layer networ'; e.g. ETH/VP, ETH/VC, ETH/FR, ETH/PPP, ETH/HDLC
adaptation functions. This development is quite straigthforward as it will
reuse the existing PWE3 encapsulations. Main item is the allocation of
EtherType values for each of the client signals. Q.10/15 will have to
identify the set of ETH clients that do not yet have an EtherType value and
then request the allocation of such values by the Registration Authority. Q.
10/15 can initiate this in the May 2009 meeting.
 
Also the MPLS-TP LSP to ETH adaptation function (MT/ETH-m_A) which is
located between the ETH based transport service layer and the MPLS-TP LSP
based transport path layer is still to be specified. In G.8121 clauses
9.3.2.3 and 9.3.2.4 are reserved to contain those specifications. These
adaptation functions are an extension of the MT/ETH_A function specified in
the clauses 9.3.2.1 and 9.3.2.2.
 
Regards,
Maarten
 
  _____  

From: HUANG Feng F [mailto:[email-masked]] 
Sent: woensdag 18 februari 2009 11:19
To: Maarten Vissers; Malcolm Betts
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP transport service layer [was: RE: [T15Q12]
FW: Liaison onthecooperationbetweenIETFandITU-Ton MPLS-TP]

Dear Maarten,
     Your solution seem any client (ETH, ATM, FR, HDLC, PPP, SDH) over
Ethernet, then Ethernet over MPLS-TP by PWE3, from view of MPLS-TP LSP, only
one kind of client, it is Ethernet. 
      In this solution, new adaptation function Client/ETH need to be
defined, seem to define a Ethernet PW?
Best regards
Feng

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: 2009年2月18日 3:34 PM
To: 'Malcolm Betts'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MPLS-TP transport service layer [was: RE: [T15Q12]
FW: Liaison onthecooperationbetweenIETFandITU-Ton MPLS-TP]

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,

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
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

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

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

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

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2009 8:14 AM
> To: Drake, John E
> Cc: Malcolm Betts; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on
> 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
> >  
> >> -----Original Message-----
> >> From: Malcolm Betts [mailto:[email-masked]]
> >> Sent: Tuesday, February 17, 2009 7:20 AM
> >> To: [email-masked]
> >> Cc: [email-masked]
> >> 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.
> >>
> >> I hope that this approach (reduction of scope) will allow
> us to focus
> >> on getting MPLS-TP defined.
> >>
> >> Malcolm Betts
> >> Nortel Networks
> >> Phone: +1 613 763 7860 (ESN 393)
> >> email: [email-masked]
> >>
> >> -----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
> >>
> >> 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.
> >>
> >>    
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of Drake, John E
> >>> Sent: 16 February 2009 15:22
> >>> To: [email-masked]
> >>> Cc: [email-masked]
> >>> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation
> >>> betweenIETFandITU-T on MPLS-TP
> >>>
> >>> There are no PW headers in this proposal.
> >>>
> >>>      
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]]
> >>>> Sent: Sunday, February 15, 2009 6:55 PM
> >>>> To: Drake, John E
> >>>> Cc: [email-masked]
> >>>> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the 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
> >>>>
> >>>>
> >>>>
> >>>> "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,
> >>>>
> >>>> 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
> >>>>
> >>>>        
> >>>>> -----Original Message-----
> >>>>> 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:
> >>>>>
> >>>>>
> >>>>> 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]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>            
> >>>>> _______________________________________________
> >>>>> mpls-tp mailing list
> >>>>> [email-masked]
> >>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>>>
> >>>>>          
> >>>> _______________________________________________
> >>>> mpls-tp mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --------------------------------------------------------
> >>>> 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.
> >>>>
> >>>>        
> >>> _______________________________________________
> >>> mpls-tp mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>
> >>>      
> >> _______________________________________________
> >> mpls-tp mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>
> >> _______________________________________________
> >> mpls-tp mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> >> _______________________________________________
> >> mpls-tp mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>
> >>    
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
> >
> >  
>
>
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp