Subject: Re: [mpls-tp] MPLS-TP and Ethernet IW scenarios (was RE: New Liaison Statement, ""Review of the MPLS-TP OAM Requirements draft" (ref # 003.01)")

From: <[email-masked]>
Date: Wed, 2 Sep 2009 00:55:55 +0100

Italo, Stewart, See below.

On 01/09/2009 09:12, "BUSI ITALO" <[email-masked]> wrote:
>> I am not sure how legitimate the 3A scenario is in terms of the trust
>> relationship between the two providers, and I would like to hear
>> from providers on how there would deploy such a network
>> fragment.
>> 
> 
> [ib] Could you please be a little more specific about your concern re
> legitimacy?
> From a trusting relationship point of view, this is an intra-carrier
> scenario where there are two technology domains.

If we put aside for one moment whether such interworking makes sense then
you are stating the requirement only applies to an intra-carrier scenario.
The original requirement in Y.Sup4 made no such restriction, which implies
to me that the intent of the original requirement is still not clear to all
parties and it is therefore difficult for the group to assess it at this
time.

Furthermore I seem to recall (maybe incorrectly) that we had received
guidance from the ADs that such interworking was out of charter for MPLS-TP
within the IETF.

> The Ethernet network can be an Ethernet access network or an Ethernet
> over SONET/SDH network under the same responsibility of the carrier
> operating the MPLS-TP network.
> The trusting relationship is the same as in scenario 3B where there is a
> single Ethernet MEG between PEB1 (MEP), T-PE1 (MIP) and T-PE2 (MEP).

Please do not assume that even in an intra-carrier scenario the trust model
is simple :-)

>> The scenario in terms of both operational and trust
>> relationship is similar to a multi-segment PW, and T-PE1
>> would have a role similar to an S-PE operating between
>> a pair of disjoint PSNs rather than as a T-PE.
>> 
> 
> [ib] To some extent I agree with you. In fact if instead of the Ethernet
> access network we have an MPLS-TP domain, then we will get exactly to
> the intra-carrier MS-PW case.
> From a data plane point of view, the operations of PE1 are identical to
> the operations of a T-PE. That's the reason why I called it T-PE.
> From an OAM point of view, there is a need to perform an IW function.
> Given that the first segment is not a real PW segment (e.g. OAM would be
> Ethernet OAM rather than PW OAM), PE1 is even not an S-PE.
> 
>> Take a look at the MPLS/PW to L2TPv3 PW operation
>> of an MS-PW.
>> 
> 
> [ib] Could you provide some references?
> 
>> However before we spend a lot of time designing a solution
>> it is important that the providers on the list validate the
>> scenario and list the set of OAM operations they want
>> to undertake and the trust relationships that have in the
>> network.
>> 
> 
> [ib] Service providers input is very much appreciated.

Given the PW segment will be supporting an Ethernet link what is the value
of interworking the Ethernet OAM with the underlying MPLS-TP network Vs just
carrying the Ethernet OAM within the Ethernet link supported by the MPLS-TP
network? We save a couple of MIPs? At the expense of complicating the
MPLS-TP network. Now extend this to other link technologies MPLS-TP may
support. The OAM interworking at the edge of the MPLS-TP network gets
progressively more complex for what benefit?

If it is an intra-carrier scenario we have complicated the MPLS-TP network
for little/no benefit. Regardless of whether it is an intra-carrier or
inter-carrier scenario we have violated the client/server relationship
principle of client/server independence.

> However this is a pending comment that is blocking the ITU-T approval of
> the OAM requirements draft and therefore we all have to do our best to
> resolve it.

The ITU themselves stated in their liaison that they couldn't reach
consensus on the comments. So while we may endeavour to resolve the original
comment, I would have thought given the original commenting organisation is
unable to reach consensus themselves that there is insufficient grounds to
block approval based on this comment alone.

Anyway as I have said before the original scope & intent of the comment is
still unclear to me.

> From the discussion we had last month, it seemed to me that there is a
> lack of understanding regarding the meaning of requirement 23 of Y.Sup4.

So the meaning and intent needs to be clarified.

> It is therefore very important that we reach a common understanding
> about this requirement and, based on that, quickly agree on a resolution
> for the pending comment.

We need a common understanding and agreement as to the intent of the
comment/requirement. We then need to asses whether such a requirement is
"real". Given the lack of understanding within the ITU as to the
meaning/intent of the original requirement, I don't think we can assume its
validity. If further scrutiny (once the intent is clarified) determines it
is valid then we can look to address it, however further scrutiny may
determine that it does not have validity.

Ben

---

From: <[email-masked]>
Date: Wed, 2 Sep 2009 13:52:10 +0100

Stewart and Italo asked for operator input, Ben has given his views below and here are mine as annotations to what Ben has already stated....so please see in-line below:

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 02 September 2009 00:56
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] MPLS-TP and Ethernet IW scenarios (was 
> RE: New Liaison Statement, ""Review of the MPLS-TP OAM 
> Requirements draft" (ref # 003.01)")
> 

NH=> This is also my understanding...and IMO this is very wise guidance.  Further, I have not seen any operator requests for IETF to consider peer interworking of different modes/technologies....but I'll say more on this later/below.
> Please do not assume that even in an intra-carrier scenario 

NH=> It's not simply a technical issue either....one has to consider the legal/regulatory implications in the country considered.  
> >> a pair of disjoint PSNs rather than as a T-PE.

NH=> Well, I have to point out that we have made a massive rod for our own back by allowing MS PWs....this has created a full-blown co-ps mode layer network that lives above MPLS.  But having made this mistake once we really should not repeat this in MPLS-TP.  How could we keep a straight face and claim that 'MPLS-TP is a transport network' if its spawns another co-ps (PW) layer network above it?

Now we don't need peer interworking between different parties in MPLS (in any spin, inc MPLS-TP), and as noted above we for sure don't want peer interworking in an unnecessary MW PW layer network above MPLS(TP).  I'll repeat shortly why peer interworking in a non top-of-stack layer network is unnecessary, because I want to position this against something Ben said below.
> network?

NH=> Exactly so Ben...but it is more general and fundamental than just this case.  The only reason we have networks at all is to support message/file/stream communication, over large geographic distance, between external (to the networks) entities. There are 2 immediate and important conclusions here:
-	there MUST always be a top-of-stack network present that has message/file/stream external application adaptation functions, eg IPv4, IPv6, ATM and PSTN....currently there are no other top-of-stack networks;
-	there MUST always be a bottom-of-stack network present that maps the binary information symbol lexicon (originally sourced from the external applications) into a q'ary symbol lexicon that modulates an EM wave in either optical, metallic or radio media.

All networks that lie between these top/bottom extremes are just creating a network builder support/flexibility role....and speaking with my operator hat firmly in place, THE (not widely as yet) key driver of cost/complexity reduction is to reduce to a minimum the number of additional layer networks that lie between the mandatory top/bottom-of-stack networks noted above.

Note also that the CP/MP/DP_OAM of *all* networks are only there in a supporting role to provide efficient/effective network operation....the primary purpose of network is the conveyance of message/file/stream information between entities external to the networks.

An important corollary of the above is that any non top-of-stack layer network (which BTW is the vast majority, including Ethernet and MPLS) MUST always be carrying a top-of-stack layer network.  The reason this is so crucially important is that, at a stroke, it shows why peer-interworking between different operating parties in any non top-of-stack layer network is technically quite unnecessary.  One is far better off fully terminating the non top-of-stack networks at an interworking point between 2 different operating parties and just passing the higher client layer network (that must be present) across transparently.

This observation is true even in the case of a single same mode/technology network with identical DP/CP/MP components.  It becomes increasingly 'more true' (for want of a better phrase) (i) when we have the same mode but different technologies (ie some degree of DP/CP/MP functional mismatch) or (the worse case) (ii) when we have different network modes (ie significant degree of DP/CP/MP functional mismatch).  And as an aside observation, it is almost unbelievably naïve to try and align only the DP OAM of each network mode (which is technically wrong anyway) in order to try and justify peer interworking.

Now I am acutely aware that many 'technology pressure fora' (like MPLSF, MEF and OIF) push UNIs and E-NNIs in their respective technologies.  However, one must question the motives of such fora when it is trivial to show that peer-interworking of non top-of-stack networks has no technical justification basis. 	  

> We save a couple of MIPs? At the expense of complicating the

NH=> Perhaps the benefit is that it keeps vendors and 'technology pressure fora' busy ;-)
> principle of client/server independence.

NH=> Exactly so....and we have shown above yet again, it has no technical justification basis.  If folks really wanted to justify peer interworking of some mode/technology then, as a minimum, they first need to imbue it with message/file/stream application adaptation functions and then sort out the CP (including all the trust/degree-of-sight/control issues)..... because we for sure are never going to peer the MP and going back to phone/fax provisioning with no good protection/restoration story is not going to wash with many operators or their customers. Just looking at OAM alone is insufficent and rather naïve.  Without these being properly addressed we are just in a 'job creation and cost generation' modus operandi IMO.

regards, Neil 

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Dan Frost <[email-masked]>
Date: Thu, 03 Sep 2009 10:37:31 +0100

Neil,

<[email-masked]> writes:

> Well, I have to point out that we have made a massive rod for our own
> back by allowing MS PWs....this has created a full-blown co-ps mode
> layer network that lives above MPLS.  But having made this mistake once
> we really should not repeat this in MPLS-TP.  How could we keep a
> straight face and claim that 'MPLS-TP is a transport network' if its
> spawns another co-ps (PW) layer network above it?

Can you describe the model you have in mind for inter-domain /
inter-provider MPLS-TP in the absence of MS-PW?

-d

---

From: <[email-masked]>
Date: Thu, 3 Sep 2009 11:31:56 +0100

> inter-provider MPLS-TP in the absence of MS-PW?

Dan,

Where have you been for the last few years?....I've explained this issue
many times in the past (eg on PWE3 list) so I am going to be quite terse
here:

I hope you grasp the arch reasons why PWs came into being.....but in
summary just in case:
-	IP traffic units running 'raw' in the same layer network as MPLS
(LDP) traffic units (this breaks the rules of consistent characteristic
info of layer networks) - also see comment on ECMP below.
-	LDP creates merging constructs that violate the (single source)
rule of connections, thus we have to add source information to recover
the lost information that a connection normally carries (aside=> when
one has proper connections in the co-ps mode one can take a short-cut on
labelling by omitting a SA label (CF a cl-ps mode technology like Eth or
IP where you can't take this labelling short-cut), ....but I will also
note here that one also needs connections for deterministic resource
management, which is rather important requirement in a transport role).

Then we had the fix for ECMP, ie sterilise 1st nibble of (non IP)
payload, ie 0000 in the CW.  This (the CW) was architecturally an
adaptation function when PWs were single hop.  Go multi-hop however and
there is a *major* step change in behaviour.  The CW is no longer
adaptation alone, but forms part of new PW co-ps mode layer
network...this requires its own set of DP OAM, addressing, CP
sig/routing, etc components.

Now in MPLS-TP we have to remove the 2 bullet items noted above, ie take
IP out of traffic DP and into its own CP/MP logically OOB network (eg
use GMPLS CP), and stop doing merging (also implies no PHP and indeed no
ECMP).  Ergo all conditions that created PWs are gone.  So now we end up
with something (ie MPLS-TP) that looks like a traditional co-ps mode
network....none of which had need for PWs you might care to note, eg
ATM, FR.

One additional twist here (that I think is still poorly understood) is
that a PW label originally had to carry a SA semantic...this was
necessary to recover the lost source info due to merging for a non cl-ps
client (and to be super accurate a cl-ps client would need unique
addressing space anyway)....go multi-hop however and the label needs to
change semantic from SA proxy to a proper forwarding label, ie DA proxy
that points towards the sink, just like any other co-ps mode network
based on label swapping).  I gave a very detailed explanation of this in
a mail to PWE3 29/11/2008.  So look that up if you don't follow what I
just stated.

Do I need to go on or can you figure out where the story needs to go
now?

Now you also mentioned inter-provider MPLS-TP....can you please explain
to me why you think an E-NNI in MPLS-TP (which is a non top-of-stack
layer network) is required?

Hint=> A non top-of-stack layer network must be carrying at least one
higher layer network, and where there MUST always be a true top-of-stack
layer network present in *any* instance of external party communications
(be it message/file/stream).  IP is a top-of-stack layer network.  So
why not terminate the non top-of-stack layer network and simply pass the
higher layer network across transparently?  Saves an awful lot of
technically quite unnecessary peer-interworking issues.

regards, Neil

---

From: Dan Frost <[email-masked]>
Date: Thu, 03 Sep 2009 14:59:13 +0100

<[email-masked]> writes:

>> > layer network that lives above MPLS.  But having made this mistake
>> > once we really should not repeat this in MPLS-TP.  How could we keep
>> > a straight face and claim that 'MPLS-TP is a transport network' if
>> > its spawns another co-ps (PW) layer network above it?
>> 
>[...]
> A non top-of-stack layer network must be carrying at least one higher
> layer network, and where there MUST always be a true top-of-stack layer
> network present in *any* instance of external party communications (be
> it message/file/stream).  IP is a top-of-stack layer network.  So why
> not terminate the non top-of-stack layer network and simply pass the

Thanks, Neil - this is the aspect of your point of view I wanted to
confirm: your preferred model for inter-domain transport, if I understand
correctly, is back-to-back connection of attachment circuits.

-d

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 08 Sep 2009 18:58:35 +0200

Dan,

The best and least complex packet transport network architecture contains:

1) an Ethernet VLAN (EVC) layer as service/channel layer and has its
traffic-engineered p2p, p2mp, rmp or mp2mp EVCs supporting any type of
customer services (Ethernet, TDM, ATM VP, ATM Vc, FR, HDLC, PPP, SDH VC-n,
...) between the UNI-N ports

2) an Ethernet VLAN (EVP) layer, or MPLS-TP LSP layer, or OTN LO ODUk layer
as tunnel/path layer carrying EVC aggregates between NNI ports on adjacent
PE nodes (T-PE to S-PE, S-PE to S-PE)

3) an Ethernet or OTN transmission media layer interconnecting adjacent PTN
nodes.

The EVC layer gives you world wide, multi-carrier UNI-N to UNI-N
connectivity for all service types: E-Line, E-Tree, E-LAN, TDM CES, ATM
Line, etc.

The EVP, LSP or LO ODUk give you per domain tunnels interconnecting the PE
nodes at the edge of the domain.

The "PW" is just present as a label stack entry header identifying EVC
signals within the MPLS-TP LSP based tunnel signals.

Two interconnect e.g. a metro with a core domain, the S-PE at the boundary
of both domains terminates the MPLS-TP LSP based tunnels, extracts the
individual EVC signals and forwards the EVC signals in the metro tunnels to
core tunnels via the Ethernet switch/brdige function. 

Two interconnect two carrier networks, the S-PE at the edge of carrier 1
domain will terminate the LSP based tunnel, extract the EVC signals and
forward the EVC signals to the E-NNI port on the S-PE that is connected to
the E-NNI port on the S-PE at the edge of carrier 2 domain. The E-NNI port
may multiplex the EVCs directly into the transmission media signal (i.e.
without intermediate tunnel) or may multiplex the EVCs first into tunnels
(e.g. Ethernet VLAN based tunnels) and then the tunnels into the
transmission media signal. The S-PE at the edge of carrier 2 domain will
perform same task as S-PE at edge of carrier 2 domain.

-------------

If you like a solution with an additional p2p service/channel layer, then
you can include an additional MPLS-TP VC (MS-PW) service/channel layer in
your packet transport network stack, creating an "Ethernet over SDH" like
architecture. For this case, p2p and p2mp services go over the MVC/MS-PW
layer and MPLS-TP LSP based tunnels, while rmp and mp2mp services go over
the EVC layer, the EVC signals go over MVC/MS-PW signals and MPLS-TP LSP
based tunnels.

The MVC/MS-PW layer network connections may be using the PW label stack
entry header as a "service" label, while each MVC/MS-PW is identified by a
LSP label... The MVC/MS-PW is now a LSP based service/channel instance, and
not longer a "PW". The data plane doesn't care how the stuff is called, the
management and control planes for PW and LSP are different.

But lowest complexity is obtained when there is no MVC/MS-PW/service-LSP
layer network at all, only an EVC service/channel layer on top of an MPLS-TP
LSP based tunnel/path layer.

To interconnect e.g. a metro with a core domain, the S-PE at the boundary of
both domains terminates the MPLS-TP LSP based tunnels, extracts the
individual MVC signals and terminates the MVC signals carrying rmp or mp2mp
EVC signals. The non-terminated (i.e. p2p, p2mp) MVC signals are forwarded
to the core tunnels. The rmp and mp2mp EVC signals are forwarded to the core
domain's MVCs and then multiplexed into the core's LSP tunnels.

To interconnect two carrier networks, the S-PE at the edge of carrier 1
domain will terminate the LSP based tunnel, extract the individual MVC
signals and terminate the MVC signals carrying rmp or mp2mp EVC signals. The
non-terminated (i.e. p2p, p2mp) MVC signals are forwarded to the E-NNI port
on the S-PE that is connected to the E-NNI port on the S-PE at the edge of
carrier 2 domain. The E-NNI port may multiplex the MVCs directly into the
transmission media signal (i.e. without intermediate tunnel) or may
multiplex the MVCs first into tunnels and then the tunnels into the
transmission media signal. The S-PE at the edge of carrier 2 domain will
perform same task as S-PE at edge of carrier 2 domain.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan Frost
Sent: donderdag 3 september 2009 11:38
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MS-PW and inter-domain MPLS-TP

Neil,

<[email-masked]> writes:

> once we really should not repeat this in MPLS-TP.  How could we keep a 

-d

---

From: [email-masked]
Date: Wed, 9 Sep 2009 10:48:46 +0800

Maarten
 according to my understanding to your describles. adding a EVC layer is 
completely for supporting RMP or MP2MP service in packet transport 
network. if the MVC channel/service layer can support RMP or MP2MP 
service, all problem may be solved. why not considering the MVC 
channel/service layer support RMP or MP2MP functions?

 it is only personal opinions. thank you

 liu

Maarten Vissers <[email-masked]> 
发件人:  [email-masked]
2009-09-09 00:58

收件人
'Dan Frost' <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] MS-PW and inter-domain MPLS-TP

Dan,

2) an Ethernet VLAN (EVP) layer, or MPLS-TP LSP layer, or OTN LO ODUk 
layer
as tunnel/path layer carrying EVC aggregates between NNI ports on adjacent
PE nodes (T-PE to S-PE, S-PE to S-PE)

3) an Ethernet or OTN transmission media layer interconnecting adjacent 
PTN
nodes.

Two interconnect e.g. a metro with a core domain, the S-PE at the boundary
of both domains terminates the MPLS-TP LSP based tunnels, extracts the
individual EVC signals and forwards the EVC signals in the metro tunnels 
to
core tunnels via the Ethernet switch/brdige function. 

-------------

The MVC/MS-PW layer network connections may be using the PW label stack
entry header as a "service" label, while each MVC/MS-PW is identified by a
LSP label... The MVC/MS-PW is now a LSP based service/channel instance, 
and
not longer a "PW". The data plane doesn't care how the stuff is called, 
the
management and control planes for PW and LSP are different.

But lowest complexity is obtained when there is no MVC/MS-PW/service-LSP
layer network at all, only an EVC service/channel layer on top of an 
MPLS-TP
LSP based tunnel/path layer.

To interconnect e.g. a metro with a core domain, the S-PE at the boundary 
of
both domains terminates the MPLS-TP LSP based tunnels, extracts the
individual MVC signals and terminates the MVC signals carrying rmp or 
mp2mp
EVC signals. The non-terminated (i.e. p2p, p2mp) MVC signals are forwarded
to the core tunnels. The rmp and mp2mp EVC signals are forwarded to the 
core
domain's MVCs and then multiplexed into the core's LSP tunnels.

signals and terminate the MVC signals carrying rmp or mp2mp EVC signals. 
The
non-terminated (i.e. p2p, p2mp) MVC signals are forwarded to the E-NNI 
port

Regards,
Maarten

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

Neil,

-d

--------------------------------------------------------
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: Wed, 09 Sep 2009 09:46:34 +0200

Liu,
 
I have suggested 2.5 years ago to extend (T-)MPLS with rmp and mp2mp cl-ps
transport entities, which I called PseudoLAN (PLAN). That suggestion was
killed within a few hours by MPLS experts. I support that decision as
Ethernet VLANs (EVCs) 
- provide all necessary capabilities, including traffic engineered p2p,
p2mp, rmp and mp2mp VLANs (EVCs)
- are widely used in Ethernet and MPLS/VPLS domains.
 
Introducing cl-ps PLANs in MPLS-TP does not make sense as such, and would
only introduce interworking problems with existing installations.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 9 september 2009 4:49
To: Maarten Vissers
Cc: 'Dan Frost'; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MS-PW and inter-domain MPLS-TP

Maarten 
 according to my understanding to your describles. adding a EVC layer is
completely for supporting RMP or MP2MP service in packet transport network.
if the MVC channel/service layer can support RMP or MP2MP service, all
problem may be solved. why not considering the MVC channel/service layer
support RMP or MP2MP functions? 

 liu 

2009-09-09 00:58 

收件人

抄送
[email-masked] 

主题

Dan,

-------------

Regards,
Maarten

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

Neil,

-d

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.