Subject: Re: [mpls-tp] [T15Q12] MPLS-TP layer stack and MTM-n Type I, II, IIIa, IIIb for revised G.8112 [was: RE: MPLS-TP transport service layer]

From: Maarten Vissers <[email-masked]>
Date: Fri, 20 Feb 2009 18:05:35 +0100

Alan,
 
Thanks for your comment.
 
> There appears to be no MPLS-TP over GFP over SDH or MPLS-TP over GFP over
OTN without the underlying Ethernet layer. 
 
I left out indeed the MPLS-TP mapping via GFP into SDH/OTN. I did this for
three reasons:
1) with GFP we would have to develop a "synchronous-ODU" to carry
synchronisation information; by using the new timing transparent mappings of
ethernet into ODUs we can use the syncEth instead.
2) when connecting a MPLS-TP node outside the OTN to a MPLS-TP switch
function located on a blade of an OTN cross connect, then the proposed
timing transparent mapping of (sync)Eth into ODU is the best means to
interconnect both.
3) I got ofline feedback from some operators that they prefer to use
Ethernet interfaces on their packet transport nodes and map those Etherent
signals into ODUs in the OTN nodes.
 
> MTM-n type 1 might be better relabelled as something else as there is
MPLS-TP layer in the stack.
 
MTM-n type I could indeed be relabelled as ETM-n type I. I will do so in a
next version.
 
> Furthermore, might be useful to indicate if MPLS-TP must always ride over
Ethernet or like MPLS can ride over any L2 from architectural standpoint
 
If you look at today's G.8112, MPLS-TP can ride over any physical media
layer technology that supports packets (via GFP). As indicated above under
3), there seems to be a desire with some operators to change this and just
ride over Ethernet, and let Ethernet ride over anything else.
 
>From the perspective of G.8112, we must decide which direction we want to
take. 
it would certainly simplify the MPLS-Tp and OTN designs if we could always
ride over Ethernet and have Ethernet ride over OTN.
 
Regards,
Maarten

  _____  

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

should be no MPLS-TP in stack for MTM type 1 - sorry about the typo

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: 20 February 2009 14:47
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [T15Q12] MPLS-TP layer stack and MTM-n Type I, II, IIIa, IIIb
for revised G.8112 [was: RE: MPLS-TP transport service layer]

Seems to be incomplete.
There appears to be no MPLS-TP over GFP over SDH or MPLS-TP over GFP over
OTN without the underlying Ethernet layer.
MTM-n type 1 might be better relabelled as something else as there is
MPLS-TP layer in the stack.
Furthermore, might be useful to indicate if MPLS-TP must always ride over
Ethernet or like MPLS can ride over any L2 from architectural standpoint

  _____  

From: Maarten Vissers [mailto:[email-masked]] 
Sent: 19 February 2009 21:28
To: 'Malcolm Betts'
Cc: [email-masked]; [email-masked]; [email-masked];
tsg15q10
Subject: [T15Q12] 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). 

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
onthecooperationbetweenIETFandITU-Ton MPLS-TP]

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

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