Subject: [mpls-tp] MIPs in MPLS-TP

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 4 Aug 2009 23:54:43 +0200

There is a pending open issue regarding MIP support in MPLS-TP.

After a discussion between myself, Stewart, Malcolm, Kam and Scott
Mansfield, we think that the following text proposal for MPLS-TP
Framework and MPLS-TP OAM Framework (to be used also as a guide for
writing G.8110.1) could solve the issue:
"
Every node MUST have at least one MIP. A node MAY support more than one
MIP.

The possible locations for a MIP within a node are ingress port, egress
port or the node itself. The choice of which MIP location(s) to support
is an implementation decision. MEPs MUST be capable of addressing any
MIP within their MEG irrespectively of the location.

A node MUST provide the identifier for each of the MIPs it supports
together with the location of the MIP.
"

We would appreciate comments from the whole community regarding this
proposal.

Thanks in advance

Italo

---

From: <[email-masked]>
Date: Tue, 4 Aug 2009 23:53:44 +0100

Why must a node contain a MIP? Is it not permissable to have MPLS-TP nodes that do not support MIPs? BEn

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of BUSI ITALO [[email-masked]]
Sent: Tuesday, August 04, 2009 10:54 PM
To: [email-masked]; [email-masked]
Subject: [mpls-tp] MIPs in MPLS-TP

Thanks in advance

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

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Tue, 4 Aug 2009 21:21:02 -0500

Ben

If a node doesn't contain a MIP for a MEG, then this node will not be able to be involved in any Loopback or route trace for the MEG.

Regards,

Kam

> -----Original Message-----

> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of [email-masked]

> Sent: Tuesday, August 04, 2009 6:54 PM

> To: BUSI, ITALO (ITALO); [email-masked]; [email-masked]

> Subject: Re: [mpls-tp] MIPs in MPLS-TP

> Why must a node contain a MIP? Is it not permissable to have MPLS-TP nodes

> that do not support MIPs? BEn

> From: [email-masked] [[email-masked]] On Behalf Of

> BUSI ITALO [[email-masked]]

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 05 Aug 2009 05:35:49 +0200

Ben,

The functional model of a node will specify which functions are supported
and in which order/combinations those functions are supported. A node with
zero MIPs can be specified as such. As Kam has indicated, such node will not
be able to respond to e.g. loopback messages. But if your network doesn't
need the support of e.g. loopback, then a node with zero MIPs is sufficient
for your network. From a vendor's perspective I expect that nodes will
contain MIPs, initially perhaps just on the node level or on ingress ports,
in future most likely on ingress and egress ports.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 5 augustus 2009 0:54
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: MIPs in MPLS-TP

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of BUSI
ITALO [[email-masked]]
Sent: Tuesday, August 04, 2009 10:54 PM
To: [email-masked]; [email-masked]
Subject: [mpls-tp] MIPs in MPLS-TP

After a discussion between myself, Stewart, Malcolm, Kam and Scott
Mansfield, we think that the following text proposal for MPLS-TP Framework
and MPLS-TP OAM Framework (to be used also as a guide for writing G.8110.1)
could solve the issue:
"
Every node MUST have at least one MIP. A node MAY support more than one MIP.

The possible locations for a MIP within a node are ingress port, egress port
or the node itself. The choice of which MIP location(s) to support is an
implementation decision. MEPs MUST be capable of addressing any MIP within
their MEG irrespectively of the location.

A node MUST provide the identifier for each of the MIPs it supports together
with the location of the MIP.
"

Thanks in advance

Italo

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 5 Aug 2009 07:21:30 +0200

Hi, 

Just one question for my clarification - 
Does this mean that a node that has a MEP must also support a MIP?

Thanx and BR,
yaacov

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext BUSI ITALO
Sent: Wednesday, August 05, 2009 00:55
To: [email-masked]; [email-masked]
Subject: [mpls-tp] MIPs in MPLS-TP

Thanks in advance

Italo

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 05 Aug 2009 09:32:54 +0200

Yaacov,

If we would use the UP MEP, DOWN MEP, MIP and Half MIP convention in
802.1ag, then 
- a DOWN MEP in a node will not have a MIP or Hlaf MIP in this node, 
- an UP MEP in a node may have a MIP or a Half MIP in this node (located on
another interface port in the node).

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Sent: woensdag 5 augustus 2009 7:22
To: ext BUSI ITALO; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Hi, 

Just one question for my clarification - Does this mean that a node that has
a MEP must also support a MIP?

Thanx and BR,
yaacov

-----Original Message-----
Of ext BUSI ITALO

Thanks in advance

Italo

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 5 Aug 2009 11:20:08 +0200

Hi,

According to this explanation, then the proposed statement, i.e. "Every
node MUST have at least one MIP" is incorrect and should read "Every
node MUST have at least one MIP or MEP"?

Thanx,
yaacov

-----Original Message-----
From: ext Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2009 10:33
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); 'ext BUSI ITALO';
[email-masked]; [email-masked]
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Yaacov,

If we would use the UP MEP, DOWN MEP, MIP and Half MIP convention in
802.1ag, then 
- a DOWN MEP in a node will not have a MIP or Hlaf MIP in this node, 
- an UP MEP in a node may have a MIP or a Half MIP in this node (located
on
another interface port in the node).

Regards,
Maarten

-----Original Message-----
Behalf

Hi, 

Just one question for my clarification - Does this mean that a node that
has
a MEP must also support a MIP?

Thanx and BR,
yaacov

-----Original Message-----
Behalf

After a discussion between myself, Stewart, Malcolm, Kam and Scott
Mansfield, we think that the following text proposal for MPLS-TP
Framework
and MPLS-TP OAM Framework (to be used also as a guide for writing
G.8110.1)
could solve the issue:
"
Every node MUST have at least one MIP. A node MAY support more than one
MIP.

The possible locations for a MIP within a node are ingress port, egress
port
or the node itself. The choice of which MIP location(s) to support is an
implementation decision. MEPs MUST be capable of addressing any MIP
within
their MEG irrespectively of the location.

together

Thanks in advance

Italo

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 5 Aug 2009 11:31:42 +0200

Hi,
I do not think we have any reference in the framework to UP/Down MEPs of
Half MIPs........
This is so trivial on an Ethernet node where each port functions as a
bridge.......
How is it modeled (if needed) in MPLS-TP?
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Maarten Vissers
Sent: Wednesday, August 05, 2009 10:33 AM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); 'ext BUSI ITALO';
[email-masked]; [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Yaacov,

Regards,
Maarten

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

Hi, 

Thanx and BR,
yaacov

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

Thanks in advance

Italo

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Wed, 5 Aug 2009 12:51:53 +0200

Hi Kam,
I agree with you, however I think  it could be possible to have  intermediate nodes not supporting MPLS-TP OAM ; these  nodes are  transparent to OAM packet information and forward them as regular data packets.  
 
Besides,   I think that an operator must be able to configure or not a  MIP ( or more than one as proposed )  on a node for each ME. That's even for scalability reasons.
 
Best Regards,
Annamaria

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: mercoledì 5 agosto 2009 4.21
To: [email-masked]; BUSI,ITALO (ITALO); [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Ben

Regards,

Kam

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 05 Aug 2009 12:41:05 +0100

I agree that we need to change the text to indicate
that it could be a MIP or a MEP - that was an
oversight yesterday.

I am OK with making the MIP optional, though
I am surprised that anyone would want to do
that.

What is important is that the placement of the
MIP (or MEP) be an implementation decision
since the placement has impact on how the
equipment is designed, which in turn impacts
scaling, cost etc.

- Stewart

Annamaria Fulignoli wrote:
> Hi Kam,
> I agree with you, however I think it could be possible to have 
> intermediate nodes not supporting MPLS-TP OAM ; these nodes are 
> transparent to OAM packet information and forward them as regular data 
> packets.
> Besides, I think that an operator must be able to configure or not a 
> MIP ( or more than one as proposed ) on a node for each ME. That's 
> even for scalability reasons.
> Best Regards,
> Annamaria
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Lam, Hing-Kam (Kam)
> *Sent:* mercoledì 5 agosto 2009 4.21
> *To:* [email-masked]; BUSI,ITALO (ITALO); 
> *Subject:* Re: [mpls-tp] MIPs in MPLS-TP
>
> Ben
>
> If a node doesn’t contain a MIP for a MEG, then this node will not be 
> able to be involved in any Loopback or route trace for the MEG.
>
> Regards,
>
> Kam
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Aug 2009 09:11:37 -0400

I am confused as to why there is such a requirement for each node.
I can see why its important for a node supporting a MIP or MEP to  
support
all the accompanying protocol stuff, but I don't see why its mandatory  
to.
I see operators like myself liking the option to disable that function.
I think Ben also agreed with me on this earlier.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Aug 2009 09:12:48 -0400

> equipment is designed, which in turn impacts

	The other perspective here is in operational
design. One might choose to not enable MIPs or MEPs
for specific reasons.

	--Tom

>> transparent to OAM packet information and forward them as regular  
>> data packets.
>> Besides, I think that an operator must be able to configure or not  
>> a MIP ( or more than one as proposed ) on a node for each ME.  
>> That's even for scalability reasons.
>> Best Regards,
>> Annamaria
>>
>> *From:* [email-masked] [mailto:[email-masked]]  
>> *On Behalf Of *Lam, Hing-Kam (Kam)
>> *To:* [email-masked]; BUSI,ITALO (ITALO); [email-masked] 
>> ; [email-masked]
>> If a node doesn’t contain a MIP for a MEG, then this node will not  
>> be able to be involved in any Loopback or route trace for the MEG.
>>
>> Regards,
>>
>> Kam
>>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 05 Aug 2009 14:19:47 +0100

> design. One might choose to not enable MIPs or MEPs
There are an number of consequences in making a MIP
optional. For example you cannot send it any form
of OAM instruction such as loopback, or terminate
an SCC/DCC there.

However I am completely OK with it being option
to implement and optional to configure.

Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Aug 2009 09:31:03 -0400

> to implement and optional to configure.

	I understand that, but again that is an operational
consideration when doing the over-all design that the
operator will understand. True it leaves a hole open for
misconfiguration, but then again, that is what the OAM
mechanism will detect if you send to a loopback that
doesn't exist. *)  OTOH, I don't want us going down the
road that was tried with Y.1711 where its configuration
was very rigid. This sort of thing doesn't fly in a real
operational environment where one-size-fits-all never
works.

	--Tom

---

From: George Newsome <[email-masked]>
Date: Wed, 05 Aug 2009 09:31:39 -0400

> in future most likely on ingress and egress ports.
Maarten,

I can't envisage a node level MIP. Is that something that can be 
assigned to a particular trail on a demand basis? If not, is it just a 
MIP with an unspecified location? Or something else?

Thanks,

	George

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 05 Aug 2009 15:32:47 +0200

Annamaria,
 
> I think that an operator must be able to configure or not a  MIP ( or more
than one as proposed )
>  on a node for each ME. That's even for scalability reasons.
 
I agree with you. An interface port card may support a set of X MIP or Half
MIP resources, which can be assigned to a set of X transport entities (e.g.
PW connections, LSP connections). if the operator sets up Y transport
entities (Y > X), then not all of these Y transport entities can be equipped
with a MIP/half MIP.
 
History has shown that the value of X will grow over time; i.e. next gen
port cards support a larger value of X then previous port cards.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Annamaria Fulignoli
Sent: woensdag 5 augustus 2009 12:52
To: Lam, Hing-Kam (Kam); [email-masked]; BUSI,ITALO (ITALO);
[email-masked]; [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Hi Kam,
 
Besides,   I think that an operator must be able to configure or not a  MIP
( or more than one as proposed )  on a node for each ME. That's even for
scalability reasons.
 
Best Regards,
Annamaria

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lam, Hing-Kam (Kam)
Sent: mercoledì 5 agosto 2009 4.21
To: [email-masked]; BUSI,ITALO (ITALO); [email-masked];
[email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Ben

If a node doesn’t contain a MIP for a MEG, then this node will not be able
to be involved in any Loopback or route trace for the MEG. 

Regards,

Kam

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 05 Aug 2009 16:16:18 +0200

George,

The node level MIP has been introduced in 802.1ag as a means for existing
designs to support some level of Ethernet OAM on those existing designs
(e.g. out in the field). It represents a hardware/software architecture in
which the MIP funcitonality is provided on a central card (not being a port
card) and the on-demand OAM (e.g. loopback) is forwarded to that central
card for processing. 

You could look at this as a specific way to implement a MIP which is
functionally specified to exist on an interface port. In functional models
we ignore the implementation (hardware/software) aspects, or stated
differently we allow many different implementations to support the
functional model as long as each implementation provides the black box
behaviour defined by the functional model.

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: woensdag 5 augustus 2009 15:32
To: Maarten Vissers
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: MIPs in MPLS-TP

Maarten Vissers wrote:
> Ben,
> 
> The functional model of a node will specify which functions are 
> supported and in which order/combinations those functions are 
> supported. A node with zero MIPs can be specified as such. As Kam has 
> indicated, such node will not be able to respond to e.g. loopback 
> messages. But if your network doesn't need the support of e.g. 
> loopback, then a node with zero MIPs is sufficient for your network. 
> From a vendor's perspective I expect that nodes will contain MIPs, 
> initially perhaps just on the node level or on ingress ports, in future
most likely on ingress and egress ports.
Maarten,

I can't envisage a node level MIP. Is that something that can be assigned to
a particular trail on a demand basis? If not, is it just a MIP with an
unspecified location? Or something else?

Thanks,

	George

MIP.
> 
> The possible locations for a MIP within a node are ingress port, 
> egress port or the node itself. The choice of which MIP location(s) to 
> support is an implementation decision. MEPs MUST be capable of 
> addressing any MIP within their MEG irrespectively of the location.
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 05 Aug 2009 16:39:55 +0200

Stewart,

SCC/DCC OAM is not terminated in the MIP. 
SCC/DCC OAM is terminated in adaptation fucntions.

A MIP is only involved in loopback and "link trace" (tracing presence of
filtering rule within a rmp/mp2mp transport entity) or "path trace" (tracing
path through the layer of a transport entity).  

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: woensdag 5 augustus 2009 15:20
To: Thomas Nadeau
Cc: Annamaria Fulignoli; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Thomas Nadeau wrote:
>
>
>> I agree that we need to change the text to indicate that it could be 
>> a MIP or a MEP - that was an oversight yesterday.
>>
>> I am OK with making the MIP optional, though I am surprised that 
>> anyone would want to do that.
>>
>> What is important is that the placement of the MIP (or MEP) be an 
>> implementation decision since the placement has impact on how the 
>> equipment is designed, which in turn impacts scaling, cost etc.
>
>     The other perspective here is in operational design. One might 
> choose to not enable MIPs or MEPs for specific reasons.
>
>     --Tom
There are an number of consequences in making a MIP optional. For example
you cannot send it any form of OAM instruction such as loopback, or
terminate an SCC/DCC there.

However I am completely OK with it being option to implement and optional to
configure.

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 05 Aug 2009 16:42:36 +0200

Nurit,

The model in MPLS-TP would be the same. From OAM functionality perspective
there is no functional difference between Ethernet and MPLS-TP. 

Regards,
Maarten

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: woensdag 5 augustus 2009 11:32
To: ext Maarten Vissers; Weingarten, Yaacov (NSN - IL/Hod HaSharon); ext
BUSI ITALO; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Hi,

-----Original Message-----
Of ext Maarten Vissers

Yaacov,

Regards,
Maarten

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

Hi, 

Thanx and BR,
yaacov

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

Thanks in advance

Italo

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 05 Aug 2009 15:42:56 +0100

> SCC/DCC OAM is terminated in adaptation fucntions.

Yes  - you are correct
> path through the layer of a transport entity).  
In which case it is fine to omit or disable the MIP.

Stewart

---

From: <[email-masked]>
Date: Wed, 5 Aug 2009 18:50:50 +0200

Hi Maarten.

"The model in MPLS-TP *would* be the same" *if* the SDO were the same.
As a matter of fact, the SDO happens to be different, therefore Nurit's
humility is legitimate...
The work being endorsed by the IETF for more than a year, let us speak
IETF language and models: is there an I-D that defines "half MIP"?
Unless defining a MIP is the same as defining twice a "half MIP", I
don't think so...

Regards,

Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers

Nurit,

The model in MPLS-TP would be the same. From OAM functionality
perspective
there is no functional difference between Ethernet and MPLS-TP. 

Regards,
Maarten

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

Hi,

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

Yaacov,

Regards,
Maarten

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

Hi, 

Thanx and BR,
yaacov

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

Thanks in advance

Italo

---

From: <[email-masked]>
Date: Thu, 6 Aug 2009 15:10:17 +0100

Maarten,

I see there has been a flurry of mails on this topic since yours but I
wanted to clarify where I was coming from with my question. I am just trying
to understand the impacts of the statement in two broad areas.

- Relationship between MEPs and MIPs. I.e. Is a MEP a superset of a MIP and
therefore stating all nodes will have a MIP really means all nodes will have
a MIP or a MEP

- What is the impact to protocol design if we can (a) assume all nodes have
MIP functionality (even if it isn't enabled on a transport path) as
suggested by the proposed text or (b) if we can't assume all nodes have a
MIP functionality. Impact may be that there is no difference to protocol
design for the two cases.

To respond to your point - lack of MIP will restrict the OAM functions that
can be supported. In some cases that may not be an issue. However the
primary case I was thinking about is nodes that only ever act as transport
path end points and therefore may contain a MEP but might not contain a MIP.
Ben

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 6 Aug 2009 17:18:30 +0300

Tom,
My reading (with some generalization) of the last statement of your message is that there is a difference between "edge" and "core" MPLS-TP devices.
For MPLS this difference has been captured in 3031 (LER vs. LSR) but, somehow, the MPLS-TP documents seem not to deal with it explicitly.
Did I miss something substantial here?

My 2c,
     Sasha

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, August 06, 2009 5:10 PM
> To: [email-masked]; [email-masked];

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 06 Aug 2009 18:37:45 +0200

Ben,

See inline.. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 6 augustus 2009 16:10
To: [email-masked]; [email-masked];

Maarten,

[mv] A MEP is a compound function and a MIP is a compound function. 
- A MEP contains a pro-active moniotirng termination function (XXX_TT) and
an on-demand endpoint monitoring termination function (XXXDe_TT). 
- A MIP contains two back to back on-demand intermediate point termination
functions (2x XXXDi_TT).
- A Half MIP contains one on-demand intermediate point termination function
(XXXDi_TT).
A Half MIP is used when a port supports MIP functionality on its ingress
only.
A MIP is used when a port supports MIP functionality on its "ingress" and
"egress".

[mv] See for details the attached MEP and MIP compound function
specifications from G.8010 and G.8110.1.

[mv] As you will notice, the MEP and MIP are different functions. The
support for MIP functions is independent of the support for MEP functions. 

[mv] The protocol is to be designed under the assumption that there may be
MIPs in a connection. If such MIPs are not active on a port, or if such MIPs
are not present on a port does not impact the OAM protocol itself. It only
impacts the ability to perform fault localization in the network.... 
- No MIPs in the port cards, or none of such MIPs on port cards activated
will result in no means to locate the fault by means of the loopback tool. 
- When MIPs are present on ports and are activated within a connection, then
the LOC alarm will normally trigger a fault localization process that uses
the loopback OAM tool to identify the node or link with the fault.

[mv] Fault localization without MIPs will require that port cards are
equipped with non-intrusive monitoring MEP_Sink functions; NMS can then
temporarily activate on each port card within the connection such MEP_Sink
function and check which MEP_Sink reports LOC and which don't detect/report
LOC. The fault is located between the  last MEP_Sink not reporting LOC and
the first reporting LOC. I hope that it is clear that the use of
non-intrusive monitoring MEP_Sink functions as fault location tool is more
complex then use of loopback OAM tool.

[mv] If you look at my PE NNI port models (that were attached to my email
yesterday, see slides 2 and 3), you will notice that the transport
path/tunnel layer endpoints (i.e. the LSP or EVP endpoints) are supported by
just a LSP MEP or EVP MEP (i.e. a Down MEP). Those PE NNI ports do not
contain a LSP MIP or EVP MIP.
When you look at the P NNI port model (slide 4), then you will notice that
there are only LSP MIP or EVP MIP functions. 

[mv] If you look at the service/channel layer transport
entities/connections, then you will notice in the UNI-N port card (see slide
1) that there are only PW MEP and EVC MEP functions (no MIP functions). And
on the PE NNI port cards, you will notice that there are PW MIP and EVC MIP
functions plus PW MEP and EVC MEP functions.

[mv] My recommendation is that new PE UNI-N, PE NNI and P NNI port cards
should support the set of MEP and MIP functions presented in those slides. 

[mv] Existing port card designs may be upgraded with some of this
recommended MEP and/or MIP functionality, but typically can not support it
all. As a subset may be good enough to start with, existing designs will
present a subset of the recommended MEP/MIP functions to their network
management systems after the (software/firmware) upgrade.

[mv] From a MEP/MIP perspective, you recognize that the tunnel/path layer is
a "thin" layer with just 1 MEG level and thus only one set of MEPs that
monitor the network connection. The service/channel layer is a "thick" layer
with multiple MEG levels and thus multiple sets of MEPs, which support
monitoring of the network connection and one or more tandem
connections/segments. There is always only one set of MIPs in the
service/channel layer (and in the tunnel/path layer), as MIPs operate on the
lowest MEG level that is passing through the MIP.

Regards,
Maarten

Ben

MIP.

---

From: Malcolm Betts <[email-masked]>
Date: Sat, 08 Aug 2009 08:44:22 -0400

All,

I think that we should state in the OAM requirements:

The support of OAM on a MPLS-TP LSP is optional.

In order to support MPLS-TP OAM on an LSP that transits a node, that
node MUST support at least one MIP.  A transit node SHOULD support two
MIPs one on the egress port the other on the egress port.

In order to support MPLS-TP OAM on an LSP that is terminated or
originated that node MUST support a MEP.

This should address the concerns with respect to scalability i.e. the
MEPs and MIPs need not be activated.  

Much of the detail being discussed below belongs in the framework draft
and/or the G.8121 (the ITU equipment Recommendation).

Regards,

Malcolm

> From: Maarten Vissers [mailto:[email-masked]]
> Sent: Thursday, August 06, 2009 12:38 PM
> To: [email-masked]; [email-masked]; mpls-
> [email-masked]; [email-masked]
> To: [email-masked]; [email-masked]; mpls-
> [email-masked]; [email-masked]
> wanted to clarify where I was coming from with my question. I am just
> trying to understand the impacts of the statement in two broad areas.
> 
> - Relationship between MEPs and MIPs. I.e. Is a MEP a superset of a
> MIP and therefore stating all nodes will have a MIP really means all
> nodes will have a MIP or a MEP
> 
> - A MEP contains a pro-active moniotirng termination function (XXX_TT)
> and an on-demand endpoint monitoring termination function (XXXDe_TT).
> - A MIP contains two back to back on-demand intermediate point
> termination functions (2x XXXDi_TT).
> - A Half MIP contains one on-demand intermediate point termination
> function (XXXDi_TT).
> A Half MIP is used when a port supports MIP functionality on its
> ingress only.
> A MIP is used when a port supports MIP functionality on its "ingress"
> and "egress".
> 
> - What is the impact to protocol design if we can (a) assume all nodes
> have MIP functionality (even if it isn't enabled on a transport path)
> as suggested by the proposed text or (b) if we can't assume all nodes
> have a MIP functionality. Impact may be that there is no difference to
> protocol design for the two cases.
> 
> [mv] The protocol is to be designed under the assumption that there
> may be MIPs in a connection. If such MIPs are not active on a port, or
> if such MIPs are not present on a port does not impact the OAM
> protocol itself. It only impacts the ability to perform fault
> localization in the network....
> - No MIPs in the port cards, or none of such MIPs on port cards
> activated will result in no means to locate the fault by means of the
> loopback tool.
> - When MIPs are present on ports and are activated within a
> connection, then the LOC alarm will normally trigger a fault
> localization process that uses the loopback OAM tool to identify the
> node or link with the fault.
> 
> equipped with non-intrusive monitoring MEP_Sink functions; NMS can
> then temporarily activate on each port card within the connection such
> MEP_Sink function and check which MEP_Sink reports LOC and which don't
> detect/report LOC. The fault is located between the  last MEP_Sink not
> reporting LOC and the first reporting LOC. I hope that it is clear
> that the use of non-intrusive monitoring MEP_Sink functions as fault
> location tool is more complex then use of loopback OAM tool.
> 
> 
> To respond to your point - lack of MIP will restrict the OAM functions
> that can be supported. In some cases that may not be an issue. However
> the primary case I was thinking about is nodes that only ever act as
> transport path end points and therefore may contain a MEP but might
> not contain a MIP.
> 
> [mv] If you look at my PE NNI port models (that were attached to my
> email yesterday, see slides 2 and 3), you will notice that the
> transport path/tunnel layer endpoints (i.e. the LSP or EVP endpoints)
> are supported by just a LSP MEP or EVP MEP (i.e. a Down MEP). Those PE
> NNI ports do not contain a LSP MIP or EVP MIP.
> When you look at the P NNI port model (slide 4), then you will notice
> that there are only LSP MIP or EVP MIP functions.
> 
> 1) that there are only PW MEP and EVC MEP functions (no MIP
> functions). And on the PE NNI port cards, you will notice that there
> are PW MIP and EVC MIP functions plus PW MEP and EVC MEP functions.
> 
> [mv] My recommendation is that new PE UNI-N, PE NNI and P NNI port
> cards should support the set of MEP and MIP functions presented in
> those slides.
> 
> recommended MEP and/or MIP functionality, but typically can not
> support it all. As a subset may be good enough to start with, existing
> designs will present a subset of the recommended MEP/MIP functions to
> their network management systems after the (software/firmware)
> upgrade.
> 
> [mv] From a MEP/MIP perspective, you recognize that the tunnel/path
> layer is a "thin" layer with just 1 MEG level and thus only one set of
> MEPs that monitor the network connection. The service/channel layer is
> a "thick" layer with multiple MEG levels and thus multiple sets of
> MEPs, which support monitoring of the network connection and one or
> more tandem connections/segments. There is always only one set of MIPs
> in the service/channel layer (and in the tunnel/path layer), as MIPs
> operate on the lowest MEG level that is passing through the MIP.
> 
> Regards,
> Maarten
> 
> 
> Ben
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 11 Aug 2009 08:34:29 +0100

Thanks Malcolm for your views here.  I have a few further observations
that we might like to consider, especially fellow operators...please see
in-line: 

Malcolm Betts wrote 08 August 2009 13:44
> The support of OAM on a MPLS-TP LSP is optional.

NH=> Agreed.  But perhaps we should add a health-warning to this...maybe
with 2 parts:

1	In co-ps mode technologies based on label-swapping (ie
forwarding labels that are only link unique and also where the traffic
units do not contain a network unique source label) then unless CV-like
OAM is run on all LSPs one cannot detect cases of traffic leaking (via
an unintended replication defect) from one LSP into another LSP.  A
client of such networks could consider the non-detection of such server
layer leaking traffic defects as compromising client information
security.

2	It should be recommended that the same type of CV-like OAM is
run on all LSPs in the same MPLS-TP layer network.  This is simply to
avoid a given LSP sink trail termination point having to be able to
understand all the different types of CV-like OAM that might exist in
the same MPLS-TP layer network....a condition that may arise due to the
type of leaking defect noted above in 1.

> MIPs one on the egress port the other on the egress port.

NH=> IMO it would be useful if vendors could provide operators the
option of being able to passively tap-off end-end CV/PM flows at
intermediate nodes in an on-demand basis for tracing/diagnostics. 
> originated that node MUST support a MEP.

NH=> Agreed.
> MEPs and MIPs need not be activated.  

NH=> True.  But I would have another concern about having nested
MEPs/MIPs that belonged to a different operating party in equipment that
I owned.  Of course, this is related to a larger and more general
observation that peer-partition interworking in a non top-of-stack layer
network (as indeed MPLS-TP is) is not technically necessary. 

regards, Neil
 
> > entities/connections, then you will notice in the UNI-N 
> port card (see
> > slide
> > > Why must a node contain a MIP? Is it not permissable to 
> have MPLS-TP
> > > nodes that do not support MIPs? BEn
> > >
> > > From: [email-masked] [[email-masked]] 
> On Behalf
> > Of
> > > Every node MUST have at least one MIP. A node MAY support 
> more than
> > > one
> > MIP.
> > >
> > > egress port or the node itself. The choice of which MIP 
> location(s)
> > to

---

From: Malcolm Betts <[email-masked]>
Date: Tue, 11 Aug 2009 09:57:41 -0400

Hi Neil,

Thanks for your comments, see in line.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, August 11, 2009 3:34 AM
> To: [email-masked]; [email-masked]; ahmpls-
> [email-masked]

[Malcolm Betts] Agree we should capture these points but, I wonder if
these comments belong in the requirements or in the framework draft.
> type of leaking defect noted above in 1.

[Malcolm Betts] Are you suggesting that we should run CV at the same
rate as CC to ensure rapid detection of such faults.
> intermediate nodes in an on-demand basis for tracing/diagnostics.

[Malcolm Betts] This is on the borderline between a requirement and an
implementation.  My interpretation of the requirements is that transit
nodes should be able read and respond to OAM messages on the LSP.  I
think that the on demand activation is functionally equivalent to
addressing an OAM message to a specific MIP.
> network (as indeed MPLS-TP is) is not technically necessary.
[Malcolm Betts] One frequently quoted use case/scenario is where we have
two maintenance regions within the network of a single operator.
 
> regards, Neil
[Malcolm Betts] Regards, Malcolm

> > > On 05/08/2009 04:35, "Maarten Vissers"
> <[email-masked]>
> > > wrote:
> > >
> > > > Ben,
> > > >
> > > > supported. A node with zero MIPs can be specified as such. As
> Kam
> > > has

---

From: <[email-masked]>
Date: Tue, 11 Aug 2009 15:30:19 +0100

Thanks Malcolm....please see my further responses in-line. 

Malcolm observed 11 August 2009 14:58
> these comments belong in the requirements or in the framework draft.

NH=> I tend to agree with you these observations should reside in a
general requirements document.  The first comment is really about a
potential client security issue caused by a leaking traffic defect, the
second comment is just common sense wrt how many types of CV-like OAM
one should run in the same layer network, ie if N types then are
potentially N!/(N-2)!*2! cases that a LSP sink needs to deal with.
> rate as CC to ensure rapid detection of such faults.

NH=> I've never really understood the subtle spin on the difference
between CC and CV.  CV was a term I first coined many years ago to
clearly differentiate OAM used to verify correct connectivity from the
'CC Cell' in I.610 ATM OAM (which cannot verify correct connectivity, it
can only show that some source is arriving at a given sink).

You can run different rates of the same generic CV OAM packet on
different LSPs but you now hit the combinatorial issue I noted earlier.
In practice this would be manifested as a cyclic entry/exit of defect
states if, for example, a 'slow' CV LSP's traffic was mismerged into a
'faster' CV LSP's traffic.   This may be considered OK by some operators
however.  A worse (practical) case would be if there were quite
different types of CV-like OAM packets being used in the same layer
network.

Aside=> For those folks who think having E-NNIs in a non top-of-stack
layer network is a good idea, the above point is quite germane...because
now one might have, quite reasonably, different operators wanting to use
different types of CV-like OAM.  However, in a single operator doamain
(which I think is the only one that makes sense technically) then the
operator could obviously avoid having more than a single type of CV-like
OAM in use.
> addressing an OAM message to a specific MIP.

NH=> This was something Andy Reid and I discussed long and hard a few
years back.  We came to the clear view that it was more beneficial (for
many reasons) to be able to tap-off end-end CV/PM flows on-demand at
intermediate nodes on the **rare** occasions one would need to, rather
than blanket-cover all nodes with nested MIPs/MEPs.  I'm not sure how
many other operators have thought about this issue, but here all I am
saying is that I think this is a valid/practical alternative view for
diagnostics (especially in a single operator domain) and it would be
useful IMO if vendors gave it some serious consideration.
> two maintenance regions within the network of a single operator.

NH=> A valid point...and a very different scenario to having an E-NNI
between 2 different operating parties.  I have no problems with this in
the case of a single operator, except please note the point above where
an alternative solution would be a capability to passively tap-off an
end-end CV/PM flow on-demand.

regards, Neil
> > > > - Relationship between MEPs and MIPs. I.e. Is a MEP a 
> superset of
> > a
> > > > the primary case I was thinking about is nodes that 
> only ever act
> > as
> > > > > initially perhaps just on the node level or on 
> ingress ports, in
> > > > > future

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Aug 2009 15:20:37 +0100

Hi Malcolm,

Good stuff.

 We will need to try to rephrase this to give guidance to the 
implementation. Note that the deployment requirements drive the 
implementation requirements so that if we intend to say that it is optional 
to deploy OAM on an LSP, the MPLS-TP nodes MUST have sufficient mechanisms 
implemented to support the OAM if the operator decides to deploy OAM on the 
LSP.

> The support of OAM on a MPLS-TP LSP is optional.

I think this has two consequences. The first is easy...

 - It MUST be possible to configure the operation of
   OAM at the ingress MPLS-TP node on a per LSP basis.

 The implication of this first point is that an ingress MPLS-TP node MUST be 
capable of supporting a MEP.

The second is more complicated because it relates to how transit and egress 
nodes can chose to offer OAM services, and how the OAM services operate if 
the nodes do not support them.

 I think we have...

 - An egress MPLS-TP node MUST be capable of supporting a MEP
   and MUST respond correctly to received OAM messages
   according to local configuration and policy.

 - A transit MPLS-TP node MUST be capable of supporting a MIP
   for any LSP, and SHOULD be capable of supporting two MIPs
   for any LSP (one on its ingress port for the LSP, and one on its
   egress port for the LSP).

- A transit MPLS-TP node MUST be capable of reporting (to a
  management system or through OAM messages) the location of
  any MIPs it supports on each LSP.

- The activation of a MIP at a transit MPLS-TP node for any LSP
  SHOULD be subject to local configuration and policy.

- The OAM mechanisms MUST continue to operate across a transit
  MPLS-TP node that supports only one MIP, or that is configured
  to not have an active MIP for a given LSP.

But I wonder if we are also missing a discussion of MEPs at transit nodes? 
Of course, the way we have decided to solve this is by pushing a label at a 
new MEP, so we have created a new LSP. But it is still important to note 
that the node that supports the MEP in this case MUST also support a MIP for 
the next label up the stack.

Cheers,
Adrian

> ----- Original Message -----
> From: "Malcolm Betts" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Sent: Saturday, August 08, 2009 1:44 PM

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 12 Aug 2009 16:49:54 +0200

Adrian,

> Of course, the way we have decided to solve this is by pushing a label at
> a new MEP, so we have created a new LSP. 

I don't agree with you that pushing a label on a single LSP creates a new
LSP layer transport entity/connection. What is does is that it creates a new
LSP MEG level within the existing LSP layer transport entity/connection.

The creation of an additional MEG level in an LSP layer transport
entity/connection establishes a security boundary for OAM, and prevents the
client MEG level to have any OAM visibility inside this additional MEG
level.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: dinsdag 11 augustus 2009 16:21
To: Malcolm Betts
Cc: [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Hi Malcolm,

Good stuff.

 I think we have...

Cheers,
Adrian

---

From: Malcolm Betts <[email-masked]>
Date: Wed, 12 Aug 2009 11:11:29 -0400

Adrian,

Good clarifications thanks,

Malcolm

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Tuesday, August 11, 2009 10:21 AM
> To: Malcolm Betts
> Cc: [email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 12 Aug 2009 18:41:37 +0200

Hi,
We had this discussion in the context of G.8110(.1).
At least in the IETF, this creates a new layer where traffic may be
aggregated. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Maarten Vissers
Sent: Wednesday, August 12, 2009 5:50 PM
To: 'Adrian Farrel'; 'Malcolm Betts'
Cc: [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Adrian,

> a new MEP, so we have created a new LSP. 

I don't agree with you that pushing a label on a single LSP creates a
new
LSP layer transport entity/connection. What is does is that it creates a
new
LSP MEG level within the existing LSP layer transport entity/connection.

The creation of an additional MEG level in an LSP layer transport
entity/connection establishes a security boundary for OAM, and prevents
the
client MEG level to have any OAM visibility inside this additional MEG
level.

Regards,
Maarten

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

Hi Malcolm,

Good stuff.

 We will need to try to rephrase this to give guidance to the
implementation. Note that the deployment requirements drive the
implementation requirements so that if we intend to say that it is
optional
to deploy OAM on an LSP, the MPLS-TP nodes MUST have sufficient
mechanisms
implemented to support the OAM if the operator decides to deploy OAM on
the
LSP.

 The implication of this first point is that an ingress MPLS-TP node
MUST be
capable of supporting a MEP.

The second is more complicated because it relates to how transit and
egress
nodes can chose to offer OAM services, and how the OAM services operate
if
the nodes do not support them.

 I think we have...

But I wonder if we are also missing a discussion of MEPs at transit
nodes? 
Of course, the way we have decided to solve this is by pushing a label
at a
new MEP, so we have created a new LSP. But it is still important to note
that the node that supports the MEP in this case MUST also support a MIP
for
the next label up the stack.

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 12 Aug 2009 19:24:13 +0200

Nurit,

As sson as you aggregate traffic you create a new layer network and not an
additional MEG level in an existing LSP transport entity/connection. 

There is a major difference between creating a transport entity in a new
layer netowrk and creating a MEG level in an existing transport entity.
Please do not mix these two very different things.

Regards,
Maarten

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
Sent: woensdag 12 augustus 2009 18:42
To: ext Maarten Vissers; Adrian Farrel; Malcolm Betts
Cc: [email-masked]
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Hi,

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

Adrian,

nodes?
> Of course, the way we have decided to solve this is by pushing a label
at

Regards,
Maarten

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

Hi Malcolm,

Good stuff.

 I think we have...

Cheers,
Adrian

---

From: <[email-masked]>
Date: Wed, 12 Aug 2009 19:06:37 +0100

Maarten is essentially right here, though I would not define a new layer
network solely on (client) traffic aggregation.

MPLS (by original concept) is based on sublayering....this is what the S
bit is about.  This is exactly why when we want to produce a true
client/server relationship between LSPs that exist in different MPLS
layer network operator domains (ie MPLSoverMPLS) we have to 'fix' the S
bit issue and truly functionally isolate the DP/CP/MP.  I worked on a
draft with Stewart Bryant a while back that used an Ethernet PW to
create the required functional breakwater between different MPLS layer
networks...this would allow independent setting of the S bit in the
client and server MPLS layer networks.  Not the most elegant solution
IMO, but it would work.  I personally think a special reserved (DP)
label would be a better and more efficient solution.

We should also carefully note here that whilst 1-hop PWs are a
degenerate layer network (ie can be classified as adapatation) the
minute these become MS (ie > 1hop) then we have created a new PW (co-ps
mode) layer above MPLS.  In MPLS-TP we really better not have MS PWs
because if we do then IMO MPLS-TP will have failed in its primary
objective of creating a transport network....this ought to be very
obvious, so I hope it is to all reading this.

regards, Neil  

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 12 August 2009 18:24
> To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'Adrian 
> Farrel'; 'Malcolm Betts'
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf
> Of ext Maarten Vissers
> [mailto:[email-masked]] On Behalf
> Of Adrian Farrel

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 12 Aug 2009 19:28:16 +0200

Hi Maarten,
Thanks for the clarification.
>From the discussion we had on G.8110.1 it looked that as even when
aggregating it is considered as sub-layer and not a new layer. Is it so?
Best regards,
Nurit

-----Original Message-----
From: ext Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2009 8:24 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'Adrian Farrel'; 'Malcolm
Betts'
Cc: [email-masked]

Nurit,

As sson as you aggregate traffic you create a new layer network and not
an
additional MEG level in an existing LSP transport entity/connection. 

Regards,
Maarten

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

Hi,

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

Adrian,

nodes?
at

Regards,
Maarten

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

Hi Malcolm,

Good stuff.

 I think we have...

Cheers,
Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 12 Aug 2009 19:29:11 +0200

Also, please note that in the IEFT we did not limit the TC (which
creates a new MEG level) for 1:1 mapping. 

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
Sent: Wednesday, August 12, 2009 8:28 PM
To: 'ext Maarten Vissers'; 'Adrian Farrel'; 'Malcolm Betts'
Cc: [email-masked]
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Hi Maarten,

-----Original Message-----
From: ext Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, August 12, 2009 8:24 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'Adrian Farrel'; 'Malcolm
Betts'
Cc: [email-masked]

Nurit,

Regards,
Maarten

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

Hi,

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

Adrian,

nodes?
at

Regards,
Maarten

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

Hi Malcolm,

Good stuff.

 I think we have...

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 12 Aug 2009 19:37:28 +0100

Hi Maarten,

> LSP MEG level within the existing LSP layer transport entity/connection.

I find it quite hard when you disagree with me over something I have not 
said!

I think that you are mapping "LSP" to "LSP layer transport 
entity/connection." You are free to make that mapping. I don't.

I define "LSP" based on the label switching properties associated with the 
topmost label on the stack. If you push a new label, you are creating a new 
LSP. This is "obvious" by looking at the LFIB at a transit node.

> client MEG level to have any OAM visibility inside this additional MEG

Bad choice of words :-)
It doesn't provide security or prevent anything.
It simply provides a demarkation.

Thanks,
Adrian

---

From: <[email-masked]>
Date: Thu, 13 Aug 2009 08:00:53 +0100

Adrian...these are excellent observations that I hope everyone takes
note of....especially the last one.  I want to add something more to
what you said here, so please see in-line. 

Adrian said 12 August 2009 19:37

> LSP. This is "obvious" by looking at the LFIB at a transit node.

NH=> Exactly so.  I have tried to make this point several times in the
past.....esp when explaining why MS PWs *will* create a new layer
network but nested LSPs *do not* create a new layer network.  Further,
my colleague Alan McGuire took great pains to work with IETF experts to
get this point right in the MPLS functional architecture model which is
given in G.8110.  The MPLS architecture has a novel/original behaviour
in that it is based on a digital wrapper concept, ie one can
add/remove/swap new headers at will.  Doing so does not create/destroy a
new MPLS layer network....nested LSPs that use the S bit are sublayers
of the *same* parent MPLS layer network.

Aside=> It is my personal opinion that MPLS-TP does not need this S bit
mechanism....or to be more accurate with what I mean here, we should not
have an ability to nest LSPs to an arbitrary level.  The really
important bit to get right in MPLS-TP wrt this area is a proper/simple
MPLS-TPoverMPLS-TP client/server layer network relationship (and one
that does not require the rather crude insertion of some other
technology, eg Ethernet, to create a 'functional breakwater' to separate
the DP/CP/MP of the 2 MPLS layer networks).

> It simply provides a demarkation.

NH=> You are so very right here.  I have discussed this topic countless
time with colleagues here in BT.  Whilst nested MEG levels *appear* as
though they create hierarchy they most certainly do not....what they do
is create arbitrary partitioning points in a single layer network, which
is exactly why your point Adrian above about demarcation is spot-on
(also see Note below).  Further, having looked very closely at all the
implications of imposing such partitioning configurations we came to the
conclusion that we did not want this (which is why many of my colleagues
and I would prefer an on-demand ability to tap-off true end-end CV/PM
OAM flows at arbitrary intermediate nodes for the *rare* occasions we
need to do this type of diagnostics).  Our observations on why AIS is
also not necessary even in a co-ps mode layer network also came from our
analysis of this topic.

Note - The consequence of nested MEG levels and the nature of LSPs in
MPLS as-is (ie with the S bit) is that one would have (potentially up to
8) nested MEG 'sublayers' within *each* nested LSP sublayer.  Further,
should we continue to have a MS PW model (ie another layer network above
MPLS-TP) then one would have the nested MEG issue repeated again
here.....but as I have noted before, we really should not be creating a
PW layer network above MPLS-TP as this kind-of defeats the whole point
of what MPLS-TP is aiming to achieve as a transport network.

regards, Neil

> > The implication of this first point is that an ingress 
> MPLS-TP node MUST 
> > be
> >> > node MUST support at least one MIP.  A transit node 
> SHOULD support
> >> two

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 13 Aug 2009 16:36:30 +0200

Adrian,

Thanks for clarifying that you don't make the mapping between "LSP" and "LSP
layer transport entity/connection". This is very important for me to
understand. Transport networks care about their transport entities, and
manage those entities and their MEG levels.

Understanding that "LSP" is not to be used to represent a "transport entity"
in a MPLS-TP layer network, I am wondering if the term "PW" should also not
be used to represent a "transport entity" in a MPLS-TP layer network?
Assuming that "PW" does not map to a MPLS-TP layer transport
entity/connection either, I would like to know what term to use for the 
- "transport entity/connection" that may have a "PW label", and 
- "transport entity/connection" that may carry one or more of the previous
transport entities?

E.g. 
- the first transport entity may be referred to as a "MPLS-TP Virtual
Channel (MVC)"
- the second transport entity may be referred to as a "MPLS-TP Virtual Path
(MVP)".

The top MEG level within a MVC is identified by a "PW label", and each lower
MEG level within a MVC is identified by a "LSP label".
The top MEG level within a MVP is identified by a "LSP label", and each
lower MEG level within a MVP is identified by another "LSP label".

On the physical media (e.g. fiber) an MVC contains one PW label and zero or
more LSP labels, while an MVP contains one or more LSP labels.

> > entity/connection establishes a security boundary for OAM, and 
> > prevents the client MEG level to have any OAM visibility inside this 
> > additional MEG level.
>
> Bad choice of words :-)

The creation of an additional MEG level and consequential activation of the
MEG level's MEP functions in either a MVC, or MVP will prevent that the
outer MEG level has access to the MIP functions within the new MEG segment.

Regards,
Maarten

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: woensdag 12 augustus 2009 20:37
To: Maarten Vissers; 'Malcolm Betts'
Cc: [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Hi Maarten,

>> Of course, the way we have decided to solve this is by pushing a 
>> label at a new MEP, so we have created a new LSP.
>
> new LSP layer transport entity/connection. What is does is that it 
> creates a new LSP MEG level within the existing LSP layer transport 
> entity/connection.

> entity/connection establishes a security boundary for OAM, and 
> prevents the client MEG level to have any OAM visibility inside this 
> additional MEG level.

Bad choice of words :-)

Thanks,
Adrian

> Behalf Of Adrian Farrel
> optional to deploy OAM on an LSP, the MPLS-TP nodes MUST have 
> sufficient mechanisms implemented to support the OAM if the operator 
> decides to deploy OAM on the LSP.
>
> MUST be capable of supporting a MEP.
>
> egress nodes can chose to offer OAM services, and how the OAM services 
> operate if the nodes do not support them.
>
> I think we have...
>
> management system or through OAM messages) the location of  any MIPs 
> it supports on each LSP.
>
> MPLS-TP node that supports only one MIP, or that is configured  to not 
> have an active MIP for a given LSP.
>
> at a new MEP, so we have created a new LSP. But it is still important 
> to note that the node that supports the MEP in this case MUST also 
> support a MIP for the next label up the stack.
>
> Cheers,
> Adrian
>
>> > In order to support MPLS-TP OAM on an LSP that transits a node, 
>> > that node MUST support at least one MIP.  A transit node SHOULD 
>> > support
>> two

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 13 Aug 2009 16:50:56 +0200

Nurit,

A layer network represents a set of transport entities which have a common
role in the transport network (from the viewpoint of the operator). E.g. a
service/channel layer network represents the set of service/channel
transport entities, a tunnel/path layer network represents the set of
tunnel/path transport entities, a section layer network represents the set
of section transport entities and a physical media layer network represents
the set of physical media transport entities.

A tunnel/path layer transport entity carries a set of service/channel layer
transport entities.
A section layer transport entity carries either a set of service/channel
layer transport entities, or a set of tunnel/path layer transport entities.
Aggregation of transport entities into a server layer transport entity is
performed to enhance the scalability of transport networks. On one hand it
adds complexity to the network, on the other hand it reduces the number of
transport entities to administer in nodes in the network, which reduces
complexity of the network. You don't aggregate as such "on the fly" (without
very clear network scalability reasons).

The transport entities in each of those four layer networks perform a
specific role in the network, have a specific life time and are created
under control of a specific authority; i.e.
- network planning controls creation of physical media layer transport
entities
- network planning controls creation of section layer transport entities
- network engineering controls creation of tunnel/path layer transport
entities, using the tunnel/path layer links provided by the available
section layer transport entities
- customers request creation/deletion/modification of service/channel layer
transport entities; service management within the transport network then
sets up/deletes/modifies the service/channel transport entity, using the
service/channel layer links provided by the available tunnel/path layer
transport entities and section layer transport entities, which have the
service/channel layer as client layer. The customer can communicate its
request in a number of ways to its service provider, e.g. by letter, by fax,
via a sales representative but also via a web based interface or a UNI
control plane. In the latter two cases it is possible to set up the
service/channel transport entity without human involvement in the service
provider's organisation (automatic service creation).

When a transport entity is owned by more then one organisation (customer,
carrier A, carrier B) or application (protection switching, testing) there
will be a need to provide dedicated monitoring for each. This is realized by
creating a MEG level for each organisation/application owning the transport
entity. Each MEG level is architecturally considered to represent a
sub-layer within the transport entity's layer network.

The terms service/channel layer, tunnel/path layer and section layer are
relative terms that represent the role of a set of transport entities within
the viewpoint of e.g. an operator. From the viewpoint of a second operator,
a customer, or the national core of operators in e.g. China, USA, India,
Russia or pan-europe some of those transport entities may be a member of
another layer network. 

A few examples:
1) A SDH VC-3/SONET STS-1 layer is a tunnel/path layer in AU3 type SDH
network domains. From the viewpoint of AU4 type SDH networks this VC-3 layer
is a service/channel layer network, and the VC-3 is carried in this latter
network as a TU-3.

2) An OTN HO ODU layer is a tunnel/path layer in an OTN network of carrier
A. From the viewpoint of e.g. a carrier B network perspective this HO ODU is
carried as a LO ODU (i.e. service/channel layer transport entity). 
Note that OTN allows to create a hierarchy of ODU layers (e.g. ODU0 -> ODU1
-> ODU2 -> ODU3 -> ODU4), but each owner just sees two of those layers.
Within one owner's viewpoint you can have e.g. ODU0/ODU1/ODU2/ODU2e/ODUflex
-> ODU3 and ODU0/ODU1/ODU2/ODU2e/ODUflex/ODU3 -> ODU4. The ODU3 and ODU4 are
signals in the HO ODUk layer network, and the ODU0, ODU1, ODU2, ODU2e,
ODUflex and ODU3 are signals in the LO ODUk layer network.

3) An Ethernet VLAN (EVP) layer is a tunnel/path layer in an Ethernet
network of carrier A. From the viewpoint of e.g. a carrier B network, this
EVP is carried as an EVC (i.e. service/channel layer transport entity).
Similarly, an Ethernet VLAN (EVS) layer is a section layer in an Ethernet
network of customer X. From the viewpoint of the transport network, this EVS
is carried as an EVC (case of port based Ethernet service).

4) A MPLS-TP VP (MVP) layer is a tunnel/path layer in a MPLS-TP network of
carrier A. From the viewpoint of e.g. a carrier B network, a MVP layer
transport entity is carried as a MPLS-TP VC (MVC) service/channel layer
transport entity.

Regards,
Maarten

-----Original Message-----
Sent: woensdag 12 augustus 2009 19:28

Hi Maarten,

-----Original Message-----
From: ext Maarten Vissers [mailto:[email-masked]]
Sent: Wednesday, August 12, 2009 8:24 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'Adrian Farrel'; 'Malcolm
Betts'
Cc: [email-masked]

Nurit,

Regards,
Maarten

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

Hi,

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

Adrian,

nodes?
at

Regards,
Maarten

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

Hi Malcolm,

Good stuff.

 I think we have...

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 13 Aug 2009 17:15:28 +0200

Neil,

I really do not understand what keeps you pointing at the S bit time after
time. 
For me, the S-bit is just a very limited protocol ID bit with which it is
possible
to identify if the encapsulated entity is again MPLS or is non-MPLS.

In SDH we have a signal label which is defined as "equipped, non-specific". 
When used it does not identify what client is encapsulated in the payload of
the VC-n.
The S=0 case in MPLS seems to be a similar "equipped, non-specific"
encoding.

As nothing is perfect, can't we simply accept that MPLS has a very
restricted 
protocol ID/payload type function and go on?

>From a data plane perspective we are able to perform a limited payload type
mismatch 
defect detection; i.e. 
- if S=0 is expected and S=1 is received there is a payload type mismatch
defect detected,
- if S=1 is expected and S=0 is received there is a payload type mismatch
defect detected,
- if S=0 is expected and received, there could or could not be a payload
type mismatch defect, which however can not be detected by checking the
S-bit. But it is possible to detect between a payload type mismatch for the
case of IPv4, IPv6 and other; the payload type mismatch in an MPLS/IPv4
adaption function can determine if there is such mismatch by inspecting the
4-bit nibble value.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 12 augustus 2009 20:07
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

MPLS (by original concept) is based on sublayering....this is what the S bit
is about.  This is exactly why when we want to produce a true client/server
relationship between LSPs that exist in different MPLS layer network
operator domains (ie MPLSoverMPLS) we have to 'fix' the S bit issue and
truly functionally isolate the DP/CP/MP.  I worked on a draft with Stewart
Bryant a while back that used an Ethernet PW to create the required
functional breakwater between different MPLS layer networks...this would
allow independent setting of the S bit in the client and server MPLS layer
networks.  Not the most elegant solution IMO, but it would work.  I
personally think a special reserved (DP) label would be a better and more
efficient solution.

We should also carefully note here that whilst 1-hop PWs are a degenerate
layer network (ie can be classified as adapatation) the minute these become
MS (ie > 1hop) then we have created a new PW (co-ps
mode) layer above MPLS.  In MPLS-TP we really better not have MS PWs because
if we do then IMO MPLS-TP will have failed in its primary objective of
creating a transport network....this ought to be very obvious, so I hope it
is to all reading this.

regards, Neil  

> To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'Adrian Farrel'; 
> 'Malcolm Betts'
> Cc: [email-masked]
> As sson as you aggregate traffic you create a new layer network and 
> not an additional MEG level in an existing LSP transport 
> entity/connection.
> 
> There is a major difference between creating a transport entity in a 
> new layer netowrk and creating a MEG level in an existing transport 
> entity.
> [mailto:[email-masked]] On Behalf Of ext Maarten Vissers
> MPLS-TP node MUST be

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 13 Aug 2009 17:28:51 +0200

Neil,

I just noticed that I inverted the S-bit value in the last dash item...
Now the last dash item with the correct value:
------
- if S=1 is expected and received, there could or could not be a payload
type mismatch defect, which however can not be detected by checking the
S-bit. But it is possible to detect between a payload type mismatch for the
case of IPv4, IPv6 and other; the payload type mismatch in an MPLS/IPv4
adaption function can determine if there is such mismatch by inspecting the
4-bit nibble value.
----

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: donderdag 13 augustus 2009 17:15
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Neil,

I really do not understand what keeps you pointing at the S bit time after
time. 
For me, the S-bit is just a very limited protocol ID bit with which it is
possible to identify if the encapsulated entity is again MPLS or is
non-MPLS.

As nothing is perfect, can't we simply accept that MPLS has a very
restricted protocol ID/payload type function and go on?

>From a data plane perspective we are able to perform a limited payload type
mismatch defect detection; i.e. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 12 augustus 2009 20:07
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

regards, Neil  

> [mailto:[email-masked]] On Behalf Of Adrian Farrel

---

From: <[email-masked]>
Date: Thu, 13 Aug 2009 16:35:07 +0100

Maarten,

The reason I feel it necessary to keep pointing this out is because I am
aware of the confusion it is causing some folks...I know this from
private conversations.  And to be super clear here are the important
bits explained again:

-	MPLS uses a digital wrapper approach, ie the S bit...it is
unique in networking technologies in this respect.

-	nested LSPs in MPLS create vertical/hierarchical sublayers (of
the same MPLS layer network).

-	Y.1731 MEG levels are not vertical hierarchy but horizontal
partitions...simply demarcs in an LSP as Adrian accurately
observed......and if applied to MPLS this is per LSP, ie one could have
8 MEG levels per LSP if one follows Y.1731.

-	the MPLS sublayering natively allows a TCM-like approach without
requiring a Y.1731 approach....a point I believe Nurit was trying to
make.

These are important distinctions IMO.

regards, Neil

> Sent: 13 August 2009 16:15
> To: Harrison,N,Neil,DEY2 R; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> > > > This should address the concerns with respect to 
> scalability i.e.
> > > the
> > > > Much of the detail being discussed below belongs in the 
> framework
> > > draft

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 13 Aug 2009 18:09:50 +0200

Neil, Adrian,

Reading the MPLS-TP framework draft I noticed the following text:

         +------------------------------------+
         |        MPLS-TP LSP label(s) (S=0)  | n*4 octets
         .                                    . (four octets per label)
         +------------------------------------+
         |      Service label (s=1)           |   4 octets
         +------------------------------------+
         |       Client Network               |
         |       Layer Protocol               |
         |           Stack.                   |
         +------------------------------------+

      Note that the Client Network Layer Protocol
      Stack may include an MPLS label stack
      with the S bit set (S=1).

         Figure 5: Network Layer Transport Service Protocol Stack

   A label per network layer protocol payload type that is to be
   transported is REQUIRED.  Such labels are referred to as "Service
   Labels", one of which is shown in Figure 5.  The mapping between
   protocol payload type and Service Label is either configured or
   signaled.

If I understand this piece of text, then in MPLS-TP we get a full functional
"payload type" function (encoded in the new "service label"); i.e. similar
to signal label in SDH VC-n and payload type in OTN OPUk. The 20-bit label
field would then be carrying a payload/protocol type, which identifies
uniquely the client layer network signal type (e.g. ATM VC, ATM VP, TDM 2
Mbit/s, TDM 34 Mbit/s, Ethernet VLAN, ...) being carried in the MPLS-TP
payload area. When two or more different client layer signal types are
carried in one MPLS-TP Virtual Channel (MVC, see response to Adrian's email
today), then one MVC will contain packets with different service label
values (e.g. packets with service label identifying an Etherent VLAN and
others with a service label identifying an ATM VC).

As the bottom-of-stack label (with S=1) is now a 'service label', MPLS-TP
can not longer support the "PW" or "MS-PW"...

The text furthermore states that Client Network Layer Protocol Stack (i.e.
the payload area) may contain another MPLS label stack with a
bottom-of-stack label (with S=1).

The text is not clear if the MPLS-TP tunnel/path layer transport
entities/connections will also comply with this Network Layer Transport
Service Protocol Stack specification; i.e. will a MPLS-TP Virtual Path (MVP)
encapsulate its MVC client signals using a "service label" that will have
the value "MVC"?

When I read further in this draft, then I find below figure 6 the following
sentence:
"  Figure 7 illustrates how the concept of Maintenance Entities can be
   mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS-
   PWs."

This sentence and the next part of the text seems to be contradicting the
REQUIREMENT described around figure 5; e.g. there can't be any "PWs" in a
MPLS-TP network.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 13 augustus 2009 17:35
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

Maarten,

The reason I feel it necessary to keep pointing this out is because I am
aware of the confusion it is causing some folks...I know this from private
conversations.  And to be super clear here are the important bits explained
again:

-	Y.1731 MEG levels are not vertical hierarchy but horizontal
partitions...simply demarcs in an LSP as Adrian accurately observed......and
if applied to MPLS this is per LSP, ie one could have
8 MEG levels per LSP if one follows Y.1731.

-	the MPLS sublayering natively allows a TCM-like approach without
requiring a Y.1731 approach....a point I believe Nurit was trying to make.

regards, Neil

> I really do not understand what keeps you pointing at the S bit time 
> after time.
> For me, the S-bit is just a very limited protocol ID bit with which it 
> is possible to identify if the encapsulated entity is again MPLS or is 
> non-MPLS.
> 
> When used it does not identify what client is encapsulated in the 
> payload of the VC-n.
> From a data plane perspective we are able to perform a limited payload 
> type mismatch defect detection; i.e.
> - if S=0 is expected and S=1 is received there is a payload type 
> mismatch defect detected,
> - if S=1 is expected and S=0 is received there is a payload type 
> mismatch defect detected,
> - if S=0 is expected and received, there could or could not be a 
> payload type mismatch defect, which however can not be detected by 
> checking the S-bit. But it is possible to detect between a payload 
> type mismatch for the case of IPv4, IPv6 and other; the payload type 
> mismatch in an
> MPLS/IPv4
> adaption function can determine if there is such mismatch by 
> inspecting the 4-bit nibble value.
> 
> Regards,
> Maarten
> 
> To: [email-masked]; [email-masked]; 
> Maarten is essentially right here, though I would not define a new 
> layer network solely on (client) traffic aggregation.
> 
> MPLS (by original concept) is based on sublayering....this is what the 
> S bit is about.  This is exactly why when we want to produce a true 
> layer network operator domains (ie MPLSoverMPLS) we have to 'fix' the 
> S bit issue and truly functionally isolate the DP/CP/MP.  I worked on 
> a draft with Stewart Bryant a while back that used an Ethernet PW to 
> > I don't agree with you that pushing a label on a single LSP creates 
> > a new LSP layer transport entity/connection. What is does is that it 
> additional MEG
> > egress nodes can chose to offer OAM services, and how the OAM 
> > services operate if the nodes do not support them.
> > 
> >  I think we have...
> > 
> > label at a new MEP, so we have created a new LSP. But it is still 
> > important to note that the node that supports the MEP in this case 
> > MUST also support a MIP for the next label up the stack.
> > 
> > Cheers,
> > Adrian
> >

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 13 Aug 2009 19:04:29 +0200

Neil,

> partitions...simply demarcs in an LSP as Adrian accurately observed......
> and if applied to MPLS this is per LSP, ie one could have

You misunderstand in my opinion the architecture associated with the Y.1731
MEG levels. If you look at G.8010, clause 7.2.4 you will read that the ETH
layer network supports vertical/hierarchical sublayers, one sublayer per MEG
level. In appendix V/G.8010 you will find a number of examples of those
vertical/hierarchical ETH sublayers.

If we would have decided to apply the MEG level encoding of ETH transport
entity MEGs also to MPLS-TP transport entity MEGs, then we would have had
the situation that
- each Label Stack Entry header in the MPLS-TP packet would have represented
a multiplexing step in the hierarchy of MPLS-TP transport entities, and
- the MEG Level (MEL) field in OAM frames would have represented the MEG
level wihtin its MPLS-TP transport entity. 
In most cases there would not have been more then two label stack entry
headers in the MPLS-TP packet on the physical media.

As the decision was to encode MEG levels within a MPLS-TP transport entity
by means of a Label Stack Entry header, the MPLS-TP packet (on the physical
media) will contain
- one or more label stack entry headers per MVC, of which the top one is the
MVC idnetifier within the MVP plus lowest MVC MEG level identifier and the
lower ones are other MVC MEG level idnetifiers, and
- one or more label stack entry headers per MVP, of which the top one is the
MVP identifier within the Section plus lowest MVP MEG level identifier and
lower ones are other MVP MEG level idnetifiers.
In many cases there will be more then two label stack entry headers in the
MPLS-TP packet on the physical media, and people need to be retrained to
correctly identify the function of each of the many label stack entry
headers in each MPLS-TP packet.

The label stack entry header thus performs two distinct roles for each
transport entity:
1) multiplex (and MEG level) identifier
2) MEG level identifier.

If we would have a MVC service/channel layer and a MVP tunnel/path layer in
a MPLS-TP network, and if on a physical media in the middle of this network
we have three MVC MEG levels active (UNI-N-to-UNI-N, UNI-N-to-ENNI, MVC
SNCP) and two MVP MEG levels (end-to-end, MVP SNCP), then there will be six
label stack entry headers on packets with client data in their payload. 
- Top-of-stack LSE header is the MVP multiplexing identifier and SNCP MEG
level label, 
- the second one is e-t-e MVP MEG level label, 
- the third one is the MVC multiplex identifier and MVC SNCP MEG level
label, 
- the forth is the UNI-N-to-ENNI MVC MEG level label and 
- the fifth is the UNI-N-to-UNI-N MVC MEG level label and
- the sixth is the 'service label' carrying the payload type of the client.

On this physical media there could also be a MPLS-TP packet with six label
stack entry headers, of which 4 LSE headers are associated with the MVC and
1 LSE header is associated with the MVP and 1 with the service label. 

The layer stack does not provide anylonger information of the transport
entity hierarchy.

With the requirement in the MPLS-TP framework draft that the bottom-of-stack
label stack entry header in a MPLS-TP network layer is a 'service label'
that carries a payload type, it could be that it is the intention of this
requirement in the draft that the MVC packets are mapped into the MVP after
encapsulation with a 'service label'. 

If it is the intention of the framework draft to require the presence of
such 'service label' as bottom-of-stack label for every MPLS-TP transport
entity, then in the above example there would be a seventh label stack entry
header which is located after the second label stack entry header; i.e.
- Top-of-stack LSE header is the MVP multiplexing identifier and SNCP MEG
level label, 
- the second one is e-t-e MVP MEG level label,
- the third one is the MVP 'service label' carrying the payload type of the
client (i.e. MVC or MPLS-TP)
- the forth one is the MVC multiplex identifier and MVC SNCP MEG level
label, 
- the fifth is the UNI-N-to-ENNI MVC MEG level label and 
- the sixth is the UNI-N-to-UNI-N MVC MEG level label and
- the seventh is the MVC 'service label' carrying the payload type of the
client.

Now it is clear where the label stack entry header set for the MVC transport
entity ends and the label stack entry header set for the MVP transport
entity starts.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 13 augustus 2009 17:35
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

Maarten,

regards, Neil

---

From: <[email-masked]>
Date: Fri, 14 Aug 2009 02:09:46 +0100

Maarten,

An LSP can be  transport entity but due to sublayering pushing a new label
on the stack may create a new LSP but not a new transport entity.

PWs are different. PWs do not contain sublayers, i.e there are not multiple
labels in a single PW. Ben

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 14 Aug 2009 11:06:41 +0300

Maarten,
I think that you've mis-interpreted the text you are quoting.

IMHO and FWIW the "Service Label" mentioned in the framework document identifies the service instance and, by implication, the client protocol stack carried over this service instance. In other words, it is a "service demultiplexer" and, as such, an exact equivalent (albeit under a different name) of the "PW label" as defined in Figure 11 of RFC 3985. As such, the construct defined in the framework draft is fully compatible with the PW architecture.

And, of course, there is nothing common with the SDH path signal label, where the service instance is identified by the position of the path in question in the SDH hierarchy, and the type of the client is encoded in the signal path label using a predefined set of values.

The framework draft should be probably reworded to preclude this type of misunderstanding.

My 2c,
     Sasha
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Maarten Vissers [[email-masked]]
Sent: Thursday, August 13, 2009 7:09 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Neil, Adrian,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 13 augustus 2009 17:35
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

Maarten,

regards, Neil

---

From: <[email-masked]>
Date: Fri, 14 Aug 2009 10:41:04 +0100

Thanks Maarten ....please see in-line: 

> Sent: 13 August 2009 15:36
> To: 'Adrian Farrel'
> Cc: [email-masked]

NH=> Our transport networks (ie in BT) don't have a suite of nested MEG
levels...and they work just fine.  Moreover, we don't want them.  I'll
not go through all the reasons why here, but we have plenty of them.

The only 2 networks that MUST ALWAYS be present are:
-	a top-of-stack network that supports *external*
message/file/stream applications (and thus has the appropriate
application adaptation functions)...without this all lower level
networking serve no purpose at all...so this network layer MUST be
present in *all* cases.
-	a bottom-of-stack network that modulates an EM wave on a
radio/metallic/optical media.....without this information cannot travel
across geogrpahic distance.

An important, but as yet unwritten, objective for operators (on the
simple grounds of capex/opex costs) is to reduce the number of
additional layer networks that lie between these 2 must-have extremes of
networking.  So here is one simple/obvious reason why I don't agree with
your multiple layer view of the transport world.

E-NNIs are *only* technically required in top-of-stack networks where
there is an internationally agreed global service, eg PSTN,
Internet....the mere fact we have to physically interconnect on a media
that modulates an EM wave at the bottom-of-stack does *not* make this an
E-NNI, and IMO it is rather disingenuous to claim that it does.
Further, in the UK operators like BT have legal/regulatory obligations
on interconnects and we cannot allow such a flawed technical concept to
appear as a requirment for compliance in standards.  However, we would
not want to stop operators who do wish to peer in non-top-of-stack
networks, but this must not be a mandatory requirement of being
compliant with a standard.  And this is not even considering the even
more erroneous case of trying to peer interwork different
modes/technologies that are not top-of-stack.

I would be grateful if our network equipment suppliers would please take
careful note of the above.  

> be used to represent a "transport entity" in a MPLS-TP layer network?

NH=> In principle you are right.  But the real reason for this is that
PWs are an artefact of the LDP type of MPLS......without going into too
much technical detail here they are a consequence of 2 things:  (i) LDP
merging (ie a PW label MUST be SA proxy to recover the lost source
information (irrespective of what others claim it is), and it is for
sure not a normal LSP forwarding label) and (ii) the fact that IP was
treated differently to other clients (which has ECMP knock-on effects).

All these things have to go in MPLS-TP else we cannot control/manage
resource deterministically between different clients...which is a key
requirement for any technology which aspires to be a transport network.
So PWs MUST revert back to some form of adaptation in MPLS-TP.  They for
sure must not continue their MS trajectory which we see in MPLS as-is
today, because this implies the creation of a PW layer network above
MPLS-TP...which would defeat the whole purpose for wanting to create a
transport network in MPLS-TP in the 1st place!

In MPLS-TP all clients are PWs and no clients are PWs....we simply have
clients of MPLS-TP LSPs.....just like any other transport network in
fact.

Now one of the reasons I suspect you are having a problem with all this
(which was confirmed in a different mail of yours) is the nature of the
S bit.  MPLS introduced the concept of a digital wrapper...we have never
done this in any other technology, and so it has DP properties that are
unique to MPLS.  The reason why it is important to be really clear what
the S bit means is because it is assumed that all nested LSPs reside
under the control/management of a single CP/MP entity....the wrapper
behaviour is simply the sublayering DP manifestation of this common
CP/MP assumption.  So when we add a new MPLS header to an existing MPLS
traffic unit we do not create a new layer network, but create a sublayer
(there is an associated illusion here that we can create 'server'
topology on-the-fly by doing this, which is actually not true).  So
whilst this is not a proper vertical client/server layering relationship
it is still a vertical DP sublayering relationship.  And most
importantly this is not the same as the arbitrary horizontal
partitioning of a single layer/sublayer DP entity that TCM
creates....which is what in in Y.1731.

MPLS does sublayering 'TCM for free'....it always did, and it has no
artifical horizonatal partitioning limits like Y.1731 has (ie 8 levels).

Whether the S bit concept is useful in MPLS-TP (ie a transport network)
is a quite different question.  Speaking personally (ie not with my BT
hat on) I don't think we should have the S bit concept in MPLS-TP....at
least not in the sense that we can create an arbitary sublayer stack
depth (I'll not tackle it here, but this issue becomes really important
when we want to do MPLSoverMPLS as a proper client/server
relationship...and this will be a very important topic for MPLS-TP to
address if it is to be sucessful as a transport network).

I also don't think we should have a TTL field in MPLS-TP as it serves no
real purpose wrt loop-prevention (the CP/MP should verify that there are
no loops present before a LSP is placed, just like all other co-ps (or
co-cs) mode technologies).

However, I also recognise that the S bit and TTL are so fundamental to
the original design of MPLS they are likely to persist in MPLS-TP.
Which is OK *providing* we recognise/understand them for what they are
and don't try and use them in an inappropriate manner.

regards, Neil

>  Whene we come to

---

From: <[email-masked]>
Date: Fri, 14 Aug 2009 10:41:00 +0100

Thanks Sasha,

I agree....but to be technically accurate/complete we should also note
this:

-	in a co mode network (both co-ps and co-cs) which respect the
important information preserving requirements of a connection (ie single
source), then it is not necessary to identify the client that the server
layer connection is carrying *providing* it is always a single/same
client.  The parent connection carries the client semantic (held in the
CP/MP as knowledge) and it is not necessary to carry the client
information as a label in the connection's child traffic units.

-	if however we wish to carry multiple/different clients in the
*same* connection then we must introduce a PID label in the child
traffic unit headers carried by the parent connection, eg see GFP
adaptation that has such a PID function.

-	in cl-ps mode networks we do not have a parent connection entity
(by definition).  We must therefore always carry a PID label function in
all cl-ps mode traffic units...as indeed we find in IP and Ethernet.

Aside=> In MPLS LDP we lose source information due to having mp2p
merging constructs (PHP has the same consequence albeit on the last
hop).  Not a problem if the client is cl-ps, but a big problem if not.
So the PW label in MPLS is primarily there to recover lost source
information.

regards, Neil 

> From: Alexander Vainshtein [mailto:[email-masked]] 
> Sent: 14 August 2009 09:07
> To: Maarten Vissers
> Cc: [email-masked]; Harrison,N,Neil,DEY2 R; [email-masked]
> IMHO and FWIW the "Service Label" mentioned in the framework 
> document identifies the service instance and, by implication, 
> the client protocol stack carried over this service instance. 
> In other words, it is a "service demultiplexer" and, as such, 
> an exact equivalent (albeit under a different name) of the 
> "PW label" as defined in Figure 11 of RFC 3985. As such, the 
> construct defined in the framework draft is fully compatible 
> with the PW architecture.
> 
> And, of course, there is nothing common with the SDH path 
> signal label, where the service instance is identified by the 
> position of the path in question in the SDH hierarchy, and 
> the type of the client is encoded in the signal path label 
> using a predefined set of values.
> 
> From: [email-masked] [[email-masked]] On 
> Behalf Of Maarten Vissers [[email-masked]]
> observed......and
> MPLS-TP node

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 14 Aug 2009 15:22:11 +0200

Sasha,

Thanks for presenting your understanding of the text. 
The specific wording:
	"A label per network layer protocol payload type" 
has been the rationale for my understanding of this "service label". 
I.e. "payload type" and not "client instance" is being used.

I expect that the author of this text will clarify the intention of this
text.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: vrijdag 14 augustus 2009 10:07
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [mpls-tp] MIPs in MPLS-TP

Maarten,

IMHO and FWIW the "Service Label" mentioned in the framework document
identifies the service instance and, by implication, the client protocol
stack carried over this service instance. In other words, it is a "service
demultiplexer" and, as such, an exact equivalent (albeit under a different
name) of the "PW label" as defined in Figure 11 of RFC 3985. As such, the
construct defined in the framework draft is fully compatible with the PW
architecture.

And, of course, there is nothing common with the SDH path signal label,
where the service instance is identified by the position of the path in
question in the SDH hierarchy, and the type of the client is encoded in the
signal path label using a predefined set of values.

The framework draft should be probably reworded to preclude this type of
misunderstanding.

My 2c,
     Sasha
Maarten Vissers [[email-masked]]

Neil, Adrian,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 13 augustus 2009 17:35
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

Maarten,

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 14 Aug 2009 19:39:02 +0200

Ben,

A Transport Network contains a hierarchy of transport entities. The top
level transport entity in a Layer 1 or Layer 2 network is a transport entity
in a service/channel/lower order/VC layer network, which then can be carried
inside either a transport entity in a tunnel/path/higher order/VP layer
network, or in a transport entity in a section layer network.

Each of these three types of transport entities may support more then one
maintenance entity group level. If more then one maintenance entity group
level is instantiated depends on the need for it (e.g. multiple admin
domains, protection domains, testing).

The first thing we do when defining a transport network technology is to
identify these layer networks and give those meaningfull names.
The second thing we do is to give the transport entities within each layer a
meaningfull name.
The third thing we do is to identify the maximum number of maintenance
entity group levels that transport entities in each layer network have to
support, and then name those levels.
The forth thing we do is to define the identification method of transport
entities when carried in a server transport entity, and of maintenance
entity group levels.

A packet transport network deploying MPLS-TP technology also has those layer
networks. Unfortunately after more then a year of development, there is
still no meaningful name selected/agreed for those layer networks and their
transport entities. This omission is causing a lot of the understanding
problems.

It will be an enormous step forward if we can agree on the names for those
layer netowrks and if we can agree on the names for their transport
entities.

I have proposed to use MPLS-TP VC (MVC) resp. MPLS-TP VP (MVP) as names for
the service/channel layer resp. tunnel/path layer and use the MVC and MVP as
names for the transport entities in those layer networks.

If we would agree on those names, then we can define the label stack entry
headers that are used to identify those MVC and MVP transport entities and
MEG levels within those transport entities; e.g.

MVC transport entity has its top most MEG level identified by a PW label
stack entry header and any lower MEG level identified by a LSP label stack
entry header.

MVP transport entity has its top most MEG level identified by a LSP label
stack entry header and any lower MEG level identified also by a LSP label
stack entry header.

If you don't like the names MPLS-TP VC /MVC and MPLS-TP VP/MVP, but prefer
to continue to use the names "PW" and "LSP" as names for those two layer
netowrks, then you have to decide how to name the transport entities in
those two layer networks. You could choose "PW" as name for the transport
netity in the PW layer network and LSP as name for the transport entity in
the LSP layer network. In this case we should define that

PW transport entity has its top most MEG level identified by a PW label
stack entry header and any lower MEG level identified by a LSP label stack
entry header; i.e. the addition of one or more LSP label stack entry headers
doesn't change the type of transport entity.

LSP transport entity has its top most MEG level identified by a LSP label
stack entry header and any lower MEG level identified also by a LSP label
stack entry header.

But you may agree with me that the use of the term PW for the layer network
and its transport entity could confuse many people... as well as the use of
an LSP label stack entry header to identify a "PW" MEG level.

So it seems better to select names for the two layer networks and their
transport entities that are different from "PW" and "LSP"; only then it is
possible to separate the layer naming and transport entity naming from the
label stack entry naming.

In absence of better naming proposals, I suggest to accept MVC and MVP for
the moment as names for the two highest layer networks in MPLS-TP and as
names for their transport entities.

Network management then manages 
- MVC trails/sublayer trails and MVC network/subnetwork/link connections,
- MVP trails/sublayer trails and MVP network/subnetwork/link connections.

It is now also possible to specify how client layer signals are mapped into
an MVC signal, how MVC and other (e.g. EVC) layer network signals are
mapped/multiplexed into an MVP signal, how OAM is carried in a MVC
connection and how OAM is carried in a MVP connection. 

I have attached a couple of slides illustrating the MPLS-TP layer stack and
MPLS-TP Transport Module (MTM-n) frame format examples using the above
naming conventions.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 14 augustus 2009 3:10
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Maarten,

On 13/08/2009 15:36, "Maarten Vissers" <[email-masked]> wrote:

> Adrian,
> 
> Thanks for clarifying that you don't make the mapping between "LSP" 
> and "LSP layer transport entity/connection". This is very important 
> for me to understand. Transport networks care about their transport 
> entities, and manage those entities and their MEG levels.
> 
> in a MPLS-TP layer network, I am wondering if the term "PW" should 
> also not be used to represent a "transport entity" in a MPLS-TP layer
network?
> - "transport entity/connection" that may carry one or more of the 
> previous transport entities?
> 
> E.g.
> - the second transport entity may be referred to as a "MPLS-TP Virtual 
> Path (MVP)".
> 
> The top MEG level within a MVC is identified by a "PW label", and each 
> lower MEG level within a MVC is identified by a "LSP label".
> The top MEG level within a MVP is identified by a "LSP label", and 
> each lower MEG level within a MVP is identified by another "LSP label".
> 
> On the physical media (e.g. fiber) an MVC contains one PW label and 
> zero or more LSP labels, while an MVP contains one or more LSP labels.
> 
> 
> The creation of an additional MEG level and consequential activation 
> of the MEG level's MEP functions in either a MVC, or MVP will prevent 
> that the outer MEG level has access to the MIP functions within the new
MEG segment.
> I find it quite hard when you disagree with me over something I have 
> not said!
> 
> I define "LSP" based on the label switching properties associated with 
> the topmost label on the stack. If you push a new label, you are 
> creating a new LSP. This is "obvious" by looking at the LFIB at a transit
node.
>> MPLS-TP node that supports only one MIP, or that is configured  to 
>> not have an active MIP for a given LSP.
>> 
nodes?

---

From: <[email-masked]>
Date: Fri, 14 Aug 2009 22:20:10 +0100

Maarten,

I think the issues you are having maybe related to the fact that ITU-T tends
to have well defined, rigid terminology whereas terminology in IETF can be
more fluid where the context a term is used in is sometimes needed to
understand the correct meaning of the term.

The complete LSP label stack describes the transport entity but the term LSP
can be used to refer to the transport entity itself or to a specific
sublayer (e.g. MEG level) in the transport entity. The terminology used in
the MPLS-TP requirements draft for a transport entity is MPLS-TP transport
path.

The same confusion does not arise with PWs IMO as PWs do not contain
sublayers, therefore PW always refers to the transport entity.

The rosetta stone draft is the place to define any mapping between terms
from the two organisations.

Regarding a specific name for the "LSP" transport entity my personal
preference is "MPLS-TP transport path" as that is the terminology used in
the MPLS-TP requirements document. I don't see any need to create a new name
for a PW as I don't see anyone becoming confused by that term.

Ben

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 14 Aug 2009 15:14:39 -0700

The section containing the quoted text is specifically dealing with the
case where there is no pseudo-wire.  I.e., the network layer payload is
carried directly over the MPLS TP server network.  

> Sent: Friday, August 14, 2009 1:07 AM
> To: Maarten Vissers
> Cc: [email-masked]
> If I understand this piece of text, then in MPLS-TP we get a 
> full functional "payload type" function (encoded in the new 
> "service label"); i.e. similar to signal label in SDH VC-n 
> and payload type in OTN OPUk. The 20-bit label field would 
> then be carrying a payload/protocol type, which identifies 
> uniquely the client layer network signal type (e.g. ATM VC, 
> ATM VP, TDM 2 Mbit/s, TDM 34 Mbit/s, Ethernet VLAN, ...) 
> being carried in the MPLS-TP payload area. When two or more 
> different client layer signal types are carried in one 
> MPLS-TP Virtual Channel (MVC, see response to Adrian's email 
> today), then one MVC will contain packets with different 
> service label values (e.g. packets with service label 
> identifying an Etherent VLAN and others with a service label 
> identifying an ATM VC).
> 
> As the bottom-of-stack label (with S=1) is now a 'service 
> label', MPLS-TP can not longer support the "PW" or "MS-PW"...
> 
> The text is not clear if the MPLS-TP tunnel/path layer 
> transport entities/connections will also comply with this 
> Network Layer Transport Service Protocol Stack specification; 
> i.e. will a MPLS-TP Virtual Path (MVP) encapsulate its MVC 
> client signals using a "service label" that will have the value "MVC"?
> 
> 
> 
> This sentence and the next part of the text seems to be 
> contradicting the REQUIREMENT described around figure 5; e.g. 
> there can't be any "PWs" in a MPLS-TP network.
> 
> Regards,
> Maarten
> 
> 
> 
> The reason I feel it necessary to keep pointing this out is 
> because I am aware of the confusion it is causing some 
> folks...I know this from private conversations.  And to be 
> super clear here are the important bits explained
> again:
>

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 14 Aug 2009 15:15:52 -0700

The section containing the quoted text refers to RFC3032.  Perhaps you
should study the reference. 

> Sent: Friday, August 14, 2009 6:22 AM
> To: 'Alexander Vainshtein'
> Cc: [email-masked]
> I expect that the author of this text will clarify the 
> intention of this text.
> 
> Regards,
> Maarten
> 
> an exact equivalent (albeit under a different
> name) of the "PW label" as defined in Figure 11 of RFC 3985. 
> As such, the construct defined in the framework draft is 
> fully compatible with the PW architecture.
>

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 14 Aug 2009 15:30:09 -0700

Snipped 
> identifying an Etherent VLAN and others with a service label 

JD:  None of the above qualify as network layer payloads as defined in
RFC3032, so they would actually need to carried within pseudo-wires.

> label', MPLS-TP can not longer support the "PW" or "MS-PW"...

JD:  That's incorrect.  The PW payload will start with an client MPLS
label stack.

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 15 Aug 2009 12:03:09 +0200

Ben,

What I refer to as MVC transport entity (or MVC connection) is the thing
that carries a client signal, e.g. a TDM signal from UNI-N to UNI-N. If such
MVC carrying TDM signal is getting a PW label stack entry header, then the
MVC MEG between the UNI-N ports is being monitored by the PW OAM. Any admin
domain specific MVC segment monitoring will cause the addition of an LSP
label stack entry header plus LSP OAM (to provide the MVC segment MEG OAM)
to the original MVC frame. But due to the 1:1 relationship it is still an
MVC transport entity, now with two active MEG levels. The adding of a label
stack entry header which is referred to as a LSP label stack entry header
and LSP OAM does not create a new Layer Network below the PW.

--------

Can it be done differently? I believe so... I.e. it would be theoretically
possible to specify that there exists a PW layer network with a single MEG
level. This PW MEG is supported by PW OAM. If the PW transport entity is
always supported by a dedicated LSP transport entity between the UNI-N
ports, then there is no need to monitor the PW transport entity itself and
this PW layer network shrinks and becomes just an adaptation function
between LSP and client.

For such case, the MVC layer network would consists of MVC signals that have
one or more LSP label stack entry headers and one or more LSP OAM sets. The
MVP layer network would consists of MVP signals that have one or more LSP
label stack entry headers and one or more LSP OAM sets. I assume that this
would make Neil happy.

----------

> specific name for the "LSP" transport entity my personal preference is
"MPLS-TP transport path"

Do you believe that people (including yourself) will be talking about
"MPLS-TP transport path connection"? I don't... It is much too long to be
used...

Furthermore, there is not just one "MPLS-TP transport path connection"
level, there are at least two:
1) a service/channel (or Lower Order, or VC) layer "MPLS-TP transport path"
and
2) a tunnel/path (or Higher Order, or VP) layer "MPLS-TP transport path".
This would extend the connection naming to "service MPLS-TP transport path
connection" and "tunnel MPLS-TP transport path connection".... Such names
will most likely result in the use of "PW" and "LSP" to identify these two
layer network transport entities, with all the confusion around it because
of the use of LSP label stack entry headers to create PW segments and LSP
segments.

MVC and MVP are short names, which are easy to use and which allow us to
decouple the label stack entry header names from the transport entity and
layer network names.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 14 augustus 2009 23:20
To: [email-masked]
Cc: [email-masked]
Subject: Re: naming of mpls-tp layers and transport entities [was: RE:
[mpls-tp] MIPs in MPLS-TP]

Maarten,

Ben

On 14/08/2009 18:39, "Maarten Vissers" <[email-masked]> wrote:

> Ben,
>
> A Transport Network contains a hierarchy of transport entities. The 
> top level transport entity in a Layer 1 or Layer 2 network is a 
> transport entity in a service/channel/lower order/VC layer network, 
> which then can be carried inside either a transport entity in a 
> tunnel/path/higher order/VP layer network, or in a transport entity in a
section layer network.
>
> Each of these three types of transport entities may support more then 
> one maintenance entity group level. If more then one maintenance 
> entity group level is instantiated depends on the need for it (e.g. 
> multiple admin domains, protection domains, testing).
>
> The first thing we do when defining a transport network technology is 
> to identify these layer networks and give those meaningfull names.
> The second thing we do is to give the transport entities within each 
> layer a meaningfull name.
> entity group levels that transport entities in each layer network have 
> to support, and then name those levels.
> The forth thing we do is to define the identification method of 
> transport entities when carried in a server transport entity, and of 
> maintenance entity group levels.
>
> A packet transport network deploying MPLS-TP technology also has those 
> layer networks. Unfortunately after more then a year of development, 
> there is still no meaningful name selected/agreed for those layer 
> networks and their transport entities. This omission is causing a lot 
> of the understanding problems.
>
> It will be an enormous step forward if we can agree on the names for 
> those layer netowrks and if we can agree on the names for their 
> transport entities.
>
> I have proposed to use MPLS-TP VC (MVC) resp. MPLS-TP VP (MVP) as 
> names for the service/channel layer resp. tunnel/path layer and use 
> the MVC and MVP as names for the transport entities in those layer
networks.
>
> If we would agree on those names, then we can define the label stack 
> entry headers that are used to identify those MVC and MVP transport 
> entities and MEG levels within those transport entities; e.g.
>
> MVC transport entity has its top most MEG level identified by a PW 
> label stack entry header and any lower MEG level identified by a LSP 
> label stack entry header.
>
> MVP transport entity has its top most MEG level identified by a LSP 
> label stack entry header and any lower MEG level identified also by a 
> LSP label stack entry header.
>
> If you don't like the names MPLS-TP VC /MVC and MPLS-TP VP/MVP, but 
> prefer to continue to use the names "PW" and "LSP" as names for those 
> two layer netowrks, then you have to decide how to name the transport 
> entities in those two layer networks. You could choose "PW" as name 
> for the transport netity in the PW layer network and LSP as name for 
> the transport entity in the LSP layer network. In this case we should 
> define that
>
> PW transport entity has its top most MEG level identified by a PW 
> label stack entry header and any lower MEG level identified by a LSP 
> label stack entry header; i.e. the addition of one or more LSP label 
> stack entry headers doesn't change the type of transport entity.
>
> LSP transport entity has its top most MEG level identified by a LSP 
> label stack entry header and any lower MEG level identified also by a 
> LSP label stack entry header.
>
> But you may agree with me that the use of the term PW for the layer 
> network and its transport entity could confuse many people... as well 
> as the use of an LSP label stack entry header to identify a "PW" MEG
level.
>
> So it seems better to select names for the two layer networks and 
> their transport entities that are different from "PW" and "LSP"; only 
> then it is possible to separate the layer naming and transport entity 
> naming from the label stack entry naming.
>
> In absence of better naming proposals, I suggest to accept MVC and MVP 
> for the moment as names for the two highest layer networks in MPLS-TP 
> and as names for their transport entities.
>
> It is now also possible to specify how client layer signals are mapped 
> into an MVC signal, how MVC and other (e.g. EVC) layer network signals 
> are mapped/multiplexed into an MVP signal, how OAM is carried in a MVC 
> I have attached a couple of slides illustrating the MPLS-TP layer 
> stack and MPLS-TP Transport Module (MTM-n) frame format examples using 
> the above naming conventions.
>
> Regards,
> Maarten
>
>
>
> An LSP can be  transport entity but due to sublayering pushing a new 
> label on the stack may create a new LSP but not a new transport entity.
>
> PWs are different. PWs do not contain sublayers, i.e there are not 
> multiple labels in a single PW. Ben
>
>
>
>> - the second transport entity may be referred to as a "MPLS-TP 
>> Virtual Path (MVP)".
>>
>> The top MEG level within a MVC is identified by a "PW label", and 
>> each lower MEG level within a MVC is identified by a "LSP label".
>>>> prevents the client MEG level to have any OAM visibility inside 
>>>> this additional MEG level.
>>>
>>> Bad choice of words :-)
>> I define "LSP" based on the label switching properties associated 
>> with the topmost label on the stack. If you push a new label, you are

---

From: "tom.petch" <[email-masked]>
Date: Mon, 17 Aug 2009 09:43:03 +0200

---- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 14, 2009 11:20 PM

> understand the correct meaning of the term.

Moreover, I think that terminology reflects underlying concepts, that ITU-T
tends to have a more formal set of concepts, of model, layers, architecture,
functional decomposition and so on, whereas IETF is more pragmatic - if the
protocol does the job, who cares what is a layer, sublayer, ....?  This last
approach is often quicker but sometimes the lack of formality comes back to
haunt us when
enhancements are required.  Thus, MPLS is a very successful protocol but seeking
to enhance it, as we are now, show up places where it might have been better to
have done it differently.

Here, if a protocol can be developed that meets users' needs for OAM, who cares
if there are MIPs, MEPs, MEGs etc?  Mmmmmm .  At the moment, I don't see the
need for this 'architecture' but perhaps, in five years time, I would regret its
absence.

Tom Petch

> On 14/08/2009 18:39, "Maarten Vissers" <[email-masked]> wrote:
<snip>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 17 Aug 2009 14:15:30 +0200

Tom,

MPLS-TP will be one of the technologies in the packet transport network.
Other technologies are Ethernet and OTN.  Ethernet and OTN technologies are
already specified in ITU-T following the well known more formal set of
concepts, of model, layers, architecture, functional decomposition, atomic
functions and so on, which support that the trnasport networks build with
those technologies can be managed according to the SDH management paradigm.

As one of the requirements for MPLS-TP is that MPLS-TP networks or MPLS-TP
parts of the packet transport network must be manageable according the SDH
management paradigm, it will be necessary to describe MPLS-TP in the well
known more formal set of concepts, of model, layers, architecture,
functional decomposition, atomic functions and so on. Such MPLS-TP
description can be in parallel to the less formal IETF description, but it
can not be omitted.

As lots of work has been done since 2004 on the translation of MPLS concepts
and specifications into ITU-T language, it should not be too difficult to
develop an ITU-T based description of MPLS-TP. Each organisation may then
decide which of the two descriptions they will use (or if both are used).
Such dual approach allows e.g. you to use the pragmatic approach today,
knowing that at any moment in time you can switch to the more formal
approach. 

By developing the more formal approach in parallel in ITU-T, we will have
the opportunity to discover issues at an early stage. I.e. we will have a
win-win situation.

Regards,
Maarten

-----Original Message-----
From: tom.petch [mailto:[email-masked]] 
Sent: maandag 17 augustus 2009 9:43
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] naming of mpls-tp layers and transport entities [was:
RE: MIPs in MPLS-TP]

---- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 14, 2009 11:20 PM

> Maarten,
>
> I think the issues you are having maybe related to the fact that ITU-T 
> tends to have well defined, rigid terminology whereas terminology in 
> IETF can be more fluid where the context a term is used in is 
> sometimes needed to understand the correct meaning of the term.

Moreover, I think that terminology reflects underlying concepts, that ITU-T
tends to have a more formal set of concepts, of model, layers, architecture,
functional decomposition and so on, whereas IETF is more pragmatic - if the
protocol does the job, who cares what is a layer, sublayer, ....?  This last
approach is often quicker but sometimes the lack of formality comes back to
haunt us when enhancements are required.  Thus, MPLS is a very successful
protocol but seeking to enhance it, as we are now, show up places where it
might have been better to have done it differently.

Here, if a protocol can be developed that meets users' needs for OAM, who
cares if there are MIPs, MEPs, MEGs etc?  Mmmmmm .  At the moment, I don't
see the need for this 'architecture' but perhaps, in five years time, I
would regret its absence.

Tom Petch

> The complete LSP label stack describes the transport entity but the 
> term LSP can be used to refer to the transport entity itself or to a 
> specific sublayer (e.g. MEG level) in the transport entity. The 
> terminology used in the MPLS-TP requirements draft for a transport 
> entity is MPLS-TP transport path.
>
> The rosetta stone draft is the place to define any mapping between 
> terms from the two organisations.
>
> preference is "MPLS-TP transport path" as that is the terminology used 
> in the MPLS-TP requirements document. I don't see any need to create a 
> new name for a PW as I don't see anyone becoming confused by that term.
>
> Ben
>
<snip>

---

From: <[email-masked]>
Date: Tue, 18 Aug 2009 00:13:45 +0100

Tom,

The value of the 'formal architecture' is that it allows an operator to
model the network in a consistent way within its operational support systems
including interfacing to network equipment from multiple vendors in a
consistent fashion, e.g. Using MTOSI interfaces defined by TMF based on
formal network models provided by ITU-T. I believe some equipment
manufacturers also derive value from formal equipment specification models
defined by ITU-T but as I don't build equipment I can't comment on that.

Maarten,

IMO the purpose is to be able to manage a transport network using a broadly
common management paradigm, there is no requirement for that paradigm to be
completely aligned with the SDH paradigm and in fact I have seen instances
where forcing a packet network into being modelled using the SDH paradigm
has caused deployment and operational issues.

At the end of the day I understand the desire for consistent terminology to
provide clarity and avoid ambiguity. What you are asking for I believe is
for guidance and agreement on specific terminology to avoid such
possibilities for ambiguity, especially for those individuals whose
background is more circuit-switched than packet switched. That's a
reasonable request but is a task for the groups (IETF & ITU) to define and
reach consensus on the appropriate terminology to be used within the group,
I've already provided my personal view.

Personally having worked with packet networks for several years I don't have
an issue with a single term (e.g. LSP) being used to mean different things
depending on its context.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 18 Aug 2009 16:52:34 +0200

Ben,

See inline... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 18 augustus 2009 1:14
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] naming of mpls-tp layers and transport entities [was:
RE: MIPs in MPLS-TP]

Tom,

Maarten,

[mv] Can you give an example of such issue? It would be helpful to
understand up to what point it is helpful and when not longer.

At the end of the day I understand the desire for consistent terminology to
provide clarity and avoid ambiguity. 

[mv] Yes.

What you are asking for I believe is for guidance and agreement on specific
terminology to avoid such possibilities for ambiguity, especially for those
individuals whose background is more circuit-switched than packet switched. 

[mv] I want to avoid possibilities for ambiguity for all individuals (both
for circuit- and packet-switched backgrounds). For the circuit-switched
experts to understand if there is a large degree of commonality with the
long existing circuit-switched networks and for the packet-switched experts
to understand the specific constructs of a transport network.

That's a reasonable request but is a task for the groups (IETF & ITU) to
define and reach consensus on the appropriate terminology to be used within
the group, I've already provided my personal view.

[mv] It are indeed the SDOs that have to agree, and this implies that their
participants (including you and me) have to come up with proposals.

[mv] I only have a problem if it is causing or would cause confusion. At
this point in time I fear confusion to exist when an LSP labels tack entry
header is used to mark a MVC (PW) segment, so we better should introduce
specific layer network naming that is independent of PW and LSP terminology.

Regards,
Maarten

Ben

On 17/08/2009 13:15, "Maarten Vissers" <[email-masked]> wrote:

> Other technologies are Ethernet and OTN.  Ethernet and OTN 
> technologies are already specified in ITU-T following the well known 
> more formal set of concepts, of model, layers, architecture, 
> functional decomposition, atomic functions and so on, which support 
> that the trnasport networks build with those technologies can be managed
according to the SDH management paradigm.
> 
> As one of the requirements for MPLS-TP is that MPLS-TP networks or 
> MPLS-TP parts of the packet transport network must be manageable 
> according the SDH management paradigm, it will be necessary to 
> describe MPLS-TP in the well known more formal set of concepts, of 
> model, layers, architecture, functional decomposition, atomic 
> functions and so on. Such MPLS-TP description can be in parallel to 
> the less formal IETF description, but it can not be omitted.
> 
> As lots of work has been done since 2004 on the translation of MPLS 
> concepts and specifications into ITU-T language, it should not be too 
> difficult to develop an ITU-T based description of MPLS-TP. Each 
> organisation may then decide which of the two descriptions they will use
(or if both are used).
> Such dual approach allows e.g. you to use the pragmatic approach 
> today, knowing that at any moment in time you can switch to the more 
> formal approach.
> 
> By developing the more formal approach in parallel in ITU-T, we will 
> have the opportunity to discover issues at an early stage. I.e. we 
> will have a win-win situation.
> 
> Regards,
> Maarten
> 
> 
>> I think the issues you are having maybe related to the fact that 
>> ITU-T tends to have well defined, rigid terminology whereas 
>> terminology in IETF can be more fluid where the context a term is 
>> used in is sometimes needed to understand the correct meaning of the
term.
> 
> Moreover, I think that terminology reflects underlying concepts, that 
> ITU-T tends to have a more formal set of concepts, of model, layers, 
> architecture, functional decomposition and so on, whereas IETF is more 
> pragmatic - if the protocol does the job, who cares what is a layer, 
> sublayer, ....?  This last approach is often quicker but sometimes the 
> lack of formality comes back to haunt us when enhancements are 
> required.  Thus, MPLS is a very successful protocol but seeking to 
> enhance it, as we are now, show up places where it might have been better
to have done it differently.
> 
> Here, if a protocol can be developed that meets users' needs for OAM, 
> who cares if there are MIPs, MEPs, MEGs etc?  Mmmmmm .  At the moment, 
> I don't see the need for this 'architecture' but perhaps, in five 
> years time, I would regret its absence.
> 
> Tom Petch
> 
>> preference is "MPLS-TP transport path" as that is the terminology 
>> used in the MPLS-TP requirements document. I don't see any need to 
>> create a new name for a PW as I don't see anyone becoming confused by
that term.