Subject: Re: [mpls-tp] [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

From: <[email-masked]>
Date: Tue, 24 Feb 2009 10:52:44 -0000

Thanks Loa,

Could someone summarise what these 'significant updates' are please?

Thanks....regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: 24 February 2009 10:25
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; ITU-T ad hoc team on MPLS-TP; George Swallow; 
> Ross Callon; David Ward; Malcolm Betts; VIGOUREUX MARTIN
> Subject: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
> 
> All,
> 
> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
> has been published.
> 
> The draft is found at:
> 
> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
> 
> Since the updates are significant this is to initiate a 2 week
> working group last call on the new version.
> 
> Please send your comments to the [email-masked] mailing list.
> 
> The working group last call will end on March 11.
> 
> /Loa
> -- 
> 
> 
> Loa Andersson
> 
> Sr Strategy and Standards Manager
> Ericsson ///                          phone:  +46 8 632 77 14
> 
>                                        email:  
> [email-masked]
>                                                
> [email-masked]
>                                                [email-masked]
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 24 Feb 2009 13:34:33 +0100

Neil,

I realize that I might be misunderstood by using the the word
"significant". I did not mean to say that the there has been
any major technical changes, but that the changes/updates are
spread across the document in such a way that there is no
possibility to limit the wg last call to "changes only" as
we sometimes do.

IETF supplies a number of useful tools to follow the development
of drafts.

go to: http://tools.ietf.org/wg/mpls/

click on the draft name; in this case  draft-ietf-mpls-tp-gach-gal
and on the next page click on diff from version 01.

And you'll have a very colorful presentation of the changes since
the last version.

/Loa

-- 

Loa Andersson

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

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 24 Feb 2009 13:44:24 +0100

Neil,

the main updates concern:
- addition of a new section on the ACH TLV defining in this document
   the strictly needed elements
- IANA considerations on the update of the PW ACH registry and creation
   of a new registry for the TLVs
- update of the GAL section to reflect the presence of the ACH TLV
   header and possibly subsequent TLVs
- clarifications wrt the distinction between the associated channel and
   the 32bits word wich materialize this channel on the wire (the ACH).
   In that context the draft does not generalize the ACH but the PW
   associated channel (by making it applicable to LSPs)
   so G-ACH has disappeared and ACH is simply used instead and the
   the generalized associated channel is referred to as G-ACh (non
   capital 'h').

Stewart was also added to the authors' list to reflect his level of
contributions to the document.

regards,
-m

Loa Andersson a écrit :
>>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>>> Of Loa Andersson
>>> [email-masked]; ITU-T ad hoc team on MPLS-TP; George Swallow; Ross 
>>> Callon; David Ward; Malcolm Betts; VIGOUREUX MARTIN

---

From: Loa Andersson <[email-masked]>
Date: Tue, 24 Feb 2009 11:25:01 +0100

All,

The draft is found at:

/Loa
-- 

Loa Andersson

---

From: <[email-masked]>
Date: Tue, 24 Feb 2009 18:11:17 -0000

I may have some comments on this document, but I need an answer to this
question first:

I note in section 2.1 it says:

"Note that for PWs, the PWE3 control word [6] MUST be present in the
encapsulation of user packets
 when the ACH is used to realize the associated control channel"

If we ignore MPLS/MPLS-TP sublayering (S bit issue) for now, do I assume
either:

(i)	all MPLS-TP clients (including IP) will effectively become PWs
and must have the CW present in the DP?

 or

(ii)	this only applies to MPLS and not MPLS-TP, which is quite
logical since there is no technical justification for PWs in a transport
network (which is what MPLS-TP is supposed to be) so the CW does not
exist at all in the MPLS-TP DP?

regards, Neil

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Feb 2009 19:05:36 +0000

> exist at all in the MPLS-TP DP?
When the service being carried is Ethernet, Frame Relay, TDM etc the 
adaptation in
your terms is a pseudowire control word. There is no point in 
re-inventing new
technology to do carry these types.

I an transport context, when the service being carried is IP/MPLS (and 
the cluster of
other protocols needed to make it work) the most consistent way to do 
this is to use a
pseudowire.

Stewart

---

From: <[email-masked]>
Date: Tue, 24 Feb 2009 20:48:42 -0000

Thank you Stewart, who responded 24 February 2009 19:06

> When the service

NH=> You mean client layer network?

> being carried is Ethernet, Frame Relay, TDM etc the 
> adaptation in

NH=> I fully agree.  So why not use GFP instead of reinventing an
adaptation function as this is the standard generic adaptation function
for *transport networks* for the last 9 years or so? 

If I look at the CW and I am brutally honest, this is not an adaptation
function by any stretch of the imagination, eg transport networks must
never re-order their client's symbols...so what purpose does the CW Seq
No. have if MPLS-TP is supposed to be a transport network?  The 1st
nibble ECMP hack of the CW is also not required in a transport network.
This hardly leaves much left of value I think.

A general purpose client/server transport network adaptation function
should cover:
-	PID....not in the CW
-	client traffic unit delineation....not in the CW
-	idle fill...not in the CW
-	error detection....not in the CW
All these are in GFP...which is why it is a generic adaptation for
transport networks.

I see nothing in the CW that is of real value as adaptation.

But what I find most upsetting here is the insistence of having PWs in
MPLS-TP.  It is technically rather obvious that a transport network has
no need of PWs......please show me another transport network where this
is true?  And if we point at existing PDH/SDH/OTN transport networks,
then of course we will not find a PW/CW adaptation but we will find that
their common generic DP client/server adaptation is GFP.  So I do not
buy any of these arguments on technical grounds....the only
(non-technical) claim is 'because it's what we did in MPLS'.....but even
this does not really wash, because for MPLS-TP to be taken seriously as
a transport network role we must remove the flaws that generated PWs in
the 1st place in MPLS.

If we stick with the PW dogma in MPLS-TP and force the CW on all MPLS-TP
clients then for goodness sake let's make sure we do not commit the even
greater sin of having these as multi-hop entities (ie create another
co-ps layer network above MPLS/MPLS-TP), noting that these still have an
unsolved problem of what their labelling semantic really means in MPLS
(see my Sat 29/11/2008 09:43 post where I explain this one in one some
detail).  Now that would be truly unforgivable IMO.

So, unless there is a change of heart to embrace GFP (well one can
hope), I am going to work on the premise that the unnecessary CW
'adaptation' is present for all MPLS-TP clients for the follow-up
questions/observations I have.  

However, I do think it would be useful if we (ie the community outside
the design team) had a clear view on what the client traffic, MPLS-TP
(server) layer CP/MP, and MPLS (server) layer DP OAM encapsulations look
like in MPLS-TP (carefully noting that defect detection/handling OAM is
a *DP function* and not CP/MP function and should *not* appear under the
GAL...DP OAM should have a header that is as identical as possible to
normal (client) traffic).   Right now I am having to guess at what these
encapsulations look like ...ergo the question I just posted on the
MPLS-TP list to try and tease out some intent/detail.

regards, Neil

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 24 Feb 2009 16:06:34 -0500

I'll take a jump into this - and Ben can update his reference to
including cowgirls:-)

I'm trying to review the control plane framework draft and I've ended up
with the same question as Neil, why are we trying to make MPLS-TP
different from MPLS (and GMPLS) for MPLS clients? In ccamp, we've
completed several RFCs on MPLS-TE to GMPLS migration (RFC5145) and
interworking requirements to support operation of MPLS-TE over MPLS-TE
(using GMPLS control) (RFC5146). They all are based on MPLS data plane.
So if an operator wants to use GMPLS for MPLS and/or MPLS-TP, why would
there be a need for different data encapsulations for the MPLS client
depending if it's over MPLS or MPLS-TP?

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stewart Bryant
Sent: Tuesday, February 24, 2009 2:06 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] [PWE3] 2nd wg last call on
draft-ietf-mpls-tp-gach-gal

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Feb 2009 21:49:47 +0000

BRUNGARD, DEBORAH A, ATTLABS wrote:
> different from MPLS (and GMPLS) for MPLS clients? 
Deborah

When you have an MPLS LSR that you wish to connect to another MPLS LSR
how do you carry the non-MPLS packets?

Stewart

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 24 Feb 2009 13:58:03 -0800

In a PPP packet with a different PID value.

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Tuesday, February 24, 2009 1:50 PM
> To: BRUNGARD, DEBORAH A, ATTLABS
> Cc: [email-masked]
> > I'm trying to review the control plane framework draft and 
> I've ended 
> > up with the same question as Neil, why are we trying to 
> make MPLS-TP 
> When you have an MPLS LSR that you wish to connect to another 
> MPLS LSR how do you carry the non-MPLS packets?
> 
> Stewart

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 24 Feb 2009 17:03:09 -0500

Hi Stewart,

Are you referring to control packets? It depends on the model (several
are discussed in the documents) (and preference of the operator).

One of the models, RFC5145, has:
5.2.  MPLS-TE Control Plane Connectivity

   Control plane connectivity between MPLS-TE LSRs connected by a GMPLS
   island in the Border Peer Model MAY be provided by the control
   channels of the GMPLS network.  If this is done, a tunneling
   mechanism (such as GRE [RFC2784]) SHOULD be used to ensure that
   MPLS-TE information is not consumed by the GMPLS LSRs.  But care is
   required to avoid swamping the control plane of the GMPLS network
   with MPLS-TE control plane (particularly routing) messages.

   In order to ensure scalability, control plane messages for the MPLS-
   TE client network MAY be carried between Border Routers in a single
   hop MPLS-TE LSP routed through the data plane of the GMPLS server
   network.

Deborah

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Tuesday, February 24, 2009 4:50 PM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [PWE3] 2nd wg last call on

Deborah

Stewart

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 24 Feb 2009 14:05:33 -0800

This is actually a very interesting point.  Up until now, the only
things carried in PWs were a handful of layer 1/2 technologies.  With
the advent of MPLS TP, Stewart seems to be saying that *everything*,
including IP and MPLS, must be carried over PWs.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Feb 2009 22:27:32 +0000

What I am saying is that the complete cluster of protocols needed
to form and manage the adjacency, and to transfer the data, needs
to be carried over the transport path in a fate shared manner.

That is only possible if you have some form of multiplexing
such as is provided with a datalink, and the way we carry
datalinks over MPLS currently is in a pseudowire.

Stewart

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 24 Feb 2009 22:39:44 +0000

:-)

Up front disclaimer: I haven't read the RFCs mentioned.

The requirement is to be able to carry MPLS(-TP) over MPLS(-TP). The
requirement is for what G.805 would call a client/server relationship which
is basically carrying one (client) operator's MPLS(-TP) network (data,
control & management planes) over another (server) operator's MPLS(-TP)
network with no interaction between the two. Issue with a single label stack
I think is how can you carry the client control/management plane
transparently without the server operator knowing what it is (i.e. What
protocols) and they may not know that.

E.g. If we compare to today. I go to another operator and order an Ethernet
circuit but I don't tell them what I want to use it for or what protocols I
will be running over it and in a lot of cases I either don't want to tell
them or my security guys won't let me tell them.

In future one may want to do something similar but order an "MPLS circuit"
instead of an Ethernet circuit.

Now with regard to using a PW Vs some other mechanism. I have said in the
past I don't care what the solution is as long as it meets the requirement,
however I see some advantage to a PW approach because my OSS is geared up to
plan, provision, configure, report, alarm, etc PWs (not LSPs) in support of
customer services. Adding a new PW type for MPLS(-TP)overMPLS(-TP) should be
fairly straightforward from an OSS perspective, I can reuse for
MPLS(-TP)overMPLS(-TP) (mostly as-is) the same OSS I already have for
Ethernet services. I have not studied the LSP proposals in depth to
understand what the OSS delta would be but I suspect it would be significant
enough to make a difference.

Note that network equipment & features are not what usually sets the limits
on service deployment timescales and costs (for me at least) but rather OSS
development is the major factor, so minimising that impact is important for
me.

HTH
Ben

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 24 Feb 2009 17:45:14 -0500

Hi Stewart,

I kind of agree with you if ECMP is possible. Is there any other case that
would cause non-fate sharing between IP/MPLS payload and control/management?

This brings me to my second question. Is ECMP permitted in MPLS-TP?

Thanks,
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: February-24-09 5:28 PM
To: Drake, John E
Cc: [email-masked]
Subject: Re: [mpls-tp] [PWE3] 2nd wg last call on
draft-ietf-mpls-tp-gach-gal

Stewart

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 24 Feb 2009 14:47:39 -0800

> Sent: Tuesday, February 24, 2009 2:28 PM
> To: Drake, John E
> Cc: BRUNGARD, DEBORAH A, ATTLABS; [email-masked]
> What I am saying is that the complete cluster of protocols 
> needed to form and manage the adjacency, and to transfer the 
> data, needs to be carried over the transport path in a fate 
> shared manner.

JD:  According to RFC3032 Section 2.2, that is the function of the
bottom-most entry in the MPLS label stack.  The section is copied in its
entirety below, in case you haven't seen it before.

> datalinks over MPLS currently is in a pseudowire.

JD: The way that layer 1/2 is carried *transparently* across an MPLS
network is with PWs.  That is a completely different situation from what
you are describing in your previous paragraph.
 
> Stewart

2.2. Determining the Network Layer Protocol

   When the last label is popped from a packet's label stack (resulting
   in the stack being emptied), further processing of the packet is
   based on the packet's network layer header.  The LSR which pops the
   last label off the stack must therefore be able to identify the
   packet's network layer protocol.  However, the label stack does not
   contain any field which explicitly identifies the network layer

Rosen, et al.               Standards Track                     [Page 5]

RFC 3032               MPLS Label Stack Encoding            January 2001

   protocol.  This means that the identity of the network layer protocol
   must be inferable from the value of the label which is popped from
   the bottom of the stack, possibly along with the contents of the
   network layer header itself.

   Therefore, when the first label is pushed onto a network layer
   packet, either the label must be one which is used ONLY for packets
   of a particular network layer, or the label must be one which is used
   ONLY for a specified set of network layer protocols, where packets of
   the specified network layers can be distinguished by inspection of
   the network layer header.  Furthermore, whenever that label is
   replaced by another label value during a packet's transit, the new
   value must also be one which meets the same criteria.  If these
   conditions are not met, the LSR which pops the last label off a
   packet will not be able to identify the packet's network layer
   protocol.

   Adherence to these conditions does not necessarily enable
   intermediate nodes to identify a packet's network layer protocol.
   Under ordinary conditions, this is not necessary, but there are error
   conditions under which it is desirable.  For instance, if an
   intermediate LSR determines that a labeled packet is undeliverable,
   it may be desirable for that LSR to generate error messages which are
   specific to the packet's network layer.  The only means the
   intermediate LSR has for identifying the network layer is inspection
   of the top label and the network layer header.  So if intermediate
   nodes are to be able to generate protocol-specific error messages for
   labeled packets, all labels in the stack must meet the criteria
   specified above for labels which appear at the bottom of the stack.

   If a packet cannot be forwarded for some reason (e.g., it exceeds the
   data link MTU), and either its network layer protocol cannot be
   identified, or there are no specified protocol-dependent rules for
   handling the error condition, then the packet MUST be silently
   discarded.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Feb 2009 22:51:16 -0000

Stewart, I am puzzled here...

> to be carried over the transport path in a fate shared manner.

Why is that?
Why do the protocols needed to form and manage the adjacency (management and 
control plane protocols) need to be carried in a fate shared manner?
Certainly there is no requirement to fate share with the data.
And there is no requirement to fate share packet to packet - this is why we 
have built these protocols on IP.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Tue, 24 Feb 2009 22:52:50 -0000

I am not sure I would completely agree with you on this Stewart.  If we
take the co-cs mode the CP/MP is forced (by the physics) to be logically
at least OOB wrt the traffic DP and run in an adjunct network....which
is what all the work on GMPLS has been about.  Moreover, if the CP fails
operators still need the DP to survive in transport networks...so they
do not necessarily totally fate share.

Note also that we need the OAM to be in the traffic DP.....not run in
the logically OOB CP/MP network (that needs its own OAM...usually CP/MP
protocol keepalives).  And this is not so in what seems is being
proposed, but was indeed the intent of the proposal John and I put
forward.  So I would still have an arch issue if the MPLS-TP DP OAM had
a different header structure to the normal traffic and sits under the
GAL....the GAL should only be used for CP/MP protocols IMO, and this way
we also get a very clean DP and CP/MP separation.

Aside=> When we were writing Y.1711 we were forced to use label 14 as
the OAM indicate.  I hated it, it is just so wrong architecturally.  But
it was all we could get at that time....due to the nature of MPLS.
However, in MPLS-TP we are supposed to be creating a *transport network*
and this requires removing a set of issues that are really only germane
to MPLS LDP/PHP/ECMP cases...if we don't do this then I really don't see
how we can claim we have created a transport network.  And of course, in
doing so the whole rationale for PWs is gone too....

regards, Neil 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: 24 February 2009 22:28
> To: Drake, John E
> Cc: [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Feb 2009 11:30:52 +0000

Adrian Farrel wrote:
> Why do the protocols needed to form and manage the adjacency 
> (management and control plane protocols) need to be carried in a fate 
> shared manner?
Consider the router hello's.

The assumption in routing is that the hellos (which may be carried in IP 
or may be carried in some other L2 protocol) fate share with the data. 
If they do not fate share an adjacency may be formed that routing thinks 
is fine, but which is black holing data traffic.

> Certainly there is no requirement to fate share with the data.
I disagree the fate sharing of hellos and data is a day one assumption 
in the design of an IGP, and we have to be able to support correct 
operation of an IGP over a transport network.
> And there is no requirement to fate share packet to packet - this is 
> why we have built these protocols on IP.
>
The way to think about this is that you have two LSRs connected by a 
real wire, and you replace that real wire with an MPLS-TP path. Can the 
LSR do any experiment that confirms that it is now on an MPLS-TP path? 
Where ever the answer is yes, we have to investigate all of the 
consequences for all the protocol and deem them to be inconsequential.

Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Feb 2009 12:26:31 -0000

Stewart,

Having reached the end of the email, commenting as I went along, it is clear 
to me that we are mixing a discussion of the client's control and data 
plane, with the server's control and data plane. My intention was to talk 
about the latter.

>> Why do the protocols needed to form and manage the adjacency (management 
>> and control plane protocols) need to be carried in a fate shared manner?
> or may be carried in some other L2 protocol) fate share with the data. If 
> they do not fate share an adjacency may be formed that routing thinks is 
> fine, but which is black holing data traffic.

Erm, yes.
And isn't this exactly the point of MPLS-TP? We are not building an IP/MPLS 
network where the control lane and data plane fate share. We are building a 
transport network where the control plane can "get its messages through".

Indeed, the concept of a router adjacency is highly suspect when we don't 
have IP traffic, and so are just exchanging TE information. There is no 
requirement to form a tight and full mesh of router adjacencies in order to 
flood information about the tight and full mesh of TE links.

> I disagree the fate sharing of hellos and data is a day one assumption in 
> the design of an IGP, and we have to be able to support correct operation 
> of an IGP over a transport network.

You say IGP over a transport network, not IGP in a transport network.

This is key.

>From the perspective of the transport network, there is no difference 
between different types of data that may be carried. It the client network 
is an IP network running an IGP then all of the user data (IP packets) and 
the routing protocol data (IP packets) can be (and should be) presented as a 
single stream of packets to be carried over the server layer LSP as if on a 
single hop link between adjacent routers in the client layer.

If the client layer is not IP/MPLS, but some transport technology (such as 
MPLS-TP, or MPLS-TE in the absence of IP traffic) then there is no 
requirement to comingle the client's data and control traffic (since the 
client is not running an IP IGP). In this case, since fate sharing is not 
required in the client network, the data and control traffic can be carried 
over the server network in different ways.

However, for an IGP *in* a transport network, I refer to the comments at the 
top of this email.

>> And there is no requirement to fate share packet to packet - this is why 
>> we have built these protocols on IP.
>
> The way to think about this is that you have two LSRs connected by a real 
> wire, and you replace that real wire with an MPLS-TP path. Can the LSR do 
> any experiment that confirms that it is now on an MPLS-TP path? Where ever 
> the answer is yes, we have to investigate all of the consequences for all 
> the protocol and deem them to be inconsequential.

I think we may be in violent agreement except to insist that we make it very 
clear when we are talking about client and when we are talking about server.

A

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Feb 2009 12:43:26 +0000

Adrian

Yes - I am only talking about the service that the server provides to a 
client, and
my point is that clients need to transparently exchange much more 
information
than IP/MPLS.

Stewart

Adrian Farrel wrote:
> Stewart,
>
> Having reached the end of the email, commenting as I went along, it is 
> clear to me that we are mixing a discussion of the client's control 
> and data plane, with the server's control and data plane. My intention 
> was to talk about the latter.
>
>>> (management and control plane protocols) need to be carried in a 
>>> fate shared manner?
>> The assumption in routing is that the hellos (which may be carried in 
>> IP or may be carried in some other L2 protocol) fate share with the 
>> data. If they do not fate share an adjacency may be formed that 
>> routing thinks is fine, but which is black holing data traffic.
>
> Erm, yes.
> And isn't this exactly the point of MPLS-TP? We are not building an 
> IP/MPLS network where the control lane and data plane fate share. We 
> are building a transport network where the control plane can "get its 
> messages through".
>
> Indeed, the concept of a router adjacency is highly suspect when we 
> don't have IP traffic, and so are just exchanging TE information. 
> There is no requirement to form a tight and full mesh of router 
> adjacencies in order to flood information about the tight and full 
> mesh of TE links.
>
>> I disagree the fate sharing of hellos and data is a day one 
>> assumption in the design of an IGP, and we have to be able to support 
>> correct operation of an IGP over a transport network.
>
> between different types of data that may be carried. It the client 
> network is an IP network running an IGP then all of the user data (IP 
> packets) and the routing protocol data (IP packets) can be (and should 
> be) presented as a single stream of packets to be carried over the 
> server layer LSP as if on a single hop link between adjacent routers 
> in the client layer.
>
> If the client layer is not IP/MPLS, but some transport technology 
> (such as MPLS-TP, or MPLS-TE in the absence of IP traffic) then there 
> is no requirement to comingle the client's data and control traffic 
> (since the client is not running an IP IGP). In this case, since fate 
> sharing is not required in the client network, the data and control 
> traffic can be carried over the server network in different ways.
>
> However, for an IGP *in* a transport network, I refer to the comments 
> at the top of this email.
>
>> real wire, and you replace that real wire with an MPLS-TP path. Can 
>> the LSR do any experiment that confirms that it is now on an MPLS-TP 
>> path? Where ever the answer is yes, we have to investigate all of the 
> I think we may be in violent agreement except to insist that we make 
> it very clear when we are talking about client and when we are talking 
> about server.
>
> A
>

---

From: <[email-masked]>
Date: Wed, 25 Feb 2009 15:43:17 -0000

Very well put Adrian.

And if MPLS-TP is supposed to be a transport network then we should take
a very long hard look at existing transport networks, understand how
they work (ideally in func arch terms) and learn from what is good (or
bad) about them...in particular when designing the CP for MPLS-TP we
should look at what was done in CCAMPs wrt to the GMPLS CP components
here.

If there is one thing that is crucial however it is that we must have a
complete functional separation of the client and server layer networks.
The DP/CP/MP of the client layer network are carried transparently (and
this word has a very precise meaning - see Note at end) over the *DP* of
the server layer network....which also means that a link connection
(==hop) of the client layer network (all 3 planes) is supported by a
end-end path (==network connection) in the DP of the server layer
network....this is how client layer topology is indeed created.

So there is no coupling of any functional component (in either DP, CP or
MP) between the client and server layer networks.  But you should
already be very familiar with this concept Stewart, as it's why with
MPLSoverMPLS (as client/server case) we had to insert a degenerate (ie
1-hop) Ethernet PW as a 'functional breakwater' between the 2 MPLS
stacks in the draft we did last year that has now expired.  Hardly
elegant/efficient but it did the job.

The CCAMPs folks have been dealing with this client/server relationship
issue for years with GMPLS with no problems.  And indeed so has IETF
(perhaps subconciously?) wrt to saying 'IP over everything'....here is
it crucial that the link connections (ie between nodes) in an IP layer
network have transparent carriage by a server layer network....I am sure
IETF would be up in arms if some lower layer server technology decided
to snoop/modify the information in client IP packets as they were
carried along.

I suspect the reason some folks are having problems with this issue is
that they are still trying to cling onto the flawed notion that there
can somehow be a common CP spanning all layers IP to Optics....it's a
lovely idea but it's a myth and plain won't work as some might think it
will (and for many reasons, though the technical ones are sufficient).  

I have said it many times before but I'll say it again and again until
the message finally sinks in....the 3 network modes are different (G.800
tries to explain why this is).  You cannot functionally crunch them all
together (and this means more than just the routing process of the CP),
and nor are the detailed requirements of all their functional components
the same....though we can have significant reuse of components as long
as folks understand (i) what subtle differences are needed for each mode
and (ii) that re-used components in different layer networks are
different/isolated instances of that component, eg I can use the same
set of v6 addresses for both SDH VC4 and VC12 access points if I
like.....but the v6 addressed access points in the VC4 layer network
cannot ever be connected to the v6 addressed access points in the VC12
layer network....and one can think of countless other examples like this
wrt to other technologies/components.

Note on Transparency:
-	the server treats all client symbols equally
-	the server ensures the ordering preservation of client symbols
-	the server makes no attempt to infer the meaning of, and for
sure never modify, the client layer symbols
-	the server does not allow the traffic behaviour of client X to
impact the performance experienced by client Y

regards, Neil

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 25 February 2009 12:27
> To: [email-masked]
> Cc: [email-masked]
> assumption in

---

From: "David Allan" <[email-masked]>
Date: Tue, 24 Feb 2009 13:34:07 -0500

Well I'll make the same comment again....

In section 4.3 it states...

   o  Unlike the mechanisms described and referenced in RFC 3429 [18],
      MPLS-TP maintenance messages will not reside immediately after the
      GAL but instead behind the ACH, which itself resides after the
      bottom of the label stack.  This ensures that OAM, using the
      G-ACh, complies with RFC 4928 [11].

While RFC 4928 says

   It must also be noted that LSRs that correctly identify a payload as
   not being IP most often will load-share traffic across multiple
   equal-cost paths based on the label stack.  Any reserved label, no
   matter where it is located in the stack, may be included in the
   computation for load balancing.  Modification of the label stack
   between packets of a single flow could result in re-ordering that
   flow.  That is, were an explicit null or a router-alert label to be
   added to a packet, that packet could take a different path through
   the network.

So the mere presence of the GAL will violate RFC 4928....the presence of
the GACH cannot fix this...and claiming the GACH does provide compliance
is misleading....the paragraph in section 4.3 should be deleted...

Cheers
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Loa Andersson
Sent: Tuesday, February 24, 2009 5:25 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked];
ITU-T ad hoc team on MPLS-TP; George Swallow; Ross Callon; David Ward;
Betts, Malcolm (CAR:X632); VIGOUREUX MARTIN
Subject: [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

All,

an updated version (-02) of the draft-ietf-mpls-tp-gach-gal has been
published.

The draft is found at:

Since the updates are significant this is to initiate a 2 week working
group last call on the new version.

/Loa
-- 

Loa Andersson

                                       email: