Subject: [mpls-tp] draft-ietf-mpls-tp-framework-08

From: Stewart Bryant <[email-masked]>
Date: Fri, 22 Jan 2010 18:45:53 +0000

This version contains the responses to section 3.4 as of last Tuesday 
and which were discussed at the regular (open) Tuesday evening call on 
MPLS-TP.

It also contains the PST text that we were supplied, but which has not 
been reviewed.

There will be another version produced in the next few days.

Regards

Stewart

Subject: New Version Notification for draft-ietf-mpls-tp-framework-08
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 22 Jan 2010 10:18:12 -0800 (PST)

A new version of I-D, draft-ietf-mpls-tp-framework-08.txt has been successfuly submitted by Stewart Bryant and posted to the IETF repository.

Filename:	 draft-ietf-mpls-tp-framework
Revision:	 08
Title:		 A Framework for MPLS in Transport Networks
Creation_date:	 2010-01-22
WG ID:		 mpls
Number_of_pages: 49

Abstract:
This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched equivalents of traditional circuit-
switched carrier networks.  It describes a common set of protocol
functions - the MPLS Transport Profile (MPLS-TP) - that supports the
operational models and capabilities typical of such networks,
including signaled or explicitly provisioned bi-directional
connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration and Maintenance (OAM)
functions, and network operation in the absence of a dynamic control
plane or IP forwarding support.  Some of these functions are defined
in existing MPLS specifications, while others require extensions to
existing specifications to meet the requirements of the MPLS-TP.

This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths.  The remaining subset, applicable
specifically to point-to-multipoint paths, are out of scope of this
document.

This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.

The IETF Secretariat.

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 23 Jan 2010 06:43:31 +0100

Stewart,

Reading the first paragraph in section 3.4.1 of this draft I find the text 
  "In terms of the MPLS label stack, when the
   client traffic type of the MPLS-TP network is an MPLS LSP or a PW,
   then the S bit of all the labels in the MPLS-TP label stack are zero,
   otherwise the bottom label of the MPLS-TP label stack has the S bit
   set to one ( i.e. there can only one S bit set in a label stack)."

When I look at the LSP OAM in the MPLS-TP network used with the MPLS LSP or
PW services, I see a label in the MPLS-TS label stack with S=1; i.e. the
GAL. As we have not identified the LSP OAM as a client of the MPLS-TP
network, the description in version 08 is not 100% accurate in my opinion.
Perhaps you should enhance the text a bit; e.g. "then the S bit of all the
labels in the MPLS-TP label stack carrying **that client information are**
zero".

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: vrijdag 22 januari 2010 19:46
To: [email-masked]; [email-masked];
[email-masked]
Subject: draft-ietf-mpls-tp-framework-08

This version contains the responses to section 3.4 as of last Tuesday and
which were discussed at the regular (open) Tuesday evening call on MPLS-TP.

It also contains the PST text that we were supplied, but which has not been
reviewed.

Regards

Stewart

---

From: <[email-masked]>
Date: Mon, 25 Jan 2010 11:16:39 -0000

Stewart,

Can you (or someone) please help me understand this paragraph please:

=====
1.3.5.1.  MPLS-TP Provider Edge (PE) Router

   An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts
   client traffic and encapsulates it to be transported over an MPLS-TP
   LSP.  Encapsulation may be as simple as pushing a label, or it may
   require the use of a pseudowire.  An MPLS-TP PE exists at the
   interface between a pair of layer networks.  For an MS-PW, an MPLS-TP
   PE may be either an S-PE or a T-PE, as defined in [RFC5659].

   A layer network is defined in [G.805].
=====

The above para states that any node that adds (removes) labelled headers
is a PE node performing an adaptation function, and that such nodes
exist between 2 different layer networks. 

The problem I have with this is that it implies that all MPLS-TP nodes
that add (remove) labelled headers are creating LSPs that belong in
*different MPLS-TP layer networks*.  IMO this is correct wrt to what
MPLS-TP SHOULD be doing.  However, this also implies we do not have
S-bit sublayering....because adding/removing a labelled header in a
S-bit sublayer context does NOT imply the creation of a new layer
network.

This goes back to a point I tried to make earlier that S bit sublayering
assumes a single instance of routing across a single layer network, and
this allows different 'signalling protocols' to exist and create nested
LSP sublayered structures, but these are NOT client/server layer network
relationships.

So there is something technically wrong here if there is still the
intention to have S-bit sublayering in MPLS-T.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stewart Bryant
> Sent: 22 January 2010 18:46
> Subject: [mpls-tp] draft-ietf-mpls-tp-framework-08
> 
> This version contains the responses to section 3.4 as of last 
> Tuesday and which were discussed at the regular (open) 
> Tuesday evening call on MPLS-TP.
> 
> It also contains the PST text that we were supplied, but 
> which has not been reviewed.
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 25 Jan 2010 11:47:11 +0000

> exist between 2 different layer networks. 
Neil, maybe we need to say this a different way, but fact that this is 
an edge device implies that this is only happening at the interface 
between the client network and the server network. Label pushing outside 
the MPLS-TP network is not our concern, and inside it is not "adapting 
or encapsulating client traffic"
> S-bit sublayer context does NOT imply the creation of a new layer
We are no longer proposing S bit delimiting between client and server - 
see section 3.4.1

In terms of the MPLS label stack, when the client traffic type of the 
MPLS-TP network is an MPLS LSP or a PW, then the S bit of all the labels 
in the MPLS-TP label stack are zero, otherwise the bottom label of the 
MPLS-TP label stack has the S bit set to one ( i.e. there can only one S 
bit set in a label stack).

The data plane behaviour of MPLS-TP is the same as the best current  
practise for MPLS.  This includes the setting of the S-Bit.  In each  
case, the S-bit is set to indicate the bottom (i.e. inner-most) label  
in the label stack that is contiguous between the MPLS-TP server and  
the client layer.  Note that this best current practise differs slightly 
from [RFC3032] which uses the S-bit to identify when MPLS  label 
processing stops and network layer processing starts.

- Stewart

---

From: <[email-masked]>
Date: Mon, 25 Jan 2010 13:18:16 -0000

Thanks Stewart for the explanation.  This means the text in para 1.3.5.1
for sure needs to change as it is not correct.  

However, I do think we are missing an important opportunity here that
probably won't come again.  IMO the best course of action would be:

-	Disallow MS PWs and only allow single hop PW cases, ie revert to
pure adaptation.  This avoids the creation of an unnecessary co-ps PW
layer network above MPLS-TP.  We really should not do this when MPLS-TP
is supposed to be THE co-ps mode transport network.  Just consider all
the duplication of functions across DP/CP/MP....which all implies more
things to configure, more things that can go wrong, more added cost,
etc.  And note in particular that this destroys any notion of a common
CP (== *routing*) between the CP used in the MPLS-TP layer network and
the CP used in the MS PW layer network.

-	Do not use S-bit sublayering.....and yes I know this is a big
wrench from what MPLS as-is does, but please remember that in MPLS as-is
the S-bit sublayering was needed  so that multiple signalling protocols
could exist in notionally the *same layer network*, ie common routing
instance - noting in particular that the LDP type of MPLS had an unusual
relationship with IP which made the definition of a MPLS layer network
"rather problematic" if I can put it like that.  So in MPLS as-is we
could create a sublayered stack of LSPs where each labelled header can
be issued by a different 'signalling protocol' and where all were
supposed to working to a common routing map of the "network".  However,
one really does not want this model/behaviour in MPLS-TP when it is
performing a transport role.  Moreover, when we use a CP (or even a MP)
to set-up MPLS-TP LSPs we want *a consistent GMPLS/RSVP-TE signalling
protocol (or MP system) to do this*.

So I am really struggling to understand *technically* why we need MS PWs
(in particular) and sublayering in MPLS-TP......and I have seen no good
answer to this.

regards, Neil

> Sent: 25 January 2010 11:47
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]; 
> Subject: Re: [mpls-tp] draft-ietf-mpls-tp-framework-08
> 
> > The above para states that any node that adds (removes) labelled 
> > headers is a PE node performing an adaptation function, and 
> that such 
> > nodes exist between 2 different layer networks.
> >   
> Neil, maybe we need to say this a different way, but fact 
> that this is an edge device implies that this is only 
> happening at the interface between the client network and the 
> server network. Label pushing outside the MPLS-TP network is 
> not our concern, and inside it is not "adapting or 
> encapsulating client traffic"
> We are no longer proposing S bit delimiting between client 
> and server - see section 3.4.1
> 
> In terms of the MPLS label stack, when the client traffic 
> type of the MPLS-TP network is an MPLS LSP or a PW, then the 
> S bit of all the labels in the MPLS-TP label stack are zero, 
> otherwise the bottom label of the MPLS-TP label stack has the 
> S bit set to one ( i.e. there can only one S bit set in a 
> label stack).
> 
> The data plane behaviour of MPLS-TP is the same as the best 
> current practise for MPLS.  This includes the setting of the 
> S-Bit.  In each case, the S-bit is set to indicate the bottom 
> (i.e. inner-most) label in the label stack that is contiguous 
> between the MPLS-TP server and the client layer.  Note that 
> this best current practise differs slightly from [RFC3032] 
> which uses the S-bit to identify when MPLS  label processing 
> stops and network layer processing starts.
> 
> - Stewart
> 
> 
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 27 Jan 2010 17:52:59 +0100

Below a number of issues identified in draft-ietf-mpls-tp-framework-08 which
requires further enhancements to the framework draft:

1. Section 3.3.2 - the 6th paragraph states:
   'Further processing to determine the context of a packet occurs when a
   swap operation is interrupted in this manner, or a pop operation
   exposes a specific reserved label at the top of the stack.  Otherwise
   the packet is forwarded according to the procedures in [RFC3032].'

	A Section layer LSP is typically carried over the physical media
layer
	in an unlabelled manner; i.e. as an 'unlabelled LSP'. The Section
LSP OAM
	packets will have as top of stack label the GAL. Packets received by
	an input port with the GAL as top label will have to be "further
processed
	to determine the context of the packet"; such packets are to be
exposed
	to this further processing wihtout an interruption of a swap
operation,
	and without a pop operation exposing a reserved label. It is
suggested
	to describe that further processing is also occuring on packets with
	GAL as top of stack label.

2.  Section 3.4.3, page 23, 3rd paragraph states:
   'Service labels are typically carried over an MPLS-TP LSP edge-to-edge
   (or transport path layer). An MPLS-TP edge-to-edge LSP is
   represented as an LSP Demux label as shown in Figure 10.  An edge-to-
   edge LSP is commonly used when more than one service exists between
   two PEs.' 

	Is it possible to formally define the term "edge-to-edge LSP"? 
	E.g. An edge-to-edge LSP is a LSP within the transport path layer
	which carries an aggregate of transport service layer signals
	from a PE node via zero or more P nodes to the next PE node.

	 'The edge-to-edge LSP may be omitted when only one service
   exists between two PEs.  For example, if only one service is carried
   between two PEs then a single Service Label could be used to provide
   both the service indication and the MPLS-TP edge-to-edge LSP.'

	Edge-to-edge LSPs are typically set up prior to the first service 
	request. Edge-to-edge LSPs are as such part of the infrastrcuture
	of the MPLS-TP network, specifically of the MPLS-TP domain
	bounded by a set of PE nodes.

	It seems as such not correct to state that if one service is carried
	between two Pes that the edge-to-edge LSP label can be removed.
	It should be expected that a next service request will add a 2nd
	transport service layer signal to the edge-to-edge LSP.

	In addition, edge-to-edge LSPs are multiplexed into the Section
	layer transport path, and if the edge-to-edge LSP label stack entry
	header would be removed, then it is not longer possible to identify
	the existence of the edge-to-edge LSP. 

	Only when the edge-to-edge LSP would be the only edge-to-edge LSP
	on a physical media, then it is possible to carry the edge-to-edge
	LSP as an unlabelled-LSP.
	Note that there will in this case be no need for a Section layer.

3. Section 3.6, Figure 12: The figure mentions that "service" is transported
	over the ACH/GAL. This is not aligned with the text. It is suggested
	to replace this by "FCAPS".

4. Section 3.7.1 introduces the terms 
	"end-to-end LSP", "segment LSP" without defining those terms. Please
	add explicit definitions of those new terms to the framework and 
	describe the relation with the "edge-to-edge LSP" and "service LSP".

5. The terms "T-PE", "S-PE", "MPLS-TP PE", "MPLS-TP P", "MPLS-TP LSR" and
	"MPLS-TP LER" are described or defined in the Terminology section
1.3
	and subsections. 
	- In section 1.3.5 a description of the term "MPLS-TP LER" is
missing; 
	  it is suggested to add such description.
	- In Section 1.3.5 it is stated that: 
   'The terms MPLS-TP PE router and MPLS-TP P router
   describe logical functions; a specific node may undertake only one of
   these roles on a given LSP.'
	  The above implies that the terms PE and P can not be used as node
	  names. Each MPLS-TP node will be providing P functionality for one
	  LSP and PE functionality for another LSP; e.g. when a MEP is
present
	  to support the monitoring of a transport path segment, a PE
function
	  is performed by such MEP, nonetheless that the transport path is 
	  continued (P function).
	  My request is to introduce terminology for MPLS-TP nodes, which
	  is based on the MPLS-TP layer (transport service layer, transport
	  path layer, section layer) processing. 

	  "Transport Service layer Terminating" node is a node in which
	  the transport service layer transport paths are terminated and the
	  customer signal is accessed. This node is the start/endpoint of
PW,
	  Service LSP and LSP transport service layer transport paths. This
	  node may also be the start/endpoint of one or more additional MEG
	  levels - monitoring a carrier segment or a protection segment - 
	  within a transport service layer transport path. This node may
also
	  be the start/endpoint of one or more transport path layer
transport
	  paths.

	  "Transport Service layer Switching" node is a node in which the
	  transport service layer transport paths (PW, service LSP, LSP,..)
are
	  switched. This node may also be the start/endpoint of one or more
	  additional MEG levels - monitoring a carrier segment or a
protection
	  segment - within a transport service layer transport path. This
node
	  may also be the start/endpoint of one or more transport path layer
	  transport paths.

	  "Transport Path layer Switching" node is a node in which the
transport
	  path layer transport paths (edge-to-edge LSPs, ...) are switched.
This
	  node may also be the start/endpoint of one or more additional MEG
levels
	  - monitoring a carrier segment or a protection segment - within a
	  transport path layer transport path.

6. It is requested to describe the relationship between the different label
	stack entry headers defined in this framework and the transport
service
	layer, transport path layer and section layer. The transport service

	layer transport path signals may be identified by a variety of label
	stack entry (LSE) header types; e.g. PW LSE, Encap + Service LSP
LSE,
	LSP LSE, one or more Segment LSP LSEs (supporting an additional MEG
level
	within the transport path), PST LSE. The transport path layer
transport
	path signals may be identified by a variety of LSE header types;
e.g.
	edge-to-edge LSP LSE, one or more segment LSP LSEs, PST LSE. The
section
	layer transport path signals may be unlabelled, or labelled (when
	carried over a section layer segment LSP). 

7. On the mpls-tp mailinglist a bundling application was described in which
	e.g. four TDM PWs were bundled into a single bundle LSP at a
transport
	service layer terminating node and then transported through as a
	transport service layer transport path through the MPLS-TP network
to
	the far end transport service layer terminating node. It is proposed
to
	introduce such bundle LSP as one of the transport service layer
	transport path alternatives, and define if it is necessary to
monitor
	the individual PWs, or if it is sufficient to monitor the bundle
LSP.

8. Section 3.8: The trnasport service layer contains transport paths with
	a variety of label stack entry headers (PW, service LSP, LSP,
segment
	LSP, PST LSP), which requires that the transport service layer of
which
	the PWs have to be controlled by LDP and the LSPs by GMPLS. A 
	single transport service layer transport path may as such have parts
that
	require LDP and other parts that require GMPLS based control to be
	setup. The activation of e.g. an additional MEG level in a PW type
	transport service layer transport path will require that some of the
	transport service layer transport path is not longer be controlled
by
	LDP, but instead by GMPLS. It seems that this is introducing
unnecessary
	complexity in the transport service layer, and it is proposed to
select
	a single control plane type for all transport paths in the transport
	service layer.

Regards,
Maarten

---

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 28 Jan 2010 16:03:13 +0100

Hi Maarten, 

Thanks for your comments.

Please see below.

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 27 January 2010 16:53
> To: [email-masked]; BOCCI Matthew
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Comment on draft-ietf-mpls-tp-framework-08
> 
> 
>  
> Below a number of issues identified in 
> draft-ietf-mpls-tp-framework-08 which requires further 
> enhancements to the framework draft:
> 
> 	A Section layer LSP is typically carried over the 
> physical media layer
> 	in an unlabelled manner; i.e. as an 'unlabelled LSP'. 
> The Section LSP OAM
> 	an input port with the GAL as top label will have to be 
> "further processed
> 	to determine the context of the packet"; such packets 
> are to be exposed
> 	to this further processing wihtout an interruption of a 
> swap operation,
> 	and without a pop operation exposing a reserved label. 
> It is suggested

OK. We will add text to explain this point.

> 	from a PE node via zero or more P nodes to the next PE node.

OK. Added clarification to where we first use the term.

>    both the service indication and the MPLS-TP edge-to-edge LSP.'

OK. We will add a definition where it is first used.

> 	transport service layer signal to the edge-to-edge LSP.

Yes, but it explicitly says that if there is only one service. This is
not mandatory, though. If you are intending to add new LSPs, then set
the first one up in an edge-to-edge LSP. The way to add another service
would be to move the service LSP onto an edge-to-edge LSP. I suggest
that we address this in the same manner as agreed on the editing call so
that we turn this text on what is essentially an optimisation into a
note (as per the encapsulation label case).

> 	Note that there will in this case be no need for a 

I don't think the text implies that you use an unlabelled LSP or
implicit null LSP label. It merely says that there is only a service
LSP, and that spans edge-to-edge. 

> 	to replace this by "FCAPS".

OK.

> 	describe the relation with the "edge-to-edge LSP" and 

End-to-end LSP should really be edge-to-edge. We will add definitions in
the terminology.

> 	- In section 1.3.5 a description of the term "MPLS-TP 
> LER" is missing; 

OK. We'll add a definition.

> 	  LSP and PE functionality for another LSP; e.g. when a 
> MEP is present
> 	  to support the monitoring of a transport path 
> segment, a PE function

As is common in the IETF, we are describing a functional architecture,
not a physical one. Therefore it is
appropriate to focus on the logical aspects of the network, and thus the
terminology is tailored to this 
style of specification. That does not preclude a mapping of logical
functions to physical nodes being 
defied elsewhere, with the appripriate terminology, but it is not the
objective of this framework draft.

> 	  customer signal is accessed. This node is the 
> start/endpoint of PW,
> 	  within a transport service layer transport path. This 
> node may also
> 	  be the start/endpoint of one or more transport path 
> layer transport
> 	  paths.
> 
> 	  transport service layer transport paths (PW, service 
> LSP, LSP,..) are
> 	  additional MEG levels - monitoring a carrier segment 
> or a protection
> 	  segment - within a transport service layer transport 
> path. This node
> 	  "Transport Path layer Switching" node is a node in 
> which the transport
> 	  node may also be the start/endpoint of one or more 
> additional MEG levels

> 	stack entry headers defined in this framework and the 
> transport service
> 	stack entry (LSE) header types; e.g. PW LSE, Encap + 
> Service LSP LSE,
> 	LSP LSE, one or more Segment LSP LSEs (supporting an 
> additional MEG level
> 	within the transport path), PST LSE. The transport path 
> layer transport
> 	path signals may be identified by a variety of LSE 
> header types; e.g.
> 	edge-to-edge LSP LSE, one or more segment LSP LSEs, PST 
> LSE. The section

I do not think this mapping is needed in this draft, but that does not 
preclude this mapping being described in an ITU document.

> 	e.g. four TDM PWs were bundled into a single bundle LSP 
> at a transport
> 	transport service layer transport path through the 
> MPLS-TP network to
> 	the far end transport service layer terminating node. 
> It is proposed to
> 	transport path alternatives, and define if it is 
> necessary to monitor
> 	the individual PWs, or if it is sufficient to monitor 
> the bundle LSP.

There was an informal discussion and an I-D a while ago in PWE3 on
something similar, 
but nothing was progressed. There
is nothing in MPLS-TP that prevents it, but I don't think it is
approriate to define it here. 
Such a concept would need to be formally defined in PWE3.

> 	a variety of label stack entry headers (PW, service 
> LSP, LSP, segment
> 	LSP, PST LSP), which requires that the transport 
> service layer of which
> 	single transport service layer transport path may as 
> such have parts that
> 	transport service layer transport path is not longer be 
> controlled by
> 	LDP, but instead by GMPLS. It seems that this is 
> introducing unnecessary
> 	complexity in the transport service layer, and it is 
> proposed to select

I think this echos the sentiment in the informal comments from the ITU.
These were discussed on the call
on Tuesday 26th Jan, and we have addressed this with a note that
although T-LDP is currently used for PWs, 
MPLS-TP does not preclude the future definition of alternative control
protocols for PWs. 

Regards

Matthew

---

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

Hi Matthew,

You state in response of my comment #5 "As is common in the IETF, we are
describing a functional architecture, not a physical one.". Description of a
functional architecture is also the approach used by SG15 to specify its
transport networks. 

The functional architectures specified by SG15 are based on the
specification signal structures and functional specicifications of the same
for layer networks as identified for MPLS-TP:
- LO or VC layer networks are transport service layer networks
- HO or VP layer networks are transport path layer networks
- Section layer networks
- Physical media layer networks.
For SDH this has resulted in the specification of a series of LOVC signal
types, their OAM/TCM and their atomic functions (LO VC-11, VC-12, VC-3), of
HOVC signal types, their OAM/TCM and their atomic functions (HO VC-3, VC-4,
VC-4-Xc (X=4,16,64,256) and of Section signal types, their OAM and atomic
functions (RSn, MSn (n=0,1,4,16,64,256).
For OTN this has resulted in the specification of a series of LO ODU signal
types, their OAM/TCM and atomic functions (LO ODU0, ODU1, ODU2, ODU2e, ODU3,
ODU4, ODUflex) and of HO ODU signal types, their OAM/TCM and atomic
functions (HO ODU1, ODU2, ODU3, ODU4).
For ATM this has resulted in the specification of a generic VC signal type,
its OAM/TCM and atomic functions, and of a generic VP signal type, its
OAM/TCM and atomic functions.

Besides specifying those different signal types (comparable with PW, service
LSP, segment LSP, edge-to-edge LSP, PST LSP, etc), OAM and TCM there is also
a very clear description of the layers those signal types (including
OAM/TCM) are a member of. This latter is missing in the MPLS-TP framework
document, and this will impact the development of network management and the
required "operational simplicity" referred to in RFC5654:
   "To realize these goals, it
   is essential that packet-transport technology be available that can
   support the same high benchmarks for reliability and operational
   simplicity set by SDH/SONET and OTN technologies."

When we developped SDH we also developed Rec. G.782. This recommendation
described a number of SDH equipment types and provided guidance to realize
SDH networks, without standardizing one physical architecture. The node
names introduced in that recommendation are still used as general type names
for SDH functionality combinations.

To obtain in MPLS-TP netowrks the "operational simplicity set by SDH/SONET
and OTN technologies." it is in my opinion important to complement the
existing specifications in the framework document by an explicit description
of 
- which named signals (PW, service LSP, segment LSP, edge-to-edge LSP, PST
LSP, etc) are member of the transport service, trnasport path and section
layer netowrks, and
- some generic node names that reflect the basic functionality provided by a
common set of MPLS-TP nodes.

The correspondence in the mpls-tp mailinglist shows that there is no common
understanding of the set of labelled signals specified in the MPLS-TP
framework draft and the layers those signals belong to. It is as such more
then necessary to include a listing - in an additional section in the
framework document - of the MPLS-TP layers and their labelled signals. A
table would be a great help for readers to combine labelled signal types and
their layers. Any new labelled signal types introduced in future (e.g.
packet PW) can be simply added to the appropriate layer.

-------

REQ30 in RFC5654 requires 
	"A generic and extensible solution MUST be provided to support the
       transport of one or more client layer networks (e.g., MPLS-TP,
       IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer network."

In order to support p2p/p2mp Ethernet, ATM, FR, etc services this
requirement 30 enforces that PWs must be an integral part of the MPLS-TP
layer networks, specifically the MPLS-TP transport service layer.
In order to support rmp/mp2mp Ethernet services, this requirement 30
enforces that HVPLS instances must be an integral part of the MPLS-TP layer
netowrks, specifically are a part of the MPLS-TP transport service layer.
Excluding the PW and HVPLS from MPLS-TP implies that REQ30 is not met by the
MPLS-TP framework specifications; i.e. MPLS-TP is not just about LSPs.

My conclusion is therefore that the MPLS-TP framework document is currently
not complete and does not meet all requirements in RFC5654.

Regards,
Maarten

-----Original Message-----
From: BOCCI Matthew [mailto:[email-masked]] 
Sent: donderdag 28 januari 2010 16:03
To: Maarten Vissers; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: Comment on draft-ietf-mpls-tp-framework-08

Hi Maarten, 

Please see below.

> draft-ietf-mpls-tp-framework-08 which requires further enhancements to 
> the framework draft:
> 

> 	transport service layer signal to the edge-to-edge LSP.

Yes, but it explicitly says that if there is only one service. This is not
mandatory, though. If you are intending to add new LSPs, then set the first
one up in an edge-to-edge LSP. The way to add another service would be to
move the service LSP onto an edge-to-edge LSP. I suggest that we address
this in the same manner as agreed on the editing call so that we turn this
text on what is essentially an optimisation into a note (as per the
encapsulation label case).

> 	Note that there will in this case be no need for a Section layer.

I don't think the text implies that you use an unlabelled LSP or implicit
null LSP label. It merely says that there is only a service LSP, and that
spans edge-to-edge. 

OK.

> 	describe the relation with the "edge-to-edge LSP" and "service LSP".

End-to-end LSP should really be edge-to-edge. We will add definitions in the
terminology.

> 	  path layer, section layer) processing. 

As is common in the IETF, we are describing a functional architecture, not a
physical one. Therefore it is appropriate to focus on the logical aspects of
the network, and thus the terminology is tailored to this style of
specification. That does not preclude a mapping of logical functions to
physical nodes being defied elsewhere, with the appripriate terminology, but
it is not the objective of this framework draft.

PW,
also
transport

LSE,
e.g.

to
monitor
LSP.

There was an informal discussion and an I-D a while ago in PWE3 on something
similar, but nothing was progressed. There is nothing in MPLS-TP that
prevents it, but I don't think it is approriate to define it here. 
Such a concept would need to be formally defined in PWE3.

Regards

Matthew

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 31 Jan 2010 21:27:51 +0200

Maarten, Matthew and all,
A short comment if you do not mind:

Maarten,
You've stated that:
> specification signal structures and functional
> specifications of the same
> - Physical media layer networks

To the best of my recollection, none of the MPLS-TP documents now in progress
use/define the terms like LO/VC or HO/VP. IMHO and FWIW, this is because
these notions, which are quite real in the SONET/SDH data plane, do not have any
meaning whatsoever in MPLS (TP or not) one, i.e., no data plane reality stands behind them.

Scientists and engineers have been successfully using the Occam's Razor principle
(entia non sunt multiplicanda praeter necessitatem) for the last 600 years.
I do not see any reason to drop it now.

My 2c,
     Sasha

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Sunday, January 31, 2010 9:03 PM
> To: 'BOCCI Matthew'; [email-masked]
> Subject: Re: [mpls-tp] Comment on draft-ietf-mpls-tp-framework-08
>
> Hi Matthew,
>
> physical media
> "further
> > 5. The terms "T-PE", "S-PE", "MPLS-TP PE", "MPLS-TP P",
> "MPLS-TP LSR"
> > and
> >    describe logical functions; a specific node may
> undertake only one
> > of
> start/endpoint of
> additional MEG
> LSP, LSP,..)
> path. This
> additional MEG
> > 6. It is requested to describe the relationship between the
> different
> > label
> additional MEG
> LSE. The
> > 7. On the mpls-tp mailinglist a bundling application was
> described in
> > which
> MPLS-TP network
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 31 Jan 2010 20:17:18 -0000

All,

Notwithstanding names, we do seem to have produced several components of the 
MPLS-TP architecture. These might be named:

client traffic
pseudowires*
LSPs
server links

* Let us please leave to a separate discussion the question of whether PW 
should continue to be part of the MPLS-TP world

I see no reason why Maarten should not observe that there is a 
correspondence between these items and other named items in other networking 
models. Providing this mapping may be useful to people attempting to 
understand MPLS-TP coming to the scene from elsewhere. Maybe representing 
this language in the Rosetta draft would be helpful to these people.

However, I agree with Sasha that there is no value to introducing these 
terms to the rest of the MPLS-TP document set. We do not need more terms for 
the same things.

Adrian
----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: "Maarten Vissers" <[email-masked]>; "'BOCCI Matthew'" 
<[email-masked]>; [email-masked]
Cc: <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Sunday, January 31, 2010 7:27 PM
Subject: [mpls-tp] Doesn't Occam's Razor apply to networking? (was: Comment 
on draft-ietf-mpls-tp-framework-08)

>> specicifications of the same