Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP)

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 08 Mar 2009 18:26:47 +0000

Malcolm,

On 26/02/2009 14:19, "Malcolm Betts" <[email-masked]> wrote:

> Ben, perhaps the concern raised by Neil could be addressed by adding the
> following sentence to the end of requirement 22:
> "However the server layer MUST guarantee that the traffic loading
> imposed by other clients does not cause the transport service provided
> to the MPLS-TP layer to fall bellow the agreed level."

OK I have added the following:

" The server layer MUST guarantee that the traffic loading imposed by other
clients does not cause the transport service provided to the MPLS-TP layer
to fall bellow the agreed level. Mechanisms to achieve this are outside the
scope of these requirements."

> 
> Also, how are the three other major issues raised by Neil in a mail sent
> 14/02/2009 at 9:41AM been addressed - body copied below:
> 
> "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.

I believe this is covered by requirements 20 through 22 and requirement 23 I
proposed in my original e-mail below.

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

MPLS-TP OAM requirements belong in the OAM requirements draft. The MPLS-TP
Requirements draft just reference the OAM requirements draft.

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

The MPLS-TP Requirements make no explicit mention of PWs except in the
definitions. Whether or not PWs are part of MPLS-TP is for the solutions to
determine not the requirements.

> regards, Neil"
>  
> Perhaps the first could be addressed by adding the following text to the
> end of requirement 23.
> "It MUST be possible to isolate the control and management planes of the
> MPLS-TP layer network from the control and management planes of the
> client and server layer networks."

Isn't that already covered by requirement 22?
" In an environment where an MPLS-TP layer network is supporting a client
network, and the MPLS-TP layer network is supported by a server layer
network then operation of the MPLS-TP layer network MUST be possible without
any dependencies on the server or client network."

I can add to emphasise if you like though.  Do you mean add to end of
original requirement 23 "It MUST be possible to operate the layers of a
multi-layer network that includes an MPLS-TP layer autonomously." or my
proposed requirement 23 below?

Ben

> 
> 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 Ben Niven-Jenkins
> Sent: Thursday, February 26, 2009 7:04 AM
> To: Harrison,N,Neil,CXM R; [email-masked]
> Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
> overMPLS(-TP)
> 
> Neil,
> 
> MPLS-TP is a subset of the MPLS toolkit where we adding to the MPLS
> toolkit those functions necessary to realise MPLS-TP that aren't already
> in the MPLS toolkit.
> 
> Use of MPLS(-TP) is purely for brevity as otherwise we will end up with
> pages of text on this in the requirements.
> 
> However, I agree with you not all combinations make sense for all
> applications. This is no different with today's networks and it is the
> responsibility of the operators to ensure they are buying server layer
> services that meet the requirements of their client layer networks, e.g.
> If I am buying an "Ethernet circuit" today I want to know if that is
> provided over a shared LAN infrastructure or I am buying a reserved
> bandwidth VLAN so I can ensure it will meet the requirements of the
> service/network I wish to run over it.
> 
> Ben
> 
> 
> On 26/02/2009 08:06, "Harrison,N,Neil,CXM R" <[email-masked]>
> wrote:
> 
>> Thanks Ben,  Looks generally OK to me.  But I think we need to
>> exercise a little care with all 4 C/S combinations here and be very
>> specific with what we mean by 'MPLS'.
>> 
>> And what I mean by this at a high-level is that we must be designing
>> MPLS-TP with a transport network role in mind (eg C/S transparency)
>> and it must therefore be fixing something that is not quite right in
>> MPLS...it has to, else we have no need to work on it.
>> 
>> However, there is more to it than this high-level observation.
>> 
>> We will only be defining a single type of MPLS-TP.  But MPLS is not
>> singular by definition...we allow many ways to allocate/distribute
>> labels.  And those labels have different semantics depending on:
>> (i) what 'signalling' protocol issued them (I say 'signalling' because
> 
>> whilst RSVP-TE and targetted LDP can be classified as signalling one
>> cannot call vanilla LDP signalling in a co-ps context, and I'd
>> hestitate to call labels issued by MP-BGP4 as signalling)
>> (ii) what application context they apply to.
>> 
>> In the past folks should have noticed me refer to the fact that (a)
>> MPLS is not singular and (b) MPLS does note have consistent
>> Characteristic Information....well the above is what I mean by this.
>> 
>> So when we say 'MPLS' we should also say what type of MPLS.  So whilst
> 
>> there is no problem with MPLSoverMPLS-TP and MPLS-TPoverMPLS-TP
>> (assuming we get the MPLS-TP design right) it is not at all clear to
>> me what MPLS-TPoverMPLS and MPLSoverMPLS really means.
>> 
>> Let me give an example of what I mean here:
>> 
>> MPLS-TP is supposed to be being designed to provide a transparent
>> transport role for its clients.  But MPLS_LDP does not provide a
>> transparent transport role whilst MPLS_RSVP-TE can do so.
>> 
>> So whilst MPLS-TPoverMPLS_RSVP-TE and MPLS(any)overMPLS_RSVP-TE should
> 
>> be OK I could not say the same for MPLS-TPoverMPLS_LDP or indeed
>> MPLS(any)overMPLS_LDP.
>> 
>> And the key observation from the requirements of C/S transprency are
>> that the server must not allow the traffic behaviour of client X to
>> impact the performance experienced by client Y.
>> 
>> I hope everyone can understand what I mean by this.
>> 
>> regards. Neil
>> 
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
>>> Sent: 26 February 2009 01:07
>>> To: [email-masked]
>>> Subject: [mpls-tp] Clarifying MPLS-TP requirements for
>>> MPLS(-TP) overMPLS(-TP)
>>> 
>>> Colleagues,
>>> 
>>> During private discussion with some folks it seems clear that the
>>> requirement for MPLS(-TP) over MPLS(-TP) is not well articulated in
>>> the requirements draft.
>>> 
>>> Currently we have:
>>>    20  A generic and extensible solution MUST be provided to support
>>> the
>>>        transport of one or more client layer networks (e.g.  MPLS-TP,
>>>        Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
>>> 
>>>    21  A solution MUST be provided to support the transport of
> MPLS-TP
>>>        transport paths over one or more server layer networks (such
> as
>>>        MPLS-TP, Ethernet, SONET/SDH, OTN, etc.).  Requirements for
>>>        bandwidth management within a server layer network are outside
>>>        the scope of this document.
>>> 
>>>    22  In an environment where an MPLS-TP layer network is supporting
> 
>>> a
>>>        client network, and the MPLS-TP layer network is supported by
> a
>>>        server layer network then operation of the MPLS-TP layer
>>> network
>>>        MUST be possible without any dependencies on the server or
>>> client
>>>        network.
>>> 
>>> I always thought these were sufficient and they cover many more cases
> 
>>> than just MPLS(-TP) over MPLS(-TP) but from those discussions I have
>>> had recently it seems to me that it might worthwhile to explicitly
>>> call out the MPLS(-TP) over MPLS(-TP) case.
>>> 
>>> As such I suggest adding the following requirement after requirement
>>> 22
>>> 
>>> 23  A solution MUST be provided to support the transport of a client
>>> MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer
>>> network.
>>> 
>>>     A  The level of co-ordination required between the client and
>>> server
>>> MPLS(-TP) layer networks MUST be minimised (preferably no
>>> co-ordination will be required).
>>> 
>>>     B  The MPLS(-TP) server layer network MUST be capable of
>>> transporting the complete set of packets generated by the client
>>> MPLS(-TP) layer network, which may contain packets that are not MPLS
>>> packets (e.g. IP or CNLS packets used by the control/management plane
> 
>>> of the client MPLS(-TP) layer network)
>>> 
>>> 
>>> Unless anyone objects I will add the above proposed requirement as
>>> part of updating the requirements draft to version -05 following WG
>>> LC.
>>> 
>>> Ben
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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

---

From: "Malcolm Betts" <[email-masked]>
Date: Mon, 9 Mar 2009 09:46:12 -0400

Ben, see in line below - I have snipped some text for clarity:

Malcolm Betts
Nortel Networks

> From: Ben Niven-Jenkins [mailto:[email-masked]] 
> Sent: Sunday, March 08, 2009 2:27 PM
> To: Betts, Malcolm (CAR:X632); Harrison,N,Neil,CXM R; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for 
> MPLS(-TP) overMPLS(-TP)
> 
> Malcolm,
> 
> 
> " The server layer MUST guarantee that the traffic loading 
> imposed by other clients does not cause the transport service 
> provided to the MPLS-TP layer to fall bellow the agreed 
> level. Mechanisms to achieve this are outside the scope of 
> these requirements."

OK thanks.

> > current and next generation transport networks is important for 
> > network operators, then the use of GFP in MPLS-TP should be given 
> > serious consideration.
> 
> I believe this is covered by requirements 20 through 22 and 
> requirement 23 I proposed in my original e-mail below.

See below:

> > network under consideration.
> 
> MPLS-TP OAM requirements belong in the OAM requirements 
> draft. The MPLS-TP Requirements draft just reference the OAM 
> requirements draft.

I think that the requirements draft should indicate that all frames,
i.e. client data, OAM, SCC, MCC, etc MUST receive identical treatment in
the data plane and therefore MUST use the same header structure.

> 
> > 3 PWs and MPLS-TP:
> > 
> 
> The MPLS-TP Requirements make no explicit mention of PWs 
> except in the definitions. Whether or not PWs are part of 
> MPLS-TP is for the solutions to determine not the requirements.

So why leave PW in the definitions section if they are not mentioned in
the rest of the document.

> 
> > regards, Neil"
> >  
> > Perhaps the first could be addressed by adding the 
> following text to 
> > the end of requirement 23.
> > "It MUST be possible to isolate the control and management 
> planes of 
> > the MPLS-TP layer network from the control and management planes of 
> > the client and server layer networks."
> 
> " In an environment where an MPLS-TP layer network is 
> supporting a client network, and the MPLS-TP layer network is 
> supported by a server layer network then operation of the 
> MPLS-TP layer network MUST be possible without any 
> dependencies on the server or client network."
> 
> I can add to emphasise if you like though.  Do you mean add 
> to end of original requirement 23 "It MUST be possible to 
> operate the layers of a multi-layer network that includes an 
> MPLS-TP layer autonomously." or my proposed requirement 23 below?

Ben I was targeting your revised 23 below - I think the emphasis is a
useful clarification and therefore should be included.  

Also some where in the draft we should make it clear that the client (or
server) may be another independent instance of a MPLS-TP layer network
and the client server independence (in the data/control/management
planes) must be maintained between them.

Considering the requirements for client server independence and the
requirement that client traffic and OAM have identical treatment.  A
possible solution would be to always follow the last header (S bit=1) in
an instance of MPLS-TP network with a payload identifier (e.g. a ACh)
and use this to distinguish between client data frames (which may be
MPLS-TP) or OAM or SCC, DCC... The ACh could also indicate the protocol
as well as the client.  In this case the last header needs to be
independent of the client type to ensure identical treatment (i.e.
always a GAL - but in this case is then use of a reserved label over
kill?).

---

From: Loa Andersson <[email-masked]>
Date: Mon, 09 Mar 2009 15:39:51 +0100

Malcolm,

> Ben, see in line below - I have snipped some text for clarity:
<snipped even more - Loa>

> the data plane and therefore MUST use the same header structure.

all packets with the same label on top will get the same treatment,
given that the TC field is the same, won't they? Is this what you mean
by "header structure" or did I miss something

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 09 Mar 2009 15:08:01 +0000

> by "header structure" or did I miss something

There is a bunch of confusion about what happens in MPLS networks.

In transport networks - set up statically or via GMPLS only the top label
effects the path (although TC effects the queuing).

There are no standard methods for looking at any other label and in
any case this is only done in networks where the path is chosen
by an IGP.

If we always use a PW then the requirement for client data, OAM, SCC,
MCC to receive identical treatment in the path to the PE occurs because
the label stack is identical.

The only case where the label stack will be different is when we are
carrying an LSP OAM in which case the GAL needs to be present.

Stewart

---

From: <[email-masked]>
Date: Mon, 9 Mar 2009 17:14:24 -0000

Thanks Stewart,  please see in-line: 

Stewart Bryant wrote 09 March 2009 15:08
> There is a bunch of confusion about what happens in MPLS networks.

NH=> I agree.  And I think one of the most worrying things I am seen is
to assume that MPLS-TP will somehow just be a profile of what MPLS is
today.  It won't be.  Sure we will re-use many component parts, but we
will also be adding some new ones like a PID field in the DP, probably
new OAM and we will be taking CP/MP functions logically OOB wrt traffic
DP.

Of a more general/practical architectural note however is that MPLS (any
spin) and MPLS-TP are *not* top-of-stack layer networks, and this means
there in no sense in trying to interwork them as peers.  They will
either carry other non top-of-stack layer networks (so this one is very
obvious reason as to why peer interworking is not required, ie
MPLS/MPLS-TP terminated either side and only client passed
transparently)  or IP which is the top-of-stack layer network (and here,
ie in the IP layer, peer interworking is vital).

So any arguments based on being backwards compatible with existing MPLS
make little real sense.

> effects the path (although TC effects the queuing).

NH=> Strictly speaking Stewart a transport network should be fully
transparent and treat all client symbols equally (which is what all
co-cs mode networks do and it is one reason why they are so succesful as
transport networks).
> the label stack is identical.

NH=> The stark technical reality is that when we create MPLS-TP (by
doing things differently to LDP MPLS)  then there is no need for PWs (or
even the CW)...all clients get treated equally, they have to be else it
won't be transport network.....so every client is a PW if you like
(which kind-of makes the name PW and any distinction inferred by this
quite irrelevant).
> carrying an LSP OAM in which case the GAL needs to be present.

NH=> This is both my original and Malcolm's point.  The defect
detection/handling OAM very clearly belongs to the DP and it should have
an identical (in all respects) header to a normal traffic unit.  This is
why I said to you Stewart that if you are proposing
http://www.ietf.org/internet-drafts/draft-bryant-pwe3-packet-pw-00.txt
as the DP encaps for MPLS-TP then the OAM indicate function needs to be
in here, eg as a PPP codepoint say.  I don't see why we need the CW as
its not doing much useful (as adapatation) but if you really want it
then keep it.  But we should ensure that the OAM indicate is here and
not under the GAL, else the DP OAM header will have a different format
to normal DP traffic.

regards, Neil

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 10 Mar 2009 11:15:12 -0400

First a minor digression to explain my paranoia on this issue ;)

In high availability networks (like the Transport network) the "killer"
faults are the ones that you do not detect.  The normal conversation
about these faults is "well that should not have happened...." but
"stuff happens".  I am not an expert on MPLS equipment implementations
or the control protocols so I am seeking expert guidance.

So with that mind set:

I agree that only the top label is use forwarding so no problems "in the
network".  However at the node that originates an terminates the MPLS-TP
path we do see a difference in the pdu structure:
For traffic the pdu is:  {label X S=1}{Payload}
For OAM the pdu is:  {label X S=0}{GAL S=1}{ACh; Payload}

Clearly these are different label stacks both at the originating and
terminating nodes.  The question is do differences create a significant
risk of undetected faults due to the different treatment of OAM and the
data path in either the originating or terminating processes.  Remember
the more successful MPLS-TP the greater the chance that a corner case
fault will appear.....

The "uniform stack" for MPLS-TP would be: {label X S=0}{GAL S=1}{ACh*;
Payload} where the ACh* code point would also include the client payload
types as well as OAM, MCC, DCC etc. 

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Loa Andersson wrote:
>> i.e. client data, OAM, SCC, MCC, etc MUST receive identical treatment

>> in the data plane and therefore MUST use the same header structure.
>

In transport networks - set up statically or via GMPLS only the top
label effects the path (although TC effects the queuing).

There are no standard methods for looking at any other label and in any
case this is only done in networks where the path is chosen by an IGP.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Mar 2009 15:46:02 +0000

> For OAM the pdu is:  {label X S=0}{GAL S=1}{ACh; Payload}
Malcolm

For PE to PE traffic the

traffic pdu is:  {label X S=1}{CW}{data payload}
oam pdu is       {label X S=1}{ACH}{oam payload}

where CW and ACH start with 0000 and 0001 respectively.

So at the PW level the label stacks are identical, it is only
the payload of the label stack that differs.

We only use the GAL when we want to run OAM directly over
an LSP not over the pseudowire.

> types as well as OAM, MCC, DCC etc. 

This is what we have for LSP OAM. What does the equivalent data packet 
look like?

- Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 10 Mar 2009 18:15:45 +0100

Malcolm,

The forwarded information is the MPLS-TP LSP Characteristic Information
(LSP_CI) and the MPLS-TP MS-PW Characteristic Information (PW_CI). 

The GAL and ACH fields are both part of the LSP_CI and the ACH is part of
the PW_CI traffic units. 

As per G.8110, the S-bit and TTL-bits or the label stack entry header are
also part of the CI and hide the GAL and ACH fields during forwarding.

The S-bit provides the first subfield of the MPLS-TP Payload Type.

LSP_CI packet formats are illustrated below:

PW_CI and VPLS_CI packet formats are illustrated below:

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

In high availability networks (like the Transport network) the "killer"
faults are the ones that you do not detect.  The normal conversation about
these faults is "well that should not have happened...." but "stuff
happens".  I am not an expert on MPLS equipment implementations or the
control protocols so I am seeking expert guidance.

So with that mind set:

I agree that only the top label is use forwarding so no problems "in the
network".  However at the node that originates an terminates the MPLS-TP
path we do see a difference in the pdu structure:
For traffic the pdu is:  {label X S=1}{Payload} For OAM the pdu is:  {label
X S=0}{GAL S=1}{ACh; Payload}

Clearly these are different label stacks both at the originating and
terminating nodes.  The question is do differences create a significant risk
of undetected faults due to the different treatment of OAM and the data path
in either the originating or terminating processes.  Remember the more
successful MPLS-TP the greater the chance that a corner case fault will
appear.....

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

There are no standard methods for looking at any other label and in any case
this is only done in networks where the path is chosen by an IGP.

If we always use a PW then the requirement for client data, OAM, SCC, MCC to
receive identical treatment in the path to the PE occurs because the label
stack is identical.

Stewart

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 10 Mar 2009 19:40:22 +0000

> the rest of the document.

Purely to aid those of IETF persuasion to visualise the concept being
defined.

> useful clarification and therefore should be included.

OK I have included.

> planes) must be maintained between them.

I think we now have that covered, see requirements 23 & 24 below (with
emphasis as discussed above):

   23  In an environment where an MPLS-TP layer network is supporting a
       client layer network, and the MPLS-TP layer network is supported
       by a server layer network then operation of the MPLS-TP layer
       network MUST be possible without any dependencies on the server
       or client layer network.

       A.  The server layer MUST guarantee that the traffic loading
           imposed by other clients does not cause the transport service
           provided to the MPLS-TP layer to fall bellow the agreed
           level.  Mechanisms to achieve this are outside the scope of
           these requirements.

       B.  It MUST be possible to isolate the control and management
           planes of the MPLS-TP layer network from the control and
           management planes of the client and server layer networks.

   24  A solution MUST be provided to support the transport of a client
       MPLS or MPLS-TP layer network over a server MPLS or MPLS-TP layer
       network.

       A.  The level of co-ordination required between the client and
           server MPLS(-TP) layer networks MUST be minimised (preferably
           no co-ordination will be required).

       B.  The MPLS(-TP) server layer network MUST be capable of
           transporting the complete set of packets generated by the
           client MPLS(-TP) layer network, which may contain packets
           that are not MPLS packets (e.g.  IP or CNLS packets used by
           the control/management plane of the client MPLS(-TP) layer
           network).

Let me know if the above is not sufficient.

Ben

---

From: <[email-masked]>
Date: Wed, 11 Mar 2009 13:45:27 -0000

Thanks Stewart,

This is very useful mail since it starts to clarify what is being
proposed for the DP in MPLS-TP...this was not at all clear before.  Can
I assume this has been discussed and agreed in the Design Team now?  

However, I have a few further questions that I hope you can answer
please.

Stewart wrote back to Malcolm:  10 March 2009 15:46

<snipped>
> traffic pdu is:  {label X S=1}{CW}{data payload}

NH=> Should this not be:
 traffic pdu is:  {label X S=1}{CW}{PID}{data payload}
                                    ^^^

> where CW and ACH start with 0000 and 0001 respectively.

NH=> I assume this is mainly for historical reasons wrt what had to be
done to make MPLS LDP work for non IP/MPLS clients and ECMP,  but of
course we don't need this ECMP fix for MPLS-TP and all clients must be
treated equally....though we still have sublayering of LSPs which does
have some impact (see later).

I suppose the 1st nibble 0000 is now being use to differentiate DP
traffic from 'all else' (1st nibble 0001).  So the DP OAM is still
lumped-in with the 'all else' here instead of being part of the DP
traffic header....though I do note that the label stacks are now
identical, which was my main concern previously (this was not at all
clear before and I suspect many people thought, as I did, that it was
under the GAL). 

Can we also assume the Seq No field will also be disabled (to all 0s
say) since a transparent transport network must not re-order client
symbols?

What happens to the other fields left in the rest of the CW for various
clients?

I think it would be useful if the DP adaptations for all client/OAM
cases were defined somewhere for MPLS-TP.

> the payload of the label stack that differs.

NH=> Do we really need to keep calling these PWs now Stewart?  I believe
you agree that we must not create a further co-ps mode 'PW layer
network' above MPLS-TP (as has happened in MPLS) as the conditions that
spawned PWs have had to be removed.  So what we have now is just some
form of common adaptation for all clients and we have MPLS-TP LSPs
(which are not the same as MPLS LSPs/PWs as they have the PID
field....indeed, the most significant part of the adaptation here is the
addition of the PID field).

I still think the Design Team should have looked at GFP adaptation
however, as this already has a PID field and aligns with the adaptation
used in current SDH/OTN transport networks for their clients.

> an LSP not over the pseudowire.

NH=> I think the main purpose of the GAL should be to provide a
logically OOB channel between adjacent nodes to carry the CP/MP
protocols.  

With what you note above, this strictly means that the OAM running under
the GAL is monitoring the GAL channel.  Is this correct?  Is there any
other reason to run OAM under the GAL on a sublayer of the traffic
carrying LSP?

Thanks...regards, Neil
<snipped to end>

---

From: "tom.petch" <[email-masked]>
Date: Wed, 11 Mar 2009 11:35:02 +0100

Maarten

I would find the points you make easier to follow if you could find a way to use
different names for your diagrams, such as TM_Layer_Stack_Version_2.jpg
Currently I have about ten all named outlook.jpg and since they do not display
as part of the e-mail- what I see is the blank lines as you see just beneath
this - I have to work hard to piece it all together.

Tom Petch

----- Original Message -----
From: "Maarten Vissers" <[email-masked]>
To: "'Malcolm Betts'" <[email-masked]>; <[email-masked]>; "'Loa
Andersson'" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 10, 2009 6:15 PM
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

---

From: "Malcolm Betts" <[email-masked]>
Date: Thu, 12 Mar 2009 08:51:11 -0400

Ben, looks good to me, I may change my mind when I read the complete
draft ;) 

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Tuesday, March 10, 2009 3:40 PM
To: Betts, Malcolm (CAR:X632); Harrison,N,Neil,CXM R; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

On 09/03/2009 13:46, "Malcolm Betts" <[email-masked]> wrote:
>> The MPLS-TP Requirements make no explicit mention of PWs except in 
>> the definitions. Whether or not PWs are part of MPLS-TP is for the 
>> solutions to determine not the requirements.
> 
> So why leave PW in the definitions section if they are not mentioned 
> in the rest of the document.

>> " In an environment where an MPLS-TP layer network is supporting a 
>> client network, and the MPLS-TP layer network is supported by a 
>> server layer network then operation of the MPLS-TP layer network MUST

>> be possible without any dependencies on the server or client 
>> network."
>> 

>> original requirement 23 "It MUST be possible to operate the layers of

>> a multi-layer network that includes an MPLS-TP layer autonomously." 
>> or my proposed requirement 23 below?
> 

OK I have included.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 12 Mar 2009 23:28:41 +0100

Malcolm,
 
You asked the question:
> The question is do differences create a significant risk of undetected
faults due to the different
> treatment of OAM and the data path in either the originating or
terminating processes.
 
The packet formats of the LSP_CI, PW_CI and VPLS_CI are inspected by the so
called "OAM Extraction Process"
in the termination and adaptation functions. Refer to G.8021 and G.8121 for
examples of such OAM Extraction Processes.
For the MPLS-TP case and assuming the packet formats below, these OAM
Extraction Processes would inspect the top 
few rows of those packets to determine the type of payload/protocol (e.g.
OAM CCM) that is carried. 
This can be illustrated as follows for the LSP OAM, MS-PW OAM and VPLS OAM:
 
LSP OAM with GAL:
-----------------------------

LSP OAM without GAL:
----------------------------------

MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:
--------------------------------

 
I hope you understand that all packets are treated the same way in a
termination or adaptation OAM Extraction process. All (OAM and DATA) packets
are inspected on the six, four or two fields and the values in those fields
determine if a packet contains OAM or DATA.
 
The GAL is really not required as its information is a copy of the
information in the S-bit of the label and the first 4-bit of the ACH.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: dinsdag 10 maart 2009 18:16
To: 'Malcolm Betts'; [email-masked]; 'Loa Andersson'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

Malcolm,

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 13 Mar 2009 07:28:55 +0100

Tom,

Thank you for this feedback.

I was not aware that these figures do not show up inside the email text
itself. 
I am using Outlook 2003 in which those figures do show up inline with the
text.
 
I will upload the figures as separate files later today.

Regards,
Maarten 

-----Original Message-----
From: tom.petch [mailto:[email-masked]] 
Sent: woensdag 11 maart 2009 11:35
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

Maarten

I would find the points you make easier to follow if you could find a way to
use different names for your diagrams, such as TM_Layer_Stack_Version_2.jpg
Currently I have about ten all named outlook.jpg and since they do not
display as part of the e-mail- what I see is the blank lines as you see just
beneath this - I have to work hard to piece it all together.

Tom Petch

----- Original Message -----
From: "Maarten Vissers" <[email-masked]>
To: "'Malcolm Betts'" <[email-masked]>; <[email-masked]>; "'Loa
Andersson'" <[email-masked]>

> The GAL and ACH fields are both part of the LSP_CI and the ACH is part 
> of the PW_CI traffic units.
>
> As per G.8110, the S-bit and TTL-bits or the label stack entry header 
> are also part of the CI and hide the GAL and ACH fields during forwarding.
>

---

From: <[email-masked]>
Date: Fri, 13 Mar 2009 06:32:48 -0000

Nice pictures Maarten, but all of this is not required:
 
-    there cannot be MS-PWs in MPLS-TP....MS-PWs represent a co-ps layer
network above MPLS-TP.  If this is true then MPLS-TP has failed as a
transport network.
 
-    there must be no interworking of Ethernet and MPLS-TP.....this is
more than OAM, though even that is not the same, eg there must be no
FDI/AIS in a cl-ps network like Ethernet, which is why IEEE threw this
out of .1ag.  There is major DP/CP functional mismatch between MPLS-TP
and Ethernet so there is no way I can agree to interworking these as
peers.  And in any case neither is a top-of-stack network so any
interworking would be a wasted exercise anyway.
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Maarten Vissers
	Sent: 12 March 2009 22:29
	To: 'Malcolm Betts'
	Cc: [email-masked]; [email-masked]
	Subject: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess

	Malcolm,
	 
	You asked the question:
	> The question is do differences create a significant risk of
undetected faults due to the different
	> treatment of OAM and the data path in either the originating
or terminating processes.
	 
	The packet formats of the LSP_CI, PW_CI and VPLS_CI are
inspected by the so called "OAM Extraction Process"
	in the termination and adaptation functions. Refer to G.8021 and
G.8121 for examples of such OAM Extraction Processes.
	For the MPLS-TP case and assuming the packet formats below,
these OAM Extraction Processes would inspect the top 
	few rows of those packets to determine the type of
payload/protocol (e.g. OAM CCM) that is carried. 
	This can be illustrated as follows for the LSP OAM, MS-PW OAM
and VPLS OAM:
	 
	LSP OAM with GAL:

	LSP OAM without GAL:

	MS-PW OAM:
	--------------------

	VPLS (i.e. ETH) OAM:

	 
	I hope you understand that all packets are treated the same way
in a termination or adaptation OAM Extraction process. All (OAM and
DATA) packets are inspected on the six, four or two fields and the
values in those fields determine if a packet contains OAM or DATA.
	 
	The GAL is really not required as its information is a copy of
the information in the S-bit of the label and the first 4-bit of the
ACH.
	 
	Regards,
	Maarten

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Maarten Vissers
	Sent: dinsdag 10 maart 2009 18:16
	To: 'Malcolm Betts'; [email-masked]; 'Loa Andersson'
	Cc: [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

	Malcolm,
	
	The forwarded information is the MPLS-TP LSP Characteristic
Information (LSP_CI) and the MPLS-TP MS-PW Characteristic Information
(PW_CI). 

	The GAL and ACH fields are both part of the LSP_CI and the ACH
is part of the PW_CI traffic units. 

	As per G.8110, the S-bit and TTL-bits or the label stack entry
header are also part of the CI and hide the GAL and ACH fields during
forwarding.

	The S-bit provides the first subfield of the MPLS-TP Payload
Type.

	 

	

	Regards,
	Maarten

	-----Original Message-----
	From: Malcolm Betts [mailto:[email-masked]]
	Sent: dinsdag 10 maart 2009 16:15
	To: [email-masked]; Loa Andersson
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

	In high availability networks (like the Transport network) the
"killer"
	faults are the ones that you do not detect.  The normal
conversation about these faults is "well that should not have
happened...." but "stuff happens".  I am not an expert on MPLS equipment
implementations or the control protocols so I am seeking expert
guidance.
	
	So with that mind set:
	
	I agree that only the top label is use forwarding so no problems
"in the network".  However at the node that originates an terminates the
MPLS-TP path we do see a difference in the pdu structure:
	For traffic the pdu is:  {label X S=1}{Payload} For OAM the pdu
is:  {label X S=0}{GAL S=1}{ACh; Payload}
	
	Clearly these are different label stacks both at the originating
and terminating nodes.  The question is do differences create a
significant risk of undetected faults due to the different treatment of
OAM and the data path in either the originating or terminating
processes.  Remember the more successful MPLS-TP the greater the chance
that a corner case fault will appear.....
	
	The "uniform stack" for MPLS-TP would be: {label X S=0}{GAL
S=1}{ACh*; Payload} where the ACh* code point would also include the
client payload types as well as OAM, MCC, DCC etc.

	Malcolm Betts
	Nortel Networks
	
	-----Original Message-----
	From: Stewart Bryant [mailto:[email-masked]]
	Sent: Monday, March 09, 2009 11:08 AM
	To: Loa Andersson
	Cc: Betts, Malcolm (CAR:X632); [email-masked];
[email-masked]
MPLS(-TP)
	overMPLS(-TP)

	
	> by "header structure" or did I miss something
	
	There is a bunch of confusion about what happens in MPLS
networks.
	
	In transport networks - set up statically or via GMPLS only the
top label effects the path (although TC effects the queuing).
	
	There are no standard methods for looking at any other label and
in any case this is only done in networks where the path is chosen by an
IGP.
	
	If we always use a PW then the requirement for client data, OAM,
SCC, MCC to receive identical treatment in the path to the PE occurs
because the label stack is identical.
	
	The only case where the label stack will be different is when we
are carrying an LSP OAM in which case the GAL needs to be present.

	Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 13 Mar 2009 08:38:56 +0100

Hello Neil,
 
Good morning.
Thank you for responding.

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 13 maart 2009 7:33
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess

 
[mv] As far as I understand the MPLS-TP requirements, there is a "transport
service layer" in MPLS-TP. Do you agree?
 
[mv] It seems that we are struggling with the name of this "transport
service layer". If I understand your persistent comment well, then you do
not like to refer to this transport service layer as the "PW" layer. At some
point in time I got the impression that you would like to deploy a second
instance of the MPLS-TP LSP as transport service layer. 
When I look at what is present in a number of networks today, then I find
the use of an Ethernet VLAN layer as transport service layer in existing
MPLS networks. This use of an Ethernet VLAN layer as transport service layer
would be aligned MEF's MEN model in which the EVC (i.e. Ethernet VLAN) is
providing the transport service layer role. This EVC layer is then supported
by the MEN Transport layer, which could be another Ethernet VLAN instance,
or MPLS LSP or MPLS-TP LSP or PBB-TE TESI, or ..., 
 
-    there must be no interworking of Ethernet and MPLS-TP..... 
 
[mv] if we agree to deploy the EVC layer as transport service layer in
MPLS-TP there will indeed be no interworking necessary at the transport
service layer of a hybrid ethernet and mpls-tp packet transport network. 
 
[mv] if we however agree to define a "MS-PW" or "LSP" based transport
service layer in the MPLS-TP stack to support p2p and p2mp services, then
there must be interworking between p2p/p2mp VLANs in the ethernet domains
and those p2p/p2mp "MS-PW"/"LSP"s in the MPLS-TP domain if we want to offer
at least p2p and p2mp services to customers in such hybrid packet transport
network. As we discussed last month in London, the p2p/p2mp VLAN and
p2p/p2mp "MS-PW"/"LSP" reside in different partitions within the same
"transport service layer". In most cases so far partitions in one layer
deploy the same technology. In this case, partitions in the transport
service layer deploy different technologies, but the information carried in
both cases is the same.
 
 this is more than OAM, though even that is not the same, eg there must be
no FDI/AIS in a cl-ps network like Ethernet, which is why IEEE threw this
out of .1ag.   
 
[mv] IEEE left out AIS because in a STP controlled domain restoration of the
VLANs is an implicit feature. This implies that generation of AIS at the end
of a failed link has to be stopped within a few second'; i.e. as soon as the
VLAN's registration on this port is removed.
 
[mv] ETH-AIS is an important feature in ethernet transport networks that do
not have end-to-end restoration active. ETH OAM checks the status and
performance of the VLAN. VLANs in a transport network are set up under
control of network management with or without the help of a GMPLS control
plane. Such VLANs have a fixed connectivity, similar as a bidirectional
point-to-multipoint connection. The ETH OAM checks this fixed connectivity;
i.e. the connection-oriented part of the VLAN is checked (ETH OAM does not
check the connectionless part (i.e. filtering rules) pro-actively; it is
however capable to check the connectionless part on-demand via its LTM/LTR
OAM). If such VLAN is interrupted and not restored, ETH-AIS must be
generated to prevent ETH LOC alarms to be raised from the downstream MEP
functions.
 
 There is major DP/CP functional mismatch between MPLS-TP and Ethernet so
there is no way I can agree to interworking these as peers.  And in any case
neither is a top-of-stack network so any interworking would be a wasted
exercise anyway. 
 
[mv] Ethernet VLAN deployment in packet transport networks is under control
of network management (possibly with the help of a GMPLS control plane).
Ethernet VLANs are Traffic Engineered. 
Such traffic engineered p2p VLANs and p2mp VLANs deploy just a Broadcast
Forwarding Rule and **no** Unicast/Multicast Filtering Rules. Traffic
engineered MPLS-TP "MS-PW"/"LSP" transport service layer connections also
deploy a Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering
Rules. Both transport entities are traffic engineered. It is as such
possible to interwork these two transport service layer transport entities
without too much problems if we make sure that the OAM PDU formats are very
common.
 
[mv] But if we agree to deploy the EVC as transport service layer in
MPLS-TP, then we do not need to create interworking between two
technological different partitions in the transport service layer, as there
will be just a single technology deployed in all partitions.
 
[mv] Deployment of the EVC as transport service layer technology however
requires that the EVC must support more then only Ethernet and TDM clients.
I.e. must support also ATM, FR, PPP, etc clients as defined in PWE3. To
support those other PWE3 clients, we need to get a number of EtherType
values, one for each client. I will upload later a set of slides presenting
those PWe3 mappings into an EVC, inluding a list of EtherTypes that would be
required to support this.
 
Regards,
Maarten
 
regards, Neil

  _____  

Malcolm,
 
terminating processes.

LSP OAM with GAL:

LSP OAM without GAL:

MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:

 

Regards,
Maarten

  _____  

Malcolm,

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

---

From: <[email-masked]>
Date: Fri, 13 Mar 2009 09:06:36 -0000

And good morning to you too Maarten.......

	From: Maarten Vissers [mailto:[email-masked]] 
	Sent: 13 March 2009 07:39
	To: Harrison,N,Neil,CXM R; [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in
OAM ExtractionProcess

	Hello Neil,
	 
	Good morning.

	Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in
OAM ExtractionProcess

	-    there cannot be MS-PWs in MPLS-TP....MS-PWs represent a
co-ps layer network above MPLS-TP.  If this is true then MPLS-TP has
failed as a transport network. 
	 
	[mv] As far as I understand the MPLS-TP requirements, there is a
"transport service layer" in MPLS-TP. Do you agree? 
	NH=> I have no idea what this term means.   MPLS-TP is supposed
to be a transport network....just like a load of others are.
	 
	[mv] It seems that we are struggling with the name of this
"transport service layer". If I understand your persistent comment well,
then you do not like to refer to this transport service layer as the
"PW" layer. 
	NH=> Let's be very clear here.  MPLS-TP is supposed to be a
transport network itself...this is whole purpose of the exercise.  PWs
started life as an adaptation to get around architectural flaws in MPLS.
Unfortunately, PWE3 decided several years ago to make PWs
multi-hop...and as soon as they did that there was a major shift in what
PWs represented....they were no longer adaptation but a full-blown co-ps
layer network.  This was a bad mistake, and I repeatedly warned PWE3 not
to do this.  
	 
	The architectural flaws in MPLS that spawned PWs *must* be
corrected in MPLS-TP...else, quite simply, it cannot be a transport
network.  I do think most folks understand this.  So, we cannot have
MS-PWs in MPLS-TP...unless we want MPLS-TP to look very silly.

	  At some point in time I got the impression that you would like
to deploy a second instance of the MPLS-TP LSP as transport service
layer. 
	NH=> We are supposed to designing MPLS-TP to be a non
top-of-stack co-ps mode transport network, so all it can do is create
higher layer network topology....nothing unusual here, we have lots of
technologies that provide such a role, esp in the co-cs mode.
	  
	When I look at what is present in a number of networks today,
then I find the use of an Ethernet VLAN layer as transport service layer
in existing MPLS networks. 
	NH=> I don't understand why you home-in on VLANs.  Ethernet
in-total is used as a server to MPLS.....MPLS does not have a
physical/section layer specification and so must run over a technology
that does, ie can modulate an EM wave on radio/optics/metrallic
media.....which actually is not a great place to start for a technology
that aspires to be a *transport* network if you think about it. 
	 
	  This use of an Ethernet VLAN layer as transport service layer
would be aligned MEF's MEN model in which the EVC (i.e. Ethernet VLAN)
is providing the transport service layer role.  This EVC layer is then
supported by the MEN Transport layer, which could be another Ethernet
VLAN instance, or MPLS LSP or MPLS-TP LSP or PBB-TE TESI, or ...,  
	NH=> I am not sure what your point is here.  There is no such
thing as 'VLAN layer networks'....there are 'Ethernet layer networks'
however. 

	[mv] if we agree to deploy the EVC layer as transport service
layer in MPLS-TP there will indeed be no interworking necessary at the
transport service layer of a hybrid ethernet and mpls-tp packet
transport network. 
	 
	[mv] if we however agree to define a "MS-PW" or "LSP" based
transport service layer in the MPLS-TP stack to support p2p and p2mp
services, then there must be interworking between p2p/p2mp VLANs in the
ethernet domains and those p2p/p2mp "MS-PW"/"LSP"s in the MPLS-TP domain
if we want to offer at least p2p and p2mp services to customers in such
hybrid packet transport network. 
	NH=> I disagree with you.  There is no need whatsover to peer
interwork Ethernet with MPLS or MPLS-TP or (heaven forbid) a PW layer
network.  The rule is very simple:  If not top-of-stack then don't peer
interwork.  And that is really all there is to be said on the matter.
If you don't respect this all you will do is create lots of work and
costs doing protocol conversion between all the DP/CP functional
components of technologies that have no need to do this.  I do not want
to see our industry expending effort/money on things that are simply not
necessary.
	 
	  As we discussed last month in London, the p2p/p2mp VLAN and
p2p/p2mp "MS-PW"/"LSP" reside in different partitions within the same
"transport service layer".  
	NH=> No they don't....this is stuff you have made up.  I don't
think you listened to what I and Andy said to you.  These are things you
think are sensible because they can be done.  But like merging in the
co-ps mode, just because one can do something does not make it a
sensible/worthwhile thing to do...there is a whole raft of crazy things
I could dream up for us to work on.  The bottom line is what I stated
above....if not top-of-stack then forget interworking as peers...esp if
the networks belong to different modes!.....it really is that simple.
We cannot afford to be throwing money away on unnecessary protocol
conversion work.
	 
	 In most cases so far partitions in one layer deploy the same
technology. In this case, partitions in the transport service layer
deploy different technologies, but the information carried in both cases
is the same.
	 
	 this is more than OAM, though even that is not the same, eg
there must be no FDI/AIS in a cl-ps network like Ethernet, which is why
IEEE threw this out of .1ag.   

	[mv] IEEE left out AIS because in a STP controlled domain
restoration of the VLANs is an implicit feature. This implies that
generation of AIS at the end of a failed link has to be stopped within a
few second'; i.e. as soon as the VLAN's registration on this port is
removed. 
	NH=> IEEE threw out AIS/FDI because it makes no sense for cl-ps
networks.  If you think it's such a great idea then go and try and
convince IETF to include it in IP and see what reaction you get.  And
here is something else that may shock you....a couple of years ago Andy
(Reid) and I were discussing this whole notion of AIS/FDI in the 3
networks modes.  We concluded that it would be better even if the co-ps
mode did not have AIS/FDI, not just the cl-ps mode (which is obvious).
AIS/FDI is only truly sensible in the co-cs mode.  I can explain why but
this now off topic....I only mention this to illustrate that one cannot
have identical functional specifications for the 3 modes (and this is
more than OAM)....it is their differences that are the important bits.
	 
	[mv] ETH-AIS is an important feature in ethernet transport
networks that do not have end-to-end restoration active. ETH OAM checks
the status and performance of the VLAN. VLANs in a transport network are
set up under control of network management with or without the help of a
GMPLS control plane. Such VLANs have a fixed connectivity, similar as a
bidirectional point-to-multipoint connection. The ETH OAM checks this
fixed connectivity; i.e. the connection-oriented part of the VLAN is
checked (ETH OAM does not check the connectionless part (i.e. filtering
rules) pro-actively; it is however capable to check the connectionless
part on-demand via its LTM/LTR OAM). If such VLAN is interrupted and not
restored, ETH-AIS must be generated to prevent ETH LOC alarms to be
raised from the downstream MEP functions.
	NH=> I don't agree with your view of networking expressed above.
	 
	 There is major DP/CP functional mismatch between MPLS-TP and
Ethernet so there is no way I can agree to interworking these as peers.
And in any case neither is a top-of-stack network so any interworking
would be a wasted exercise anyway. 
	 
	[mv] Ethernet VLAN deployment in packet transport networks is
under control of network management (possibly with the help of a GMPLS
control plane). Ethernet VLANs are Traffic Engineered. 
	Such traffic engineered p2p VLANs and p2mp VLANs deploy just a
Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering Rules.
Traffic engineered MPLS-TP "MS-PW"/"LSP" transport service layer
connections also deploy a Broadcast Forwarding Rule and **no**
Unicast/Multicast Filtering Rules. Both transport entities are traffic
engineered. It is as such possible to interwork these two transport
service layer transport entities without too much problems if we make
sure that the OAM PDU formats are very common.
	NH=> I do not agree with this.
	 
	[mv] But if we agree to deploy the EVC as transport service
layer in MPLS-TP, then we do not need to create interworking between two
technological different partitions in the transport service layer, as
there will be just a single technology deployed in all partitions.
	 
	[mv] Deployment of the EVC as transport service layer technology
however requires that the EVC must support more then only Ethernet and
TDM clients. I.e. must support also ATM, FR, PPP, etc clients as defined
in PWE3. To support those other PWE3 clients, we need to get a number of
EtherType values, one for each client. 
	NH=> You may not be aware, but there is now an Ethetype for
GFP...its 891F.  Now you can use UPI codepoints for legacy technologies
without bothering IEEE for an Ethetype for every technology that does
not have one....but if you want to go and get then fine.
	 
	regards, Neil
	 
	  I will upload later a set of slides presenting those PWe3
mappings into an EVC, inluding a list of EtherTypes that would be
required to support this.
	 
	Regards,
	Maarten
	 
	regards, Neil

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
		Sent: 12 March 2009 22:29
		To: 'Malcolm Betts'
		Cc: [email-masked]; [email-masked]
		Subject: [mpls-tp] MPLS-TP protocol/payload type usage
in OAM ExtractionProcess

		Malcolm,
		 
		You asked the question:
		> The question is do differences create a significant
risk of undetected faults due to the different
		> treatment of OAM and the data path in either the
originating or terminating processes.
		 
		The packet formats of the LSP_CI, PW_CI and VPLS_CI are
inspected by the so called "OAM Extraction Process"
		in the termination and adaptation functions. Refer to
G.8021 and G.8121 for examples of such OAM Extraction Processes.
		For the MPLS-TP case and assuming the packet formats
below, these OAM Extraction Processes would inspect the top 
		few rows of those packets to determine the type of
payload/protocol (e.g. OAM CCM) that is carried. 
		This can be illustrated as follows for the LSP OAM,
MS-PW OAM and VPLS OAM:
		 
		LSP OAM with GAL:

		LSP OAM without GAL:

		MS-PW OAM:
		--------------------

		VPLS (i.e. ETH) OAM:

		 
		I hope you understand that all packets are treated the
same way in a termination or adaptation OAM Extraction process. All (OAM
and DATA) packets are inspected on the six, four or two fields and the
values in those fields determine if a packet contains OAM or DATA.
		 
		The GAL is really not required as its information is a
copy of the information in the S-bit of the label and the first 4-bit of
the ACH.
		 
		Regards,
		Maarten

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
		Sent: dinsdag 10 maart 2009 18:16
		To: 'Malcolm Betts'; [email-masked]; 'Loa Andersson'
		Cc: [email-masked]; [email-masked]
		Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements
for MPLS(-TP)overMPLS(-TP)

		Malcolm,
		
		The forwarded information is the MPLS-TP LSP
Characteristic Information (LSP_CI) and the MPLS-TP MS-PW Characteristic
Information (PW_CI). 

		The GAL and ACH fields are both part of the LSP_CI and
the ACH is part of the PW_CI traffic units. 

		As per G.8110, the S-bit and TTL-bits or the label stack
entry header are also part of the CI and hide the GAL and ACH fields
during forwarding.

		The S-bit provides the first subfield of the MPLS-TP
Payload Type.

		 

		

		Regards,
		Maarten

		-----Original Message-----
		From: Malcolm Betts [mailto:[email-masked]]
		Sent: dinsdag 10 maart 2009 16:15
		To: [email-masked]; Loa Andersson
		Cc: [email-masked]; [email-masked]
		Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements
for MPLS(-TP)overMPLS(-TP)
		
		First a minor digression to explain my paranoia on this
issue ;)
		
		In high availability networks (like the Transport
network) the "killer"
		
		So with that mind set:
		
		I agree that only the top label is use forwarding so no
problems "in the network".  However at the node that originates an
terminates the MPLS-TP path we do see a difference in the pdu structure:
		For traffic the pdu is:  {label X S=1}{Payload} For OAM
the pdu is:  {label X S=0}{GAL S=1}{ACh; Payload}
		
		Clearly these are different label stacks both at the
originating and terminating nodes.  The question is do differences
create a significant risk of undetected faults due to the different
treatment of OAM and the data path in either the originating or
terminating processes.  Remember the more successful MPLS-TP the greater
the chance that a corner case fault will appear.....
		
		The "uniform stack" for MPLS-TP would be: {label X
S=0}{GAL S=1}{ACh*; Payload} where the ACh* code point would also
include the client payload types as well as OAM, MCC, DCC etc.

		Malcolm Betts
		Nortel Networks
		
		-----Original Message-----
		From: Stewart Bryant [mailto:[email-masked]]
		Sent: Monday, March 09, 2009 11:08 AM
		To: Loa Andersson
		Cc: Betts, Malcolm (CAR:X632); [email-masked];
[email-masked]
		Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements
for MPLS(-TP)
		overMPLS(-TP)

		

		In transport networks - set up statically or via GMPLS
only the top label effects the path (although TC effects the queuing).
		
		There are no standard methods for looking at any other
label and in any case this is only done in networks where the path is
chosen by an IGP.
		
		If we always use a PW then the requirement for client
data, OAM, SCC, MCC to receive identical treatment in the path to the PE
occurs because the label stack is identical.
		
		The only case where the label stack will be different is
when we are carrying an LSP OAM in which case the GAL needs to be
present.

		Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 13 Mar 2009 08:20:55 -0400

> -    there cannot be MS-PWs in MPLS-TP....MS-PWs represent a co-ps  
> layer network above MPLS-TP.  If this is true then MPLS-TP has  

	I disagree; I actually see lots of benefit in using PWs for MPLS-TP,  
as we've stated before.

>  -    there must be no interworking of Ethernet and MPLS-TP.....this  
> is more than OAM, though even that is not the same, eg there must be  
> no FDI/AIS in a cl-ps network like Ethernet, which is why IEEE threw  
> this out of .1ag.  There is major DP/CP functional mismatch between  
> MPLS-TP and Ethernet so there is no way I can agree to interworking  
> these as peers.  And in any case neither is a top-of-stack network  
> so any interworking would be a wasted exercise anyway.

	Here we agree.  Lets keep things simple. Interworking between  
ethernet, MPLS-TP or MPLS (say on the same switch) is a recipe for  
complexity beyond what is necessary.

	--Tom

> Behalf Of Maarten Vissers
> The packet formats of the LSP_CI, PW_CI and VPLS_CI are inspected by  
> the so called "OAM Extraction Process"
> in the termination and adaptation functions. Refer to G.8021 and G. 
> 8121 for examples of such OAM Extraction Processes.
> For the MPLS-TP case and assuming the packet formats below, these  
> OAM Extraction Processes would inspect the top
> few rows of those packets to determine the type of payload/protocol  
> (e.g. OAM CCM) that is carried.
> termination or adaptation OAM Extraction process. All (OAM and DATA)  
> packets are inspected on the six, four or two fields and the values  
> in those fields determine if a packet contains OAM or DATA.
>
> Behalf Of Maarten Vissers
> Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(- 
> TP)overMPLS(-TP)
>
> Malcolm,
>
> Information (LSP_CI) and the MPLS-TP MS-PW Characteristic  
> Information (PW_CI).
>
> The GAL and ACH fields are both part of the LSP_CI and the ACH is  
> part of the PW_CI traffic units.
>
> header are also part of the CI and hide the GAL and ACH fields  
> during forwarding.
>
> Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(- 
> TP)overMPLS(-TP)
>
> "stuff happens".  I am not an expert on MPLS equipment  
> I agree that only the top label is use forwarding so no problems "in  
> the network".  However at the node that originates an terminates the  
> For traffic the pdu is:  {label X S=1}{Payload} For OAM the pdu is:   
> {label X S=0}{GAL S=1}{ACh; Payload}
>
> terminating nodes.  The question is do differences create a  
> significant risk of undetected faults due to the different treatment  
> of OAM and the data path in either the originating or terminating  
> processes.  Remember the more successful MPLS-TP the greater the  
> chance that a corner case fault will appear.....
>
> The "uniform stack" for MPLS-TP would be: {label X S=0}{GAL S=1} 
> {ACh*; Payload} where the ACh* code point would also include the  
> any case this is only done in networks where the path is chosen by  
> an IGP.
>

---

From: <[email-masked]>
Date: Fri, 13 Mar 2009 12:30:10 -0000

I think you are missing the point Tom.  If MPLS is to be a transport
network then it can only have PWs *as adaptation*.....they cannot be
multi-hop else they become a switched/networked entity (in other words
'they create a network above MPLS-TP').  Perhaps you don't understand
this distinction?  This mistake was nearly made with GFP many years ago,
those alert to the issues wisely stopped it becoming a switched entity.
 
I think we can fix this for MPLS-TP however.
 
Wrt peer interworking, then yes of course we agree here......if one
looks at the problem technically one can easily work out there is no
need to peer-interwork *any* layer networks that are not top-of-stack.
It's a very simple rule.  I'll send you a paper that fully explains this
later.
 
regards, neil

	From: Thomas Nadeau [mailto:[email-masked]] 
	Sent: 13 March 2009 12:21
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
	Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage in
OAM ExtractionProcess

		-    there cannot be MS-PWs in MPLS-TP....MS-PWs
represent a co-ps layer network above MPLS-TP.  If this is true then
MPLS-TP has failed as a transport network.

	I disagree; I actually see lots of benefit in using PWs for
MPLS-TP, as we've stated before. 

		 -    there must be no interworking of Ethernet and
MPLS-TP.....this is more than OAM, though even that is not the same, eg
there must be no FDI/AIS in a cl-ps network like Ethernet, which is why
IEEE threw this out of .1ag.  There is major DP/CP functional mismatch
between MPLS-TP and Ethernet so there is no way I can agree to
interworking these as peers.  And in any case neither is a top-of-stack
network so any interworking would be a wasted exercise anyway.

	--Tom

		 regards, Neil

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
			Sent: 12 March 2009 22:29
			To: 'Malcolm Betts'
			Cc: [email-masked]; [email-masked]
			Subject: [mpls-tp] MPLS-TP protocol/payload type
usage in OAM ExtractionProcess

			Malcolm,
			 
			You asked the question:
			> The question is do differences create a
significant risk of undetected faults due to the different
			> treatment of OAM and the data path in either
the originating or terminating processes.
			 
			The packet formats of the LSP_CI, PW_CI and
VPLS_CI are inspected by the so called "OAM Extraction Process"
			in the termination and adaptation functions.
Refer to G.8021 and G.8121 for examples of such OAM Extraction
Processes.
			For the MPLS-TP case and assuming the packet
formats below, these OAM Extraction Processes would inspect the top 
			few rows of those packets to determine the type
of payload/protocol (e.g. OAM CCM) that is carried. 
			This can be illustrated as follows for the LSP
OAM, MS-PW OAM and VPLS OAM:
			 
			LSP OAM with GAL:
			 
			LSP OAM without GAL:
			 
			MS-PW OAM:
			--------------------

			VPLS (i.e. ETH) OAM:

			I hope you understand that all packets are
treated the same way in a termination or adaptation OAM Extraction
process. All (OAM and DATA) packets are inspected on the six, four or
two fields and the values in those fields determine if a packet contains
OAM or DATA.
			 
			The GAL is really not required as its
information is a copy of the information in the S-bit of the label and
the first 4-bit of the ACH.
			 
			Regards,
			Maarten

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
			Sent: dinsdag 10 maart 2009 18:16
			To: 'Malcolm Betts'; [email-masked]; 'Loa
Andersson'
			Cc: [email-masked]; [email-masked]
			Subject: Re: [mpls-tp] Clarifying MPLS-TP
requirements for MPLS(-TP)overMPLS(-TP)

			Malcolm,

			The GAL and ACH fields are both part of the
LSP_CI and the ACH is part of the PW_CI traffic units. 

			As per G.8110, the S-bit and TTL-bits or the
label stack entry header are also part of the CI and hide the GAL and
ACH fields during forwarding.

			The S-bit provides the first subfield of the
MPLS-TP Payload Type.

			 
			PW_CI and VPLS_CI packet formats are illustrated
below:

			Regards,
			Maarten

			-----Original Message-----
			From: Malcolm Betts [mailto:[email-masked]]
			Sent: dinsdag 10 maart 2009 16:15
			To: [email-masked]; Loa Andersson
			Cc: [email-masked]; [email-masked]
			Subject: RE: [mpls-tp] Clarifying MPLS-TP
requirements for MPLS(-TP)overMPLS(-TP)
			
			First a minor digression to explain my paranoia
on this issue ;)
			
			In high availability networks (like the
Transport network) the "killer"
			faults are the ones that you do not detect.  The
normal conversation about these faults is "well that should not have
happened...." but "stuff happens".  I am not an expert on MPLS equipment
implementations or the control protocols so I am seeking expert
guidance.
			
			So with that mind set:
			
			I agree that only the top label is use
forwarding so no problems "in the network".  However at the node that
originates an terminates the MPLS-TP path we do see a difference in the
pdu structure:
			For traffic the pdu is:  {label X S=1}{Payload}
For OAM the pdu is:  {label X S=0}{GAL S=1}{ACh; Payload}
			
			Clearly these are different label stacks both at
the originating and terminating nodes.  The question is do differences
create a significant risk of undetected faults due to the different
treatment of OAM and the data path in either the originating or
terminating processes.  Remember the more successful MPLS-TP the greater
the chance that a corner case fault will appear.....
			
			The "uniform stack" for MPLS-TP would be: {label
X S=0}{GAL S=1}{ACh*; Payload} where the ACh* code point would also
include the client payload types as well as OAM, MCC, DCC etc.

			Malcolm Betts
			Nortel Networks
			
			-----Original Message-----
			From: Stewart Bryant [mailto:[email-masked]]
			Sent: Monday, March 09, 2009 11:08 AM
			To: Loa Andersson
			Cc: Betts, Malcolm (CAR:X632);
[email-masked]; [email-masked]
			Subject: Re: [mpls-tp] Clarifying MPLS-TP
requirements for MPLS(-TP)
			overMPLS(-TP)

			
			> by "header structure" or did I miss something
			
			There is a bunch of confusion about what happens
in MPLS networks.
			
			In transport networks - set up statically or via
GMPLS only the top label effects the path (although TC effects the
queuing).
			
			There are no standard methods for looking at any
other label and in any case this is only done in networks where the path
is chosen by an IGP.
			
			If we always use a PW then the requirement for
client data, OAM, SCC, MCC to receive identical treatment in the path to
the PE occurs because the label stack is identical.
			
			The only case where the label stack will be
different is when we are carrying an LSP OAM in which case the GAL needs
to be present.

			Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 13 Mar 2009 15:18:32 +0100

Tom,
 
> I actually see lots of benefit in using PWs for MPLS-TP, as we've stated
before.
 
I believe that it is possible to design a transport service layer using the
MPLS-TP packet format.
This is what we essentially did in T-MPLS and which we documented in
G.8110.1 and G.8121.
 
At the time we did T-MPLS, we decided that it was not appropriate to reuse
the terms "PW" and "LSP"
as those terms are associated with some behaviour that was not (100%)
present in T-MPLS. 
As such we decided to refer to the layers as T-MPLS Channel, Path and
Section layers (TMC, TMP, TMS).
The basic packet formats were however the same.
 
- TMC was located at the same position in the layer stack as a MS-PW layer.
- TMP was located at the same position in the layer stack as a LSP layer.
- TMS was located at the same position in the layer stack as a section
layer.
 
TMC, TMP and TMS are all true co-ps layers.
 
In a T-MPLS network those layers would be complemented by an ETH Channel
layer to
support mp2mp and rmp E-TREE and E-LAN services.
- ETH Channel was located at the same position in the layer stack as a VPLS
layer.
 
At this point in time in the development of MPLS-TP, I get the impression
that the term "PW" for some
person is representing 1-to-1 what is available today in IP/MPLS networks.
To get around this issue, 
it may help to refer to the true co-ps MPLS-TP MS-PW with a different name.
E.g. refer to it as a
"MPLS VC".
 
In the same manner we could refer to the MPLS-TP LSP as a "MPLS VP". 
 
There will be no change in the packet format, only a change of name for this
packet format, such that we 
break the possible association with existing operational behaviour in an
IP/MPLS network.
 
> Interworking between ethernet, MPLS-TP or MPLS (say on the same switch) 
> is a recipe for complexity beyond what is necessary
 
I assume that you will agree with the fact that the packet transport network
contains both Ethernet VLAN
and MPLS technologies, and in future will also contain MPLS-TP technology.
 
I assume that you agree that customers in some part of the network connect
to Ethernet domains, 
while in other parts of the network they connect to MPLS and in future
MPLS-TP domains.
 
I assume that you agree that a customer should not have to care what
technology an operator or
multiple operators are using in the domains where this customer has its
buildings.
 
If so, then the hybrid Ethernet and MPLS(-TP) technology packet transport
network must be able
to support a customer service between any set of customer locations,
independent if those
locations are connected to domains with different technologies (e.g.
Ethernet and MPLS-TP).
 
An example presented some weeks ago on a carrier ethernet website was the
case of an E1 service
that had one endpoint behind an Ethenret domain and the other endpoint
behind a MPLS domain.
So at the first endpoint a device was present supporting MEF8, while at the
other endpoint a
device was present supporting RFC4553.
 
The answer today that we can give is to replace the RFC4553 device by a MEF8
device.
I.e. when both endpoints have MEF8 device, then the VLAN carrying the E1
service can 
be transported through the MPLS network as an Ethernet service using an
Ethernet PW, and
this Ethernet VLAN can be handed of to the Ethernet network were it will
continue to 
the other MEF8 device.
 
Some operators have made sure that they will not be confronted with such
incompatibility, and
they have designed their network with an Ethernet VLAN (in MEF terms an EVC)
as transport
service layer.
 
To make this decision was not too difficult a few year ago as there was only
a SS-PW (providing
just encapsulation and labelling), so there was no alternative available for
the ethernet vlan layer as
transport service layer in a multi-domain network.
 
With the extension of the SS-PW towards a transport service layer network
(started as MS-PW) 
we are introducing an MPLS(-TP) based alternative for the EVC. And this
alternative can not
support all services, i.e. it is only capable to support the p2p and p2mp
services. The EVC
is still required for the mp2mp and rmp services.
 
Therefore the introduction of a MPLS VC (co-ps MPLS-TP MS-PW) layer will
introduce an partial 
alternative for the EVC. And it will introduce more interworking problems
(e.g. MEF8 vs. RFC4553
interworking problems) in the network.
 
It is very bad to design a technology (MPLS-TP) that will introduce
interworking problems and
an inability to deliver services between locations that happen to be between
domains with different 
packet transport technologies.
 
In my opinion we either do not introduce such MPLS VC (co-ps MPLS-TP MS-PW)
layer and continue to 
deploy the EVC layer, or we make sure that the MPLS VC can be interworked
with the EVC.
 
The least complex alternative in my current understanding is to continue to
use the EVC layer as
transport service layer in both Ethernet and MPLS-TP domains. 
Note -  we have to support this in either case as a number of networks have
this as their
architecture. Any change from this architecture (i.e. to add the MPLS VC)
will introduce
only unnecessary complexity and interworking issues. 
 
Regards,
Maarten

  _____  

From: Thomas Nadeau [mailto:[email-masked]] 
Sent: vrijdag 13 maart 2009 13:21
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess

I disagree; I actually see lots of benefit in using PWs for MPLS-TP, as
we've stated before. 

 -    there must be no interworking of Ethernet and MPLS-TP.....this is more
than OAM, though even that is not the same, eg there must be no FDI/AIS in a
cl-ps network like Ethernet, which is why IEEE threw this out of .1ag.
There is major DP/CP functional mismatch between MPLS-TP and Ethernet so
there is no way I can agree to interworking these as peers.  And in any case
neither is a top-of-stack network so any interworking would be a wasted
exercise anyway.

Here we agree.  Lets keep things simple. Interworking between ethernet,
MPLS-TP or MPLS (say on the same switch) is a recipe for complexity beyond
what is necessary.

--Tom

 regards, Neil

  _____  

Malcolm,
 
terminating processes.

LSP OAM with GAL:
 
LSP OAM without GAL:
 
MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:

 
 
Regards,
Maarten

  _____  

Malcolm,

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

---

From: [email-masked]
Date: Mon, 16 Mar 2009 15:06:54 +0800

Hi Maarten,
You said:
 if we agree to deploy the EVC layer as transport service layer in MPLS-TP
...

What does this really mean? It means EVC layer is one of MPLS-TP's clients 
or EVC layer is the only client of MPLS-TP or EVC layer is part of 
MPLS-TP?
If EVC layer is MPLS-TP's client, we just need to define the adaption 
function.
If EVC layer is part of MPLS-TP, Does it mean MPLS-TP equipment must 
provide ETH switching function?

Regards,
Suhui

Maarten Vissers <[email-masked]> 
发件人:  [email-masked]
2009-03-13 15:38

收件人
[email-masked], [email-masked]
抄送
[email-masked], [email-masked]
主题
Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM ExtractionProcess

Hello Neil,
 
Good morning.

 

[mv] It seems that we are struggling with the name of this "transport 
service layer". If I understand your persistent comment well, then you do 
not like to refer to this transport service layer as the "PW" layer. At 
some point in time I got the impression that you would like to deploy a 
second instance of the MPLS-TP LSP as transport service layer. 
When I look at what is present in a number of networks today, then I find 
the use of an Ethernet VLAN layer as transport service layer in existing 
MPLS networks. This use of an Ethernet VLAN layer as transport service 
layer would be aligned MEF's MEN model in which the EVC (i.e. Ethernet 
VLAN) is providing the transport service layer role. This EVC layer is 
then supported by the MEN Transport layer, which could be another Ethernet 
VLAN instance, or MPLS LSP or MPLS-TP LSP or PBB-TE TESI, or ..., 

 
[mv] if we however agree to define a "MS-PW" or "LSP" based transport 
service layer in the MPLS-TP stack to support p2p and p2mp services, then 
there must be interworking between p2p/p2mp VLANs in the ethernet domains 
and those p2p/p2mp "MS-PW"/"LSP"s in the MPLS-TP domain if we want to 
offer at least p2p and p2mp services to customers in such hybrid packet 
transport network. As we discussed last month in London, the p2p/p2mp VLAN 
and p2p/p2mp "MS-PW"/"LSP" reside in different partitions within the same 
"transport service layer". In most cases so far partitions in one layer 
deploy the same technology. In this case, partitions in the transport 
service layer deploy different technologies, but the information carried 
in both cases is the same.

[mv] IEEE left out AIS because in a STP controlled domain restoration of 
the VLANs is an implicit feature. This implies that generation of AIS at 
the end of a failed link has to be stopped within a few second'; i.e. as 
soon as the VLAN's registration on this port is removed.
 
[mv] ETH-AIS is an important feature in ethernet transport networks that 
do not have end-to-end restoration active. ETH OAM checks the status and 
performance of the VLAN. VLANs in a transport network are set up under 
control of network management with or without the help of a GMPLS control 
plane. Such VLANs have a fixed connectivity, similar as a bidirectional 
point-to-multipoint connection. The ETH OAM checks this fixed 
connectivity; i.e. the connection-oriented part of the VLAN is checked 
(ETH OAM does not check the connectionless part (i.e. filtering rules) 
pro-actively; it is however capable to check the connectionless part 
on-demand via its LTM/LTR OAM). If such VLAN is interrupted and not 
restored, ETH-AIS must be generated to prevent ETH LOC alarms to be raised 
from the downstream MEP functions.
 
 There is major DP/CP functional mismatch between MPLS-TP and Ethernet so 
there is no way I can agree to interworking these as peers.  And in any 
case neither is a top-of-stack network so any interworking would be a 
wasted exercise anyway. 
 
[mv] Ethernet VLAN deployment in packet transport networks is under 
control of network management (possibly with the help of a GMPLS control 
plane). Ethernet VLANs are Traffic Engineered. 
Such traffic engineered p2p VLANs and p2mp VLANs deploy just a Broadcast 
Forwarding Rule and **no** Unicast/Multicast Filtering Rules. Traffic 
engineered MPLS-TP "MS-PW"/"LSP" transport service layer connections also 
deploy a Broadcast Forwarding Rule and **no** Unicast/Multicast Filtering 
Rules. Both transport entities are traffic engineered. It is as such 
possible to interwork these two transport service layer transport entities 
without too much problems if we make sure that the OAM PDU formats are 
very common.

[mv] Deployment of the EVC as transport service layer technology however 
requires that the EVC must support more then only Ethernet and TDM 
clients. I.e. must support also ATM, FR, PPP, etc clients as defined in 
PWE3. To support those other PWE3 clients, we need to get a number of 
EtherType values, one for each client. I will upload later a set of slides 
presenting those PWe3 mappings into an EVC, inluding a list of EtherTypes 
that would be required to support this.
 
Regards,
Maarten
 
regards, Neil

Malcolm,
 
terminating processes.
 
The packet formats of the LSP_CI, PW_CI and VPLS_CI are inspected by the 
so called "OAM Extraction Process"
in the termination and adaptation functions. Refer to G.8021 and G.8121 
for examples of such OAM Extraction Processes.
For the MPLS-TP case and assuming the packet formats below, these OAM 
Extraction Processes would inspect the top 
few rows of those packets to determine the type of payload/protocol (e.g. 
OAM CCM) that is carried. 
This can be illustrated as follows for the LSP OAM, MS-PW OAM and VPLS 
OAM:
 
LSP OAM with GAL:

LSP OAM without GAL:

MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:

 
I hope you understand that all packets are treated the same way in a 
termination or adaptation OAM Extraction process. All (OAM and DATA) 
packets are inspected on the six, four or two fields and the values in 
those fields determine if a packet contains OAM or DATA.

Regards,
Maarten

Malcolm,

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for 
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

If we always use a PW then the requirement for client data, OAM, SCC, MCC 
to receive identical treatment in the path to the PE occurs because the 
label stack is identical.

Stewart

--------------------------------------------------------
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: "Maarten Vissers" <[email-masked]>
Date: Mon, 16 Mar 2009 12:56:49 +0100

Suhui,
 
If you look at MEF4 (see
http://metroethernetforum.org/page_loader.php?p_id=29) you find the MEN
layer network model depicted in Figure 2/MEF4. This layer network model
defines:
- Application Services layer
- Ethernet Service layer (EVC)
- Transport layer.
 
The MEF4 Transport layer may be implemented by different technologies, such
as 802.1, SDH/SONET, MPLS. This is not further specified in the MEF.
 
At the moment, MEF is extending its scope beyond the metro. For instance
MEF12 update straw ballot #1 (see
http://www.metroethernetforum.net/apps/org/workgroup/technical/download.php/
6809/SB00143) describes the extension to a Carrier Ethernet Network (CEN)
and interconnected CENs (see clause 5, Figure 1). The EVC is the only
technology in the transport Services layer, and this EVC is supported by the
MEF Transport layer.
 
If we now decompose this Transport layer then we will find in there the
presence of a 
- Transport Path layer 
- Transport Section layer
- Physical media layer.
 
In an Ethernet domain those transport path/section layers would be VLANs.
In a PBB-TE domain those transport path/section layers would be the
TESI/VLAN.
In a MPLS-TP domain those transport path/section layers would be the
LSP/Section layers.
 
If we apply this MEF CEN model as basis for MPLS-TP, then the MPLS-TP LSP
has the EVC as only client layer. See the attached figure in which I have
tried to illustrate an extended version of Figure 2/MEF4; i.e. in this
attached figure I have added the transport path, section and physical media
layers.
 
The attached figure also illustrates that all non-ethernet services in the
Application Services layer are transported via an EVC after passing through
an interworking function. Specified today is the TDM IWF (MEF8). To be added
are the ATM IWFs, FR IWFs, etc as per my earlier proposal; i.e. use the PWE3
encapsulation up to and including the CW and then add a TYPE field, SA field
and DA field.
 
The attached figure also illustrates that ethernet services exist in both
the Ethernet Services (EVC) and Application Services layers. 
An example of Ethernet services in the Application Services layer are
C-VLANs which are transported as a bundle through the CEN. In this case the
Ethernet IWF inserts the C-Tag (if not present) or preserves the incoming
C-Tag.
 
The EVC signal can now be carried through the different metro and core
domains in the CEN and through multiple CENs. Each domain may deploy a
different Transport layer technology. E.g. if an EVC is carried through
three domains, of which one domain deploys an Ethernet based Transport
layer, another domain deploys MPLS-TP based Transport layer and the last
domain deploys a PBB-TE based Transport layer, then the EVC frames will be
VLAN Tagged in the first domain, will be PW Labelled in the second domain
and will be I-Tagged in the third domain. Nontheless the different
tagging/labelling of the EVC frames along the path through the CEN, the EVC
is providing the UNI-to-UNI transport service layer functionality for all
types of services.

When I would be presenting the functionality in a MPLS-TP domain, then I
would describe that MPLS-TP includes the EVC, LSP, Section and PHY layers. 
The MPLS-TP PE nodes are EVC Switching/Bridging nodes and must as such
support the ETH switching function (G.8021: ETH_C). 
The MPLS-TP P nodes must support the LSP switching function. A MPLS-TP PE/P
node must support both EVC switching/bridging and LSP switching.
 
MPLS nodes today (as far as I understand) support the EVC layer for Ethernet
services.
For non-Ethernet services those MPLS nodes do not provide a Services layer.
This implies that the Application Services layer in MPLS today is directly
supported by the Transport layer.
 
The development of the MS-PW as a layer would introduce an MPLS Services
layer (MPLS VC (MVC)) however. Such MPLS VC layer would be the second
Transport Services layer in the CEN and will compete with the Ethernet
Services layer (EVC), but only for p2p and p2mp services. In order to
provide in such dual Service layer scenario p2p/p2mp UNI-to-UNI services, it
will be necessary to deploy EVC to MVC interworking functions at the
boundary of MPLS-TP domains when interconnecting with Ethernet or PBB-TE
domains. We can prevent that the network needs to support such EVC<=>MVC
IWFs if we agree that MPLS-TP deploys the EVC as its transport services
layer.
 
Regards,
Maarten
 
  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 16 maart 2009 8:07
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: 答复: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess

Hi Maarten, 
You said: 
 if we agree to deploy the EVC layer as transport service layer in
MPLS-TP... 

What does this really mean? It means EVC layer is one of MPLS-TP's clients
or EVC layer is the only client of MPLS-TP or EVC layer is part of MPLS-TP? 
If EVC layer is MPLS-TP's client, we just need to define the adaption
function. 
If EVC layer is part of MPLS-TP, Does it mean MPLS-TP equipment must provide
ETH switching function? 

Regards, 
Suhui 

2009-03-13 15:38 

收件人

抄送

主题

Hello Neil, 
  
Good morning. 

  _____  

  

  

  

  

  
  
Regards, 
Maarten 
  
regards, Neil 

  _____  

Malcolm, 
  
terminating processes. 

LSP OAM with GAL: 

LSP OAM without GAL: 

MS-PW OAM: 
-------------------- 

VPLS (i.e. ETH) OAM: 

  

Regards, 
Maarten 

  _____  

Malcolm,

 

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [ <mailto:[email-masked]> mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [ <mailto:[email-masked]>
mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

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: Tue, 17 Mar 2009 15:58:41 +0800

Maarten:
i have doubt about LSP OAM without GAL. IMO, there maybe the same 
processing of LSP OAM as client data. so Label Stack Entry is not 
different between client data and LSP OAM. maybe adaption structure change 
into the following as the red text.

how about you. thank you.
liu

2009-03-13 06:28

收件人
'Malcolm Betts' <[email-masked]>
抄送
[email-masked], [email-masked]
主题
[mpls-tp] MPLS-TP protocol/payload type usage in OAM Extraction Process

Malcolm,
 
terminating processes.

LSP OAM with GAL:

LSP OAM without GAL:

MS-PW OAM:
--------------------

VPLS (i.e. ETH) OAM:

 

Regards,
Maarten

Malcolm,

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for 
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

---

From: "Maarten Vissers" <[email-masked]>
Date: Tue, 17 Mar 2009 17:33:09 +0100

Liu,
 
Client data in a MPS-TP LSP are labeled client packets (e.g. PW labelled
packets/frames). 
Those labeled client packets have a MPLS-TP LSP label in which the S-bit is
set to 0.
 
Any further packets present in the MPLS-TP LSP are packets which do not
include a label. 
All those packets have a MPLS-TP LSP label in which the S-bit is set to 1.
All MPLS-TP LSP OAM packets carry a 32-bit ACH, of which the first 4-bits
are set to 0001.
 
MPLS-TP LSP OAM processing is very different from the processing of MPLS-TP
LSP client packets. 
OAM packets are extracted and processed within the LSP, while client packets
are not extracted
and passed through without modification to the output ports of the LSP.
 
The forwarding of MPLS-TP LSP packets in a LSP switch function will not make
any distinction
between LSP OAM packets and LSP client packets. This forwarding processing
is (and must be) 
the same for LSP OAM and LSP client packets. But this forwarding processing
is fully based
on the common LSP label, not on any information beyond the LSP label.
 
This is the reason that there is no need for the presence of a 32-bit GAL in
the MPLS-TP LSP OAM packet.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 17 maart 2009 8:59
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] MPLS-TP protocol/payload type usage in OAM Extraction
Process

Maarten: 
i have doubt about LSP OAM without GAL. IMO, there maybe the same processing
of LSP OAM as client data. so Label Stack Entry is not different between
client data and LSP OAM. maybe adaption structure change into the following
as the red text. 

2009-03-13 06:28 

收件人

抄送

主题
[mpls-tp] MPLS-TP protocol/payload type usage in OAM Extraction
Process

Malcolm, 
  
terminating processes. 

LSP OAM with GAL: 

LSP OAM without GAL: 

MS-PW OAM: 
-------------------- 

VPLS (i.e. ETH) OAM: 

  

Regards, 
Maarten 

  _____  

Malcolm,

 

 

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [ <mailto:[email-masked]> mailto:[email-masked]]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

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

Stewart

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 17 Mar 2009 13:04:29 -0400

Maarten thanks, I agree, this answers my original question.  If we use
the the ACH under the last LSP label (S=1) then we are guaranteed common
processing of client (PW) data and OAM (behind the ACH) within the
MPLS-TP network.

Malcolm Betts 
Nortel Networks 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Tuesday, March 17, 2009 12:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP protocol/payload type usage in OAM
ExtractionProcess

Liu,
 
Client data in a MPS-TP LSP are labeled client packets (e.g. PW labelled
packets/frames). 
Those labeled client packets have a MPLS-TP LSP label in which the S-bit
is set to 0.
 
Any further packets present in the MPLS-TP LSP are packets which do not
include a label. 
All those packets have a MPLS-TP LSP label in which the S-bit is set to
1.
All MPLS-TP LSP OAM packets carry a 32-bit ACH, of which the first
4-bits are set to 0001.
 
MPLS-TP LSP OAM processing is very different from the processing of
MPLS-TP LSP client packets. 
OAM packets are extracted and processed within the LSP, while client
packets are not extracted
and passed through without modification to the output ports of the LSP.
 
The forwarding of MPLS-TP LSP packets in a LSP switch function will not
make any distinction
between LSP OAM packets and LSP client packets. This forwarding
processing is (and must be) 
the same for LSP OAM and LSP client packets. But this forwarding
processing is fully based
on the common LSP label, not on any information beyond the LSP label.
 
This is the reason that there is no need for the presence of a 32-bit
GAL in the MPLS-TP LSP OAM packet.
 
Regards,
Maarten

[Malcolm Betts] snip>---------------------------

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: dinsdag 10 maart 2009 16:15
To: [email-masked]; Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Clarifying MPLS-TP requirements for
MPLS(-TP)overMPLS(-TP)

So with that mind set:

Malcolm Betts
Nortel Networks

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, March 09, 2009 11:08 AM
To: Loa Andersson
Cc: Betts, Malcolm (CAR:X632); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP)

Stewart

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