Subject: [mpls-tp] Pseudo wires and MPLS-TP

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Dec 2008 18:00:06 +0100

All,

An issue that limit me when trying to do constructive work
on e.g. the MPLS-TP stopping me to do constructive work is
whether PWs are part of MPLS-TP or not.

People have been asking me this frequently, and my response
has been that one reason they are in here is because we want
to use the same OAM for pseudo-wires as we do for LSPs, this
argument seem to become less and less valid.

As I see it there are two possibilities

1. MPLS and MPLS-TP has the same relationship to PWs
2. MPLS and MPLS-TP has a different relationship to PWs

Since MPLS-TP is MPLS it seems like the first alternative
should be true. If it is true we can't make PWs dependent
on MPLS-TP only, because that would eventually lead to two
different kinds of pseudo wires and end with conflicts being
built into MPLS and maybe also PWs.

I think it is fair to say that MPLS-TP is another layer network
than PWs, and more specific PWs is a client of MPLS networks
(including MPLS networks operated according the MPLS transport
profile.

I would like to see a decision to keep PWs as they are (not to
be changed because of MPLS-TP), this greatly effects the control
plane draft, since we can exclude everything on LDP. It would also
effect the reference model that we plan to put into the control
plane draft.

Now if there are transport requirements on PWSs the requirement
specification is vague.

If on the other hand PWs are a part of MPLS-TP, then MPLS-TP
is not MPLS (since PWs is not part of MPLS).

/Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager
Redback Networks                           phone:  +46 8 632 77 14
An Ericsson company
                                            email: 
[email-masked]
                                                    [email-masked]

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

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 09:07:00 -0800

Loa,

Per the e-mail discussion that Andy Malis and I had on this topic on the
list last week, I think possibility 1. is clearly correct.  I.e., PWs
are only of many possible clients of MPLS TP.

Thanks,

John
>-----Original Message-----
>From: Loa Andersson [mailto:[email-masked]] 
>Sent: Thursday, December 18, 2008 9:00 AM
>To: [email-masked]
>Subject: [mpls-tp] Pseudo wires and MPLS-TP
>
>All,
>
>An issue that limit me when trying to do constructive work on 
>e.g. the MPLS-TP stopping me to do constructive work is 
>1. MPLS and MPLS-TP has the same relationship to PWs 2. MPLS 
>and MPLS-TP has a different relationship to PWs
>
>should be true. If it is true we can't make PWs dependent on 
>MPLS-TP only, because that would eventually lead to two 
>I think it is fair to say that MPLS-TP is another layer 
>network than PWs, and more specific PWs is a client of MPLS 
>networks (including MPLS networks operated according the MPLS 
>transport profile.
>
>be changed because of MPLS-TP), this greatly effects the 
>control plane draft, since we can exclude everything on LDP. 
>It would also effect the reference model that we plan to put 
>into the control plane draft.
>
>Now if there are transport requirements on PWSs the 
>requirement specification is vague.
>

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 18 Dec 2008 19:13:44 +0200

Loa,

Thanks,

John

[YJS] That seems to be contradictory.
For MPLS there are only 3 clients, namely MPLS (stacking), IP, and PW.

If MPLS-TP has many clients, then the relationship of PWs to MPLS-TP is
different from that of MPLS.

Loa - BTW, we already have 2 types of PWs, namely MPLS-PWs and L2TP-PWs.
So I guess you mean we don't really want a third type !

Y(J)S

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 09:23:31 -0800

>From: Yaakov Stein [mailto:[email-masked]] 
>Sent: Thursday, December 18, 2008 9:14 AM
>To: Drake, John E; Loa Andersson; [email-masked]
>Subject: RE: [mpls-tp] Pseudo wires and MPLS-TP
>
>Loa,
>
>Per the e-mail discussion that Andy Malis and I had on this 
>topic on the list last week, I think possibility 1. is clearly 
>correct.  I.e., PWs are only of many possible clients of MPLS TP.
>
>Thanks,
>
>John
>
>
>If MPLS-TP has many clients, then the relationship of PWs to 
>MPLS-TP is different from that of MPLS.

JD:  Not at all.  MPLS and MPLS TP share the same set of clients,
regardless of its membership.  Attempting to conflate PWs and MPLS TP
does not make much sense to me.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Dec 2008 18:27:56 +0100

Adrian,

Adrian Farrel wrote:
> I liked the language used by the first of the two ITU conference calls 
> this week...
> 
> MPLS-TP is a combination of two layer networks:
> - The TP-LSP layer network
> - The PW layer network

isn't that to say that PWs are clients of MPLS-TP and MPLS and
that the PWs are not to be changed by the MPLS-TP effort, any
change to PWs should be done by the PWE3 working group

again the relationship between PWs and MPLS is the same for
PWs and MPLS-TP, isn't it?

> 
> The TP-LSP layer network can only have one of two clients
> - another TP-LSP layer network
> - a PW layer network

does this mean that we have to define IP and MPLS PWs? Meaning that
we have to define PWs for MPLS to transport MPLS on top of MPLS,
why is that

> 
> The PW layer network can have any client for which a PW encapsulation 
> has been defined.
> 
> 
> This split of the layers while keeping them within the "MPLS-TP 
> Framework" seems to be a pragmatic and satisfactory solution (although 
> I'm guessing lots of people will not like it when they think about it).

I don't know if I don't like it, but I don't understand it ;), why do we
need to keep it in if we are not going to do anything about it?

/Loa
> 
> 
> A
> 
> ----- Original Message ----- From: "Loa Andersson" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, December 18, 2008 5:00 PM

-- 

Loa Andersson

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 18 Dec 2008 18:32:24 +0100

John,

MS-PWs are part of the MPLS-TP solution. Non-MPLS-TP client signals are
mapped into MPLS-TP MS-PW signals and carried inside an MS-PW connection
through the MPLS-TP network. In carrier-carrier applications, MPLS-TP LSP
signals may be carried through the MPLS-TP network in addition to MPLS-TP
MS-PW signals. 

The MPLS-TP MS-PW is *the* signal/connection that must comply with the
complete set of Transport Profile requirements, as this signal/connection is
1-to-1 with a service being carried through the multi-operator network. It
is the signal/connection that must meet the SLA of the service and thus
requires traffic engineering, fault and performance monitoring, and
protection switching.

If we do not want a dedicated MPLS-TP MS-PW, then there is the option to
only deploy SS-PWs. SS-PWs do not require any OAM, as these SS-PWs are
always carried inside an MPLS-TP service LSP. In terms of G.805, a SS-PW
represents a link connection in a client layer link, which link is supported
by the MPLS-TP service LSP trail.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Drake, John E
Sent: donderdag 18 december 2008 18:07
To: Loa Andersson; [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

Loa,

Per the e-mail discussion that Andy Malis and I had on this topic on the
list last week, I think possibility 1. is clearly correct.  I.e., PWs are
only of many possible clients of MPLS TP.

Thanks,

John
>An issue that limit me when trying to do constructive work on e.g. the 
>MPLS-TP stopping me to do constructive work is whether PWs are part of 
>MPLS-TP or not.
>
>People have been asking me this frequently, and my response has been 
>that one reason they are in here is because we want to use the same OAM 
>for pseudo-wires as we do for LSPs, this argument seem to become less 
>and less valid.
>
>1. MPLS and MPLS-TP has the same relationship to PWs 2. MPLS and 
>MPLS-TP has a different relationship to PWs
>
>Since MPLS-TP is MPLS it seems like the first alternative should be 
>true. If it is true we can't make PWs dependent on MPLS-TP only, 
>because that would eventually lead to two different kinds of pseudo 
>wires and end with conflicts being built into MPLS and maybe also PWs.
>
>I think it is fair to say that MPLS-TP is another layer network than 
>PWs, and more specific PWs is a client of MPLS networks (including MPLS 
>networks operated according the MPLS transport profile.
>
>I would like to see a decision to keep PWs as they are (not to be 
>changed because of MPLS-TP), this greatly effects the control plane 
>draft, since we can exclude everything on LDP.
>It would also effect the reference model that we plan to put into the 
>control plane draft.
>
>If on the other hand PWs are a part of MPLS-TP, then MPLS-TP is not 
>MPLS (since PWs is not part of MPLS).
>
>/Loa
>--
>
>
>Loa Andersson
>

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 09:36:40 -0800

>Sent: Thursday, December 18, 2008 9:28 AM
>To: Adrian Farrel; [email-masked]

JD:  Loa, I think the term 'TP-LSP' is shorthand for IP and/or MPLS.
>
>does this mean that we have to define IP and MPLS PWs? Meaning 
>that we have to define PWs for MPLS to transport MPLS on top 
>of MPLS, why is that
>
>> 
>I don't know if I don't like it, but I don't understand it ;), 
>why do we need to keep it in if we are not going to do 
>anything about it?

JD:  We should remove all references to PWs from the documents
describing MPLS TP.

>>> An issue that limit me when trying to do constructive work on e.g. 
>>> the MPLS-TP stopping me to do constructive work is whether PWs are 
>>> part of MPLS-TP or not.
>>>
>has been 
>>> that one reason they are in here is because we want to use the same 
>>> OAM for pseudo-wires as we do for LSPs, this argument seem 
>to become 
>>> less and less valid.
>>>
>network than 
>>> PWs, and more specific PWs is a client of MPLS networks (including 
>>> MPLS networks operated according the MPLS transport profile.
>>>
>>> draft, since we can exclude everything on LDP. It would also effect 
>>> the reference model that we plan to put into the control 
>plane draft.
>>>

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 09:39:39 -0800

Maarten,

Interestingly enough, I disagree with *all* of the assertions in your
note, below.

Thanks,

John 

>From: Maarten Vissers [mailto:[email-masked]] 
>Sent: Thursday, December 18, 2008 9:32 AM
>To: Drake, John E; [email-masked]
>MS-PWs are part of the MPLS-TP solution. Non-MPLS-TP client 
>signals are mapped into MPLS-TP MS-PW signals and carried 
>inside an MS-PW connection through the MPLS-TP network. In 
>carrier-carrier applications, MPLS-TP LSP signals may be 
>carried through the MPLS-TP network in addition to MPLS-TP 
>MS-PW signals. 
>
>The MPLS-TP MS-PW is *the* signal/connection that must comply 
>with the complete set of Transport Profile requirements, as 
>this signal/connection is
>1-to-1 with a service being carried through the multi-operator 
>network. It is the signal/connection that must meet the SLA of 
>the service and thus requires traffic engineering, fault and 
>performance monitoring, and protection switching.
>
>If we do not want a dedicated MPLS-TP MS-PW, then there is the 
>option to only deploy SS-PWs. SS-PWs do not require any OAM, 
>as these SS-PWs are always carried inside an MPLS-TP service 
>LSP. In terms of G.805, a SS-PW represents a link connection 
>in a client layer link, which link is supported by the MPLS-TP 
>service LSP trail.
>
>Regards,
>Maarten
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Drake, John E
>e.g. the

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 18 Dec 2008 17:40:59 -0000

Since Loa has copied my private email to the list, I guess I'll respond on 
the list :-(

> change to PWs should be done by the PWE3 working group

That plays into your question at the bottom of the email.
I'll answer it there.

> PWs and MPLS-TP, isn't it?

Yes, I think so.
Most of MPLS and MPLS-TP are the same.

> we have to define PWs for MPLS to transport MPLS on top of MPLS,

Depends what you mean by a PW.
A PW is a way to encapsulate (in packets) a data stream to be carried over 
MPLS(-TP).

If you recall, the PWE3 working group starte off just specifying 
encapsualtions.
A null encapsulation is perfectly possible, but it does need to be 
specified.

>> The PW layer network can have any client for which a PW encapsulation has 
>> been defined.
>>
>>

Why do we need to keep all sorts of pieces of MPLS if we are not changing 
them?

We are trying to build an MPLS-based transport network that is capable of 
carrying services transparently. Most of that specification requires the 
specification of MPLS-based function. Some of that specification requires 
the definition of adaptation to the transport network (without which it is 
not possible to carry services).

On the whole, the "PW layer" is just adaptation. But some folk like to be 
able to signal and negotiate the adaptation between the end points, and 
other like the idea of multi-segment PWs. Those features turn the PW thing 
into a real layer.

A

---

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Dec 2008 19:11:20 +0100

Adrian Farrel wrote:
> Since Loa has copied my private email to the list, I guess I'll respond 
> on the list :-(

ooops - sorry I thought I missed doing a reply-all

<snip>
>>> Framework" seems to be a pragmatic and satisfactory solution 
>>> (although I'm guessing lots of people will not like it when they 
>>> think about it).
>>
> Why do we need to keep all sorts of pieces of MPLS if we are not 
> changing them?

the MPLS architecture is what we use to design things into (or out of),
but we are doing niothing to PWs, are we?

/Loa

-- 

Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Dec 2008 19:12:46 +0100

Drake, John E wrote:
<snip>
> JD:  Loa, I think the term 'TP-LSP' is shorthand for IP and/or MPLS.

it is? How could it be? IP is one client, MPLS is the another, and
PWs are a third, there we only talk about two.

<snip>

/Loa

-- 

Loa Andersson

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 10:24:14 -0800

Loa,

I think what I wrote to Andy last week is probably close to correct:

So, it is up to the client endpoints of the MPLS TP LSP to understand
the payload contents and we could have as payloads, for example, MPLS
packets with their own label stack, IP packets, or ethernet PW packets
which in turn contain, for example, MPLS packets or IP packets.

As I said in my note to Yakov S, nothing precludes additional clients in
the future.

Thanks,

John 

>Sent: Thursday, December 18, 2008 10:13 AM
>To: Drake, John E
>Cc: Adrian Farrel; [email-masked]
>it is? How could it be? IP is one client, MPLS is the another, 
>and PWs are a third, there we only talk about two.
>
>
>
><snip>
>
>/Loa
>
>-- 
>
>
>Loa Andersson
>

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 18:34:15 -0000

Loa,

Please let me try and explain some of this.

MPLS as originally specified did not (on purpose of design) treat all
clients the same.  That is:
-	if the DP client was IP it got a null encaps in MPLS....however,
IP can also appear as a peer PDU to an MPLS PDU on the same interface in
a CP/MP role
-	if the DP client was MPLS it got a digital wrapper
treatment...just 'stick another header on at will'
-	all other clients got a PW encaps treatment....and I'll come to
the reasons for this shortly, because in MPLS-TP those reasons MUST be
removed...with the inevitable conclusion that PWs are NOT required in
MPLS-TP.

So let's work-up that story.....

The first bullet above is THE root cause all all the major arch problems
with MPLS.  If I put a functional architecture hat on for the moment,
this would be classified a violation of consistent characteristic
information (CI).  MPLS has several of these CI violations, but this is
the key one.

The reason things had to be like was LDP.  You know as well as anyone
how LDP works wrt how LSPs get created as LSRs independently start
distributing labels for FECs (IP addresses).  This 'self nucleation' of
LSPs means LDP is not like a normal signalling protocol, and it demands
that IP can run raw (in a CP/MP role) alongside MPLS.  A corollary of
how LDP grows LSPs is that merging constructs are created.

Now this is all fine IFF (i) the only client of MPLS is IP *and* (ii)
one is not concerned about managing resource on a per customer instance.

However, a merging co-ps forwarding construct loses information wrt
source.  This information MUST be recovered somehow.  If the client is
IP there is no problem in doing this (at the IP layer) as each/every IP
traffic unit MUST carry a SA....this is the nature of the cl-ps mode.
However, if the client is not IP (or more generally cl-ps) then the loss
of SA information must be recovered by some other means...and this is
THE prime driver for PWs.  That is, a PW label MUST be proxy for a
client SA to recover the information loss caused by lower level LDP
merging.

PHP also creates a merging problem on the last hop.  This too is
therefore a not a good idea.

LDP also introduced another problem wrt to the use of ECMP...itself a
violation of a client/server trasparency requirement.  This had to be
fixed with the Martini CW 1st nibble hack.  Indeed, this is the the
primary driver for the Martini CW....all the other fields here are not
good ideas for an adaptation function, but lets park that one as it's a
second order issue.

Now, in MPLS-TP we MUST fix these problems....and a key requirement here
is resource management, so we must have pukka connections which, by
definition, must only have a single source, ie p2p and p2mp constructs
only (this also does not create a loss of SA inforation as a
consequential benefit).

Once we do this, and we stop the dual nature of IP issue mentioned right
at the start (which as an aside is one reason why we need a GMPLS CP
solution here), then all the reasons that created PWs in the 1st place
have disappeared.  And this is a very, very good thing.  A slightly more
subtle reason that this is a very, very good thing is due to the
consequences of PWs becoming multi-hop.  Recall I said above that a PW
label MUST take on a SA semantic to recover merging...well, in a
multi-hop PW case the label MUST change to DA proxy in order to be able
to do normal forwarding in the multi-hop PW entity....so PWs have a real
unresolved (and very poorly understood) problem here right now in MPLS
as-is.  

So, as we see, once PWs go multihop they create a further co-ps mode
layer network above the MPLS/IP layer network hybrid.  And this is NOT a
good idea at all.  {Aside I provided a far more detailed technical
explanation of all this on a post to the PWE3 list recently for anyone
who wants to check that out}

However, once the conditions that spanwed PWs in the 1st place are
removed, as they must be in MPLS-TP, then there is no reason to create
this PW layer network at all....indeed PWs can now be seen as an
unnecessary artefact of the intial specification of MPLS.  And to be
crystal clear...PWs are not needed in MPLS-TP.  

I hope that helps.

There will be lots of people who hate what I have just gone through
above because a whole industry seems to have grown up on the back of
PWs.  However, we should here try and be technically honest/accurate and
understand PWs for what they really are.  And we must strive not to
respeat this mistake in MPLS-TP....or heaven forbid make even more
mistakes by including over complex OAM and attempting to interwork
MPLS-TP with other technologies like Ethernet...these mistakes would IMO
be unforgiveable now given we can correctly analyse them and seem them
for what they really are.

regards, neil

> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: 18 December 2008 17:28
> isn't that to say that PWs are clients of MPLS-TP and MPLS 
> and that the PWs are not to be changed by the MPLS-TP effort, 
> any change to PWs should be done by the PWE3 working group
> 
> does this mean that we have to define IP and MPLS PWs? 
> Meaning that we have to define PWs for MPLS to transport MPLS 
> on top of MPLS, why is that
> 
> > 
> I don't know if I don't like it, but I don't understand it 
> ;), why do we need to keep it in if we are not going to do 
> anything about it?
> 
> /Loa
> > 
> > 
> > A
> > 
> should be

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 18:56:07 -0000

And I also disagree with all your assertions Maarten...and so does
everyone here in BT...so which operators want all this stuff?  Can they
please speak up and say why now?  We cannot afford you steering the
industry down another expensive rat hole...esp in the current climate.

BTW I have just posted a mail that explains why PWs came about in the
1st place and why they are completely unncessary in MPLS-TP....and
anyone who harbours the sligtest doubt about this might like to ask
themselves why IP, ethernet, SDH, ATM, etc, etc don't have PWs....my
mail simply provides the technical explanation for those who want to
understand.

regards, neil

> Sent: 18 December 2008 17:40
> To: Maarten Vissers; [email-masked]
> Interestingly enough, I disagree with *all* of the assertions 
> in your note, below.
> 
> Thanks,
> 
> John 
> 
> signals are 
> >mapped into MPLS-TP MS-PW signals and carried inside an MS-PW 
> >connection through the MPLS-TP network. In carrier-carrier 
> >applications, MPLS-TP LSP signals may be carried through the MPLS-TP 
> >network in addition to MPLS-TP MS-PW signals.
> >
> >1-to-1 with a service being carried through the 
> multi-operator network. 
> >It is the signal/connection that must meet the SLA of the 
> service and 
> >thus requires traffic engineering, fault and performance monitoring, 
> >and protection switching.
> >
> >If we do not want a dedicated MPLS-TP MS-PW, then there is 
> the option 
> >to only deploy SS-PWs. SS-PWs do not require any OAM, as 
> these SS-PWs 
> >are always carried inside an MPLS-TP service LSP. In terms 
> of G.805, a 
> >SS-PW represents a link connection in a client layer link, 
> which link 
> >is supported by the MPLS-TP service LSP trail.
> >
> >Regards,
> >Maarten
> >
> >Per the e-mail discussion that Andy Malis and I had on this topic on 
> >the list last week, I think possibility 1. is clearly 
> correct.  I.e., 
> >PWs are only of many possible clients of MPLS TP.
> >
> >Thanks,
> >
> >John

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 18 Dec 2008 14:38:22 -0500

Hi Neil,

I think I follow what you are saying below, or may be not..
However, what I did not quite get it is, how do you propose carrying
native ATM, FR, Ethernet traffic over MPLS-TP (I am guessing absolutely
not by using PWs as per your note below).

Are you suggesting that only traffic that should be carried over
MPLS-TP,
is MPLS and IP and nothing else?

regards,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, December 18, 2008 1:34 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

Loa,

I hope that helps.

regards, neil

> isn't that to say that PWs are clients of MPLS-TP and MPLS and that 
> the PWs are not to be changed by the MPLS-TP effort, any change to PWs

> should be done by the PWE3 working group
> 
> again the relationship between PWs and MPLS is the same for PWs and 
> MPLS-TP, isn't it?
> 
> > 
> Meaning that we have to define PWs for MPLS to transport MPLS on top 
> of MPLS, why is that
> 
> > 
> I don't know if I don't like it, but I don't understand it ;), why do 
> we need to keep it in if we are not going to do anything about it?
> 
> /Loa
> > 
> > 
> > A
> >

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 19:55:29 -0000

Thanks Himanshu,

I've looked at this stuff in detail over many years and discussed it
with lots of colleagues, so I am very comfortable/certain of my comments
wrt their technical accuracy.  If something is not clear I'll do my best
to explain further...just ask.

Now your question.  Try asking yourself how this is done in SDH, PDH,
Eth, IP, etc etc today.  But to be specific:

-	if we have a cl-ps server it MUST carry a PID in each/every
traffic unit;

-	if we have a co-cs/co-ps mode server that uses proper
connections, ie single source (and ignore the bizarre case of MPLS as-is
for now) then we do not need a PID field in the (child) traffic units
*providing* the (parent) connection only carries a single client type
over the connection lifetime...so the CP/MP carries/holds the PID
semantic here for the (parent) DP connection.  If this is not true (ie
we want to mux lots of different clients into the same server layer
connection) then we will require a (per child) traffic unit PID field in
the DP.

PWs are quite odd, and as I showed are a necessary artefact of the way
MPLS was orginally specified wrt 2 arch violations:
-	the dual nature of IP as DP client and peer CP/MP PDU
-	the loss of SA information due to LDP (and PHP) merging
*together* with the transparency violation of ECMP

When both these problems are removed (as they MUST be in MPLS-TP) then
the requirement for PWs totally evaporates.  I'm sure
politics/religion/commercials won't let PWs die, but as engineers who
SHOULD be striving for honesty/accuracy we should at least understand
all this.  Enough mistakes have been made already and I would hate to
see more made due to technical ignorance on our part.

regards, neil

> From: Shah, Himanshu [mailto:[email-masked]] 
> Sent: 18 December 2008 19:38
> To: Harrison,N,Neil,CXM R; [email-masked]; [email-masked]; 
> [email-masked]
> However, what I did not quite get it is, how do you propose 
> carrying native ATM, FR, Ethernet traffic over MPLS-TP (I am 
> guessing absolutely not by using PWs as per your note below).
> 
> Are you suggesting that only traffic that should be carried 
> over MPLS-TP, is MPLS and IP and nothing else?
> 
> regards,
> himanshu
> 
> 
> 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> MPLS as originally specified did not (on purpose of design) 
> treat all clients the same.  That is:
> IP can also appear as a peer PDU to an MPLS PDU on the same 
> interface in a CP/MP role
> the reasons for this shortly, because in MPLS-TP those 
> reasons MUST be removed...with the inevitable conclusion that 
> PWs are NOT required in MPLS-TP.
> 
> The first bullet above is THE root cause all all the major 
> arch problems with MPLS.  If I put a functional architecture 
> hat on for the moment, this would be classified a violation 
> of consistent characteristic information (CI).  MPLS has 
> several of these CI violations, but this is the key one.
> 
> The reason things had to be like was LDP.  You know as well 
> as anyone how LDP works wrt how LSPs get created as LSRs 
> independently start distributing labels for FECs (IP 
> addresses).  This 'self nucleation' of LSPs means LDP is not 
> like a normal signalling protocol, and it demands that IP can 
> run raw (in a CP/MP role) alongside MPLS.  A corollary of how 
> LDP grows LSPs is that merging constructs are created.
> 
> Now this is all fine IFF (i) the only client of MPLS is IP 
> *and* (ii) one is not concerned about managing resource on a 
> per customer instance.
> 
> However, a merging co-ps forwarding construct loses 
> information wrt source.  This information MUST be recovered 
> somehow.  If the client is IP there is no problem in doing 
> this (at the IP layer) as each/every IP traffic unit MUST 
> carry a SA....this is the nature of the cl-ps mode.
> However, if the client is not IP (or more generally cl-ps) 
> then the loss of SA information must be recovered by some 
> other means...and this is THE prime driver for PWs.  That is, 
> a PW label MUST be proxy for a client SA to recover the 
> information loss caused by lower level LDP merging.
> 
> PHP also creates a merging problem on the last hop.  This too 
> is therefore a not a good idea.
> 
> LDP also introduced another problem wrt to the use of 
> ECMP...itself a violation of a client/server trasparency 
> requirement.  This had to be fixed with the Martini CW 1st 
> nibble hack.  Indeed, this is the the primary driver for the 
> Martini CW....all the other fields here are not good ideas 
> for an adaptation function, but lets park that one as it's a 
> second order issue.
> 
> Now, in MPLS-TP we MUST fix these problems....and a key 
> requirement here is resource management, so we must have 
> pukka connections which, by definition, must only have a 
> single source, ie p2p and p2mp constructs only (this also 
> does not create a loss of SA inforation as a consequential benefit).
> 
> Once we do this, and we stop the dual nature of IP issue 
> mentioned right at the start (which as an aside is one reason 
> why we need a GMPLS CP solution here), then all the reasons 
> that created PWs in the 1st place have disappeared.  And this 
> is a very, very good thing.  A slightly more subtle reason 
> that this is a very, very good thing is due to the 
> consequences of PWs becoming multi-hop.  Recall I said above 
> that a PW label MUST take on a SA semantic to recover 
> merging...well, in a multi-hop PW case the label MUST change 
> to DA proxy in order to be able to do normal forwarding in 
> the multi-hop PW entity....so PWs have a real unresolved (and 
> very poorly understood) problem here right now in MPLS as-is.  
> 
> So, as we see, once PWs go multihop they create a further 
> co-ps mode layer network above the MPLS/IP layer network 
> hybrid.  And this is NOT a good idea at all.  {Aside I 
> provided a far more detailed technical explanation of all 
> this on a post to the PWE3 list recently for anyone who wants 
> to check that out}
> 
> However, once the conditions that spanwed PWs in the 1st 
> place are removed, as they must be in MPLS-TP, then there is 
> no reason to create this PW layer network at all....indeed 
> PWs can now be seen as an unnecessary artefact of the intial 
> specification of MPLS.  And to be crystal clear...PWs are not 
> needed in MPLS-TP.  
> 
> I hope that helps.
> 
> There will be lots of people who hate what I have just gone 
> through above because a whole industry seems to have grown up 
> on the back of PWs.  However, we should here try and be 
> technically honest/accurate and understand PWs for what they 
> really are.  And we must strive not to respeat this mistake 
> in MPLS-TP....or heaven forbid make even more mistakes by 
> including over complex OAM and attempting to interwork 
> MPLS-TP with other technologies like Ethernet...these 
> mistakes would IMO be unforgiveable now given we can 
> correctly analyse them and seem them for what they really are.
> 
> regards, neil
> 
> ;), why do 
> > >> wires and end with conflicts being built into MPLS and 
> maybe also 
> > >> PWs.
> > >>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Dec 2008 21:11:15 +0100

> Please let me try and explain some of this.

yes -maybe for some value of "this", but ...
> removed...with the inevitable conclusion that PWs are NOT required in

we agree so far (at lest for some value f agree), but you are
misrepresenting what I said

I didn't claim that mpls-tp (or for tht matter mpls) needs to
treat every client (have the same relationship to every client),
in fact I said the opposite, that mpls and mpls-tp should have the
relationship to one specific client (maybe even better "client type"
the PWs.

This makes the rest of your mail interesting reading, but oo topic.

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Redback Networks                      phone: +46 8 632 77 14
An Ericsson Company
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: <[email-masked]>
Date: Thu, 18 Dec 2008 20:22:03 -0000

Thanks Loa....I sense 'it's not what I want to hear' in your response.
Fair enough, but all I am presenting is accurate analysis of why PWs
exist in MPLS as-is and why they have no need to exist in MPLS-TP....and
I really think we owe to all reading these lists to be accurate/honest.
So I hope others found it useful.

regards, Neil  

> Sent: 18 December 2008 20:11
> To: Harrison,N,Neil,CXM R
> Cc: [email-masked]; [email-masked]
> interface 
> > in a CP/MP role
> reasons MUST be 
> treat every client (have the same relationship to every 
> client), in fact I said the opposite, that mpls and mpls-tp 
> should have the relationship to one specific client (maybe 
> even better "client type"
> the PWs.
> 
> > The first bullet above is THE root cause all all the major arch 
> > problems with MPLS.  If I put a functional architecture hat 
> on for the 
> > moment, this would be classified a violation of consistent 
> > characteristic information (CI).  MPLS has several of these CI 
> > violations, but this is the key one.
> > 
> as anyone 
> > distributing labels for FECs (IP addresses).  This 'self 
> nucleation' 
> > of LSPs means LDP is not like a normal signalling protocol, and it 
> > demands that IP can run raw (in a CP/MP role) alongside MPLS.  A 
> > corollary of how LDP grows LSPs is that merging constructs 
> are created.
> > 
> *and* (ii) 
> > IP there is no problem in doing this (at the IP layer) as 
> each/every 
> > IP traffic unit MUST carry a SA....this is the nature of 
> the cl-ps mode.
> > However, if the client is not IP (or more generally cl-ps) then the 
> > loss of SA information must be recovered by some other means...and 
> > this is THE prime driver for PWs.  That is, a PW label MUST 
> be proxy 
> > for a client SA to recover the information loss caused by 
> lower level 
> > LDP merging.
> > 
> ECMP...itself a 
> > good ideas for an adaptation function, but lets park that 
> one as it's 
> > a second order issue.
> > 
> > Now, in MPLS-TP we MUST fix these problems....and a key requirement 
> > here is resource management, so we must have pukka 
> connections which, 
> > by definition, must only have a single source, ie p2p and p2mp 
> > constructs only (this also does not create a loss of SA 
> inforation as 
> > a consequential benefit).
> > 
> > Once we do this, and we stop the dual nature of IP issue mentioned 
> > right at the start (which as an aside is one reason why we need a 
> > GMPLS CP solution here), then all the reasons that created 
> PWs in the 
> > 1st place have disappeared.  And this is a very, very good 
> thing.  A 
> > slightly more subtle reason that this is a very, very good thing is 
> > due to the consequences of PWs becoming multi-hop.  Recall I said 
> > above that a PW label MUST take on a SA semantic to recover 
> > merging...well, in a multi-hop PW case the label MUST change to DA 
> > proxy in order to be able to do normal forwarding in the 
> multi-hop PW 
> > entity....so PWs have a real unresolved (and very poorly 
> understood) 
> > problem here right now in MPLS as-is.
> > 
> co-ps mode 
> > layer network above the MPLS/IP layer network hybrid.  And 
> this is NOT 
> > a good idea at all.  {Aside I provided a far more detailed 
> technical 
> > PWs.  However, we should here try and be technically 
> honest/accurate 
> > and understand PWs for what they really are.  And we must 
> strive not 
> > to respeat this mistake in MPLS-TP....or heaven forbid make 
> even more 
> mistakes would 
> > IMO be unforgiveable now given we can correctly analyse 
> them and seem 
> > them for what they really are.
> > 
> > regards, neil
> > 
> and that 
> >> the PWs are not to be changed by the MPLS-TP effort, any change to 
> >> PWs should be done by the PWE3 working group
> >>

---

From: George Swallow <[email-masked]>
Date: Thu, 18 Dec 2008 15:40:38 -0500

Yaakov -

I very much agree.  One of the things that was discussed in the JWT was that
we did not want to open up the possibility of defining a whole new set of
ways of carrying all the payloads that are carried in PW.

...George

---

From: Luca Martini <[email-masked]>
Date: Thu, 18 Dec 2008 13:56:07 -0700

Loa Andersson wrote:
> Adrian,
>
> Adrian Farrel wrote:
>> I liked the language used by the first of the two ITU conference 
>> calls this week...
>>
Yes it is.
Since we are expanding the OAM capabilities of MPLS , it make sense that 
some clients might want to take advantage of new MPLS capabilities.
However that does not change the relationship between the client ( PW , 
) and the MPLS/MPLS-TP transport layer.
So I also Agree that #1 above is correct. This does not mean that we 
might have new type of pw associated channels , or that LDP might have 
to signal some extra capabilities to  meet new OAM requirements.

> we have to define PWs for MPLS to transport MPLS on top of MPLS,
I have always stated that I do not think this is a useful thing to work 
on. The reason some folks had proposed to do an MPLS PW is to 
effectively change MPLS , and break the forwarding paradigm of MPLS.
We already have an IP PW, as defined in some document I cannot find 
right now .

> need to keep it in if we are not going to do anything about it?
Not sure what you are saying here.
Luca

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Dec 2008 21:45:09 +0000

John
> JD:  We should remove all references to PWs from the documents
That does not make sense, surely we need to make a statement - perhaps
in the arch/framework noting that MPLS-TP has two clients - MPLS-TP
and PWE3. Whether MPLS-TP also has IP or MPLS as a client is something
that we need to establish and will  depend on whether we are satisfied 
with the
degree of client server isolation.

Stewart

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 15:22:05 -0800

George,

I don't know what gave you the impression I thought otherwise.  

Thanks,

John 

>From: George Swallow [mailto:[email-masked]] 
>Sent: Thursday, December 18, 2008 12:41 PM
>To: Yaakov Stein; Drake, John E; Loa Andersson; [email-masked]
>I very much agree.  One of the things that was discussed in 
>the JWT was that we did not want to open up the possibility of 
>defining a whole new set of ways of carrying all the payloads 
>that are carried in PW.
>
>...George
>
>
>> If MPLS-TP has many clients, then the relationship of PWs to MPLS-TP 
>> is different from that of MPLS.
>>

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 18 Dec 2008 15:27:22 -0800

>From: Stewart Bryant [mailto:[email-masked]] 
>Sent: Thursday, December 18, 2008 1:45 PM
>To: Drake, John E
>Cc: Loa Andersson; Adrian Farrel; [email-masked]
>That does not make sense, surely we need to make a statement - 
>perhaps in the arch/framework noting that MPLS-TP has two 
>clients - MPLS-TP and PWE3.

JD:  IP, MPLS (since MPLS == MPLS TP), and PWE3.  Do the MPLS documents
describe the clients of MPLS?  If so, there is precedent.

>Whether MPLS-TP also has IP or 
>MPLS as a client is something that we need to establish and 
>will  depend on whether we are satisfied with the degree of 
>client server isolation.

JD:  We had that discussion last week, and pretty much came to the
conclusion that mandating a PWE3 header didn't buy you anything wrt
client/server isolation.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 18 Dec 2008 21:38:05 -0500

Copied from below --

himanshu> I don't agree. Not sure how that 'conclusion' was
himanshu> reached. If PW are used, keeping aside for a moment about the arguments made
himanshu> against it, control word is very much in the play and
himanshu> I don't believe anyone has made a convincing argument
himanshu> for not using PW header (i.e. control word) except for
himanshu> a statement that control word does not provide sufficient
himanshu> protection against rogue LSR. This is also true for double EOS bits which was
himanshu> an alternative suggestion. But there are reasons to include
himanshu> PW control word other than protection against rogue LSR.

regards,
himanshu

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Fri, 19 Dec 2008 06:48:19 +0100

Neil,

I am also very interested in an operator's direct view <or several operators' direct views> as to the importance of the said functions below to their operations .

Thus far: I have not seen a direct affirmation on this list from an operator.

Best/m

Monique Jeanne Morrow
SP APAC CTO/Distinguished Consulting Engineer

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Thu 12/18/2008 10:56 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

regards, neil

> maybe also PWs.

---

From: <[email-masked]>
Date: Fri, 19 Dec 2008 09:05:56 -0000

Stewart,
 
who wrote 18 December 2008 21:45:

> That does not make sense, surely we need to make a statement 
> - perhaps in the arch/framework noting that MPLS-TP has two 
> clients - MPLS-TP and PWE3. Whether MPLS-TP also has IP or 

This is not accurate Stewart.

I am not sure if you saw my post the other day that explains why PWs had
to be created in MPLS and why, when these conditions (which are actually
arch violations at root) are removed, PWs are not required in MPLS-TP.
Further, PWs have now morphed from a (poor) adaptation function into a
full-blown layer network in their own right (this is NOT a minor change
of behaviour!)...which as I pointed out has a current unresolved and
rather serious problem with label semantics, ie
-	1-hop -> PW label MUST proxy for SA to recover information lost
due to any lower LDP/PHP merging,
-	N-hop -> PW label MUST proxy for DA to effect required
forwarding behaviour
-	...but both conditions cannot exist together in the same label,
though whilst LDP/PHP persist one MUST retain the former semantic.

Put very simply/bluntly, when we fix the things that MUST be sorted in
MPLS-TP then all the arch problems that generated PWs in the 1st place
are gone and there is no need to continue to promulgate this mistake.

This should not be a surprising revelation to anyone who reads the PWE3
list as I have been attempting to point this out for the last ~4 years
or so.  At some stage we really need to come-clean on this, rather than
keep pretending it's all OK....and that watershed moment is now here wrt
MPLS-TP.

I believe that in the light of the evidence and analysis that has been
provided it would be unforgivable for IETF not to take the right action
now.

Having said that, if folks really want to keep 'PWs' then at a minimum
we should be honest about what they are (and they are NOT a client at
all, they are a DP adaptation function and MUST revert to this role, ie
we do NOT network this entity)....and I would suggest the following
actions, in addition to the obvious(?) requirements for (i) OOB CP/MP
using GMPLS and (ii) providing a proper client/server relationship (both
of which can be easily and efficiently sorted using *functional* labels
from the 0-15 reserved set), are given very serious consideration:

-	we should remove the Control-Word (this is quite important for
many reasons...I can spell out if not obvious)

-	we should consider re-spinning the TTL field....a TTL function
is NOT required in any co mode layer networks, the CP (or MP) can verify
there are no loops prior to placing a connection (current GMPLS
controlled networks have no need for TTL).  This is quite important IMO
as the MPLS header is small that failing to recover 8 bits (25%) that
are otherwise wasted would be more than just a pity.

-	the OAM indicate function should be associated with a MPLS-TP
trail termination point (ie completely real client agnostic) and **it
should be an intrinsic field of the MPLS-TP (traffic unit) header**...we
only require 1-bit (from the recovered TTL field)...we should NOT be
generating a functional label for this (this was an arch mistake forced
on Y.1711 (label 14) due to the arch problems in MPLS at the time of
writing Y.1711...these arch problems should not exist in MPLS-TP).

-	the key issue I believe that underpins a desire to keep 'PWs' is
the perceived additional functionality one can carry in the
Associated-Channel (AC).  And like the 'OAM indicate' function, this too
should be indicated by a flag in **MPLS-TP (traffic unit) header**.  Now
if you really want to use another 'alert label (13)' for this then
OK....but it is not the optimum/right arch way to go about addressing
this issue.

If we did these things we would have a pretty excellent arch solution
for MPLS-TP IMO, and one I could feel good about supporting.

But please be clear about what PWs are...they are for sure NOT a client
of MPLS-TP....they are an artefact of arch failings in MPLS, and they
have no role (as was) in MPLS-TP.

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 19 Dec 2008 12:03:20 +0000

My 2p

PW provide two functions:
Adaptation (SS-PW)
Adaptation & 'forwarding' (MS-PW)

Unless we are to respecify the adaptation function performed by PWs then
they are necessary to carry anything but MPLS or IP over MPLS.  Given a
blank sheet of paper we could all come up with a new adaptation that is
'cleaner' than the PW one but we don't have a blank sheet of paper, PWs are
widely deployed in large networks (including BT's). The most pragmatic
approach is therefore to modify the current PW specs where necessary and
live with some of the wrinkles - not ideal but then nothing is in the world.

The value of MS-PW to me is that it provide a common client layer when I
want to carry something over multiple independent domains that may be
different technologies - it avoids the need for lower layer NNIs and because
S-Pes do not contain NSPs they are independent of what is contained in the
PW and enable me to provision segments between S-PEs in a common reusable
way regardless of the client of the PW.  My OSS is simpler and needs less
service-specific service activation code. It also provides me a method to do
E2E monitoring independent of the client of the PW and the server layers the
Pw traverses.

Do we need to specify PW behaviour in MPLS-TP? I think we do to some extent.
MPLS-TP needs to support OOB control. We have two ways to achieve that IMO:
1) Reserved MPLS labels
2) Some other channel.  The JWT has settled (if my interpretation is
correct) on defining and using a GACH in a PW for this purpose.

This functionality doesn't exist today and so needs specifying.  That
specification should obviously be done by the PWE3 WG. There may be other
additional pieces that also need specifying.

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 19 Dec 2008 07:48:10 -0500

I agree with you guys here. I want to modify the existing clients as  
little as possible, and
not at all if we can help it. At present, I don't see any reasons to  
modify the PWE3 specifications,
for example, if we remain reasonable about the requirements of what we  
are trying to achieve. This assumes
you agree with me that most if not all of Maartin's recent  
requirements and assertions on them were
inaccurate.

	--Tom

---

From: <[email-masked]>
Date: Fri, 19 Dec 2008 12:48:34 -0000

Thanks Ben...a couple of points in-line: 

Ben wrote 19 December 2008 12:03
 
> Adaptation & 'forwarding' (MS-PW)
NH=> You have to distinguish these functions from the (i) the PW label
(which has the key role of information recovery due to LDP/PHP merging)
and (ii) 1st nibble ECMP hack mitigation.  The latter is non-issue in
MPLS-TP.  However, the former is intrinsically tied to the functions you
identify for the multi-hop case....and here we have the currently
unresolved labelling problem I identified.  Now this is a serious
problem that must be corrected in MPLS-TP, and the right way to sort
this is NOT to use multi-hop PWs because this will create another co-ps
layer network above MPLS-TP....so let's get back to pure adaptation case
no matter how good/bad it is.

In addition, I believe the key thing some folks really want to have is
the Ass-Ch...and see the mail I posted this morning which addresses
this.  The CW is of very dubious value in MPLS-TP (I'd say none).

> 
> Unless we are to respecify the adaptation function performed 
> by PWs then they are necessary to carry anything but MPLS or 
> IP over MPLS.
NH=> I really don't think so.  MPLS-TP done right would be like any
other layer network, eg why are these non-issue in GMPLS controlled
networks I wonder? (rhetorical question to make a point).

Aside=> If you want to really get into what adaptation should consider
(and what is actually used depends on specific client and server modes),
the primary functions are (i) client traffic unit delineation, (ii)
idle-fill/rate-decoupling, (ii) PID and (iv) integrity check.  None of
these figure in the CW...but it has some functions that have
problems...and I can/will explain if need be.  To summarise CW bad,
Ass-Ch OK.

There is however a more subtle point wrt the S bit that I have
consciously steered cleared of because I did not want to hit everyone
will all the issues at once, ie the S-bit in MPLS as-is creates
sublayers.  This is OK per se, but these are not client/server and they
carry the illusion that we can create client topology on the fly just by
'adding another (lower level) header'.  Sublayers can bite you
architecturally....so we should be a little careful here with MPLS-TP.

> Given a blank sheet of paper we could all come 
> up with a new adaptation that is 'cleaner' than the PW one 
> but we don't have a blank sheet of paper, PWs are widely 
> deployed in large networks (including BT's).
NH=> Ben....because folks have mistakes in the past this is no reason to
keep making them.  We have to be able to change direction and fix
problems in *future* stds work from lessons learned...else there is
little real point in doing it.

> The most 
> pragmatic approach is therefore to modify the current PW 
> specs where necessary and live with some of the wrinkles - 
> not ideal but then nothing is in the world.
NH=> Agreed.  In the mail I posted earlier today I was trying to offer
what I consider would be the best way to proceed with MPLS-TP wrt this
very view.  And I am very conscious of the value some folks place on the
Ass-Ch...but don't confuse this with the problems that caused PWs in the
1st place or the CW....and for goodness sake let us please not create
another co-ps mode layer network above MPLS-TP...now that would be
really daft given we now have a better understanding of this.

> 
> The value of MS-PW to me is that it provide a common client 
> layer when I want to carry something over multiple 
> independent domains that may be different technologies - it 
> avoids the need for lower layer NNIs and because S-Pes do not 
> contain NSPs they are independent of what is contained in the 
> PW and enable me to provision segments between S-PEs in a 
> common reusable way regardless of the client of the PW.  My 
> OSS is simpler and needs less service-specific service 
> activation code. It also provides me a method to do E2E 
> monitoring independent of the client of the PW and the server 
> layers the Pw traverses.
> 
> MPLS-TP needs to support OOB control.
NH=> Absolutely...this is key a issue.

> We have two ways to 
> achieve that IMO:
NH=> OK, but this is really not the best way IMO.  I would suggest that
the OOB CP/MP is kept logically separate from any other functions that
one might want to impose on the *traffic DP*...albeit flagged up here by
some 'DP alert label'.

And I would also suggest folks give serious consideration to my proposal
to use a reserved label for creating an efficient client/server
'functional breakwater' between the LSPs belong to different MPLS-TP
layer networks....unlike the S bit issue (of sublayering) this carries a
proper client/server semantic.

regards, Neil

> 
> This functionality doesn't exist today and so needs 
> specifying.  That specification should obviously be done by 
> the PWE3 WG. There may be other additional pieces that also 
> need specifying.
> 
> Ben
> 
> 
> 
> 
> 
> carrying 
> > native ATM, FR, Ethernet traffic over MPLS-TP (I am guessing 
> > absolutely not by using PWs as per your note below).
> > 
> > MPLS-TP, is MPLS and IP and nothing else?
> > 
> > regards,
> > himanshu
> > 
> > 
> > 
> > - if the DP client was IP it got a null encaps in 
> MPLS....however, IP 
> > can also appear as a peer PDU to an MPLS PDU on the same 
> interface in 
> > a CP/MP role
> > - all other clients got a PW encaps treatment....and I'll 
> come to the 
> > reasons for this shortly, because in MPLS-TP those reasons MUST be 
> >> PWs

---

From: <[email-masked]>
Date: Fri, 19 Dec 2008 13:45:28 -0000

Himanshu,
 
I'll bite now wrt the CW.  In a mail I just sent Ben I tried to outline
what the important functions are for adaptation....which are:
-    client traffic unit delineation
-    idle-fill/rate-decoupling
-    client PID
-    integrity check
 
Not all these are required in every case of adaptation...that is
determined by *both* the client and server network modes under
consideration.
 
Now if I look at the CW none of these function are present in it.  So
what have we got here?  In order we have:
 
1    1st nibble ECMP hack.  This is actually a latent PID function of
sorts.  It is not required in MPLS-TP as we must remove the LDP/ECMP
causes that created it.
 
2    Client specific flags + frag.  Lots of options on specific clients
compression here.  And whilst compression is not necessarily a
client/server transparency violation it can be if the client signal has
not got ergodic symbol properties (ie over all time).  As a general
observation, client compression (BW squeezing optimisation) is not a
critical general requirement in today's networks.  The most transparent
case is where every client bit is treated equally, and this is what
today's PDH, SDH and OTN *transport networks* do.
 
3    Length.  Not really sure how important this is....I suspect not
really important.
 
4    Seq Nos.  Firstly, a key property of a transport network (that in
turn is a key property of a connection) is that symbols MUST preserve
ordering.  So, a Seq No. function is wholly redundant in MPLS-TP.
Secondly, if this Seq No field was to persist (and this also still
applies to MPLS as-is) then it should have very clear entry and exit
criteria conditions specified for aberrations of the expected Seq No.
ordering.....and this has never been done and is still a current
drop-off in the specification.  However, as noted this 2nd point is
academic for MPLS-TP as we MUST NOT reorder symbols in a transport
network.
 
Hopefully this better explains why I don't see much value in the CW for
MPLS-TP as part of 'adaptation' (sic)....also noting that (i) the CW is
optional and (ii) its functional fields are also generally optional...so
hardly a mandatory thing anyway!
 
 I also think the newer Ass-Ch should be decoupled from any association
with the old CW, and if folks want to keep this then fine.  But I still
think it would be far better to have different reserved labels for the
OOB CP/MP functions from any *DP alert* labels to identify Ass-Ch
payloads in the *traffic DP*.
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Shah, Himanshu
	Sent: 19 December 2008 02:38
	To: Drake, John E; [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

	Copied from below --
	JD:  We had that discussion last week, and pretty much came to
the
	conclusion that mandating a PWE3 header didn't buy you anything
wrt
	client/server isolation.
	
	himanshu> I don't agree. Not sure how that 'conclusion' was
	himanshu> reached. If PW are used, keeping aside for a moment
about the arguments made
	himanshu> against it, control word is very much in the play and
	himanshu> I don't believe anyone has made a convincing argument
	himanshu> for not using PW header (i.e. control word) except for
	himanshu> a statement that control word does not provide
sufficient
	himanshu> protection against rogue LSR. This is also true for
double EOS bits which was
	himanshu> an alternative suggestion. But there are reasons to
include
	himanshu> PW control word other than protection against rogue
LSR.
	
	regards,
	himanshu

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

	
	
	>clients - MPLS-TP and PWE3.
	
	JD:  IP, MPLS (since MPLS == MPLS TP), and PWE3.  Do the MPLS
documents
	describe the clients of MPLS?  If so, there is precedent.
	
	>will  depend on whether we are satisfied with the degree of
	
	JD:  We had that discussion last week, and pretty much came to
the
	conclusion that mandating a PWE3 header didn't buy you anything
wrt
	client/server isolation.

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 19 Dec 2008 06:08:48 -0800

>Sent: Thursday, December 18, 2008 6:38 PM
>the conclusion that mandating a PWE3 header didn't buy you 
>anything wrt client/server isolation.
>
>reached. If 
>himanshu> PW are used, keeping aside for a moment about the arguments 
>himanshu> made against it, control word is very much in the play and I 
>himanshu> don't believe anyone has made a convincing argument for not 
>himanshu> using PW header (i.e. control word) except for a statement 
>himanshu> that control word does not provide sufficient protection 
>himanshu> against rogue LSR.

JD:  No, the statement was that the PW encapsulation provides no
additional benefit in terms of client/server separation.  It introduces
additional overhead in both the control and data planes.

>This is also true for double EOS 
>bits which 
>himanshu> was an alternative suggestion.

JD:  No, the suggestion was that MPLS TP be payload agnostic.  This
means the payload can either be IP, MPLS (in which case the payload has
its own stack), or PW (in which case the the payload has its own stack
and a control word).  In the latter case, the PW payload could be either
IP or MPLS.

The whole point is that we can include a PW encapsulation but we don't
require it. 

>But there are reasons to 
>himanshu> include PW control word other than protection 
>against rogue LSR.

JD:  I wish you would stop keeping them to yourself.

>- perhaps 
>>in the arch/framework noting that MPLS-TP has two clients - 
>MPLS-TP and 
>>PWE3.
>
>documents describe the clients of MPLS?  If so, there is precedent.
>
>>MPLS as a client is something that we need to establish and will  
>>depend on whether we are satisfied with the degree of client server 
>>isolation.
>
>the conclusion that mandating a PWE3 header didn't buy you 
>anything wrt client/server isolation.
>
>>
>>Stewart
>>
>>
>>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 19 Dec 2008 15:40:06 +0100

Neil,

[email-masked] wrote:
> Thanks Loa....I sense 

hmmm ... you might be a bit too sensitive ;)
'it's not what I want to hear' in your response.

my point was that it was not a response - so as far as that goes
that was not not what I wanted to hear.

I need situation - trying to progress the MPLS-TP at a pace where we
can meet the very challenging schedules indicated from e.g. SG15 -
I need to be able to ask questions and have responses.

I appreciate responses even if they are different from the opinions
I have on the subject matter.

E.g I think Luca made a good point about the OAM changes that
might effect the LDP protocol and the need to use it as support
for OAM functions.

Now I will try to rephrase my question a bit and send a new mail
with a new subject line and hope that the discus ion will focus
on the question I ask.

If you or anyone else needs to tell me why we made mistakes in the
or deviate from the subject in general - please do so but change the
subject line.

Having said that it is is not my opinion in general that what you
bing up in your mails is uninteresting or useless, quite the opposite
they are often interesting and entertaining.

/Loa

-- 

Loa Andersson

---

From: George Swallow <[email-masked]>
Date: Fri, 19 Dec 2008 09:56:30 -0500

John -

The impetus for MPLS-TP are the requirements from the ITU.  I think that is
is absolutely necessary that PWs be included in the MPLS-TP Framework and
Architecture documents so that the IETF clearly communicates how client
payloads are to be encapsulated over MPLS-TP.

If the ITU needs new encapsulations or OAM capabilities for client flows,
those requirements need to come to PWE3.  I don't want any confusion on this
point.  

Not mentioning PW in our docs will lead us in the wrong direction.

Otherwise I think we are in total agreement.

...George

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 19 Dec 2008 10:18:59 -0500

OK I see your point, I think.

Let me re-iterate, because based on what others have said,
there seems to be confusion alright.

Your point is that we can carry client IP and MPLS traffic
across MPLS-TP in a "layer 3ish manner". That is ingress/egress
PEs participate in client IP/MPLS on customer facing interfaces.

However, if you want to carry the same in "layer 2ish manner"
then we use respective PW (IP - defined as Layer 2 IP transport PW
or MPLS PW which is not defined yet). In this case, ingress
PE would decapsulate layer-2 headers from the Attachment circuits
and encapsulate it at egress and PEs do not have to participate
in client IP/MPLS protocols.

I was referring to the second case. I believe, some others based on my
reading of their emails, also were referring to the second case.
Since you are not advocating this case, there is no sense to discuss
whether control word is necessary for this case or not. But just to
make a point, balus and I wrote a draft making a case for IP PW to include
control word, at least to support IS-IS PDU since they get encapsulated
in 802.3 framing and not ethernet-ii framing at egress ethernet AC.

Not withstanding Neil's point on validity of PW and its control word
in general, as a whole separate argument/discussion.

/himanshu

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 19 Dec 2008 10:27:29 -0500

George, while I agree with you that we must include PWEs in the
documentation for the reasons you cited, I also want to encourage us to
question the ITU requirements when they imply changes to the existing
PWE3/MPLS definitions.  The discussion around the interpretation of the
requirements that Maartin cited is a great example of how we can go down the
road of re-inventing everything in MPLS/PWE3 just for the sake of
re-inventing them to fit into a different model.

    --Tom

-- 
Principal Architect - 21CN Networks

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 19 Dec 2008 15:13:22 -0500

Just to recap the position that John and I were taking on an earlier
version of this discussion, on the mpls-interop list:

MPLS-TP is a transport service, and presents a packet-oriented
interface to its clients. It is agnostic as to what the client chooses
to carry over in the packets that are transported by this service. The
client can use the MPLS-TP label on which the packet arrives to
discriminate between various MPLS-TP LSPs and to identify the context
of the client packets being delivered. It is up to the clients at the
two ends of the MPLS-TP LSP to decide what is being transported
between them. This may be provisioned at the two ends of the MPLS-TP
LSP, or dynamically signaled. It is expected that typical client
payloads will be data-oriented MPLS, unlabeled IP, and PWs of all
sorts as defined by the IETF. Other payloads may also be possible.

Cheers,
Andy

---

From: George Swallow <[email-masked]>
Date: Fri, 19 Dec 2008 15:31:14 -0500

All things are possible. But not all are expedient.

If MPLS-TP is used as an aggregation technology, which to me seems the
largest potential use, then we will have many instances where one client is
connected to MPLS-TP and the other is connected to MPLS (sans TP).  If we
want interoperability here, then any payload needs to standard.  We have a
workgroup that defines standards for non-IP payloads.  That group is PWE3
and that is why they are part of the MPLS-TP work.

Just who elso do suppose is going to define these "other payloads".

...George

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 19 Dec 2008 15:34:13 -0500

> and that is why they are part of the MPLS-TP work.

    I might be confused, but I thought we agree that it was only
MPLS-TP-to-MPLS-TP for interop reasons? A given LSR could have links that do
MPLS-TP or MPLS, but either end of a link was going to be like-to-like only?

    --Tom

---

From: George Swallow <[email-masked]>
Date: Fri, 19 Dec 2008 15:48:10 -0500

I think the following use of MS-PW will prove to be very popular.

T-PE-(MPLS-TP cloud)-S-PE-(MPLS cloud)-T-PE.

Depending on box capabilities and particular deployments, there may be two
S-PEs to bridge the two PSN domains.  So at one end of the MPLS-TP cloud,
the client may be the terminus of a PW segment, but not of the MS-PW.

...George

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Dec 2008 21:03:35 -0000

George is right, but I don't see any interop between MPLS and MPLS-TP here.

The two "transport" networks do not need to know about each other and there 
is no gateway function.

The PW is placed on and carried by the MPLS-TP network with no knowledge of 
whether the second network is MPLS or MPLS-TP.

Further, the S-PE doesn't do anything different.

No interworking at all.

A
----- Original Message ----- 
From: "George Swallow" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>; "Andrew G. Malis" 
<[email-masked]>; "Drake, John E" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 19, 2008 8:48 PM
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

>>>> On Thu, Dec 18, 2008 at 1:24 PM, Drake, John E 
>>>> <[email-masked]>
>>>> wrote:
>>>>> Loa,
>>>>>

---

From: Lucy Yong <[email-masked]>
Date: Fri, 19 Dec 2008 15:21:37 -0600

Adrian,

In this case, Service layer (PW) is supported by multiple transport domains
(MPLS-TP or MPLS). Transport domains do not interconnect at all. Each
transport domain provides virtual interfaces to the service layer.

Regards,
Lucy

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Adrian Farrel
> Sent: Friday, December 19, 2008 3:04 PM
> To: George Swallow; Thomas Nadeau; Andrew G. Malis; Drake, John E
> Cc: [email-masked]
> >>> largest potential use, then we will have many instances where one
client
> >>> is
> >>> want interoperability here, then any payload needs to standard.  We
have
> >>> a
> >> MPLS-TP-to-MPLS-TP for interop reasons? A given LSR could have links
that
> >> do
> >>>>> As I said in my note to Yakov S, nothing precludes additional
clients
> >>>>> in

---

From: <[email-masked]>
Date: Fri, 19 Dec 2008 21:47:22 -0000

I also don't see any need for MPLS and MPLS-TP interworking (as
peers)....and it can be quite easily proved that for non top-of-stack
layer networks (which includes all spins of MPLS as well as Eth, PDH,
SDH and many other 'transport networks') peer-interworking is a
non-issue.  But I also don't see any need for PWs to be a common
adaptation (sic) glue between them either.

If we get MPLS-TP right (and I'm getting a wee bit concerned we may fail
here....not for want of trying but due to simply misunderstandings which
many private I've had seem to indicate) then we do not require PWs in
MPLS-TP at all.  PWs are only something we have created due to way MPLS
as-is has been specified.  We should therefore strive to get MPLS-TP
right and keep the all the old PW stuff in MPLS as much as possible.

So if in one network domain I have XoverMPLS-TP (DP) {CP/MP OOB) and in
another domain I have XoverPWoverMPLS (DP) (CP/MP IB) then the only
thing we transfer transparently between the 2 domains in the DP is
X...we for sure do not carry the old PW stuff into MPLS-TP.

If this is not immediately obvious, asume you are building an IP
(top-of-stack) layer network....you can create each link connection in
the IP topology from quite different server layer network paths (eg SDH
VC4, PDH T3, Eth, MPLS-TP, etc) and there is NO INTERWORKING between
these server layer paths...they remain independent in ALL DP/CP/MP
facets.

The MPLS and MPLS-TP case is no different as server layers...save we are
now at last recognising why MPLS as-is caused us problems here in the
past...and PWs should (I hope) have acted as the catalyst to really
bring home this point (I can but hope!).

And Andy (Malis) with your MPLSF hat on (as indeed anyone thinking of
MEF here too), can you start to see now why NNIs between non-top-of
stack networks make no sense?  If you don't get this, you add fuel to
the flawed views Maarten is advocating wrt interworking lots of
different modes/technologies....'just because we can', not because its
useful.  I for sure don't want my company, BT, to spend lots of money on
such flawed ideas.

regards, neil

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 19 December 2008 21:04
> To: George Swallow; Nadeau,TD,Tom,DMF R; Andrew G. Malis; 
> Drake, John E
> Cc: [email-masked]
> The two "transport" networks do not need to know about each 
> other and there is no gateway function.
> 
> The PW is placed on and carried by the MPLS-TP network with 
> no knowledge of whether the second network is MPLS or MPLS-TP.
> 
> >>> largest potential use, then we will have many instances 
> where one client 
> >>> is
> >>> connected to MPLS-TP and the other is connected to MPLS 
> (sans TP).  If 
> >>> we
> >>> want interoperability here, then any payload needs to 
> standard.  We have 
> >>> a
> >>> workgroup that defines standards for non-IP payloads.  
> That group is 
> >>> PWE3
> >> MPLS-TP-to-MPLS-TP for interop reasons? A given LSR could 
> have links that 
> >> do
> >> MPLS-TP or MPLS, but either end of a link was going to be 
> like-to-like 
> >> only?
> >>
> >>     --Tom
> >>
> >>
> >>
> >>>>> As I said in my note to Yakov S, nothing precludes 
> additional clients 
> >>>>> in
> >>>>> the future.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> John
> >>>>>

---

From: <[email-masked]>
Date: Fri, 19 Dec 2008 21:45:03 -0000

Hi Andy...

As I have discovered (from many private mails I have received over last
few days, and somewhat to my surprise) the stuff I take as 'obvious'
isn't obvious to all who don't have a background in functional
architecture concepts....so whilst I may think 'that's done/dusted,
folks can't argue with that' I've discovered this is not true in all
cases.

If we get MPLS-TP right (and I sincerely hope we do) then there will be
benefits all round....but some sacred cows are going to have to go I am
afraid...and PWs (esp in multi-hop guise) are one of them.

Here's one issue that cropped up tonight that I thought was obvious and
that I had already explained completely, but some private comments I've
had show this is not understood, even by the key players in IETF:  The S
bit in MPLS as-is is all about sublayering (ie stacked LSPs) and does
NOT create a client/server relationship between stacked LSPs.  Now I
don't really care if folks want to retain the S bit sublayering in
MPLS-TP or not (architecturally it's a nonsense, each LSP SHOULD be an
independemnt layer network in MPLS-TP), but if some folks DO want to
retain it AND we want to create a proper transparent client/server
relationship we are going to need something ADDITIONAL to the S bit to
effect this in the traffic DP.  

The most efficacious way to do this is to define reserved label (from
the 0-15 set) that has the globally well-known semantic "this label
marks a boundary between the MPLS network of party X and that of party
Y"...and now the S bit can be used in each of these verically stacked
client/server partitions independently.  A key use here could be
MPLS(old)overMPLS-TP....where folks want to retain the old S bit ideas
in the MPLS(old) layer network.

A key point here is that this reserved label provides a (traffic DP)
indication function for the case of MPLS (old or TP) clients/servers.
Anything other than MPLS (old/TP) as a client (inc IP as *DP
traffic*...IP as *CP/MP* gets carried in a logically OOB GMPLS adjunct
network, again using a different resereved label) gets transparently
carried in the MPLS-TP payload directly...just as Andy remarks below.

Hope that makes sense.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Andrew G. Malis
> Sent: 19 December 2008 20:13
> To: Drake, John E
> Cc: [email-masked]
> Just to recap the position that John and I were taking on an 
> earlier version of this discussion, on the mpls-interop list:
> 
> MPLS-TP is a transport service, and presents a 
> packet-oriented interface to its clients. It is agnostic as 
> to what the client chooses to carry over in the packets that 
> are transported by this service. The client can use the 
> MPLS-TP label on which the packet arrives to discriminate 
> between various MPLS-TP LSPs and to identify the context of 
> the client packets being delivered. It is up to the clients 
> at the two ends of the MPLS-TP LSP to decide what is being 
> transported between them. This may be provisioned at the two 
> ends of the MPLS-TP LSP, or dynamically signaled. It is 
> expected that typical client payloads will be data-oriented 
> MPLS, unlabeled IP, and PWs of all sorts as defined by the 
> IETF. Other payloads may also be possible.
> 
> Cheers,
> Andy
> 
> <[email-masked]> wrote:
> > Loa,
> >
> > in the future.
> >>it is? How could it be? IP is one client, MPLS is the 
> another, and PWs 
> >>are a third, there we only talk about two.
> >>
> >>
> >>
> >><snip>
> >>
> >>/Loa
> >>
> >>--
> >>
> >>
> >>Loa Andersson
> >>

---

From: <[email-masked]>
Date: Fri, 19 Dec 2008 22:02:44 -0000

Lucy...what you seem to advocate here is potentially dangerous IMO.  You
may create a full-blown PW layer network if you are not careful....and
it's a PW layer network per client type, as PWs are not generic but
client specific.

This is not at all the way we should be proceeding now.  But I can see
the temptation to do so, even though its so obviously wrong to me. And
if this happens then pray what is the common adaptation above
this?....we can recurse this ever upwards.

Aside=> This nearly happened with GFP in ITU, ie create a layer network
out of GFP (instead of keeping it as pure adaptation).  However, it was
fortunately stopped in time.  This why I am so against multi-hop
PWs...hope you can see this, ie multi-hop==networked entity.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Lucy Yong
> Sent: 19 December 2008 21:22
> To: 'Adrian Farrel'; 'George Swallow'; Nadeau,TD,Tom,DMF R; 
> 'Andrew G. Malis'; 'Drake, John E'
> Cc: [email-masked]
> In this case, Service layer (PW) is supported by multiple 
> transport domains (MPLS-TP or MPLS). Transport domains do not 
> interconnect at all. Each transport domain provides virtual 
> interfaces to the service layer.
> 
> Regards,
> Lucy
> 
> > Behalf
> > George is right, but I don't see any interop between MPLS 
> and MPLS-TP
> here.
> > 
> other and
> there
> > The PW is placed on and carried by the MPLS-TP network with no 
> > knowledge
> of
> > > Depending on box capabilities and particular deployments, 
> there may 
> > > be
> two
> > >>> If MPLS-TP is used as an aggregation technology, which 
> to me seems 
> > >>> the largest potential use, then we will have many 
> instances where 
> > >>> one
> client
> > >>> is
> (sans TP).  
> > >>> If we want interoperability here, then any payload needs to 
> > >>> standard.  We
> have
> > >>> a
> That group 
> > >> like-to-like only?
> > >>>> to carry over in the packets that are transported by 
> this service.
> The
> > >>>> discriminate between various MPLS-TP LSPs and to identify the 
> > >>>> context of the client packets being delivered. It is up to the 
> > >>>> clients at the two ends of the MPLS-TP LSP to decide what is 
> > >>>> being transported between them. This may be provisioned at the 
> > >>>> two ends of the MPLS-TP LSP, or dynamically signaled. It is 
> > >>>> expected that typical client payloads will be 
> data-oriented MPLS, 
> > >>>> unlabeled IP, and PWs of all sorts as defined by the 
> > >>>>> the payload contents and we could have as payloads, 
> for example,
> MPLS
> > >>>>>>> JD:  Loa, I think the term 'TP-LSP' is shorthand 
> for IP and/or
> MPLS.
> > >>>>>>

---

From: Lucy Yong <[email-masked]>
Date: Fri, 19 Dec 2008 17:11:22 -0600

Neil,

PW provides encapsulation for all kinds of client signals such as ATM, FR,
etc.
So MPLS-TP and MPLS do not do encapsulation. This is inline with current
PW/MPLS approach, which conducts S-PWs and let multi MPLS domains to
transport one PW. 

Regards,
Lucy

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 19, 2008 4:03 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Sat, 20 Dec 2008 13:34:09 -0000

It's become apparent to me, through some private mail discussions, that
I have done a truly awful job in explaining why I have proposed using a
reserved label in MPLS to effect a proper client/server relationship
between stacked LSPs....and how this relates to the S-bit.  So I am
going to try and correct that here.

The key bit to understand is that stacked LSPs in MPLS today are
sublayers.....this implies they all belong to the same parent MPLS layer
network and, most importantly, they are operating under a common CP/MP
instance.  The S bit works within this framework by indicating when we
are the end of such a sublayering stack.

If we did not have the concept of sublayers (so no need for the S bit)
we would NOT require the reserved label at all...indeed, this would be
how MPLS-TP SHOULD be specified IMO, ie a proper client/server
relationship between all stacked LSPs means each one is a proper layer
network in its own right and there is no sublayering.

Sublayering creates problems (as I remarked in an earlier mail) and one
needs to be very careful with it.  I knew it would be a problem that one
day would surface in MPLS when folks wanted to do MPLSoverMPLS as a
transparent client/server relationship *and* they figured out the myth
of the 'common single instance of CP/MP'.

Stewart and I had a draft (expired) a while back that used a pair of
degenerate 1-hop ETH+PW entities instead of a reserved label to create
this functional breakwater (between different S bit sublayered stacks of
LSPs).  However, not only is this rather ugly/inefficient (esp if
recursed a couple of times), but as we start to recognise the flawed
nature of PWs we really need a better and more generic way within MPLS
itself to create this functional breakwater...and this is what the
reserved label does.

Aside=> The sublayering issue is also one reason (though there are many
others) why we do not like the nested TCM MEP (and esp MIP) ideas
....one will hit similar downstream problems with this stuff, ie
different operator ownership of nested OAM levels and yet the
sublayering is trying to force a common CP/MP view.

Now, if folks want to retain the concept of sublayering and the S bit
as-is in MPLS-TP, as well as MPLS(old), it is then that you need the
reserved label....if you don't have sublayers (ie no S bit) you do not
need the reserved label, ie you are already operating in a true
client/server manner.  And this is the point I failed to clearly
articulate previously.....my sincere apologies as I can now see why it
must have caused much confusion.

So it is MPLS(old) that really needs the reserved label approach.  But
if the S bit sublayering is retained in MPLS-TP then this also needs it.
And clearly we also need it for these cases:
-	MPLS(old)_over_MPLS-TP
-	MPLS-TP_over_MPLS(old)

I hope it is clear now and that this explanation has helped.

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 21 Dec 2008 09:28:42 +0000

Neil,

> these server layer paths...they remain independent in ALL DP/CP/MP

You are correct about the lack of interworking in this scenario. But,
transferring X between domains implies that the domain boundary point has to
be an access point in layer network X.

Or in other words (using your example) the device between the two different
server layer paths must participate in the IP layer network.

Where I see PWs being useful is for E2E monitoring independent of the client
& server networks (A CAL in Y.1401 terminology). The situation I am thinking
of is that outlined by George:

Client(Y) --- MPLS-XX --- MPLS --- MPLS-XX --- Client(Y)

Where MPLS-XX could be MPLS but in future *may* be MPLS-TP.

If I do not run something like a PW E2E then I can't monitor E2E and remain
transparent to the client (Y).

If I just run X over MPLS-XX on the access segments then the device on the
MPLS-XX/MPLS boundary has to be able to switch layer Y data units. Layer Y
is not a single technology but many which means that the MPLS-XX/MPLS
boundary has to have significantly more functionality than if a PW is used
E2E. 

Ben

---

From: <[email-masked]>
Date: Sun, 21 Dec 2008 10:24:47 -0000

Thanks Ben,

Yes I am well aware of this stuff as you know, having asked you to help
me work on it in ITU way back.  Since then further analysis by myself,
Andy and Alan (esp as part of the G.800 work) has merely cemented our
views on the problems we have been quietly generating with PWs.  A
couple of points for you to consider here:

-	I hope we are all now better realising that PWs as currently
defined are a direct consequence of the way MPLS was originally
specified.  There is no need for us to promulgate this mistake in
MPLS-TP.  We can if we wish BUT I would urge great caution and that
attention is paid to the following points so that what results is at
least architecturally/operationally sensible (a key point relates to the
relationship of the CW and Ass-Ch which I'll come on to shortly):

-	whatever we do, we must not create another set of co-ps layer
networks above MPLS-TP....but this is where the PW stuff is currently
heading, and *per PW client type* please note (in fact they have almost
arrived, and with the unresolved labelling problem I have previously
pointed out).  So, we must force them to revert to a pure 'adaptation
function' (sic - see later) between a client/server layer network
boundary.  In such a case (and with the LDP/ECMP-hack having to had be
removed in MPLS-TP), then we discover the PW label has no need to even
go back to its original SA proxy information recovery function.  One may
consider it as a client muxing function now (if one wants to assign some
role to it).....not quite right/pretty but better than a DA proxy
(multi-hop new co-ps layer network case) or SA proxy (original LDP
demerging case, now gone in MPLS-TP).

-	however, when one considers what properties an
inter-layer-network adaptation function should have we find *none of
them* in the CW (go compare the CW to a well defined adaptation function
like GFP).  In fact we now find redundant functions in the CW (eg a Seq
No has no real value in a properly defined co-ps mode network like
MPLS-TP needs to be, but even if retained it still has an undefined
entry/exit aberration criteria issue....not really good enough leaving
it like this IMO....but, hey, since everything is optional anyway maybe
nobody really cares!).  Further details about this topic can be found in
my response to Himanshu a couple of days ago.

-	so having dismissed the CW as clearly 'not required' in MPLS-TP
we come on to the Ass-Ch.  Now this does have considerably more
potential value....and is worth salvaging if folks think this is the
best way to add currently missing functionality, eg OAM, prot-sw
protocol, etc.  Indeed, the end-end OAM point you raise below would fit
here if we were 'peer-interworking' (which it strictly isn't)
XoverASS-CH/MPLS and XoverASS-CH/MPLS-TP.  I personally would try and
avoid this error (as I can see better ways to do the OAM for MPLS-TP,
and I would accept the fact that just like all other technologies
carrying XoverY, XoverZ, etc there is no artificially induced adaptation
end-end OAM EXCEPT where it should be in X!), but I can understand its
appeal to some folks and so I would not fight this very strongly (unlike
TCM and new multi-hop PW layer networks).

Besides the above, the really 2 important points we must get right in
MPLS-TP are:
-	OOB CP/MP re-using GMPLS
-	transparent MPLS-TPoverMPLS-TP

Both these require the use of reserved labels from the 0-15 set (the 2nd
case is more subtle, and is ONLY a consequence of me anticipating folks
will want to retain the sublayering of stacked LSPs using the S bit in
MPLS-TP....it's actually a mistake, but if this is so hard a concept to
let go of then this is the way to solve it...you may have noticed a post
from me yesterday that tried to explain this better, since I had been
privately alerted I had done a poor job of explaining this so far).

regards, Neil

> From: Niven-jenkins,B,Ben,DMF R 
> Sent: 21 December 2008 09:29
> To: Harrison,N,Neil,CXM R; [email-masked]; 
> [email-masked]; Nadeau,TD,Tom,DMF R; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> > So if in one network domain I have XoverMPLS-TP (DP) {CP/MP 
> OOB) and 
> > in another domain I have XoverPWoverMPLS (DP) (CP/MP IB) 
> then the only 
> > the IP topology from quite different server layer network paths (eg 
> > SDH VC4, PDH T3, Eth, MPLS-TP, etc) and there is NO INTERWORKING 
> > between these server layer paths...they remain independent in ALL 
> > DP/CP/MP facets.
> 
> You are correct about the lack of interworking in this 
> scenario. But, transferring X between domains implies that 
> the domain boundary point has to be an access point in layer 
> network X.
> 
> Or in other words (using your example) the device between the 
> two different server layer paths must participate in the IP 
> layer network.
> 
> Where I see PWs being useful is for E2E monitoring 
> independent of the client & server networks (A CAL in Y.1401 
> terminology). The situation I am thinking of is that outlined 
> by George:
> 
> If I do not run something like a PW E2E then I can't monitor 
> E2E and remain transparent to the client (Y).
> 
> If I just run X over MPLS-XX on the access segments then the 
> device on the MPLS-XX/MPLS boundary has to be able to switch 
> layer Y data units. Layer Y is not a single technology but 
> many which means that the MPLS-XX/MPLS boundary has to have 
> significantly more functionality than if a PW is used E2E. 
> 
> Ben
> 
>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 08:16:46 +0100

Adrian,

> We are trying to build an MPLS-based transport network that is capable
> of carrying services transparently. Most of that specification requires
> the specification of MPLS-based function. Some of that specification
> requires the definition of adaptation to the transport network (without
> which it is not possible to carry services).
>
> On the whole, the "PW layer" is just adaptation. But some folk like to
> be able to signal and negotiate the adaptation between the end points,
> and other like the idea of multi-segment PWs. Those features turn the
> PW thing into a real layer.

The above describes indeed the issue we have to resolve. 
We need to agree what is meant by the term "PW". 

It is perhaps the simplest to restrict the term "PW" to the "encapsulation
of a client signal into the payload of an MPLS-TP service layer signal" and
to introduce the term "MPLS-TP service layer" to represent the layer in
which "multi-segment PW" connections exist.

The MPLS-TP service layer signal has a 1-to-1 relationship with the customer
requested service. 
MPLS-TP service layer signals are multiplexed into a MPLS-TP tunnel layer
signal. MPLS-TP Tunnel connections start/end at domain boundaries (e.g.
metro domain tunnels, core domain tunnels).

The "PW Demultiplexer" becomes then a "MPLS-TP Service Demultiplexer/Label".

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: donderdag 18 december 2008 18:41
To: Loa Andersson; [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

Yes, I think so.

> does this mean that we have to define IP and MPLS PWs? Meaning that we 
> have to define PWs for MPLS to transport MPLS on top of MPLS, why is 
> that

>> (although I'm guessing lots of people will not like it when they think
about it).

A

>>> OAM for pseudo-wires as we do for LSPs, this argument seem to become 
>>> less and less valid.
>>>
>>> the reference model that we plan to put into the control plane 
>>> draft.
>>>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 09:10:38 +0100

Neil,

You use a very narrow interpretation of the term "PW" as basis for your
ramblings. As Adrian has written, a "PW" in the eyes of some represents two
things:
- adaptation of client into a service layer signal's payload
- multi-segment service layer connection,
whereas for others it only represents
- adaptation of client into MPLS signal.

As I wrote this morning, it could be wise to deploy two distinct terms for
those two entities:
1) "PW" = adaptation of client into a service layer signal's payload
2) "MPLS-TP service layer connection" = multi-segment service layer
connection (previously called "MS-PW").

With the above split, there is again full alignment with all other transport
network technologies; i.e. "PW" is synonimous with "client adaptation" that
is supported in every technology.

It may be even better to go one step further and use the terms 
- MPLS-TP Channel layer network and ETH Channel layer network
- MPLS-TP Path layer network
- MPLS-TP Section layer network
- Physical Media layer network
to describe the layer network stack of a multi-domain, multi-operator
MPLS-TP based packet transport network.

It is now possible to make a mapping between the original MPLS terminology
and the MPLS-TP layered network terminology, without having to redefine
these original terms.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 18 december 2008 19:56
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Pseudo wires and MPLS-TP

And I also disagree with all your assertions Maarten...and so does everyone
here in BT...so which operators want all this stuff?  Can they please speak
up and say why now?  We cannot afford you steering the industry down another
expensive rat hole...esp in the current climate.

BTW I have just posted a mail that explains why PWs came about in the 1st
place and why they are completely unncessary in MPLS-TP....and anyone who
harbours the sligtest doubt about this might like to ask themselves why IP,
ethernet, SDH, ATM, etc, etc don't have PWs....my mail simply provides the
technical explanation for those who want to understand.

regards, neil

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 11:06:47 +0100

Ben,

Thanks for this pragmatic proposal. I agree with you.

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: vrijdag 19 december 2008 13:03
To: Shah, Himanshu; [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

My 2p

Ben

On 18/12/2008 19:38, "Shah, Himanshu" <[email-masked]> wrote:

> - if the DP client was IP it got a null encaps in MPLS....however, IP 
> can also appear as a peer PDU to an MPLS PDU on the same interface in 
> a CP/MP role
> - if the DP client was MPLS it got a digital wrapper treatment...just 
> 'stick another header on at will'
> - all other clients got a PW encaps treatment....and I'll come to the 
> problems with MPLS.  If I put a functional architecture hat on for the 
> distributing labels for FECs (IP addresses).  This 'self nucleation' 
> corollary of how LDP grows LSPs is that merging constructs are created.
> 
> IP there is no problem in doing this (at the IP layer) as each/every 
> IP traffic unit MUST carry a SA....this is the nature of the cl-ps mode.
> this is THE prime driver for PWs.  That is, a PW label MUST be proxy 
> for a client SA to recover the information loss caused by lower level 
> LDP merging.
> 
> good ideas for an adaptation function, but lets park that one as it's 
> a second order issue.
> 
> here is resource management, so we must have pukka connections which, 
> constructs only (this also does not create a loss of SA inforation as 
> GMPLS CP solution here), then all the reasons that created PWs in the 
> 1st place have disappeared.  And this is a very, very good thing.  A 
> proxy in order to be able to do normal forwarding in the multi-hop PW 
> entity....so PWs have a real unresolved (and very poorly understood) 
> layer network above the MPLS/IP layer network hybrid.  And this is NOT 
> a good idea at all.  {Aside I provided a far more detailed technical 
> PWs.  However, we should here try and be technically honest/accurate 
> and understand PWs for what they really are.  And we must strive not 
> to respeat this mistake in MPLS-TP....or heaven forbid make even more 
> MPLS-TP with other technologies like Ethernet...these mistakes would 
> IMO be unforgiveable now given we can correctly analyse them and seem

---

From: <[email-masked]>
Date: Mon, 22 Dec 2008 10:28:34 -0000

Folks,

Maarten wrote 22 December 2008 07:17
> > of carrying services transparently. Most of that specification 
> > requires the specification of MPLS-based function. Some of that 
> > specification requires the definition of adaptation to the 
> transport 
> > network (without which it is not possible to carry services).
> >
NH=> Well, I think it might be better to initially understand why PWs
exist in MPLS and precisely what they are doing...esp when they don't
exist in any other cl-ps or co-ps mode technologies.

In previous posts I have explained this in some detail...in summary, PWs
are an artefact of the way MPLS was initially specified.  However, many
of the major arch problems of MPLS must get resolved in MPLS-TP,
including the reasons why PWs were initially created.  In other words,
we do not need (ie are not forced) to promulgate PWs in MPLS-TP....that
is now our choice....but as a minimum we must not create another set of
co-ps mode layer networks out of them.....noting that this currently
holds a labelling problem wrt to whether a PW label is a SA proxy
(demerging recovery) or a DA proxy (forwarding)...multi-hop PWs require
the latter, but LDP (and PHP) demand the former.  And as you should know
better than anyone else, a layer network must have consistent
CI....there are many examples of where is a problem in MPLS as-is, this
too needs fixing in MPLS-TP.

I would also a look at my response to Himanshu where I am explaining 2
things:  (i) what the key functions of adaptation are (and none of these
appear in the CW) and (ii) the differences between the CW and the
Ass-Ch.....we don't need the former in MPLS-TP, but the latter may be
considered useful.

> 
> It is perhaps the simplest to restrict the term "PW" to the 
> "encapsulation of a client signal into the payload of an 
> MPLS-TP service layer signal" and to introduce the term 
> "MPLS-TP service layer" to represent the layer in which 
> "multi-segment PW" connections exist.
NH=> No thanks.  We can't afford the cost of creating/supporting layer
networks 'just for the fun of it'...esp when we can clearly show
when/how these are unnecessary.  We also can't afford the unnecessary
cost of interworking different technologies or installing nested TCM
sublayers ('just for the fun of it').  You may have noticed that
world-economics is somewhat adverse at the present time (and for the
foreseeable future), so all unnecessary work/cost must be identified and
removed.

regards, Neil
> 
> The MPLS-TP service layer signal has a 1-to-1 relationship 
> with the customer requested service. 
> MPLS-TP service layer signals are multiplexed into a MPLS-TP 
> tunnel layer signal. MPLS-TP Tunnel connections start/end at 
> domain boundaries (e.g.
> Since Loa has copied my private email to the list, I guess 
> I'll respond on the list :-(
> 
> Meaning that we 
> A PW is a way to encapsulate (in packets) a data stream to be 
> carried over MPLS(-TP).
> 
> If you recall, the PWE3 working group starte off just 
> specifying encapsualtions.
> A null encapsulation is perfectly possible, but it does need 
> to be specified.
> 
> >> think
> Why do we need to keep all sorts of pieces of MPLS if we are 
> not changing them?
> 
> We are trying to build an MPLS-based transport network that 
> is capable of carrying services transparently. Most of that 
> specification requires the specification of MPLS-based 
> function. Some of that specification requires the definition 
> of adaptation to the transport network (without which it is 
> On the whole, the "PW layer" is just adaptation. But some 
> folk like to be able to signal and negotiate the adaptation 
> between the end points, and other like the idea of 
> multi-segment PWs. Those features turn the PW thing into a real layer.
> 
> A
>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 11:48:33 +0100

Tom,

> This assumes you agree with me that most if not all of Maartin's
> recent requirements and assertions on them were inaccurate.

Perhaps you can indicate what was inaccurate in those requirements and
assertions. So far that has been totally unclear to me.

My starting point is to:
1) maintain the MPLS-PW encapsulations in full alignment with Ben's
approach: "The most pragmatic approach is therefore to modify the current PW
specs where necessary and live with some of the wrinkles - not ideal but
then nothing is in the world." 
2) deploy the MS-PW in full alignment with Ben's approach: "The value of
MS-PW to me is that it provide a common client layer when I want to carry
something over multiple independent domains that may be different
technologies - it avoids the need for lower layer NNIs and because S-Pes do
not contain NSPs they are independent of what is contained in the PW and
enable me to provision segments between S-PEs in a common reusable way
regardless of the client of the PW.  My OSS is simpler and needs less
service-specific service activation code. It also provides me a method to do
E2E monitoring independent of the client of the PW and the server layers the
Pw traverses.".

As there is more then one type of PW these days, i.e. MPLS-PW and L2TP-PW
(see Yaakov's email), I consider the "MPLS-PW" to be part of the MPLS-TP
solution space, and an MPLS MS-PW layer to be one of the MPLS-TP layer
networks. 

The other MPLS-TP layer networks are the MPLS tunnel and MPLS link layer
networks. But also the service VLAN layer network (referred to as VPLS
layer) is part of the MPLS-TP solution space.

What I have added to the above MPLS-TP basis is the recognition that MPLS-TP
will not be the only technology being used in the network to support
Ethernet and TDM services; the other main technology is Ethernet VLAN. In
many networks all or a part of the UNIs will be located in Ethernet VLAN
type equipment.

This recognition at this point in the MPLS-TP development is important in my
opinion, as it allows us to **prevent** that we will have to develop
**complex interworking** between p2p service VLANs and p2p MPLS MS-PWs to
support etherent and TDM services of which UNIs are in both Ethernet VLAN
and MPLS-TP domains in the future (e.g. 2010).

MEF already took care of such potential interworking by copying the TDM PW
specifying in MEF8 as TDM over Ethernet encapsulation.

The Ethernet PW and the Ethernet over Ethernet encapsulation are also very
similar, which allows interworking.

The other PWs (e.g. ATM PW, FR PW, PPP PW, HDLC PW) have not been copied
into Ethernet service specifications, but if it is necessary to carry e.g
ATM over Ethernet, then it is a simple matter to reuse the ATM PW
encapsulation as ATM over Ethernet encapsulation. This again enables
interworking.

We all know that interworking also requires interoperability of OAM. In this
case interoperability of the existing Ethernet VLAN OAM and the MPLS-TP OAM
under development. Rather then to wait until 2010 to figure out how to
interwork the p2p service VLAN OAM with the p2p MPLS-TP MS-PW OAM, I propose
to accept such interworking requirement already today as one of the MPLS-TP
OAM requirements. I.e. follow a "pro-active" approach instead of a
"reactive" one in 2010. Pro-active approach today implies simple
interworking in 2010,2011,etc, reactive approach implies complex
interworking in 2010,2011,etc.

In my opinion, good engineering practice will follow a pro-active approach.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Thomas Nadeau
Sent: vrijdag 19 december 2008 13:48
To: George Swallow
Cc: [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

	I agree with you guys here. I want to modify the existing clients as
little as possible, and not at all if we can help it. At present, I don't
see any reasons to modify the PWE3 specifications, for example, if we remain
reasonable about the requirements of what we are trying to achieve. This
assumes you agree with me that most if not all of Maartin's recent
requirements and assertions on them were inaccurate.

	--Tom

> Yaakov -
>
> I very much agree.  One of the things that was discussed in the JWT 
> was that we did not want to open up the possibility of defining a 
> whole new set of ways of carrying all the payloads that are carried in 
> PW.
>
> ...George
>
>
>> the list last week, I think possibility 1. is clearly correct.  I.e., 
>> If MPLS-TP has many clients, then the relationship of PWs to MPLS- TP

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 12:08:03 +0100

Neil,

I have the impression that you advocate that MPLS-TP is not an extension of
MPLS (including MPLS-PW), but that MPLS-TP is a brand new thing, with new
encapsulation methods of client signals. You do so as you want to get rid of
the Control Word. You prefer to use the Associated Channel instead ("To
summarise CW bad, Ass-Ch OK.").

Nonetheless that I would have preferred to see a Protocol Type/Identifier
field in the frame format of MPLS, such is not the case today for the
encapsulation formats of its client signals Ethernet VLAN, ATM VP, ATM VC,
FR, PPP, TDM, HDLC, IP. Such Protocol Type/Identfier field has in the mean
time been defined as Associated Channel and has been added to other clients
including OAM type "clients".

As MPLS-TP is stated to be an evolution of MPLS (including MPLS-PW) we have
to live with the current encapsulation methods and frame formats, including
thus the Control Word.

Furthermore, it is in my opinion extremely important to separate the data
plane discussions from the control plane discussions. I have the impression
that you mix up both discussions. Let's make sure we first discuss the data
plane independent of the control plane.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: vrijdag 19 december 2008 13:49
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

 
NH=> You have to distinguish these functions from the (i) the PW label
(which has the key role of information recovery due to LDP/PHP merging) and
(ii) 1st nibble ECMP hack mitigation.  The latter is non-issue in MPLS-TP.
However, the former is intrinsically tied to the functions you identify for
the multi-hop case....and here we have the currently unresolved labelling
problem I identified.  Now this is a serious problem that must be corrected
in MPLS-TP, and the right way to sort this is NOT to use multi-hop PWs
because this will create another co-ps layer network above MPLS-TP....so
let's get back to pure adaptation case no matter how good/bad it is.

In addition, I believe the key thing some folks really want to have is the
Ass-Ch...and see the mail I posted this morning which addresses this.  The
CW is of very dubious value in MPLS-TP (I'd say none).

> 
> Unless we are to respecify the adaptation function performed by PWs 
> then they are necessary to carry anything but MPLS or IP over MPLS.
NH=> I really don't think so.  MPLS-TP done right would be like any other
layer network, eg why are these non-issue in GMPLS controlled networks I
wonder? (rhetorical question to make a point).

Aside=> If you want to really get into what adaptation should consider (and
what is actually used depends on specific client and server modes), the
primary functions are (i) client traffic unit delineation, (ii)
idle-fill/rate-decoupling, (ii) PID and (iv) integrity check.  None of these
figure in the CW...but it has some functions that have problems...and I
can/will explain if need be.  To summarise CW bad, Ass-Ch OK.

There is however a more subtle point wrt the S bit that I have consciously
steered cleared of because I did not want to hit everyone will all the
issues at once, ie the S-bit in MPLS as-is creates sublayers.  This is OK
per se, but these are not client/server and they carry the illusion that we
can create client topology on the fly just by 'adding another (lower level)
header'.  Sublayers can bite you architecturally....so we should be a little
careful here with MPLS-TP.

> Given a blank sheet of paper we could all come up with a new 
> adaptation that is 'cleaner' than the PW one but we don't have a blank 
> sheet of paper, PWs are widely deployed in large networks (including 
> BT's).
NH=> Ben....because folks have mistakes in the past this is no reason to
keep making them.  We have to be able to change direction and fix problems
in *future* stds work from lessons learned...else there is little real point
in doing it.

> The most
> pragmatic approach is therefore to modify the current PW specs where 
> necessary and live with some of the wrinkles - not ideal but then 
> nothing is in the world.
NH=> Agreed.  In the mail I posted earlier today I was trying to offer what
I consider would be the best way to proceed with MPLS-TP wrt this very view.
And I am very conscious of the value some folks place on the Ass-Ch...but
don't confuse this with the problems that caused PWs in the 1st place or the
CW....and for goodness sake let us please not create another co-ps mode
layer network above MPLS-TP...now that would be really daft given we now
have a better understanding of this.

> 
> The value of MS-PW to me is that it provide a common client layer when 
> I want to carry something over multiple independent domains that may 
> be different technologies - it avoids the need for lower layer NNIs 
> and because S-Pes do not contain NSPs they are independent of what is 
> contained in the PW and enable me to provision segments between S-PEs 
> in a common reusable way regardless of the client of the PW.  My OSS 
> is simpler and needs less service-specific service activation code. It 
> also provides me a method to do E2E monitoring independent of the 
> client of the PW and the server layers the Pw traverses.
> 

> correct) on defining and using a GACH in a PW for this purpose.
NH=> OK, but this is really not the best way IMO.  I would suggest that the
OOB CP/MP is kept logically separate from any other functions that one might
want to impose on the *traffic DP*...albeit flagged up here by some 'DP
alert label'.

And I would also suggest folks give serious consideration to my proposal to
use a reserved label for creating an efficient client/server 'functional
breakwater' between the LSPs belong to different MPLS-TP layer
networks....unlike the S bit issue (of sublayering) this carries a proper
client/server semantic.

regards, Neil

> specification should obviously be done by the PWE3 WG. There may be 
> other additional pieces that also need specifying.
> 
> Ben
> 
> 
> 
> 
>

---

From: <[email-masked]>
Date: Mon, 22 Dec 2008 11:57:54 -0000

Maarten,

My guide above all else is accuracy/honesty.  Further, an engineer must
be able to wear the hat of a technician, an economist and a scientist.
Put simply, I am trying to ensure that when we specify MPLS-TP it is as
best as we can possibly make it taking into account all factors (inc the
history of MPLS and all we have learned about networking (good/bad) from
the past).  I do not provide my suggestions lightly...there is much
thought and internal discussion with collegaues both internal and
external here.

Now please see in-line for some specific remarks:

> Sent: 22 December 2008 11:08
> To: Harrison,N,Neil,CXM R; Niven-jenkins,B,Ben,DMF R; 
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> I have the impression that you advocate that MPLS-TP is not 
> an extension of MPLS (including MPLS-PW), but that MPLS-TP is 
> a brand new thing, with new encapsulation methods of client 
> signals.
NH=> Not really.  I am not advocating the invention of new CP protocols,
new addressing, a new MPLS traffic unit's fundamental structure, etc.
So your view here is incorrect.  We do not have a greenfield site
however....but we should learn from past mistakes and correct them where
we can.  And perhaps even more importantly we should not introduce new
mistakes.

> You do so as you want to get rid of the Control 
> Word. You prefer to use the Associated Channel instead ("To 
NH=> Please see my analysis (mail to Himanshu).  I am merely pointing
out what should be obvious...just in case it isn't to all.

> 
> Nonetheless that I would have preferred to see a Protocol 
> Type/Identifier field in the frame format of MPLS,
NH=> Well, I'd personally agree, but this was not done in MPLS and to
introduce it in MPLS-TP might be considered a major change of traffic
unit.  A PID functional field is only forced in the cl-ps mode (ie each
traffic unit MUST carry it because there is no connection to carry that
semantic).  It is not forced in the co-cs or co-ps modes IFF they (i)
obey the rules of a connection (most important of which is single
source) and (ii) that (the single) source is not inserting different
types of client into the connection *over the lifetime of that
connection*...if it does then you do need a PID.  You get one 'for-free'
if you base your co-ps mode on a cl-ps traffic unit (CF PBB-TE), or you
can add this function by a well-specified generic adaptation like GFP
(UPI field).

> such is 
> not the case today for the encapsulation formats of its 
> client signals Ethernet VLAN, ATM VP, ATM VC, FR, PPP, TDM, 
> HDLC, IP. Such Protocol Type/Identfier field has in the mean 
> time been defined as Associated Channel and has been added to 
> other clients including OAM type "clients".
NH=> Have you ever analysed just how the PID function works in MPLS
as-is?  I have, its not pretty...but this is a digression.  I don't want
to have to keep repeating the full set of analysis of why things look
like they do today (or at least I hope I don't, but I will until folks
grasp it if necessary)...however, I DO want to make MPLS-TP the best it
can possibly be...and that means exposing some things I suspect some
folks would rather not hear and preventing unnecessary work.  As I said
at the outset, my guide here is accuracy/honesty, and you can only make
wise direction-setting decisions if you are prepared to properly
understand where and why things stand today as they do.

> 
> As MPLS-TP is stated to be an evolution of MPLS (including 
> MPLS-PW) we have to live with the current encapsulation 
> methods and frame formats, including thus the Control Word.
NH=> I do not agree with all this.  We have choices here with some of
this.  But we can only exercise that choice if we are properly armed
with all the facts.  All I am trying to do is open folks eyes to what is
good (ie worth keeping) and what is bad (and should be removed if
possible...and a great deal of the bad stuff can be removed).
> 
> 
> 
> Furthermore, it is in my opinion extremely important to 
> separate the data plane discussions from the control plane 
> discussions.
NH=> I don't...the DP/CP/MP are interelated and folks working on network
stds should have a strong understanding of all these 3 planes and how
they interact/relate in each mode.  This of course assumes a good grasp
of what is in G.800 and how networks work, eg in a very simplistic sense
you CANNOT divorce the DP/CP/MP in a cl-ps mode network, but you are
FORCED to separate them in the co-cs mode....in the co-ps mode you can
either make good or bad choices wrt DP/CP/MP relationships....it's the
nature of resource partitioning and labelling as G.800 shows.  I know
you have spent a long time with Andy Reid recently, so I would have
hoped some of this was starting to rub off on you.

 I have the impression that you mix up both 
> discussions. Let's make sure we first discuss the data plane 
> independent of the control plane.
NH=> No way....try telling that to IETF wrt IP or IEEE wrt Ethernet (cl
types)  We can't do that.  We have to consider the full networking
system.  There is more to networking than (DP) OAM ;-)....and there is
(less) to OAM than some think ;-)!

regards, Neil
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> NH=> You have to distinguish these functions from the (i) the 
> PW label (which has the key role of information recovery due 
> to LDP/PHP merging) and
> However, the former is intrinsically tied to the functions 
> you identify for the multi-hop case....and here we have the 
> currently unresolved labelling problem I identified.  Now 
> this is a serious problem that must be corrected in MPLS-TP, 
> and the right way to sort this is NOT to use multi-hop PWs 
> because this will create another co-ps layer network above 
> MPLS-TP....so let's get back to pure adaptation case no 
> matter how good/bad it is.
> 
> In addition, I believe the key thing some folks really want 
> to have is the Ass-Ch...and see the mail I posted this 
> morning which addresses this.  The CW is of very dubious 
> value in MPLS-TP (I'd say none).
> 
> > 
> NH=> I really don't think so.  MPLS-TP done right would be 
> like any other layer network, eg why are these non-issue in 
> GMPLS controlled networks I wonder? (rhetorical question to 
> make a point).
> 
> Aside=> If you want to really get into what adaptation should 
> consider (and what is actually used depends on specific 
> client and server modes), the primary functions are (i) 
> client traffic unit delineation, (ii) 
> idle-fill/rate-decoupling, (ii) PID and (iv) integrity check. 
>  None of these figure in the CW...but it has some functions 
> that have problems...and I can/will explain if need be.  To 
> summarise CW bad, Ass-Ch OK.
> 
> There is however a more subtle point wrt the S bit that I 
> have consciously steered cleared of because I did not want to 
> hit everyone will all the issues at once, ie the S-bit in 
> MPLS as-is creates sublayers.  This is OK per se, but these 
> are not client/server and they carry the illusion that we can 
> create client topology on the fly just by 'adding another 
> (lower level) header'.  Sublayers can bite you 
> NH=> Ben....because folks have mistakes in the past this is 
> no reason to keep making them.  We have to be able to change 
> direction and fix problems in *future* stds work from lessons 
> learned...else there is little real point in doing it.
> 
> > The most
> specs where 
> NH=> Agreed.  In the mail I posted earlier today I was trying 
> to offer what I consider would be the best way to proceed 
> with MPLS-TP wrt this very view.
> And I am very conscious of the value some folks place on the 
> Ass-Ch...but don't confuse this with the problems that caused 
> PWs in the 1st place or the CW....and for goodness sake let 
> us please not create another co-ps mode layer network above 
> MPLS-TP...now that would be really daft given we now have a 
> better understanding of this.
> 
> 
> > 
> layer when 
> > Do we need to specify PW behaviour in MPLS-TP? I think we 
> do to some 
> > extent.
> NH=> OK, but this is really not the best way IMO.  I would 
> suggest that the OOB CP/MP is kept logically separate from 
> any other functions that one might want to impose on the 
> *traffic DP*...albeit flagged up here by some 'DP alert label'.
> 
> And I would also suggest folks give serious consideration to 
> my proposal to use a reserved label for creating an efficient 
> client/server 'functional breakwater' between the LSPs belong 
> to different MPLS-TP layer networks....unlike the S bit issue 
> (of sublayering) this carries a proper client/server semantic.
> 
> regards, Neil
> 
> > 
> specifying.  That 
> information wrt 
> requirement 
> mentioned 
> place are 
> 2. MPLS and

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 13:37:43 +0100

Andy,

It seems that you limit MPLS-TP to the tunnel/path and link/section layers
of the layer stack, and that you exclude the service/channel layer from this
MPLS-TP layer stack.

With your MPLS-TP definition you can only serve a single domain (e.g. metro
domain). Your definition of MPLS-TP can not provide a multi-domain,
multi-operator packet transport network supporting p2p, p2mp Ethernet, TDM,
ATM, FR, etc services and rmp, mp2mp Ethernet services; i.e. your definition
of MPLS-TP is lacking the service/channel layer that supports these services
and provides the UNI-N to UNI-N connectivity.

A transport network without service/channel layer is incomplete. MPLS-TP
based packet transport network must include such service/channel layer to be
a packet transport network.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andrew G. Malis
Sent: vrijdag 19 december 2008 21:13
To: Drake, John E
Cc: [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

Just to recap the position that John and I were taking on an earlier version
of this discussion, on the mpls-interop list:

MPLS-TP is a transport service, and presents a packet-oriented interface to
its clients. It is agnostic as to what the client chooses to carry over in
the packets that are transported by this service. The client can use the
MPLS-TP label on which the packet arrives to discriminate between various
MPLS-TP LSPs and to identify the context of the client packets being
delivered. It is up to the clients at the two ends of the MPLS-TP LSP to
decide what is being transported between them. This may be provisioned at
the two ends of the MPLS-TP LSP, or dynamically signaled. It is expected
that typical client payloads will be data-oriented MPLS, unlabeled IP, and
PWs of all sorts as defined by the IETF. Other payloads may also be
possible.

Cheers,
Andy

On Thu, Dec 18, 2008 at 1:24 PM, Drake, John E <[email-masked]>
wrote:
> As I said in my note to Yakov S, nothing precludes additional clients 
> in the future.
>
> Thanks,
>
> John
>
>>it is? How could it be? IP is one client, MPLS is the another, and PWs

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 13:48:38 +0100

George,

The T-PE may not be a MPLS or MPLS-TP node; it may be an Ethernet node (e.g.
PEB, I-BEB, or other service VLAN terminating node). 

T-PE-(ethernet cloud)-S-PE-(MPLS-TP cloud)-S-PE-(MPLS cloud)-T-PE.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of George Swallow
Sent: vrijdag 19 december 2008 21:48
To: Thomas Nadeau; Andrew G. Malis; Drake, John E
Cc: [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

...George

On 12/19/08 3:34 PM, "Thomas Nadeau" <[email-masked]> wrote:

>> If MPLS-TP is used as an aggregation technology, which to me seems 
>> the largest potential use, then we will have many instances where one 
>> client is connected to MPLS-TP and the other is connected to MPLS 
>> (sans TP).  If we want interoperability here, then any payload needs 
>> to standard.  We have a workgroup that defines standards for non-IP 
>> payloads.  That group is PWE3 and that is why they are part of the
MPLS-TP work.
> that do MPLS-TP or MPLS, but either end of a link was going to be
like-to-like only?
>>> interface to its clients. It is agnostic as to what the client 
>>> chooses to carry over in the packets that are transported by this 
>>> service. The client can use the MPLS-TP label on which the packet 
>>> arrives to discriminate between various MPLS-TP LSPs and to identify 
>>> the context of the client packets being delivered. It is up to the 
>>> clients at the two ends of the MPLS-TP LSP to decide what is being 
>>> transported between them. This may be provisioned at the two ends of 
>>> the MPLS-TP LSP, or dynamically signaled. It is expected that 
>>> typical client payloads will be data-oriented MPLS, unlabeled IP, 
>>> and PWs of all sorts as defined by the IETF. Other payloads may also be
possible.
>>>> So, it is up to the client endpoints of the MPLS TP LSP to 
>>>> understand the payload contents and we could have as payloads, for 
>>>> example, MPLS packets with their own label stack, IP packets, or 
>>>> ethernet PW packets which in turn contain, for example, MPLS packets or
IP packets.
>>>> clients in the future.

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 13:58:04 +0100

Adrian,

The MPLS-TP MS-PW and the MPLS MS-PW will be using the same encapsulation
for their client signals, so indeed no interworking for this part. 

The MPLS-TP MS-PW and MPLS MS-PW will be using different sets of OAM to
accompany the encapsulated client signals, so we need OAM interworking
between MPLS-TP and MPLS PWs.

MPLS-TP endpoints must also interwork with p2p Etherent VLAN endpoints.

MPLS-TP PW OAM could therefore support the Ethernet Y.1731 OAM PDUs (of
course with MPLS-TP OAM headers replacing the Ethernet OAM headers) plus
BFD. When interworking with MPLS PW endpoints, MPLS-TP BFD is used. When
interworking with Ethernet VLAN endpoints MPLS-TP CCM is used as well as
e.g. MPLS-TP AIS, MPLS-TP LMM/LMR, MPLS-TP LBM/LBR, etc.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: vrijdag 19 december 2008 22:04
To: George Swallow; Thomas Nadeau; Andrew G. Malis; Drake, John E
Cc: [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

No interworking at all.

A
----- Original Message -----
From: "George Swallow" <[email-masked]>
To: "Thomas Nadeau" <[email-masked]>; "Andrew G. Malis" 

>>> largest potential use, then we will have many instances where one client

>>> want interoperability here, then any payload needs to standard.  We have

>> MPLS-TP-to-MPLS-TP for interop reasons? A given LSR could have links that

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 14:32:00 +0100

Neil,

I see a multi-stage Protocol Type/Identifier being present in MPLS today.

The S-bit is a single bit Protocol Type/Identifier with the following
encoding:
S=0: client layer signal is a MPLS(-TP) layer signal
S=1: client layer signal is non-MPLS(-TP) layer signal.

When S=1, the first 4-bits following the label stack entry header provide a
next element of the Protocol Type/Identifier; values 0,1,4 and 6 are defined
(as far as I know). 
- values 4 and 6 identify IP clients. 
- value 1 identifies the presence of a 16-bit protocol type/identifier
(called Channel Type)
- value 0 identifies the presence of Ethernet, TDM, ATM VP, ATM VC, and a
few more.

Value 0 is non-specific. This is how it is and we can't change history, so
let's live with it.

Regards,
Maarten
PS.1: In theory it is possible to add a GACH to the encapsulation frame
format of Ethernet, TDM, ATM VP, etc in MPLS-TP; i.e. the CW is preceeded by
a GACH. Such additonal GACH can then be removed in the MPLS-TP<=>MPLS PW
interworking function when interconnecting with existing MPLS PW endpoint.
When interworking with Ethernet VLAN such GACH is replaced by the TYPE
field; if the Channel Type values would use the EtherType values, this
replacement is very simple.

PS.2: Note that a similar 1-bit Protocol Type/Identifer is defined in
802.1ah; i.e. the UCA. UCA=0 is a 1-bit representation of EtherType=89-10.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: vrijdag 19 december 2008 22:45
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Pseudo wires and MPLS-TP

Hi Andy...

As I have discovered (from many private mails I have received over last few
days, and somewhat to my surprise) the stuff I take as 'obvious'
isn't obvious to all who don't have a background in functional architecture
concepts....so whilst I may think 'that's done/dusted, folks can't argue
with that' I've discovered this is not true in all cases.

Here's one issue that cropped up tonight that I thought was obvious and that
I had already explained completely, but some private comments I've had show
this is not understood, even by the key players in IETF:  The S bit in MPLS
as-is is all about sublayering (ie stacked LSPs) and does NOT create a
client/server relationship between stacked LSPs.  Now I don't really care if
folks want to retain the S bit sublayering in MPLS-TP or not
(architecturally it's a nonsense, each LSP SHOULD be an independemnt layer
network in MPLS-TP), but if some folks DO want to retain it AND we want to
create a proper transparent client/server relationship we are going to need
something ADDITIONAL to the S bit to effect this in the traffic DP.  

The most efficacious way to do this is to define reserved label (from the
0-15 set) that has the globally well-known semantic "this label marks a
boundary between the MPLS network of party X and that of party Y"...and now
the S bit can be used in each of these verically stacked client/server
partitions independently.  A key use here could be
MPLS(old)overMPLS-TP....where folks want to retain the old S bit ideas in
the MPLS(old) layer network.

A key point here is that this reserved label provides a (traffic DP)
indication function for the case of MPLS (old or TP) clients/servers.
Anything other than MPLS (old/TP) as a client (inc IP as *DP traffic*...IP
as *CP/MP* gets carried in a logically OOB GMPLS adjunct network, again
using a different resereved label) gets transparently carried in the MPLS-TP
payload directly...just as Andy remarks below.

Hope that makes sense.

regards, Neil

> understand

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 14:35:37 +0100

Neil,

> and it's a PW layer network per client type, as PWs
> are not generic but client specific

I do not understand what is giving you the suggestion that PWs are not
generic?

As far as I understand PWs, they represent three pieces:
1) client to PW encapsulation
2) PW connection (multi-segment)
3) PW connection identifier (PW label) within a PW link supported by a MPLS
tunnel LSP.

Only the first piece is client specific, the other two pieces are client
independent.

Regards,
Maarten

-----Original Message-----
Sent: vrijdag 19 december 2008 23:03

Lucy...what you seem to advocate here is potentially dangerous IMO.  You may
create a full-blown PW layer network if you are not careful....and it's a PW
layer network per client type, as PWs are not generic but client specific.

This is not at all the way we should be proceeding now.  But I can see the
temptation to do so, even though its so obviously wrong to me. And if this
happens then pray what is the common adaptation above this?....we can
recurse this ever upwards.

Aside=> This nearly happened with GFP in ITU, ie create a layer network out
of GFP (instead of keeping it as pure adaptation).  However, it was
fortunately stopped in time.  This why I am so against multi-hop PWs...hope
you can see this, ie multi-hop==networked entity.

regards, Neil

> To: 'Adrian Farrel'; 'George Swallow'; Nadeau,TD,Tom,DMF R; 'Andrew G. 
> Malis'; 'Drake, John E'
> Cc: [email-masked]
> In this case, Service layer (PW) is supported by multiple transport 
> domains (MPLS-TP or MPLS). Transport domains do not interconnect at 
> all. Each transport domain provides virtual interfaces to the service 
> layer.
> 
> Regards,
> Lucy
> 
> chooses

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 14:46:39 +0100

Neil,

You realy mix up independent elements: data plane and control plane. Let's
ignore the control plane for some time and just focus on the data plane
alone. Only in this way we will be able to make progress.

There are a couple of steps to go through in the data plane design for
MPLS-TP:
1) specification of layers: service/channel, tunnel/path, link/section, phy
media
2) specification of domains: administrative domains (per carrier) and
access, metro, (regional, national) core domains
3) specification of transport entities in those layers (connections, flow
domain fragments)
4) specification of maintenance entity groups in each transport entity in
each layer
5) specification of frame formats.

Once this data plane building is described and agreed we should start the
control plane discussion.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: zaterdag 20 december 2008 14:34
To: [email-masked]
Subject: [mpls-tp] Sublayers and the S-bit...why we need a reserved label to
do client/server in MPLS-TP

It's become apparent to me, through some private mail discussions, that I
have done a truly awful job in explaining why I have proposed using a
reserved label in MPLS to effect a proper client/server relationship between
stacked LSPs....and how this relates to the S-bit.  So I am going to try and
correct that here.

The key bit to understand is that stacked LSPs in MPLS today are
sublayers.....this implies they all belong to the same parent MPLS layer
network and, most importantly, they are operating under a common CP/MP
instance.  The S bit works within this framework by indicating when we are
the end of such a sublayering stack.

If we did not have the concept of sublayers (so no need for the S bit) we
would NOT require the reserved label at all...indeed, this would be how
MPLS-TP SHOULD be specified IMO, ie a proper client/server relationship
between all stacked LSPs means each one is a proper layer network in its own
right and there is no sublayering.

Sublayering creates problems (as I remarked in an earlier mail) and one
needs to be very careful with it.  I knew it would be a problem that one day
would surface in MPLS when folks wanted to do MPLSoverMPLS as a transparent
client/server relationship *and* they figured out the myth of the 'common
single instance of CP/MP'.

Stewart and I had a draft (expired) a while back that used a pair of
degenerate 1-hop ETH+PW entities instead of a reserved label to create this
functional breakwater (between different S bit sublayered stacks of LSPs).
However, not only is this rather ugly/inefficient (esp if recursed a couple
of times), but as we start to recognise the flawed nature of PWs we really
need a better and more generic way within MPLS itself to create this
functional breakwater...and this is what the reserved label does.

Aside=> The sublayering issue is also one reason (though there are many
others) why we do not like the nested TCM MEP (and esp MIP) ideas ....one
will hit similar downstream problems with this stuff, ie different operator
ownership of nested OAM levels and yet the sublayering is trying to force a
common CP/MP view.

Now, if folks want to retain the concept of sublayering and the S bit as-is
in MPLS-TP, as well as MPLS(old), it is then that you need the reserved
label....if you don't have sublayers (ie no S bit) you do not need the
reserved label, ie you are already operating in a true client/server manner.
And this is the point I failed to clearly articulate previously.....my
sincere apologies as I can now see why it must have caused much confusion.

So it is MPLS(old) that really needs the reserved label approach.  But if
the S bit sublayering is retained in MPLS-TP then this also needs it.
And clearly we also need it for these cases:
-	MPLS(old)_over_MPLS-TP
-	MPLS-TP_over_MPLS(old)

regards, Neil

---

From: <[email-masked]>
Date: Mon, 22 Dec 2008 14:00:29 -0000

Thanks Maarten, spot on.  This is as clear a statement as I've seen yet
that we have already created a new (call it a PW) co-ps mode layer
network above MPLS.  Sure, it a generic (albeit specific type of) co-ps
mode layer network that is in *addition* to MPLS-TP.  Just like a SDH
VC4 layer network is generic.  But because of the way we adapt (sic)
clients into this network via all manner of CW fields that are client
specific (usually various forms of client specific compression) then the
adaption commonality is not there (cf with GFP for example where it is).

There is also the rather thorny problem that if the server is LDP then
the PW label must be a (demerging) SA proxy, whilst with the creation of
a new co-ps 'PW layer network' we need the PW label to take on a
(forwarding) DA proxy....CI conflict.

But let's get back to the critical point, which then solves the
labelling problem noted above, ie do not create a PW layer network in
the 1st place!  Bingo..some key problems go, and we don't have the cost
of this artifically created PW co-ps layer network to manage.

But now we have to seriously question just why did we create PWs in the
1st place?....and we do examine this we find none of the key adaptation
functions exist in the CW header, but we do find client specific fields
(THIS is my point about NOT being generic - CF GFP which is generic),
undefined OAM (eg entry/exit criteria of Seq No aberrations....a field
that is no longer required), a 1st nibble PID/ECMP hack which is also no
longer necssary, etc.....hardly a great thing to carry over into MPLS-TP
IMO when there is no need to.

The Ass-Ch would be more useful however.

regards, Neil

> Sent: 22 December 2008 13:36
> To: Harrison,N,Neil,CXM R; [email-masked]; 
> [email-masked]; [email-masked]; Nadeau,TD,Tom,DMF R; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> > and it's a PW layer network per client type, as PWs are not generic 
> > but client specific
> 
> I do not understand what is giving you the suggestion that 
> PWs are not generic?
> 
> 3) PW connection identifier (PW label) within a PW link 
> supported by a MPLS tunnel LSP.
> 
> Only the first piece is client specific, the other two pieces 
> are client independent.
> 
> Regards,
> Maarten
> 
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Lucy...what you seem to advocate here is potentially 
> dangerous IMO.  You may create a full-blown PW layer network 
> if you are not careful....and it's a PW layer network per 
> client type, as PWs are not generic but client specific.
> 
> This is not at all the way we should be proceeding now.  But 
> I can see the temptation to do so, even though its so 
> obviously wrong to me. And if this happens then pray what is 
> the common adaptation above this?....we can recurse this ever upwards.
> 
> Aside=> This nearly happened with GFP in ITU, ie create a 
> layer network out of GFP (instead of keeping it as pure 
> adaptation).  However, it was fortunately stopped in time.  
> This why I am so against multi-hop PWs...hope you can see 
> this, ie multi-hop==networked entity.
> 
> regards, Neil
> 
> [mailto:[email-masked]] On 
> > > Behalf
> > Of
> > > Adrian Farrel
> > > > S-PEs to bridge the two PSN domains.  So at one end of 
> the MPLS-TP
> > cloud,
> packet-oriented 
> > > >>>>> packets with their own label stack, IP packets, or 
> ethernet PW
> > packets
> additional

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 22 Dec 2008 06:34:40 -0800

Maarten,

It seems that you are unaware of any of the inter/intra AS TE work done
in the IETF over the last six or so years.

Thanks,

John 

>Sent: Monday, December 22, 2008 4:38 AM
>To: 'Andrew G. Malis'; Drake, John E
>Cc: [email-masked]
>It seems that you limit MPLS-TP to the tunnel/path and 
>link/section layers of the layer stack, and that you exclude 
>the service/channel layer from this MPLS-TP layer stack.
>
>With your MPLS-TP definition you can only serve a single 
>domain (e.g. metro domain). Your definition of MPLS-TP can not 
>provide a multi-domain, multi-operator packet transport 
>network supporting p2p, p2mp Ethernet, TDM, ATM, FR, etc 
>services and rmp, mp2mp Ethernet services; i.e. your 
>definition of MPLS-TP is lacking the service/channel layer 
>that supports these services and provides the UNI-N to UNI-N 
>connectivity.
>
>A transport network without service/channel layer is 
>incomplete. MPLS-TP based packet transport network must 
>include such service/channel layer to be a packet transport network.
>
>Regards,
>Maarten
>
>chooses to carry over in the packets that are transported by 
>this service. The client can use the MPLS-TP label on which 
>the packet arrives to discriminate between various MPLS-TP 
>LSPs and to identify the context of the client packets being 
>delivered. It is up to the clients at the two ends of the 
>MPLS-TP LSP to decide what is being transported between them. 
>This may be provisioned at the two ends of the MPLS-TP LSP, or 
>dynamically signaled. It is expected that typical client 
>payloads will be data-oriented MPLS, unlabeled IP, and PWs of 
>all sorts as defined by the IETF. Other payloads may also be possible.
>
>Cheers,
>Andy
>

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 22 Dec 2008 06:34:40 -0800

Maarten,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 22 Dec 2008 06:34:40 -0800

Maarten,

Thanks,

John

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 22 Dec 2008 06:34:40 -0800

Maarten,

Thanks,

John

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Dec 2008 17:27:28 +0100

Neil,

> NH=> I don't...the DP/CP/MP are interelated and folks working on network
stds
> should have a strong understanding of all these 3 planes and how they
> interact/relate in each mode.  This of course assumes a good grasp of what
is in
> G.800 and how networks work, eg in a very simplistic sense you CANNOT
divorce
> the DP/CP/MP in a cl-ps mode network, but you are FORCED to separate them
in the
> co-cs mode....in the co-ps mode you can either make good or bad choices
wrt
> DP/CP/MP relationships....it's the nature of resource partitioning and
labelling
> as G.800 shows.  I know you have spent a long time with Andy Reid
recently, so I
> would have hoped some of this was starting to rub off on you. 

Indeed, Andy and I have spent many hours together recently and got into a
very good common understanding, at least that has been my impression. And
this understanding does not align with your writings.

This common understanding also resulted in some changes to G.800. I.e. the
introduction of the "transport entity". This transport entity (e.g.
connection, flow domain fragment (e.g. VLAN)) is what is being managed and
monitored and what secures the flow of information. 

Within such transport entity there are "forwarding rules" which control the
forwarding of traffic units applied at an input port of the transport
entity.

The connection-oriented and connectionless behaviour are forwarding modes
within a transport entity. 

Connection-oriented forwarding within a transport entity implies that a
traffic unit applied at an input port of that transport entity is broadcast
and delivered to all output ports of that transport entity, with the
exception of the output port associated with the input port on which the
traffic unit was applied. I.e. the transport entity has one forwarding rule:
"broadcast".

Connectionless forwarding within a transport entity implies that a traffic
unit applied at an input port of that transport entity is delivered to a
subset of output ports of that transport entity if there is a forwarding
rule associated with that traffic unit (otherwise the traffic unit is
discarded). I.e. the transport entity has zero or more forwarding rules. 

Hybrid (connection-oriented plus connectionless) forwarding within a
transport entity implies that a traffic unit applied at an input port of
that transport entity is broadcast and delivered to all output ports of that
transport entity, with the exception of the output port associated with the
input port on which the traffic unit was applied and with exception of the
output ports for which there is a "filtering rule" associated with that
traffic unit. I.e. the transport entity has one forwarding rule (broadcast)
and zero or more filtering rules.

Every **transport entity** is managed (set up, monitored, protected) like a
n-port connection using network management or a ASON/GMPLS control plane.

Every **forwarding rule** inside a transport entity may be
- unmanaged default behaviour (e.g. broadcast forwarding rule in VC-12, ATM
VC, and Ethernet VLAN)
- locally managed in equipment (e.g. MAC learning in Ethernet VLAN)
- managed using a forwarding rule control plane tool (e.g. GMRP/MMRP in
Ethernet VLAN)
- managed using a forwarding rule management action (e.g. configuration in
Static Filtering Entry in Ethernet VLAN).

Your cl-ps mode network is as such a network in which there are transport
entities with connectionless or hybrid forwarding (but possibly also
transport entities with connection-oriented forwarding).

Your co-cs and co-ps mode networks are as such a network in which there are
transport entities with connection-oriented forwarding only.

In all three network modes (co-cs, co-ps and cl-ps) it is common to separate
the DP from the **transport entity CP/MP**.

The **forwarding rule CP/MP** may be 
- completely absent (e.g. in VLAN transport entity supporting only unicast
and broadcast forwarding), or may be
- present to control the multicast filtering rules (e.g. in VLAN transport
entity), or may be
- present to control all forwarding rules (in IP transport entity: Internet
or IP VPN transport entities).

As those forwarding rules are located inside a transport entity, it is
necessary to bound the effects of the **forwarding rule CP/MP** actions to
such transport entity. There is thus a strong relation with the configured
transport entity in the DP.

I hope the above helps you to enhance your view on the transport network and
allows you to distinguish between independent entities. I have been
describing the viewpoint you present as the viewpoint of a person sitting
inside a n-port pipe, which gives him the impression that the world is
everything ongoing in this pipe (there is nothing else he can see). If he
would walk to one of the ports on this pipe and look outside, he will notice
that there is a lot more in this world (i.e. many other n-port pipes). He
also will find me in the helicopter above those pipes, watching for him to
come out and discover the real world :-).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 22 december 2008 12:58
To: [email-masked]; [email-masked];

Maarten,

My guide above all else is accuracy/honesty.  Further, an engineer must be
able to wear the hat of a technician, an economist and a scientist.
Put simply, I am trying to ensure that when we specify MPLS-TP it is as best
as we can possibly make it taking into account all factors (inc the history
of MPLS and all we have learned about networking (good/bad) from the past).
I do not provide my suggestions lightly...there is much thought and internal
discussion with collegaues both internal and external here.

Now please see in-line for some specific remarks:

> To: Harrison,N,Neil,CXM R; Niven-jenkins,B,Ben,DMF R; [email-masked]; 
> I have the impression that you advocate that MPLS-TP is not an 
> extension of MPLS (including MPLS-PW), but that MPLS-TP is a brand new 
> thing, with new encapsulation methods of client signals.
NH=> Not really.  I am not advocating the invention of new CP protocols, new
addressing, a new MPLS traffic unit's fundamental structure, etc.
So your view here is incorrect.  We do not have a greenfield site
however....but we should learn from past mistakes and correct them where we
can.  And perhaps even more importantly we should not introduce new
mistakes.

> You do so as you want to get rid of the Control Word. You prefer to 
> use the Associated Channel instead ("To summarise CW bad, Ass-Ch 
> OK.").
NH=> Please see my analysis (mail to Himanshu).  I am merely pointing out
what should be obvious...just in case it isn't to all.

NH=> Well, I'd personally agree, but this was not done in MPLS and to
introduce it in MPLS-TP might be considered a major change of traffic unit.
A PID functional field is only forced in the cl-ps mode (ie each traffic
unit MUST carry it because there is no connection to carry that semantic).
It is not forced in the co-cs or co-ps modes IFF they (i) obey the rules of
a connection (most important of which is single
source) and (ii) that (the single) source is not inserting different types
of client into the connection *over the lifetime of that connection*...if it
does then you do need a PID.  You get one 'for-free'
if you base your co-ps mode on a cl-ps traffic unit (CF PBB-TE), or you can
add this function by a well-specified generic adaptation like GFP (UPI
field).

> such is
> not the case today for the encapsulation formats of its client signals 
> Ethernet VLAN, ATM VP, ATM VC, FR, PPP, TDM, HDLC, IP. Such Protocol 
> Type/Identfier field has in the mean time been defined as Associated 
> Channel and has been added to other clients including OAM type 
> "clients".
NH=> Have you ever analysed just how the PID function works in MPLS as-is?
I have, its not pretty...but this is a digression.  I don't want to have to
keep repeating the full set of analysis of why things look like they do
today (or at least I hope I don't, but I will until folks grasp it if
necessary)...however, I DO want to make MPLS-TP the best it can possibly
be...and that means exposing some things I suspect some folks would rather
not hear and preventing unnecessary work.  As I said at the outset, my guide
here is accuracy/honesty, and you can only make wise direction-setting
decisions if you are prepared to properly understand where and why things
stand today as they do.

> MPLS-PW) we have to live with the current encapsulation methods and 
> frame formats, including thus the Control Word.
NH=> I do not agree with all this.  We have choices here with some of this.
But we can only exercise that choice if we are properly armed with all the
facts.  All I am trying to do is open folks eyes to what is good (ie worth
keeping) and what is bad (and should be removed if possible...and a great
deal of the bad stuff can be removed).
> 
> 
> 
> Furthermore, it is in my opinion extremely important to separate the 
> data plane discussions from the control plane discussions.
NH=> I don't...the DP/CP/MP are interelated and folks working on network
stds should have a strong understanding of all these 3 planes and how they
interact/relate in each mode.  This of course assumes a good grasp of what
is in G.800 and how networks work, eg in a very simplistic sense you CANNOT
divorce the DP/CP/MP in a cl-ps mode network, but you are FORCED to separate
them in the co-cs mode....in the co-ps mode you can either make good or bad
choices wrt DP/CP/MP relationships....it's the nature of resource
partitioning and labelling as G.800 shows.  I know you have spent a long
time with Andy Reid recently, so I would have hoped some of this was
starting to rub off on you.

NH=> No way....try telling that to IETF wrt IP or IEEE wrt Ethernet (cl
types)  We can't do that.  We have to consider the full networking system.
There is more to networking than (DP) OAM ;-)....and there is
(less) to OAM than some think ;-)!

regards, Neil
> However, the former is intrinsically tied to the functions you 
> this is NOT to use multi-hop PWs because this will create another 
> co-ps layer network above MPLS-TP....so let's get back to pure 
> adaptation case no matter how good/bad it is.
> 
> (and what is actually used depends on specific client and server 
> modes), the primary functions are (i) client traffic unit delineation, 
> (ii) idle-fill/rate-decoupling, (ii) PID and (iv) integrity check.
>  None of these figure in the CW...but it has some functions that have 
> sublayers.  This is OK per se, but these are not client/server and 
> they carry the illusion that we can create client topology on the fly 
> just by 'adding another (lower level) header'.  Sublayers can bite you 
> NH=> Ben....because folks have mistakes in the past this is no reason 
> to keep making them.  We have to be able to change direction and fix 
> very view.
> Ass-Ch...but don't confuse this with the problems that caused PWs in 
> the 1st place or the CW....and for goodness sake let us please not 
> create another co-ps mode layer network above MPLS-TP...now that would 
> be really daft given we now have a better understanding of this.
> 
> 
> >