Subject: [mpls-tp] Results of informal review of Section 3.4 draft-ietf-mpls-tp-framework-07

From: [email-masked]
Date: Tue, 19 Jan 2010 17:03:43 -0500

Stewart,

Your  request for an informal review of section 3.4 of 
draft-ietf-mpls-tp-framework-07 was assigned to Q.12/15.  This review 
produced a number of comments.  Many of which were capture in a marked up 
document that was discussed today on the MPLS-TP call.  The results of 
that discussion have been posted to the MPLS-TP wiki  (
http://wiki.tools.ietf.org/misc/mpls-tp/attachment/wiki/meeting-notes/).

Two other significant comments arose that were not captured directly in 
the marked up document:

1)      Use of the term ?Network Layer?:
2)      Need for multi segment pseudo wires.

I have provide my view of the key points that were raised, I invite other 
ITU participants to add any points that I missed.

Network Layer:

A request was made to provide reference for how a 'network layer' 
protocol, as mentioned in sections 3.4.3, is defined.  Based on discussion 
today my understanding is that the term ?network layer protocol? is used 
in RFC3031.  I think that this comment could be resolved if the authors 
can avoid using the term ?Network Layer? and make it clear that the 
context for ?Network Layer Protocol? is described in RFC 3031.

Multi segment pseudo wire:

The initial request was to provide the rational for the inclusion of multi 
segment PWs in MPLS-TP.
This provoked some further discussion (both on line and off line) that 
raised some questions and concerns over the use of PWs in general and in 
particular making the PW a layer network (in the G.800/G.805 sense) vs. 
restricting the role of the PW to providing client adaptation..  A summary 
of the points raised is provided below.

In an instance of an implementation of a MPLS-TP network the bottom label 
in the scope of that network may be either a PW label or an LSP label.
PWs uses T-LDP for signalling, it is my understanding that this is ?in 
band? and relies on IP forwarding contrary to the requirements.  It is not 
clear what protocols are used for other control plane functions (e.g. 
routing, discovery).  LSPs use an out of band GMPLS control plane (as 
defined in the requirements).
T-LDP does not support traffic engineering
T-LDP requires extension to support multi segment PWs.  The scope of these 
extensions and the proposed routing protocols are not well understood 
within the ITU.
Tandem connection monitoring of a PW is achieved by pushing a (LSP) label 
and using the (server) LSP for PST monitoring (same as for a LSP).
Setting up a PW with traffic engineering and/or segment monitoring 
requires the use and coordination of both a T-LDP and a GMPLS control 
plane.

These issues could be either avoided or limited if we restrict the role of 
the PW to providing client adaptation at the edge of a MPLS-TP network and 
using LSPs in the core of the network.

We would very much appreciate your comments on these points.

Regards

Malcolm Betts
Co chair ad hoc on MPLS-TP

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 19 Jan 2010 17:11:37 -0500

Malcolm,

I totally agree with the concerns about viewing PWs as an intrinsic part of MPLS-TP rather than a client of MPLS-TP network layer.

Igor

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, January 19, 2010 5:04 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [mpls-tp] Results of informal review of Section 3.4 draft-ietf-mpls-tp-framework-07

Stewart,

Your  request for an informal review of section 3.4 of draft-ietf-mpls-tp-framework-07 was assigned to Q.12/15.  This review produced a number of comments.  Many of which were capture in a marked up document that was discussed today on the MPLS-TP call.  The results of that discussion have been posted to the MPLS-TP wiki  (http://wiki.tools.ietf.org/misc/mpls-tp/attachment/wiki/meeting-notes/).

Two other significant comments arose that were not captured directly in the marked up document:

1)        Use of the term "Network Layer":
2)        Need for multi segment pseudo wires.

I have provide my view of the key points that were raised, I invite other ITU participants to add any points that I missed.

Network Layer:

A request was made to provide reference for how a 'network layer' protocol, as mentioned in sections 3.4.3, is defined.  Based on discussion today my understanding is that the term "network layer protocol" is used in RFC3031.  I think that this comment could be resolved if the authors can avoid using the term "Network Layer" and make it clear that the context for "Network Layer Protocol" is described in RFC 3031.

The initial request was to provide the rational for the inclusion of multi segment PWs in MPLS-TP.
This provoked some further discussion (both on line and off line) that raised some questions and concerns over the use of PWs in general and in particular making the PW a layer network (in the G.800/G.805 sense) vs. restricting the role of the PW to providing client adaptation..  A summary of the points raised is provided below.

 *   In an instance of an implementation of a MPLS-TP network the bottom label in the scope of that network may be either a PW label or an LSP label.
 *   PWs uses T-LDP for signalling, it is my understanding that this is "in band" and relies on IP forwarding contrary to the requirements.  It is not clear what protocols are used for other control plane functions (e.g. routing, discovery).  LSPs use an out of band GMPLS control plane (as defined in the requirements).
 *   T-LDP does not support traffic engineering
 *   T-LDP requires extension to support multi segment PWs.  The scope of these extensions and the proposed routing protocols are not well understood within the ITU.
 *   Tandem connection monitoring of a PW is achieved by pushing a (LSP) label and using the (server) LSP for PST monitoring (same as for a LSP).
 *   Setting up a PW with traffic engineering and/or segment monitoring requires the use and coordination of both a T-LDP and a GMPLS control plane.

These issues could be either avoided or limited if we restrict the role of the PW to providing client adaptation at the edge of a MPLS-TP network and using LSPs in the core of the network.

Regards

Malcolm Betts

---

From: "Loa Andersson" <[email-masked]>
Date: Wed, 20 Jan 2010 02:44:48 +0100 (CET)

Malcolm,

reading RFC3031 reveals that

> Co chair ad hoc on MPLS-TP

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///
   phone:  +46 10 717 52 13
           +46 767 72 92 13

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

---

From: "Loa Andersson" <[email-masked]>
Date: Wed, 20 Jan 2010 02:58:12 +0100 (CET)

All,

sorry the previous mail with the same subject, ws sent to early
(I'm using a web-mail when travelling, that I'm really not
used to :( ).

Malcolm,

reading rfc3031 reveals that "network layer" is used in the
following combinations:

network layer protocol
network layer routing algorithm
network layer header
network layer forwarding
network layer destination address
network layer packet
network layer encapsulation
network layer address

The RFC also says that network layer is synomous with Layer 3.

This shows that the network layer concept is a corner stone in
the mpls architecture and hardly something we can avoid, by a
statement that "network layer protocol is used as in rfc3031".

/Loa

Loa Andersson

---

From: <[email-masked]>
Date: Wed, 20 Jan 2010 08:50:57 -0000

Thanks for this very useful summary Malcolm which, of course, I agree
with.  We should also not forget the point I raised about the nature of
the original PW label, ie this MUST take-on a SA proxy semantic to
provide a demerging service for non-IP clients.  We do not require this
demerging service in MPLS-TP and, more importantly, we do not need
MS-PWs...technically we do not even require single-hop PWs, but for
'backwards alignment' if PWs are constrained to a single hop then at
least we will have avoided the major technical mistake/cost of creating
a quite unnecessary layer network above MPLS-TP.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Igor Bryskin
	Sent: 19 January 2010 22:12
	To: [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked];
[email-masked]
	Subject: Re: [mpls-tp] Results of informal review of Section3.4
draft-ietf-mpls-tp-framework-07

	Malcolm,

	I totally agree with the concerns about viewing PWs as an
intrinsic part of MPLS-TP rather than a client of MPLS-TP network layer.

	Igor

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Tuesday, January 19, 2010 5:04 PM
	To: [email-masked]
	Cc: [email-masked]; [email-masked];
[email-masked]
	Subject: [mpls-tp] Results of informal review of Section 3.4
draft-ietf-mpls-tp-framework-07

	Stewart, 
	
	Your  request for an informal review of section 3.4 of
draft-ietf-mpls-tp-framework-07 was assigned to Q.12/15.  This review
produced a number of comments.  Many of which were capture in a marked
up document that was discussed today on the MPLS-TP call.  The results
of that discussion have been posted to the MPLS-TP wiki
(http://wiki.tools.ietf.org/misc/mpls-tp/attachment/wiki/meeting-notes/)
. 
	
	Two other significant comments arose that were not captured
directly in the marked up document: 

	I have provide my view of the key points that were raised, I
invite other ITU participants to add any points that I missed. 
	
	Network Layer: 
	
	A request was made to provide reference for how a 'network
layer' protocol, as mentioned in sections 3.4.3, is defined.  Based on
discussion today my understanding is that the term "network layer
protocol" is used in RFC3031.  I think that this comment could be
resolved if the authors can avoid using the term "Network Layer" and
make it clear that the context for "Network Layer Protocol" is described
in RFC 3031. 

	The initial request was to provide the rational for the
inclusion of multi segment PWs in MPLS-TP. 
	This provoked some further discussion (both on line and off
line) that raised some questions and concerns over the use of PWs in
general and in particular making the PW a layer network (in the
G.800/G.805 sense) vs. restricting the role of the PW to providing
client adaptation..  A summary of the points raised is provided below. 

	*	In an instance of an implementation of a MPLS-TP network
the bottom label in the scope of that network may be either a PW label
or an LSP label. 
	*	PWs uses T-LDP for signalling, it is my understanding
that this is "in band" and relies on IP forwarding contrary to the
requirements.  It is not clear what protocols are used for other control
plane functions (e.g. routing, discovery).  LSPs use an out of band
GMPLS control plane (as defined in the requirements). 
	*	T-LDP does not support traffic engineering 
	*	T-LDP requires extension to support multi segment PWs.
The scope of these extensions and the proposed routing protocols are not
well understood within the ITU. 
	*	Tandem connection monitoring of a PW is achieved by
pushing a (LSP) label and using the (server) LSP for PST monitoring
(same as for a LSP). 
	*	Setting up a PW with traffic engineering and/or segment
monitoring requires the use and coordination of both a T-LDP and a GMPLS
control plane. 

	These issues could be either avoided or limited if we restrict
the role of the PW to providing client adaptation at the edge of a
MPLS-TP network and using LSPs in the core of the network. 

	Regards 
	
	Malcolm Betts

---

From: <[email-masked]>
Date: Wed, 20 Jan 2010 09:27:10 -0000

Loa,

Loa Andersson wrote 20 January 2010 01:58
> 
> All,
> 
> sorry the previous mail with the same subject, ws sent to 
> early (I'm using a web-mail when travelling, that I'm really 
> not used to :( ).
> 
> Malcolm,
> 

NH=> Layer 3 actually means nothing useful.  An SDH VC4 layer network is
also 'Layer 3' in the OSI sense...just a fact.  The OSI model was
created before we had any really good generic models of networking.  IMO
we are only just beginning to get this written down now in G.800.  You
can also see that the OSI model never really fitted reality even for IP,
eg above the IP layer network there is not a good fit of the OSI Ls4-7
with what we find in practically deployed IP-based networks.

> 
> This shows that the network layer concept is a corner stone 
> in the mpls architecture and hardly something we can avoid, 
> by a statement that "network layer protocol is used as in rfc3031".

NH=> Well, the rather harsh fact is that the cornerstone is broken.  I
actually don't care too much about all this wrt to 'what is a name', but
what I do strongly object to is when some incorrect property is assigned
to a given mode/technology because of the flawed naming convention.

For example, I think many folks make the association that there is only
one 'network layer' protocol (though clearly adding MPLS to this list
breaks this rule anyway), and that a network layer protocol must be
cl-ps....this is just plain technically wrong....and this is not very
hard to prove.  But even a simple observation can show this....just look
at the work in CCAMPs on GMPLS...we add IP to SDH, OTN, etc (in an OOB
CP/MP sense) and the layer networks we create here are for sure NOT L1
or L2!  And with the work on MPLS-TP we are doing exactly the same, ie
moving the IP-based CP/MP logically OBB wrt to the MPLS-TP DP....we
simply have to in order to create a proper layer network for MPLS-TP and
remove the problems of inconsistent CI we find in LDP.

I think the technical evidence is totally compelling that the OSI term
'network layer' is way past its sell-by date.  It's now time to move on
and stop promulgating obvious mistakes.

regards, Neil
> > of that discussion have been posted to the MPLS-TP wiki  ( 
> > 
> > I have provide my view of the key points that were raised, I invite 
> > other ITU participants to add any points that I missed.
> >
> > Network Layer:
> >
> > protocol, as mentioned in sections 3.4.3, is defined.  Based on 
> > discussion today my understanding is that the term ?network layer 
> > protocol? is used in RFC3031.  I think that this comment could be 
> > resolved if the authors can avoid using the term ?Network 
> Layer? and 
> > make it clear that the context for ?Network Layer Protocol? 
> is described in RFC 3031.
> >
> line) that 
> > raised some questions and concerns over the use of PWs in 
> general and 
> > in particular making the PW a layer network (in the 
> G.800/G.805 sense) vs.
> > restricting the role of the PW to providing client adaptation..  A 
> > summary of the points raised is provided below.
> >
> > In an instance of an implementation of a MPLS-TP network the bottom 
> > label in the scope of that network may be either a PW label 
> or an LSP label.
> > band? and relies on IP forwarding contrary to the 
> requirements.  It is 
> > not clear what protocols are used for other control plane 
> functions (e.g.
> > T-LDP does not support traffic engineering T-LDP requires 
> extension to 
> > support multi segment PWs.  The scope of these extensions and the 
> > proposed routing protocols are not well understood within the ITU.
> > Tandem connection monitoring of a PW is achieved by pushing a (LSP) 
> > label and using the (server) LSP for PST monitoring (same 
> as for a LSP).
> > These issues could be either avoided or limited if we restrict the 
> > role of the PW to providing client adaptation at the edge 
> of a MPLS-TP 
> > network and using LSPs in the core of the network.
> >
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 20 Jan 2010 11:20:48 -0500

> The RFC also says that network layer is synomous with Layer 3.

Loa,
	To add to your point we can look at RFC3209 which built on this point 
and went down one level in detail.  It says:

       L3PID
          an identifier of the layer 3 protocol using this path.
          Standard Ethertype values are used.

(From context in the document it is clear that it too is treating "layer 
3" as synonymous with "network layer".)

I don't think this resolves the discussion, but it adds a bit of 
specificity to what was meant by "network layer" (layer 3) in RFCs3031 
and 3032.

Lou

---

From: "Loa Andersson" <[email-masked]>
Date: Wed, 20 Jan 2010 18:12:05 +0100 (CET)

Lou,

sure agree, my point ís that if we suddenly declare that we abandon
one of the cornerstones in the mpls architecture this would also
rock the JWT agreement and we would need to go back and rework
the mpls architecture, and I feel that this is both a lengthy and
unnecessary process.

My take is that rfc3031 and rfc3032 are suffiecently clear, and it is
well motivated to use the term "network layer" in mpls-tp rfc's the same
way as is doen in the rfc3031 and rfc3032.

/Loa

Loa Andersson

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 26 Jan 2010 21:36:14 +0100

As discussed during the IETF call today, I am sending some slides describing my understanding of the the issue with the current PW TCM (or PST) definition and some alternative solutions to be used as an input for the discussion.
 
The issue of PW TCM will be addressed during the IETF call planned for next week.
 
Any early feedbacks/comments on the slides are appreciated.
 
Italo

P.S. Please note my new email address, [email-masked], effective since 1 November 2009.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: martedì 19 gennaio 2010 23.04
	To: [email-masked]
	Cc: [email-masked]; [email-masked]; [email-masked]
	Subject: [mpls-tp] Results of informal review of Section 3.4draft-ietf-mpls-tp-framework-07

	Stewart, 

	

	Network Layer: 

	

	
	
	Regards 
	
	Malcolm Betts

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 28 Jan 2010 15:45:23 +0000

[email-masked] wrote:
>  (_http://wiki.tools.ietf.org/misc/mpls-tp/attachment/wiki/meeting-notes/_). 
>
>

Malcolm, thank you for this additional feedback on 
draft-ietf-mpls-tp-framework-07.

These points were discussed at the weekly MPLS-TP call on the evening of 
Tuesday 26th January 2010.
> *Network Layer:*
> make it clear that the context for "Network Layer Protocol" is 
> described in RFC 3031.
>
After lengthy discussion on the call it was resolved that the new text 
that references RFC3031 & RFC3032 for the use of the term "Network 
Layer" was adequate for the purposes of this document, and is consistent 
with current IETF best practice. Please refer to 
draft-ietf-mpls-tp-framework-08 section 3.4.3.

> *Multi segment pseudo wire:*
>
These individual points were extensively discussed  in the 26th January 
call, and the  response are notes below.
> multi segment PWs in MPLS-TP.
It was notes that in some network scenarios, MS-PW was a useful tool. 
However it have been noted in version 9 of the draft that MP-PWs are 
optional and not precluded from the MPLS-TP architecture.
> raised some questions and concerns over the use of PWs in general and 
> in particular making the PW a layer network (in the G.800/G.805 sense) 
> vs. restricting the role of the PW to providing client adaptation..  A 
>     * In an instance of an implementation of a MPLS-TP network the
>       bottom label in the scope of that network may be either a PW
>       label or an LSP label.
>
This is correct, but note that a PW label and an LSP label are BOTH MPLS 
labels (see RFC4447).
>
>     * PWs uses T-LDP for signalling, it is my understanding that this
>       is "in band" and relies on IP forwarding contrary to the
>       requirements.  It is not clear what protocols are used for other
>       control plane functions (e.g. routing, discovery).  LSPs use an
>       out of band GMPLS control plane (as defined in the requirements).
>
Version 9 of the framework clarifies that T-LDP may be sent out of band 
or over the DCC. The choice of which protocols to use for routing and 
discovery is already described in  the relevant PWE3 and L2VPN RFC and 
drafts, which are referenced by this framework.
>     * T-LDP does not support traffic engineering
This was discussed on the call, and it was noted that 
draft-ietf-pwe3-dynamic-ms-pw describes the support for the element of 
TE required for MS-PW e.g. bandwidth signaling and path selection. ITU-T 
experts are invited to read this draft and provide comment to the PWE3 WG.
>
>     * T-LDP requires extension to support multi segment PWs.  The
>       scope of these extensions and the proposed routing protocols are
>       not well understood within the ITU.
>
T-LDP extensions are defined in draft-ietf-pwe3-segmented-pw (which is 
under IESG review), and in draft-ietf-pwe3-dynamic-ms-pw.
>
>     * Tandem connection monitoring of a PW is achieved by pushing a
>       (LSP) label and using the (server) LSP for PST monitoring (same
>       as for a LSP).
>
This point was accepted on the call and as noted in version 9 of the 
framework is an item requiring further study.
>       monitoring requires the use and coordination of both a T-LDP and
>       a GMPLS control plane.
>
It was accepted on the call that this is the current state of the art, 
but as noted above the future definition of other PW control protocols 
is not precluded. However since this definition does not yet exist and 
considering the wide deployment of T-LDP for packet transport by IP/MPLS 
networks, a pragmatic recommendation was made to continue with the use 
of T-LDP until a suitably mature alternative protocol exists.
> role of the PW to providing client adaptation at the edge of a MPLS-TP 
A PW provides additional functionality in addition to adaptation. These 
additional functions provide considerable scaling advantages. For 
example the multiplexing provides significant scaling advantages over an 
LSP approach, which is why it was adopted instead of alternative IETF 
proposed protocols that omitted this multiplexing component. In addition 
the state co-ordination provides a number of benefits.

Regards

Stewart Bryant
PWE3 Co-chair.

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 29 Jan 2010 11:06:25 +0100

Stewart,
 
thanks for having summarized the discussion we had this tuesday.
 
See my comments in line marked with [ib]
 
Italo

 

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
	Sent: giovedì 28 gennaio 2010 16.45
	To: [email-masked]
	Cc: [email-masked]; [email-masked]; [email-masked]
	Subject: Re: [mpls-tp] Results of informal review of Section 3.4draft-ietf-mpls-tp-framework-07

		Stewart, 

		

	Malcolm, thank you for this additional feedback on draft-ietf-mpls-tp-framework-07.
	
	These points were discussed at the weekly MPLS-TP call on the evening of Tuesday 26th January 2010.

		Network Layer: 

	After lengthy discussion on the call it was resolved that the new text that references RFC3031 & RFC3032 for the use of the term "Network Layer" was adequate for the purposes of this document, and is consistent with current IETF best practice. Please refer to draft-ietf-mpls-tp-framework-08 section 3.4.3.

	These individual points were extensively discussed  in the 26th January call, and the  response are notes below.

	It was notes that in some network scenarios, MS-PW was a useful tool. However it have been noted in version 9 of the draft that MP-PWs are optional and not precluded from the MPLS-TP architecture.

	This is correct, but note that a PW label and an LSP label are BOTH MPLS labels (see RFC4447).

	Version 9 of the framework clarifies that T-LDP may be sent out of band or over the DCC. The choice of which protocols to use for routing and discovery is already described in  the relevant PWE3 and L2VPN RFC and drafts, which are referenced by this framework. 

	This was discussed on the call, and it was noted that draft-ietf-pwe3-dynamic-ms-pw describes the support for the element of TE required for MS-PW e.g. bandwidth signaling and path selection. ITU-T experts are invited to read this draft and provide comment to the PWE3 WG.

	T-LDP extensions are defined in draft-ietf-pwe3-segmented-pw (which is under IESG review), and in draft-ietf-pwe3-dynamic-ms-pw.

	This point was accepted on the call and as noted in version 9 of the framework is an item requiring further study.
	
	[[ib]]  I recall we have agreed to further discuss this issue at the next IETF weekly call on 2 February in the context of the OAM Framework draft. Is my memory correct?
	As I stated during the call, this is a major open issue to be resolved before closing this discussion: if we adopt MS-PW as a layer network in the scope of MPLS-TP, we need to ensure that MPLS-TP can support all the transport requirements. We currently have an open issue with PW TCM.

	It was accepted on the call that this is the current state of the art, but as noted above the future definition of other PW control protocols is not precluded. However since this definition does not yet exist and considering the wide deployment of T-LDP for packet transport by IP/MPLS networks, a pragmatic recommendation was made to continue with the use of T-LDP until a suitably mature alternative protocol exists.

	A PW provides additional functionality in addition to adaptation. These additional functions provide considerable scaling advantages. For example the multiplexing provides significant scaling advantages over an LSP approach, which is why it was adopted instead of alternative IETF proposed protocols that omitted this multiplexing component. 
	
	[[ib]] I might have missed this point during the discussion (I apologize).
	I agree with your statement but it is also true that using PW just as an adaptation toward a Service LSP does not preclude multiplexing different Service LSPs within a Tunnel LSP for scaling purposes.
	My point during the call was that, if MS-PW can support all the transport requirements, I do not see any advantage of using Service LSP (over tunnel LSPs) versus using MS-PW over tunnel LSPs.
	As said above, the main pending issue remains the feasibility of the MS-PW extensions that are required to meet all the transport requirements. PW TCM seems to be the major open issue so far.
	 
	 In addition the state co-ordination provides a number of benefits.
	
	[[ib]] Could you please provide more details regarding this statement?
	 
	Regards
	
	Stewart Bryant
	PWE3 Co-chair.

		Regards 
		
		Malcolm Betts

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Jan 2010 10:26:10 +0000

Italo
>
>
>>         * Tandem connection monitoring of a PW is achieved by pushing
>>           a (LSP) label and using the (server) LSP for PST monitoring
>>           (same as for a LSP).
>>
>     This point was accepted on the call and as noted in version 9 of
>     the framework is an item requiring further study.
>
>     [[ib]]  I recall we have agreed to further discuss this issue at
>     the next IETF weekly call on 2 February in the context of the OAM
>     Framework draft. Is my memory correct?
>     As I stated during the call, this is a major open issue to be
>     resolved before closing this discussion: if we adopt MS-PW as a
>     layer network in the scope of MPLS-TP, we need to ensure that
>     MPLS-TP can support all the transport requirements. We currently
>     have an open issue with PW TCM.
>

There are several candidate solutions emerging, yours and some that 
Matthew/Dan and I came up with. To settle on a solution will take a 
little while. I would propose that we continue with the publication 
process of the main framework with this item left for further study and  
to write up the PW TCM as a separate draft. That allows us to get 
started on the last call process with the framework make progress on the 
vast majority of the technical material. We can if necessary merge the 
two documents a part of the LC resolution process. if we proceed with 
two documents, then the second one would be very short and should get 
though the process quite quickly.

What is important from where we stand today is to get a conditional 
approval to publish the framework subject to a satisfactory way forward 
for PW  TCM.

- Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 29 Jan 2010 16:39:00 +0100

Stewart, Italo,

>From a transport network viewpoint we will have a
- transport service layer network in which the transport paths
  have a 1-to-1 relationship with the customer services, and
- transport path layer network in which the transport paths
  carry an aggregate of transport service layer transport paths.

The transport paths in the transport service layer network will
be a mixture of MS-PWs, Service LSPs, PST LSPs, Segment LSPs, 
Bundle LSPs, Packet PWs and HVPLSs.

Any difference in OAM, PSW and TCM handling between PWs, LSPs
and HVPLSs in this transport service layer will unnecessary 
complicate MPLS-TP equipment and its management.

Developing a PW TCM solution that is different from the LSP TCM
and HVPLS TCM (i.e ETH TCM) solutions will introduce a third TCM
solution in the transport service layer of MPLS-TP networks.

One of the T-MPLS requirements was to design a low complex, traffic
engineered packet transport technology, with minimized differences with 
the HVPLS technology that is supporting the rmp and mp2mp services. 
MPLS-TP seems to have dropped this requirement as far as I can observe; 
it is becoming the most complex packet transport technology alternative
with multiple solutions for the same functions.

Is this the right direction?

It would be much better from the transport network's perspective to
have only one type of transport path in the transport service layer.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: vrijdag 29 januari 2010 11:26
To: BUSI ITALO
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mpls-tp] Results of informal review of
Section3.4draft-ietf-mpls-tp-framework-07

Italo

There are several candidate solutions emerging, yours and some that
Matthew/Dan and I came up with. To settle on a solution will take a little
while. I would propose that we continue with the publication process of the
main framework with this item left for further study and to write up the PW
TCM as a separate draft. That allows us to get started on the last call
process with the framework make progress on the vast majority of the
technical material. We can if necessary merge the two documents a part of
the LC resolution process. if we proceed with two documents, then the second
one would be very short and should get though the process quite quickly.

What is important from where we stand today is to get a conditional approval
to publish the framework subject to a satisfactory way forward for PW  TCM.

- Stewart

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 15:56:39 -0000

Stewart,
 
Thanks for providing these notes.  Just wanted to to add my
recollections from the call (mainly for information of those not able to
make the call)...please see in-line:

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stewart Bryant
	Sent: 28 January 2010 15:45
	To: [email-masked]
	Cc: [email-masked]; [email-masked];
[email-masked]
	Subject: Re: [mpls-tp] Results of informal review of Section
3.4draft-ietf-mpls-tp-framework-07

		Stewart, 

		Two other significant comments arose that were not
captured directly in the marked up document: 

		I have provide my view of the key points that were
raised, I invite other ITU participants to add any points that I missed.

	These points were discussed at the weekly MPLS-TP call on the
evening of Tuesday 26th January 2010.

		Network Layer: 
		
		A request was made to provide reference for how a
'network layer' protocol, as mentioned in sections 3.4.3, is defined.
Based on discussion today my understanding is that the term "network
layer protocol" is used in RFC3031.  I think that this comment could be
resolved if the authors can avoid using the term "Network Layer" and
make it clear that the context for "Network Layer Protocol" is described
in RFC 3031. 

	After lengthy discussion on the call it was resolved that the
new text that references RFC3031 & RFC3032 for the use of the term
"Network Layer" was adequate for the purposes of this document, and is
consistent with current IETF best practice. Please refer to
draft-ietf-mpls-tp-framework-08 section 3.4.3. 
	NH=> Yes there was a lengthy discussion, and a key point of this
was that the term 'network layer' in its old OSI L3 sense is meaningless
at best.  The major reason we did not  want to change anything is that
this flawed 'network layer' term goes back a long time and it would be
difficult to change all the standards that would be impacted (which is
more than IETF).  My advice on the call was for folks to try and stop
using this flawed term and instead try and think more in terms of how
G.800 functionally describes layer networks.  And to illustrate this
point I offered the example of a co-cs mode SDH VC4 layer network that
uses an adjunct logically OOB cl-ps GMPLS/IP-based layer network for the
important CP/MP protocols.  So where is the 'network layer'
here?....noting that there are least 2 layer networks involved in this
network system.  

	These individual points were extensively discussed  in the 26th
January call, and the  response are notes below.

	It was notes that in some network scenarios, MS-PW was a useful
tool. However it have been noted in version 9 of the draft that MP-PWs
are optional and not precluded from the MPLS-TP architecture. 
	NH=> There was another point here that is not reported.  From
purely technical analysis it can be shown that PWs are an artefact of
the LDP type of MPLS.   And we noted on the call that if we were
designing MPLS-TP today with a better understanding of layer networks
then we would almost certainly not have PWs.  However, given they exist
and are considered useful then they will be carried-over into MPLS-TP. 

		This provoked some further discussion (both on line and
off line) that raised some questions and concerns over the use of PWs in
general and in particular making the PW a layer network (in the
G.800/G.805 sense) vs. restricting the role of the PW to providing
client adaptation..  A summary of the points raised is provided below. 

		*	In an instance of an implementation of a MPLS-TP
network the bottom label in the scope of that network may be either a PW
label or an LSP label. 

	This is correct, but note that a PW label and an LSP label are
BOTH MPLS labels (see RFC4447). 
	NH=>  In MPLS as-is a PW label is a non-swapped SA proxy which
is required to recover from any lower level LDP merging.  In MPLS-TP we
are not going to lose source information (ie no LDP/PHP merging LSPs)
and so we only need 2 types of label semantic:  (i) 0-15 set that carry
globally well-known 'functional action' semantics (i) >15 that are used
in normal (destination targeted) label-swapped forwarding sense. 

	We also discussed the related issue of layered network vs
sublayered networks.  In MPLS as-is we largely assume a single layer
network (ie common routing domain) where nested LSPs represent
sublayers...this is not true client/server.  In a true layered case,
nested LSPs would form a client/server relationship, ie each LSP belongs
to a disjoint routing domain in a different layer network.
	 
	Stewart made the point on the call that in a stack of nested
LSPs we could have any mix of sublayering and layering.   

	 PWs uses T-LDP for signalling, it is my understanding that this
is "in band" and relies on IP forwarding contrary to the requirements.
It is not clear what protocols are used for other control plane
functions (e.g. routing, discovery).  LSPs use an out of band GMPLS
control plane (as defined in the requirements). 

	Version 9 of the framework clarifies that T-LDP may be sent out
of band or over the DCC. The choice of which protocols to use for
routing and discovery is already described in  the relevant PWE3 and
L2VPN RFC and drafts, which are referenced by this framework.  

	This was discussed on the call, and it was noted that
draft-ietf-pwe3-dynamic-ms-pw describes the support for the element of
TE required for MS-PW e.g. bandwidth signaling and path selection. ITU-T
experts are invited to read this draft and provide comment to the PWE3
WG. 
	NH=> The critical issue here IMO is whether there is a 1:1
geographic span of the PW and any serving LSPs.  If there is, one can
try and make an appeal to a common routing domain and single layer
network case (this is thus a sublayering case).  In a more general model
however, where there could be multiple MPLS-TP layer networks of
different parties carrying the same PW (as a client), then it is quite
clear that the PW layer network is of greater geographic span than any
of its serving MPLS-TP layer networks and, of course, the routing domain
of the PW layer network is now clearly disjoint from the routing domains
of any of its serving MPLS-TP layer networks.   So now all PW routing
calculations  lie in this (PW) layer only and there will usually be no
ability to control the routing over the lower layer MPLS-TP layer
networks...noting that the (server) multi-hop end-end LSPs create a
fixed link-connection (ie a single hop) in the end-end PW (client) layer
network connection.

	Aside:
	 
	1     A key corollary of all this of course is that the old
notion of a common CP instance is now obviously dead, it's last home was
MPLS.

	2     The PW CW is largely redundant in MPLS-TP since the 1st
nibble ECMP hack is no longer required and the 16 bit Seq No. field is
redundant since a (parent) connection must not re-order its (child)
traffic units.   So its seems the only real difference between PWs and
LSPs in MPLS-TP is the use of 2 different signalling protocols.

		*	T-LDP requires extension to support multi
segment PWs.  The scope of these extensions and the proposed routing
protocols are not well understood within the ITU. 

	T-LDP extensions are defined in draft-ietf-pwe3-segmented-pw
(which is under IESG review), and in draft-ietf-pwe3-dynamic-ms-pw.

		*	Tandem connection monitoring of a PW is achieved
by pushing a (LSP) label and using the (server) LSP for PST monitoring
(same as for a LSP). 

		*	Setting up a PW with traffic engineering and/or
segment monitoring requires the use and coordination of both a T-LDP and
a GMPLS control plane. 

	It was accepted on the call that this is the current state of
the art, but as noted above the future definition of other PW control
protocols is not precluded. However since this definition does not yet
exist and considering the wide deployment of T-LDP for packet transport
by IP/MPLS networks, a pragmatic recommendation was made to continue
with the use of T-LDP until a suitably mature alternative protocol
exists. 
	NH=> But note my previous point above, ie in the more general
case we can very easily have disjoint client PW and server MPLS-TP layer
networks where (i) the TE routing decisions in the (client) PW layer
network and the (server) MPLS-TP layer are quite independent, with the
former not being able to select routing in the latter when different
parties are involved, and (ii) given the CW is essentially redundant in
MPLS-TP, then PWs really only 'live-on' in the sense that they use a
different CP signalling protocol from MPLS-TP LSPs.  
	 
	regards, Neil

		These issues could be either avoided or limited if we
restrict the role of the PW to providing client adaptation at the edge
of a MPLS-TP network and using LSPs in the core of the network. 

	A PW provides additional functionality in addition to
adaptation. These additional functions provide considerable scaling
advantages. For example the multiplexing provides significant scaling
advantages over an LSP approach, which is why it was adopted instead of
alternative IETF proposed protocols that omitted this multiplexing
component. In addition the state co-ordination provides a number of
benefits.
	
	Regards
	
	Stewart Bryant
	PWE3 Co-chair.

		We would very much appreciate your comments on these
points. 
		
		Regards 
		
		Malcolm Betts

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 29 Jan 2010 12:58:24 -0800

Hi Malcolm,

Please see my comment at the end.

<snipped>

> of the points raised is provided below.

<snipped>

> using LSPs in the core of the network.

<RA> I agree that the server layer of MPLS-TP must be restricted to
MPLS-TP LSPs. The framework document needs to be modified to reflect
this.

We should ask given that section 3.4.2 describes how to carry PWs as
clients over MPLS-TP LSP  that is the server layer and section 3.4.3 describes how to
carry Network layers over a MPLS-TP LSP that is the server layer, why do we need PWs to
be a server layer? In other words why is it not necessary and sufficient
to restrict the server layer to LSPs?

rahul

---

From: John E Drake <[email-masked]>
Date: Fri, 29 Jan 2010 13:45:54 -0800

Snipped...

> additional functions provide considerable scaling advantages. For example
> the multiplexing provides significant scaling advantages over an LSP
> approach, which is why it was adopted instead of alternative IETF proposed
> protocols that omitted this multiplexing component. 
>

[JD]  Stewart, I don't think this is correct.  LSP hierarchy (RFC 4206) would have exactly the same scaling properties as pseudowires.  I.e., the net result is the same wrt scaling whether one chooses targeted LDP to instantiate a PW within an LSP or targeted RSVP-TE (section 6.1.1 of RFC 4206) to instantiate a contained LSP.

So, a multi-segment pseudowire in which switching is done in the pseudowire layer does not provide any scaling advantages over an e2e pseudowire over an e2e LSP instantiated over multiple hierarchical LSPs in which switching is done in the LSP layer.  It also has the advantage of having an e2e inband control channel over which OAM and e2e pseudowire signaling may be run.

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 21:56:12 -0000

John, I agree. regards, Neil 

> From: John E Drake [mailto:[email-masked]] 
> Sent: 29 January 2010 21:46
> To: [email-masked]; [email-masked]
> [email-masked]; Harrison,N,Neil,DKQ7 R
> Subject: RE: [mpls-tp] Results of informal review of Section 
> > A PW provides additional functionality in addition to adaptation. 
> > These additional functions provide considerable scaling advantages. 
> > For example the multiplexing provides significant scaling 
> advantages 
> > over an LSP approach, which is why it was adopted instead of 
> > alternative IETF proposed protocols that omitted this 
> multiplexing component.
> >
> 
> [JD]  Stewart, I don't think this is correct.  LSP hierarchy 
> (RFC 4206) would have exactly the same scaling properties as 
> pseudowires.  I.e., the net result is the same wrt scaling 
> whether one chooses targeted LDP to instantiate a PW within 
> an LSP or targeted RSVP-TE (section 6.1.1 of RFC 4206) to 
> instantiate a contained LSP.
> 
> So, a multi-segment pseudowire in which switching is done in 
> the pseudowire layer does not provide any scaling advantages 
> over an e2e pseudowire over an e2e LSP instantiated over 
> multiple hierarchical LSPs in which switching is done in the 
> LSP layer.  It also has the advantage of having an e2e inband 
> control channel over which OAM and e2e pseudowire signaling 
> may be run.  
> 
> > 
> > Regards
> > 
> > Stewart Bryant
> > PWE3 Co-chair.
> > 
> > 
> >

---

From: <[email-masked]>
Date: Fri, 29 Jan 2010 23:11:01 -0000

Rahul,

> <RA> I agree that the server layer of MPLS-TP must be 
> restricted to MPLS-TP LSPs. The framework document needs to 
> be modified to reflect this.

NH=> It's actually a little more definitive than this Rahul, and it
concerns the nature of 'performance inheritance' across nested layer
networks (from application down to the duct).

If one wants deterministic performance in layer N, which includes
consideration of the requirement that the traffic behaviour of client X
of layer N cannot impact the SLA enjoyed by client Y of layer N, then:
-	layer N MUST use proper single-source connections (necessary
condition in layer N)
-	the resources of layer N MUST NOT be overbooked  (full
sufficiency condition in layer N)
-	AND all layer network below layer N to the duct MUST meet the
above requirements (a recursive necessary condition)

The performance experienced at layer N is a sum of (i) the impairments
sourced from all the layer N nodes transitted (the impairments of which
can be a function of load in the co-ps case, but not in the co-cs case,
at layer N) and (ii) all the layer N links transitted.  Now a link
connection (==hop) in layer N is provided by and end-end connection in
layer N-1.  So we have a recursive performance inheritance situation
that terminates at the bottom-of-stack layer network which modulates an
EM wave.  

To cut to the chase...if one wants deterministic performance at layer N
then all layer networks at and below layer N need to be either (i) co-cs
or (ii) co-ps that emulates co-cs.  It really is that simple.

> 
> We should ask given that section 3.4.2 describes how to carry 
> PWs as clients over MPLS-TP LSP  that is the server layer and 
> section 3.4.3 describes how to carry Network layers over a 
> MPLS-TP LSP that is the server layer, why do we need PWs to 
> be a server layer? In other words why is it not necessary and 
> sufficient to restrict the server layer to LSPs?

NH=> The above sentence construction/grammar is broken. 

regards, Neil

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 29 Jan 2010 15:17:11 -0800

Hi Neil,

<snipped>

> NH=> The above sentence construction/grammar is broken.

Let me try to rephrase.

I would like an answer to the following:

Given that section 3.4.2 describes how to carry
PWs as clients over MPLS-TP LSPs and section 3.4.3 describes how to carry
Network layers over MPLS-TP LSPs, where MPLS-TP LSPs form the
server layer, why do we need PWs to be a server layer?
In other words why is it not necessary and
sufficient to restrict the server layer to MPLS-TP LSPs?

rahul

---

From: Igor Bryskin <[email-masked]>
Date: Sun, 31 Jan 2010 09:15:44 -0500

Rahul,

I've been asking the very same question time and again for more than a year.

Cheers,
Igor

Let me try to rephrase.

rahul

---

From: Maarten Vissers <[email-masked]>
Date: Sun, 31 Jan 2010 20:02:40 +0100

Rahul,

The Client/Server relationship exists between any two layers in a stack.
In MPLS-TP there are three MPLS-TP layers defined:
- MPLS-TP transport service layer
- MPLS-TP transport path layer
- MPLS-TP section layer.

Other transport technologies have similar layer sets.

The MPLS-TP transport service layer is a server layer for the MPLS-TP client
layers and a client layer for the MPLS-TP transport path layer. The MPLS-TP
transport path layer is a server layer for the MPLS-TP transport service
layer and a client layer of the MPLS-TP Section layer.

The transport service layer transport paths (i.e. connections) have a 1-to-1
relationship with the customer's services. Those transport paths are set up
after the transport network received a service request. Service requests can
be for individual and bundled p2p Ethernet, ATM, FR, PPP, TDM, MPLS, IP
service connections, or for p2mp Ethernet service connections, or for
rooted-mp Ethernet service connections or for mp2mp Ethernet service
connections.

In MPLS-TP networks those customer services are supported by transport paths
which are identified by means of a PW label, a service LSP label, a bundle
LSP label, a segment LSP label. A PW label will used to identify both
p2p/p2mp Ethernet services, and rmp/mp2mp ethernet services (referred to as
HVPLS).

Operators who deploy an Ethernet Services layer as transport service layer
(as per MEF specifications) will support all those services via Ethernet
Connections (see MEF12/MEF12.1). Those Ethernet Connections are identified
by either an S-VLAN Tag, I-Tag, operator proprietary VLAN Tag or PW label
(latter when Ethernet Connections are carried over an MPLS transport path
layer.

In the MEF case, all services are supported by one transport service layer
technology with a single type of OAM, protection switching and TCM method,
which is independent of the label used to identify the connections. 

In the MPLS-TP case, there are two and a half technologies used in the
transport service layer to support the service mix: Ethernet (rmp/mp2mp
services), MPLS-TP LSP (subset of p2p/p2mp services) and MPLS-TP PW (subset
of p2p/p2mp services). PW and LSP share a common label stack entry header
format, but have furthermore different OAM encapsulations and seems to get
different TCM methods. Furthermore, the control planes for PW and LSP are
different and we may end up also with different protection switching
methods.

PW, service LSP, bundle LSP, segment LSP and HVPLS type transport paths are
all members of the MPLS-TP transport service layer, are all switched in
transport service layer switches and are all clients of the MPLS-TP
transport path layer.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rahul Aggarwal
Sent: zaterdag 30 januari 2010 0:17
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Results of informal review of Section 3.4
draft-ietf-mpls-tp-framework-07

Hi Neil,

<snipped>

> > clients over MPLS-TP LSP  that is the server layer and section 3.4.3 
> > describes how to carry Network layers over a MPLS-TP LSP that is the 
> > server layer, why do we need PWs to be a server layer? In other 
> > words why is it not necessary and sufficient to restrict the server 
> > layer to LSPs?
>

Let me try to rephrase.

Given that section 3.4.2 describes how to carry PWs as clients over MPLS-TP
LSPs and section 3.4.3 describes how to carry Network layers over MPLS-TP
LSPs, where MPLS-TP LSPs form the server layer, why do we need PWs to be a
server layer?
In other words why is it not necessary and sufficient to restrict the server
layer to MPLS-TP LSPs?

rahul