Subject: Re: [mpls-tp] -03 of requirements draft & actions still to beresolved

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 08:16:44 +0100

Ben,

Section 1.2 contains a paragraph describing encapsulation of client signals
and aggregation of those encapsulated signals. Reading through the text of
this paragraph I found the text to be inaccurate and possibly incorrect. Let
me describe the issue I see with the current text:

>  "Clients are first encapsulated.  These encapsulated client signals
>  may then be aggregated into a connection for transport through the
>  network in order to optimize network management.  

It is not clear for me if the encapsulated client signal is the "transport
service layer signal". In my opinion the encapsulated client signal plus
transport service layer OAM constitutes the transport service layer signal's
characteristic information. Transport service layer signals are carried
through the MPLS-TP network in a transport service layer network connection
(or in general network transport entity).

Aggregation of such transport service layer signals creates a "transport
path layer signal", which will have its own transport path layer OAM that is
independent of the transport service layer signal OAM.

Aggregation of such transport path layer signals creates a transmission
media section layer signal, which will have its own transmission media
section layer OAM that is independent of the transport path layer signal
OAM.

In addition it is possible that transport service layer signals are
aggregated into a transmission media section layer signal (without
intermediate transport path layer signal).

Before encapsulating client signals it is possible to aggregate (or bundle)
client signals. This bundling/aggregation of client signals seems to be
missing from the description.

>  Server layer OAM is
>  used to monitor the transport integrity of the client layer or client
>  aggregate.  

It is not clear to me if the server layer OAM refers to transport service
layer OAM or to transport path layer OAM.

>  At any hop, the aggregated signals may be further
>  aggregated in lower layer transport network paths for transport
>  across intermediate shared links.  The encapsulated client signals
>  are extracted at the edges of aggregation domains, and are either
>  delivered to the client or forwarded to another domain. In the core
>  of the network, only the server layer aggregated signals are
>  monitored; individual client signals are monitored at the network
>  boundary in the client layer network.  

It is not clear to me if the "client signal" refers to the customer's signal
applied at the UNI, or if "client signal" refers to "transport service layer
signal" or "transport path layer signal".

I propose to use "client" in this paragraph to refer to the customer's
signal, and use "transport service" and "transport path" to refer to clients
of the transport path resp. transmission media section layers.

>  Although the connectivity of
>  the client of the transport path layer may be point-to-point, point-
>  to-multipoint or multipoint-to-multipoint, the transport path layer
>  itself only provides point-to-point or point-to-multipoint transport
>  paths which are used to carry the client."

Regards,
Maarten

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

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 08:27:38 +0100

Ben,

I have the feeling that Requirement 28 "MPLS-TP MUST be capable of using
P2MP server (sub-)layer capabilities when supporting P2MP MPLS-TP transport
paths (for example context-specific labels [RFC5331])." is not compliant
with the definitions of transport path and transmission media layers.

According to the definitions, transport path signals are carried by the
section layer and the transmission media layer. The transmission media (i.e.
G.805's physical media) layer "provides sections (two-port point-to-point
connections)" and not any P2MP connections.

Should Req 28 be talking about "using P2MP transport path layer capabilities
when supporting P2MP MPLS-TP transport services"?

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 08:32:25 +0100

Ben,

Requirement 44 "The MPLS-TP control pane MUST support the configuration and
modification of OAM maintenance points as well as the
activation/deactivation of OAM when the transport path is established or
modified." should be applicable as well to the transport service layer. I
propose to modify this requirement as follows:

   44  The MPLS-TP control pane MUST support the configuration and
       modification of OAM maintenance points as well as the activation/
       deactivation of OAM when the transport path and transport service
       is established or modified.                 ^^^^^^^^^^^^^^^^^^^^^

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 02 Feb 2009 08:55:08 +0100

Ben,

In the protections section you list in Requirements 54 and 55 1+1 and 1:n
protection. 
I assume that this is SNC protection. Is this correct?
I also assume that this is individual (transport service, transport path,
transmission media section) signal protection. Is this correct?

Besides individual signal protection, Q.9/15 has recently defined some
powerful group protection schemes, referred to as Compound Link SNC Group
protection with inherent monitoring. Those CL-SNCG protection schemes are
efficient protection methods for
- protection of a group of transport service layer signals through a core
domain 
- protection of a group of transport path layer signals through a
transmission media.

I propose to add a requirement to support 1:1 CL-SNCG/I protection in
MPLS-TP.

Regards,
Maarten

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 23:13:30 +0000

Maarten,

On 02/02/2009 07:16, "Maarten Vissers" <[email-masked]> wrote:

> this paragraph I found the text to be inaccurate and possibly incorrect.

The text was taken from the Q12/15 liaison describing T-MPLS to IETF from
the 30 October - 10 November 2006 meeting (Annex J TD358/PLEN) :-)

> Let

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 23:24:42 +0000

Maarten,

> connections)" and not any P2MP connections.

No, according to the definitions transport paths are network connections and
as far as I am aware connections may be P2P or P2MP. So for example when
supporting P2MP (Client) MPLS-TP over a P2MP (server) MPLS-TP. Equally
MPLS-TP may may use of P2MP capabilities at different sublayers within a
single MPLS-TP layer network.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 23:26:45 +0000

Done except I used "or transport service" instead of "and". Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 02 Feb 2009 23:32:43 +0000

> I assume that this is SNC protection. Is this correct?

The requirement is to protect paths. How that is achieved is outside the
scope of the document. Protection of groups of multiple paths is not
explicitly a requirement I have seen but is not precluded by the current
requirements. It is not the purpose of the document to require specific
solutions.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Feb 2009 11:58:10 +0100

Ben,

Thanks for your response. It made me aware of the underlying confusion (for
me at least) in the terminology section 1.1.

In this section you specify the following layers

1) transport service layer
2) transport path layer
3) section (layer)
4) transmission media layer.

A "transport path" exists in both the "transport service layer" and the
"transport path layer".
What is meant by Req. 28 is that a P2MP transport path in the transport
service layer can be supported by a P2MP transport path in the transport
path layer. Req. 28 does not require that a P2MP transport path in the
transport path layer is supported by a P2MP section layer (which is a server
layer of the transport path layer) connection.

I propose to clarify this in Req. 28.

----------

Note that according 5.3.3.3.3/G.805 the section layer is one of the two
layer networks in a transmission media layer netowrk. The other layer
network is the physical media layer network. It would be helpful to describe
that the transmission media layer contains also the physical media layer.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: dinsdag 3 februari 2009 0:25
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to
beresolved

Maarten,

On 02/02/2009 07:27, "Maarten Vissers" <[email-masked]> wrote:

> Ben,
> 
> I have the feeling that Requirement 28 "MPLS-TP MUST be capable of 
> using P2MP server (sub-)layer capabilities when supporting P2MP 
> MPLS-TP transport paths (for example context-specific labels 
> [RFC5331])." is not compliant with the definitions of transport path and
transmission media layers.
> 
> According to the definitions, transport path signals are carried by 
> the section layer and the transmission media layer. The transmission media
(i.e.
> G.805's physical media) layer "provides sections (two-port 
> point-to-point connections)" and not any P2MP connections.

Ben

> 
> Should Req 28 be talking about "using P2MP transport path layer 
> capabilities when supporting P2MP MPLS-TP transport services"?
> 
> Regards,
> Maarten
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 05 Feb 2009 21:21:24 +0000

Maarten,

Thanks. I have updated the definition of section as per you suggestion so it
now reads

Section: A section is a server layer (which may be MPLS-TP or a different
technology) which provides for encapsulation and OAM of a MPLS-TP transport
path client layer. A section layer may provide for aggregation of multiple
MPLS-TP clients. Note that [G805] defines the section layer as one of the
two layer networks in a transmission media layer network. The other layer
network is the physical media layer network.

Ben