Subject: Re: [mpls-tp] MEG - who, what and how

From: "Shahram Davari" <[email-masked]>
Date: Wed, 15 Jul 2009 06:46:39 -0700

I think using the same terms differently will cause more confusion 

Shahram

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Wed Jul 15 02:04:16 2009
Subject: Re: [mpls-tp] MEG - who, what and how

Let me provide a mapping between the different definitions of ME in ITU-T G.8010/Y.1731/G.8110-1 and IETF MPLS-TP Framework:
 
G.8010              
Y.1731            MPLS-TP FRMWRK
G.8110.1
-------------------------------------------------------
    MEG                     ME
     ME               <no term available>
 
I expect that the redefinition of the term Maintenance Entity (ME) in the MPLS-TP framework document will cause confusion in the MPLS-TP work. In our discussion we will have to state every time we us ME if this term is used in the ITU-T or IETF definition.
 
Regards,
Maarten

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: dinsdag 14 juli 2009 9:18
To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'ext Shahram Davari'; 'Rolf Winter'; [email-masked]
Subject: Re: [mpls-tp] MEG - who, what and how

Nurit,
 
See inline..

________________________________

From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: maandag 13 juli 2009 20:07
To: ext Maarten Vissers; ext Shahram Davari; Rolf Winter; [email-masked]
Subject: RE: [mpls-tp] MEG - who, what and how

Maaretn,

Thanks for your response.

Please see inline.

Best regards,

Nurit

-----Original Message-----
From: ext Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, July 13, 2009 3:43 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'ext Shahram Davari'; 'Rolf Winter'; [email-masked]
Subject: RE: [mpls-tp] MEG - who, what and how

Nurit,

Divide and rule is applicable when we have many cases to consider...

The most extensive case is the n-port "mp2mp transport entity". This

transport entity contains n*(n-1) p2p maintenance entities (MEs), which form

together one maintenance entity group (MEG). 

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Please note that in MPLS-TP we do not have n-port "mp2mp transport entity". A transport path can be p2p or ptmp. The services that are delivered over the MPLS transport network, ca be multipoint services. 

[mv]  In a PTN we have mp2mp transport entities and p2p transport entities and p2mp transport entities and rmp transport entities and in some PTN technologies also mp2p transport entities. MPLS-TP p2p transport entities and MPLS-TP p2mp transport entities are as such just a small subset of the total set of transport entitities in a PTN. MPLS-TP is one of the multiple technologies that may be present in a PTN.

When n=2, the bidirectional "mp2mp transport entity" becomes a bidirectional

"p2p transport entity" with one MEG and  2*(2-1) = 2 MEs. 

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] maybe it is unidirectional p2p transport path? This is clearly one of the transport paths supported by MPLS-TP, as well as associated p2p transport paths, etc. 

[mv] the term "transport path" in MPLS-TP represents a "transport entity" in a MPLS-TP transport path layer network. MPLS-TP transport path layer networks seems to be the MPLS-TP LSP and the MPLS-TP MS-PW layer networks. We will figure out the details when we deploy MPLS-TP technology in the PTN and develop the functional models.

[mv] A "bidirectional p2p transport entity" in one of the MPLS-TP transport path layer networks is **not** a "unidirectional p2p transport path". 

[mv] A "bidirectional p2p transport entity" in one of the MPLS-TP transport path layer networks is a co-routed or associated "bidirectional p2p transport path".

Only when there is a 2-port *unidirectional* p2p transport entity, there is

one MEG and one ME.

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] according to the ITU-T definition. Clearly in MPLS-TP we support more types of transport paths……how can we differentiate between unidirectional p2p transport path and co-routed bi-directional transport paths, etc? 

[mv] A transport path is a transport entity in one of the MPLS-TP layer networks. What applies for transport entities applies as such for an example of such transport entities (i.e. the transport path). A unidirectional p2p transport path contains one MEG and one ME. A co-routed bidirectional p2p transport path contains one MEG and two MEs. An associated bidirectional p2p transport path contains one MEG and two MEs. A unidirectional n-port p2mp transport path contains one MEG and n-1 MEs.

A n-port p2mp unidirectional transport entity contanins one MEG and n*(n-1)

MEs. 

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Well, in MPLS-TP we are talking about the transport paths that can be p2mp or p2p. There is no definition of n-port p2mp transport entity in MPLS-TP.  

[mv] As described above, a transport path is a transport entity in one of the MPLS-TP transport path layer networks. By definition a p2mp transport path is as such a p2mp transport entity. 

As MPLS-TP will support more then just the 2-port p2p unidirectional

transport entity, it is necessary to use both MEG and ME terms in MPLS-TP

OAM and accept that in one of the cases one MEG will just contain one ME; in

all other cases one MEG will contain more then one ME.

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Well I think we can clearly indicate what type of ME we support. 

[mv] There is only one type of ME as a ME is defined between one MEP source and one MEP sink function. 

[mv] The different transport entitities in MPLS-TP transport path layer networks and section layer networks have different types of MEG.

Regards,

Maarten  

Regards,

Maarten

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

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

Of Sprecher, Nurit (NSN - IL/Hod HaSharon)

Sent: zondag 12 juli 2009 9:51

To: ext Shahram Davari; Rolf Winter; [email-masked]

Subject: Re: [mpls-tp] MEG - who, what and how

Hi,

I have the feeling that we have two many entities.....

For a point-to-point, we have one ME although we would like to monitor and

hold information per direction.

Having the same logic, we can have a p2mp ME, and hold the information per

leaf. The framework already defines that a ME may include two or more MEPs,

etc. 

Best regards,

Nurit

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

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

Of ext Shahram Davari

Sent: Friday, July 10, 2009 8:02 PM

To: Rolf Winter; [email-masked]

Subject: Re: [mpls-tp] MEG - who, what and how

Rolf,

Here is the definition of MEG from where it was originated, which is ITU-T

Y.1731:

5.2 ME Group (MEG)

ME Group (MEG) includes different MEs that satisfy the following

conditions:

* MEs in a MEG exist in the same administrative boundary; and

* MEs in a MEG have the same MEG Level (see sub-clause 5.6), and

* MEs in a MEG belong to the same point-to-point ETH connection or

multipoint ETH connectivity.

For a point-to-point ETH connection, a MEG contains a single ME. For a

multipoint ETH connectivity containing n end-points, a MEG contains

n*(n-1)/2 MEs.

For MPLS-TP, replace ETH with MPLS-TP and Multipoint with P2MP.

Regards,

Shahram

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

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

Of Rolf Winter

Sent: Friday, July 10, 2009 8:00 AM

To: [email-masked]

Subject: [mpls-tp] MEG - who, what and how

Hi,

A bunch of drafts are including the Maintenance Entity Group (MEG) term and

concept (mostly only as term), sometimes as an open issue, other times as a

big question mark. It creeps up once talking about the P2MP case which often

is rather underrepresented in most drafts - hence the MEG confusion maybe.

The question is, does one need this concept at all for MPLS-TP? If it is

needed how is it implemented specifically, i.e.

would it be a collection of Maintenance Entities that are "somehow"

associated for the sake of OAM. Would a multicast ME be the right approach

assuming the P2MP is the only use case for such a concept? To some degree

this is a terminology question, but also a functionality question. Since

this seem to be at least considered by a number of drafts I would like to

pose the following three part question to the

list:

- What is the functionality needed here, how is it supposed to operate/being

implemented and how should we call it in order for people to better

understand what its purpose really is?

Best,

      Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London

W3 6BL | Registered in England 2832014 

_______________________________________________

mpls-tp mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________

mpls-tp mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________

mpls-tp mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 15 Jul 2009 16:15:54 +0200

Hi,

I would like to close the discussion on this as this might stall the work of a number of people. Based on the discussion we had I think we're converging but I would like to spill it out and ask whether this receives a broad consensus or not in order to move forward:

A) The OAM framework drafts needs some re-writing in order to align the terminology closer to what has been defined in the ITU-T mainly for two reasons:

  1) to not confuse people
  2) based on the requirements that Neil has mentioned in an earlier Email which rather fits to the MEG concept of the ITU-T

The (main) changes I see right now are to align ME (e.g. restrict it to 2 MEPs) and include the MEG.

B) There is a draft out there (and I personally believe it is an important one) that describes OAM based on Y.1731. I fear that other (other than the ITU-T) elements and definitions might cause problems for this work in terms of confusion but also in terms of functionality if we are not careful

C) I think the OAM elements the ITU-T has defined are versatile enough to not preclude any solution at this point which I believe is also in important criterion for a framework. 

Please voice your opinion both positive and negative so that we can hopefully move forward. 

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Shahram Davari
> Sent: Mittwoch, 15. Juli 2009 15:47
> To: [email-masked]'; [email-masked]'
> Let me provide a mapping between the different definitions of ME in
> ITU-T G.8010/Y.1731/G.8110-1 and IETF MPLS-TP Framework:
> 
> G.8010
> Y.1731            MPLS-TP FRMWRK
> G.8110.1
> I expect that the redefinition of the term Maintenance Entity (ME) in
> the MPLS-TP framework document will cause confusion in the MPLS-TP work.
> In our discussion we will have to state every time we us ME if this
> term is used in the ITU-T or IETF definition.
> 
> Regards,
> Maarten
> 
> [Sprecher, Nurit (NSN - IL/Hod HaSharon)] Please note that in MPLS-TP
> we do not have n-port "mp2mp transport entity". A transport path can be
> p2p or ptmp. The services that are delivered over the MPLS transport
> network, ca be multipoint services.
> 
> 
> 
> [mv]  In a PTN we have mp2mp transport entities and p2p transport
> entities and p2mp transport entities and rmp transport entities and in
> some PTN technologies also mp2p transport entities. MPLS-TP p2p
> transport entities and MPLS-TP p2mp transport entities are as such just
> a small subset of the total set of transport entitities in a PTN. MPLS-
> TP is one of the multiple technologies that may be present in a PTN.
> 
> 
> 
> [Sprecher, Nurit (NSN - IL/Hod HaSharon)] maybe it is unidirectional
> p2p transport path? This is clearly one of the transport paths
> supported by MPLS-TP, as well as associated p2p transport paths, etc.
> 
> 
> 
> [mv] the term "transport path" in MPLS-TP represents a "transport
> entity" in a MPLS-TP transport path layer network. MPLS-TP transport
> path layer networks seems to be the MPLS-TP LSP and the MPLS-TP MS-PW
> layer networks. We will figure out the details when we deploy MPLS-TP
> technology in the PTN and develop the functional models.
> 
> 
> 
> [mv] A "bidirectional p2p transport entity" in one of the MPLS-TP
> transport path layer networks is **not** a "unidirectional p2p
> transport path".
> 
> 
> 
> [mv] A "bidirectional p2p transport entity" in one of the MPLS-TP
> transport path layer networks is a co-routed or associated
> "bidirectional p2p transport path".
> 
> 
> 
> [Sprecher, Nurit (NSN - IL/Hod HaSharon)] according to the ITU-T
> definition. Clearly in MPLS-TP we support more types of transport
> paths……how can we differentiate between unidirectional p2p transport
> path and co-routed bi-directional transport paths, etc?
> 
> 
> 
> [mv] A transport path is a transport entity in one of the MPLS-TP layer
> networks. What applies for transport entities applies as such for an
> example of such transport entities (i.e. the transport path). A
> unidirectional p2p transport path contains one MEG and one ME. A co-
> routed bidirectional p2p transport path contains one MEG and two MEs.
> An associated bidirectional p2p transport path contains one MEG and two
> MEs. A unidirectional n-port p2mp transport path contains one MEG and
> n-1 MEs.
> 
> 
> 
> [Sprecher, Nurit (NSN - IL/Hod HaSharon)] Well, in MPLS-TP we are
> talking about the transport paths that can be p2mp or p2p. There is no
> definition of n-port p2mp transport entity in MPLS-TP.
> 
> 
> 
> [mv] As described above, a transport path is a transport entity in one
> of the MPLS-TP transport path layer networks. By definition a p2mp
> transport path is as such a p2mp transport entity.
> 
> 
> 
> [mv] The different transport entitities in MPLS-TP transport path layer
> networks and section layer networks have different types of MEG.
> 
> 
> 
> Regards,
> 
> Maarten
> 
> 
> 
> Regards,
> 
> Maarten
> 
> 
> 
> 
>

---

From: hejia 48726 <[email-masked]>
Date: Wed, 15 Jul 2009 22:45:36 +0800

Agree.

Jia

----- Original Message -----
From: Rolf Winter <[email-masked]>
Date: Wednesday, July 15, 2009 10:17 pm
Subject: Re: [mpls-tp] MEG - who, what and how
To: Shahram Davari <[email-masked]>, [email-masked], [email-masked]

> Hi,
> 
> I would like to close the discussion on this as this might stall 
> the work of a number of people. Based on the discussion we had I 
> think we're converging but I would like to spill it out and ask 
> whether this receives a broad consensus or not in order to move 
> forward:
> A) The OAM framework drafts needs some re-writing in order to 
> align the terminology closer to what has been defined in the ITU-T 
> mainly for two reasons:
> 
>  1) to not confuse people
>  2) based on the requirements that Neil has mentioned in an 
> earlier Email which rather fits to the MEG concept of the ITU-T
> 
> B) There is a draft out there (and I personally believe it is an 
> important one) that describes OAM based on Y.1731. I fear that 
> other (other than the ITU-T) elements and definitions might cause 
> problems for this work in terms of confusion but also in terms of 
> functionality if we are not careful
> 
> C) I think the OAM elements the ITU-T has defined are versatile 
> enough to not preclude any solution at this point which I believe 
> is also in important criterion for a framework. 
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
> 
> 
> > Behalf Of Maarten Vissers
> > transport entity contains n*(n-1) p2p maintenance entities 
> (MEs), which
> > form
> > 
> > supported by MPLS-TP, as well as associated p2p transport paths, 
> etc.> 
> > 
> > 
> > routed bidirectional p2p transport path contains one MEG and two 
> MEs.> An associated bidirectional p2p transport path contains one 
> MEG and two
> > transport entity, it is necessary to use both MEG and ME terms 
> in MPLS-
> > TP
> > 
> > OAM and accept that in one of the cases one MEG will just 
> contain one
> > ME; in
> > 
> > [Sprecher, Nurit (NSN - IL/Hod HaSharon)] Well I think we can 
> clearly> indicate what type of ME we support.
> > 
> > 
> > 
> > Behalf
> > For a point-to-point, we have one ME although we would like to 
> monitor> and
> > 
> > Having the same logic, we can have a p2mp ME, and hold the 
> information> per
> > 
> > leaf. The framework already defines that a ME may include two or 
> more> MEPs,
> > 
> > etc.
> > 
> > Best regards,
> > 
> > Nurit
> > 
> > 
> > 
> > Behalf
> > Here is the definition of MEG from where it was originated, 
> which is
> > ITU-T
> > 
> > Y.1731:
> > 
> > 
> > 
> > 5.2 ME Group (MEG)
> > 
> > Behalf
> > A bunch of drafts are including the Maintenance Entity Group 
> (MEG) term
> > and
> > 
> > concept (mostly only as term), sometimes as an open issue, other 
> times> as a
> > 
> > big question mark. It creeps up once talking about the P2MP case 
> which> often
> > 
> > The question is, does one need this concept at all for MPLS-TP? 
> If it
> > is
> > 
> > this seem to be at least considered by a number of drafts I 
> would like
> > to
> >

---

From: Dieter Beller <[email-masked]>
Date: Wed, 15 Jul 2009 16:56:41 +0200

Rolf and all,

I agree moving forward as proposed.

Rolf Winter wrote:

Hi,

1) to not confuse people

Best,

Rolf

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

Shahram

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Sent: Wed Jul 15 02:04:16 2009
Subject: Re: [mpls-tp] MEG - who, what and how

G.8010
Y.1731 MPLS-TP FRMWRK
G.8110.1

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: dinsdag 14 juli 2009 9:18
To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'ext Shahram Davari';
'Rolf Winter'; [email-masked]
Subject: Re: [mpls-tp] MEG - who, what and how

Nurit,

See inline..

From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]]
Sent: maandag 13 juli 2009 20:07
To: ext Maarten Vissers; ext Shahram Davari; Rolf Winter; mpls-
[email-masked]
Subject: RE: [mpls-tp] MEG - who, what and how

Maaretn,

Please see inline.

Best regards,

Nurit

-----Original Message-----
From: ext Maarten Vissers [mailto:[email-masked]]
Sent: Monday, July 13, 2009 3:43 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'ext Shahram Davari';
'Rolf Winter'; [email-masked]
Subject: RE: [mpls-tp] MEG - who, what and how

Nurit,

transport entity contains n*(n-1) p2p maintenance entities (MEs), which
form

When n=2, the bidirectional "mp2mp transport entity" becomes a
bidirectional

Only when there is a 2-port *unidirectional* p2p transport entity,
there is

one MEG and one ME.

A n-port p2mp unidirectional transport entity contanins one MEG and
n*(n-1)

MEs.

transport entity, it is necessary to use both MEG and ME terms in MPLS-
TP

OAM and accept that in one of the cases one MEG will just contain one
ME; in

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Well I think we can clearly
indicate what type of ME we support.

[mv] There is only one type of ME as a ME is defined between one MEP
source and one MEP sink function.

Regards,

Maarten

Regards,

Maarten

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

Hi,

For a point-to-point, we have one ME although we would like to monitor
and

Having the same logic, we can have a p2mp ME, and hold the information
per

leaf. The framework already defines that a ME may include two or more
MEPs,

etc.

Best regards,

Nurit

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

Of ext Shahram Davari

Rolf,

Here is the definition of MEG from where it was originated, which is
ITU-T

Y.1731:

5.2 ME Group (MEG)

conditions:

n*(n-1)/2 MEs.

Regards,

Shahram

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

Of Rolf Winter

To: [email-masked]

Hi,

A bunch of drafts are including the Maintenance Entity Group (MEG) term
and

concept (mostly only as term), sometimes as an open issue, other times
as a

big question mark. It creeps up once talking about the P2MP case which
often

is rather underrepresented in most drafts - hence the MEG confusion
maybe.

The question is, does one need this concept at all for MPLS-TP? If it
is

associated for the sake of OAM. Would a multicast ME be the right
approach

assuming the P2MP is the only use case for such a concept? To some
degree

this is a terminology question, but also a functionality question.
Since

this seem to be at least considered by a number of drafts I would like
to

list:

- What is the functionality needed here, how is it supposed to
operate/being

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

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

--

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 15 Jul 2009 11:11:33 -0700

Hi Rolf,

I agree we need to align the terminology with ITU-T.

If I get you right you are stating that for P2MP case we will have n
ME's in the MEG and not a single ME. Is that correct? So an ME is related
to a trail relationship, while an MEG is related to a connection.

Thanks,
Vishwas

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 16 Jul 2009 01:44:53 +0200

Hi,

Please see inline.

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Dieter Beller
Sent: Wednesday, July 15, 2009 5:57 PM
To: Rolf Winter; [email-masked]
Subject: Re: [mpls-tp] MEG - who, what and how

Rolf and all,

Rolf Winter wrote: 

Hi,
 
I would like to close the discussion on this as this might stall the
work of a number of people. Based on the discussion we had I think we're
converging but I would like to spill it out and ask whether this
receives a broad consensus or not in order to move forward:
 
A) The OAM framework drafts needs some re-writing in order to align the
terminology closer to what has been defined in the ITU-T mainly for two
reasons:
 
  1) to not confuse people
[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I think the people of the IETF
are not confused. They may be confused to see that they have N MEs per
p2mp transport paths one they send one message to monitor the p2mp
transport paths. 
  2) based on the requirements that Neil has mentioned in an earlier
Email which rather fits to the MEG concept of the ITU-T
[Sprecher, Nurit (NSN - IL/Hod HaSharon)] we do not have such a
requirement in the IETF requirements drafts
 
The (main) changes I see right now are to align ME (e.g. restrict it to
2 MEPs) and include the MEG.
[Sprecher, Nurit (NSN - IL/Hod HaSharon)] should we also include meg
level? I do not think we need it. Also we need to indicate which MEG
type it is....and I think it is redundant in MPLS-TP, confuse and does
not add any benefit. 
 
B) There is a draft out there (and I personally believe it is an
important one) that describes OAM based on Y.1731. 
[Sprecher, Nurit (NSN - IL/Hod HaSharon)] we should differentiate
between the framework/architecture and a solution. There are other
important documents  that provide different proposals. 
I fear that other (other than the ITU-T) elements and definitions might
cause problems for this work in terms of confusion but also in terms of
functionality if we are not careful
 
C) I think the OAM elements the ITU-T has defined are versatile enough
to not preclude any solution at this point which I believe is also in
important criterion for a framework. 
[Sprecher, Nurit (NSN - IL/Hod HaSharon)] well as the implementation of
the monitoring level is different in MPLS-TP than in Ethernet
(monitoring end-to-end LSP which may be used as a TC), then by
definition  we do not aligned with the ITU-T's. Also there are other
proposals on the table.
 
Please voice your opinion both positive and negative so that we can
hopefully move forward. 
[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I think my view is clear. 
 
Best,

        Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014 

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
On
	Behalf Of Shahram Davari
	Sent: Mittwoch, 15. Juli 2009 15:47
	To: [email-masked]'; [email-masked]'
	Subject: Re: [mpls-tp] MEG - who, what and how
	 
	I think using the same terms differently will cause more
confusion
	 
	Shahram
	 
	----- Original Message -----
	From: [email-masked] <[email-masked]>
<mailto:[email-masked]> 
	To: [email-masked] <[email-masked]>
<mailto:[email-masked]> 
	Sent: Wed Jul 15 02:04:16 2009
	Subject: Re: [mpls-tp] MEG - who, what and how
	 
	Let me provide a mapping between the different definitions of ME
in
	ITU-T G.8010/Y.1731/G.8110-1 and IETF MPLS-TP Framework:
	 
	G.8010
	Y.1731            MPLS-TP FRMWRK
	G.8110.1
	 
	I expect that the redefinition of the term Maintenance Entity
(ME) in
	the MPLS-TP framework document will cause confusion in the
MPLS-TP work.
	In our discussion we will have to state every time we us ME if
this
	term is used in the ITU-T or IETF definition.
	 
	Regards,
	Maarten

	From: [email-masked] [mailto:[email-masked]]
On
	Behalf Of Maarten Vissers
	Sent: dinsdag 14 juli 2009 9:18
	To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'ext Shahram
Davari';
	'Rolf Winter'; [email-masked]
	Subject: Re: [mpls-tp] MEG - who, what and how

	Nurit,
	 
	See inline..

	 
	Maaretn,

	Please see inline.
	 
	Best regards,
	 
	Nurit

	-----Original Message-----
	From: ext Maarten Vissers [mailto:[email-masked]]
	Sent: Monday, July 13, 2009 3:43 PM
	To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'ext Shahram
Davari';

	Nurit,

	Divide and rule is applicable when we have many cases to
consider...

	The most extensive case is the n-port "mp2mp transport entity".
This

	 
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Please note that in
MPLS-TP
	we do not have n-port "mp2mp transport entity". A transport path
can be
	p2p or ptmp. The services that are delivered over the MPLS
transport
	network, ca be multipoint services.

	[mv]  In a PTN we have mp2mp transport entities and p2p
transport
	entities and p2mp transport entities and rmp transport entities
and in
	some PTN technologies also mp2p transport entities. MPLS-TP p2p
	transport entities and MPLS-TP p2mp transport entities are as
such just
	a small subset of the total set of transport entitities in a
PTN. MPLS-
	TP is one of the multiple technologies that may be present in a
PTN.

	 
	 
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] maybe it is
unidirectional
	p2p transport path? This is clearly one of the transport paths
	supported by MPLS-TP, as well as associated p2p transport paths,
etc.

	[mv] the term "transport path" in MPLS-TP represents a
"transport
	entity" in a MPLS-TP transport path layer network. MPLS-TP
transport
	path layer networks seems to be the MPLS-TP LSP and the MPLS-TP
MS-PW
	layer networks. We will figure out the details when we deploy
MPLS-TP
	technology in the PTN and develop the functional models.

	[mv] A "bidirectional p2p transport entity" in one of the
MPLS-TP
	transport path layer networks is **not** a "unidirectional p2p
	transport path".

	[mv] A "bidirectional p2p transport entity" in one of the
MPLS-TP
	transport path layer networks is a co-routed or associated
	"bidirectional p2p transport path".

	Only when there is a 2-port *unidirectional* p2p transport
entity,
	there is
	 
	one MEG and one ME.
	 
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] according to the ITU-T
	definition. Clearly in MPLS-TP we support more types of
transport
	paths......how can we differentiate between unidirectional p2p
transport
	path and co-routed bi-directional transport paths, etc?

	[mv] A transport path is a transport entity in one of the
MPLS-TP layer
	networks. What applies for transport entities applies as such
for an
	example of such transport entities (i.e. the transport path). A
	unidirectional p2p transport path contains one MEG and one ME. A
co-
	routed bidirectional p2p transport path contains one MEG and two
MEs.
	An associated bidirectional p2p transport path contains one MEG
and two
	MEs. A unidirectional n-port p2mp transport path contains one
MEG and
	n-1 MEs.

	A n-port p2mp unidirectional transport entity contanins one MEG
and
	n*(n-1)
	 
	MEs.
	 
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Well, in MPLS-TP we
are
	talking about the transport paths that can be p2mp or p2p. There
is no
	definition of n-port p2mp transport entity in MPLS-TP.

	[mv] As described above, a transport path is a transport entity
in one
	of the MPLS-TP transport path layer networks. By definition a
p2mp
	transport path is as such a p2mp transport entity.

	As MPLS-TP will support more then just the 2-port p2p
unidirectional

	 
	 
clearly

	[mv] There is only one type of ME as a ME is defined between one
MEP
	source and one MEP sink function.

	[mv] The different transport entitities in MPLS-TP transport
path layer
	networks and section layer networks have different types of MEG.

	Regards,
	 
	Maarten

	Regards,
	 
	Maarten

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

	 

	 
	Hi,

monitor
	and

information
	per
	 
more
	MEPs,
	 
	etc.
	 
	Best regards,
	 
	Nurit

	-----Original Message-----
	 
	From: [email-masked] [mailto:[email-masked]]
On
	Behalf
	 
	Of ext Shahram Davari

	 

	Rolf,

	 
	Y.1731:

	5.2 ME Group (MEG)

	conditions:

	 
	* MEs in a MEG belong to the same point-to-point ETH connection
or

	For a point-to-point ETH connection, a MEG contains a single ME.
For a
	 
	multipoint ETH connectivity containing n end-points, a MEG
contains
	 
	n*(n-1)/2 MEs.

	 
	Regards,
	 
	Shahram

	-----Original Message-----
	 
	From: [email-masked] [mailto:[email-masked]]
On
	Behalf
	 
	Of Rolf Winter

	To: [email-masked]

	 
	Hi,

	 
times
	as a
	 
which
	often
	 
	is rather underrepresented in most drafts - hence the MEG
confusion
	maybe.

	 
	would it be a collection of Maintenance Entities that are
"somehow"
	 
	associated for the sake of OAM. Would a multicast ME be the
right
	approach
	 
	assuming the P2MP is the only use case for such a concept? To
some
	degree
	 
	this is a terminology question, but also a functionality
question.
	Since

	 
	list:

	 
	implemented and how should we call it in order for people to
better

	 
	Best,

	      Rolf

Road,
	London

	 

	mpls-tp mailing list
	 
	[email-masked]

	 

	mpls-tp mailing list
	 
	[email-masked]

	 
	mpls-tp mailing list
	 
	[email-masked]

	 

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

--

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 16 Jul 2009 01:35:37 +0200

Hi,

Well, I disagree on this...

I think what we need to do is to comply with the requirements of
MPLS-TP.

If we have n MEs for p2mp transport path, so does it mean that the root
send individual monitoring message for each leave? I believe the root
send one message which is distributed to all leaves, so we actually have
one p2mp entity. Alos how do we know how many MEs we have in one MEG? We
need to know the type of the MEG, to know whether it groups two
co-routed unidirectional LSPs or maybe it groups N NEs of p2mp LSPs,
etc.? We have one entity which we actually monitor. We have a
requirement to monitor the following entities:

*         Unidirectional p2p transport path

*         Co-routed p2p transport path

*         Associated p2p transport path

*         Unidirectional p2mp transport path

I think we need to define ME per each of the entities above, and I can
see no justification to split it to multiple entities which are grouped
together in another entity.  

In Ethernet we also had to talk about MEG level which in MPLS-TP has no
real meaning, because the LSP which is being monitored actually presents
it.......

Why should we complicate it and have so many entities to configure? 

As I indicated in previous mails, I believe that we can have one entity,
ME per the entity which is being monitored, and this ME can be of
different types. 

Best regards,

Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Vishwas Manral
Sent: Wednesday, July 15, 2009 9:12 PM
To: Rolf Winter
Cc: [email-masked]
Subject: Re: [mpls-tp] MEG - who, what and how

Hi Rolf,

ME's in the MEG and not a single ME. Is that correct? So an ME is
related

Thanks,

Vishwas

work of a number of people. Based on the discussion we had I think we're
converging but I would like to spill it out and ask whether this
receives a broad consensus or not in order to move forward:

> A) The OAM framework drafts needs some re-writing in order to align
the terminology closer to what has been defined in the ITU-T mainly for
two reasons:

> B) There is a draft out there (and I personally believe it is an
important one) that describes OAM based on Y.1731. I fear that other
(other than the ITU-T) elements and definitions might cause problems for
this work in terms of confusion but also in terms of functionality if we
are not careful

hopefully move forward.

transport

monitor

information

times

which

mpls-tp mailing list

[email-masked]

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 15 Jul 2009 17:56:08 -0700

I am not sure why the MEG concept is needed for MPLS LSPs.

Each MPLS LSP in itself is a maintenance entity. The entity consists of the 2 end-points (in case the LSP is P2P)
and the entity consists of N end-points (Ingress & N-1 leaves of a P2MP LSP).

The various end-points of a MPLS LSP are clearly identified by the LSP parameters.

Are you proposing defining the MEG concept just for conceptual understanding/mapping or are you
Proposing that it be further used with different MEG levels as in Ethernet OAM? I am against the former as
I don't see a use case (and a requirement in any requirements draft) for different MEG levels in MPLS-TP.

Can you clarify in some more detail why a MEG is needed and how it would be used ?

Thanks
Nitin

On 7/15/09 7:56 AM, "Dieter Beller" <[email-masked]> wrote:

Rolf and all,

Rolf Winter wrote:

Hi,

  1) to not confuse people

Best,

 Rolf

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

Shahram

----- Original Message -----
From: [email-masked] <[email-masked]> <mailto:[email-masked]>
To: [email-masked] <[email-masked]> <mailto:[email-masked]>
Sent: Wed Jul 15 02:04:16 2009
Subject: Re: [mpls-tp] MEG - who, what and how

G.8010
Y.1731            MPLS-TP FRMWRK
G.8110.1

Regards,
Maarten

Nurit,

See inline..

Maaretn,

Please see inline.

Best regards,

Nurit

-----Original Message-----
From: ext Maarten Vissers [mailto:[email-masked]]
Sent: Monday, July 13, 2009 3:43 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'ext Shahram Davari';

Nurit,

one MEG and one ME.

[Sprecher, Nurit (NSN - IL/Hod HaSharon)] according to the ITU-T
definition. Clearly in MPLS-TP we support more types of transport
paths......how can we differentiate between unidirectional p2p transport
path and co-routed bi-directional transport paths, etc?

MEs.

Regards,

Maarten

Regards,

Maarten

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

Hi,

etc.

Best regards,

Nurit

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

Of ext Shahram Davari

Rolf,

Y.1731:

5.2 ME Group (MEG)

conditions:

n*(n-1)/2 MEs.

Regards,

Shahram

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

Of Rolf Winter

To: [email-masked]

Hi,

list:

Best,

      Rolf

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: Zhang Haiyan <[email-masked]>
Date: Thu, 16 Jul 2009 10:19:12 +0800

Agree.

Haiyan

---

From: Masahiko Mizutani <[email-masked]>
Date: Thu, 16 Jul 2009 11:53:03 +0900

I, too, agree with the proposal.

Masahiko

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Jul 2009 10:03:44 +0200

Nurit,
 
see in line marked with [ib]
 
Italo

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
	Sent: Thursday, July 16, 2009 1:45 AM
	To: ext Dieter Beller; Rolf Winter; [email-masked]
	Subject: Re: [mpls-tp] MEG - who, what and how

	Hi,

	Please see inline.

	Best regards,

	Nurit

On Behalf Of ext Dieter Beller

	Rolf and all,

	Rolf Winter wrote: 

	Hi,
	 
	I would like to close the discussion on this as this might stall
the work of a number of people. Based on the discussion we had I think
we're converging but I would like to spill it out and ask whether this
receives a broad consensus or not in order to move forward:

	  1) to not confuse people
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I think the people of
the IETF are not confused. They may be confused to see that they have N
MEs per p2mp transport paths one they send one message to monitor the
p2mp transport paths.  

[ib] I do not understand this point. The MEG/ME model has been very well
understood by ITU-T and IEEE people. Why IETF people should have
problems in understanding the model?

	The (main) changes I see right now are to align ME (e.g.
restrict it to 2 MEPs) and include the MEG.
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] should we also include
meg level? I do not think we need it. Also we need to indicate which MEG
type it is....and I think it is redundant in MPLS-TP, confuse and does
not add any benefit.  

[ib] I do not see any proposal to include the MEG level. Based on the
JWT agreement I do not see the need for if.
I would like to decouple MEG level from the MEG/ME discussion. Not
introducing the MEG concept is not precludign people to invent an "ME
level" concept.

	B) There is a draft out there (and I personally believe it is an
important one) that describes OAM based on Y.1731. 
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] we should
differentiate between the framework/architecture and a solution. There
are other important documents  that provide different proposals.  

[ib] I fully agree with you. However all the solutions should be
compliant with the framework/architecture and meet the requirements.

	I fear that other (other than the ITU-T) elements and
definitions might cause problems for this work in terms of confusion but
also in terms of functionality if we are not careful
	 
	C) I think the OAM elements the ITU-T has defined are versatile
enough to not preclude any solution at this point which I believe is
also in important criterion for a framework. 
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] well as the
implementation of the monitoring level is different in MPLS-TP than in
Ethernet (monitoring end-to-end LSP which may be used as a TC), then by
definition  we do not aligned with the ITU-T's. Also there are other
proposals on the table. 

[ib] You are correct but your observation apply to the "MEG level"
concept and not to the MEG concept.

	Please voice your opinion both positive and negative so that we
can hopefully move forward. 
	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I think my view is
clear. 
	 
	Best,

	        Rolf

	  

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On
		Behalf Of Shahram Davari
		Sent: Mittwoch, 15. Juli 2009 15:47
		To: [email-masked]'; [email-masked]'
		Subject: Re: [mpls-tp] MEG - who, what and how

		Shahram
		 
		----- Original Message -----
		From: [email-masked]
<[email-masked]> <mailto:[email-masked]> 
		To: [email-masked] <[email-masked]>
<mailto:[email-masked]> 
		Sent: Wed Jul 15 02:04:16 2009
		Subject: Re: [mpls-tp] MEG - who, what and how
		 
		Let me provide a mapping between the different
definitions of ME in
		ITU-T G.8010/Y.1731/G.8110-1 and IETF MPLS-TP Framework:
		 
		G.8010
		Y.1731            MPLS-TP FRMWRK
		G.8110.1
		 
		I expect that the redefinition of the term Maintenance
Entity (ME) in
		the MPLS-TP framework document will cause confusion in
the MPLS-TP work.
		In our discussion we will have to state every time we us
ME if this
		term is used in the ITU-T or IETF definition.
		 
		Regards,
		Maarten

		From: [email-masked]
[mailto:[email-masked]] On
		Behalf Of Maarten Vissers
		Sent: dinsdag 14 juli 2009 9:18
		To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'ext
Shahram Davari';
		'Rolf Winter'; [email-masked]
		Subject: Re: [mpls-tp] MEG - who, what and how

		Nurit,
		 
		See inline..

		To: ext Maarten Vissers; ext Shahram Davari; Rolf
Winter; mpls-

		Maaretn,

		Please see inline.
		 
		Best regards,
		 
		Nurit

		-----Original Message-----
		From: ext Maarten Vissers
[mailto:[email-masked]]
		Sent: Monday, July 13, 2009 3:43 PM
		To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'ext
Shahram Davari';
		'Rolf Winter'; [email-masked]
		Subject: RE: [mpls-tp] MEG - who, what and how

		Nurit,

		 
		The most extensive case is the n-port "mp2mp transport
entity". This
		 
		transport entity contains n*(n-1) p2p maintenance
entities (MEs), which
		form

		[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Please note
that in MPLS-TP
		we do not have n-port "mp2mp transport entity". A
transport path can be
		p2p or ptmp. The services that are delivered over the
MPLS transport
		network, ca be multipoint services.

		[mv]  In a PTN we have mp2mp transport entities and p2p
transport
		entities and p2mp transport entities and rmp transport
entities and in
		some PTN technologies also mp2p transport entities.
MPLS-TP p2p
		transport entities and MPLS-TP p2mp transport entities
are as such just
		a small subset of the total set of transport entitities
in a PTN. MPLS-
		TP is one of the multiple technologies that may be
present in a PTN.

		When n=2, the bidirectional "mp2mp transport entity"
becomes a
		bidirectional
		 
		"p2p transport entity" with one MEG and  2*(2-1) = 2
MEs.
		 
		[Sprecher, Nurit (NSN - IL/Hod HaSharon)] maybe it is
unidirectional
		p2p transport path? This is clearly one of the transport
paths
		supported by MPLS-TP, as well as associated p2p
transport paths, etc.

		[mv] the term "transport path" in MPLS-TP represents a
"transport
		entity" in a MPLS-TP transport path layer network.
MPLS-TP transport
		path layer networks seems to be the MPLS-TP LSP and the
MPLS-TP MS-PW
		layer networks. We will figure out the details when we
deploy MPLS-TP
		technology in the PTN and develop the functional models.

		[mv] A "bidirectional p2p transport entity" in one of
the MPLS-TP
		transport path layer networks is **not** a
"unidirectional p2p
		transport path".

		[mv] A "bidirectional p2p transport entity" in one of
the MPLS-TP
		transport path layer networks is a co-routed or
associated
		"bidirectional p2p transport path".

		Only when there is a 2-port *unidirectional* p2p
transport entity,
		there is
		 
		one MEG and one ME.
		 
		[Sprecher, Nurit (NSN - IL/Hod HaSharon)] according to
the ITU-T
		definition. Clearly in MPLS-TP we support more types of
transport
		paths......how can we differentiate between
unidirectional p2p transport
		path and co-routed bi-directional transport paths, etc?

		[mv] A transport path is a transport entity in one of
the MPLS-TP layer
		networks. What applies for transport entities applies as
such for an
		example of such transport entities (i.e. the transport
path). A
		unidirectional p2p transport path contains one MEG and
one ME. A co-
		routed bidirectional p2p transport path contains one MEG
and two MEs.
		An associated bidirectional p2p transport path contains
one MEG and two
		MEs. A unidirectional n-port p2mp transport path
contains one MEG and
		n-1 MEs.

		A n-port p2mp unidirectional transport entity contanins
one MEG and
		n*(n-1)
		 
		MEs.
		 
		[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Well, in
MPLS-TP we are
		talking about the transport paths that can be p2mp or
p2p. There is no
		definition of n-port p2mp transport entity in MPLS-TP.

		[mv] As described above, a transport path is a transport
entity in one
		of the MPLS-TP transport path layer networks. By
definition a p2mp
		transport path is as such a p2mp transport entity.

		 
		transport entity, it is necessary to use both MEG and ME
terms in MPLS-
		TP
		 
		OAM and accept that in one of the cases one MEG will
just contain one
		ME; in

		[Sprecher, Nurit (NSN - IL/Hod HaSharon)] Well I think
we can clearly
		indicate what type of ME we support.

		[mv] There is only one type of ME as a ME is defined
between one MEP
		source and one MEP sink function.

		[mv] The different transport entitities in MPLS-TP
transport path layer
		networks and section layer networks have different types
of MEG.

		Regards,
		 
		Maarten

		Regards,
		 
		Maarten

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

		 

		 
		Hi,

		For a point-to-point, we have one ME although we would
like to monitor
		and

		Having the same logic, we can have a p2mp ME, and hold
the information
		per
		 
		leaf. The framework already defines that a ME may
include two or more
		MEPs,
		 
		etc.
		 
		Best regards,
		 
		Nurit

		-----Original Message-----
		 
		From: [email-masked]
[mailto:[email-masked]] On
		Behalf
		 
		Of ext Shahram Davari

		 

		Rolf,

		Here is the definition of MEG from where it was
originated, which is
		ITU-T
		 
		Y.1731:

		5.2 ME Group (MEG)
		 
		ME Group (MEG) includes different MEs that satisfy the
following
		 
		conditions:
		 
		* MEs in a MEG exist in the same administrative
boundary; and
		 
		* MEs in a MEG have the same MEG Level (see sub-clause
5.6), and
		 
		* MEs in a MEG belong to the same point-to-point ETH
connection or

		For a point-to-point ETH connection, a MEG contains a
single ME. For a
		 
		multipoint ETH connectivity containing n end-points, a
MEG contains
		 
		n*(n-1)/2 MEs.

		For MPLS-TP, replace ETH with MPLS-TP and Multipoint
with P2MP.

		Regards,
		 
		Shahram

		-----Original Message-----
		 
		From: [email-masked]
[mailto:[email-masked]] On
		Behalf
		 
		Of Rolf Winter

		To: [email-masked]

		 
		Hi,

		A bunch of drafts are including the Maintenance Entity
Group (MEG) term
		and
		 
		concept (mostly only as term), sometimes as an open
issue, other times
		as a
		 
		big question mark. It creeps up once talking about the
P2MP case which
		often
		 
		is rather underrepresented in most drafts - hence the
MEG confusion
		maybe.
		 
		The question is, does one need this concept at all for
MPLS-TP? If it
		is

		would it be a collection of Maintenance Entities that
are "somehow"
		 
		associated for the sake of OAM. Would a multicast ME be
the right
		approach
		 
		assuming the P2MP is the only use case for such a
concept? To some
		degree

		this seem to be at least considered by a number of
drafts I would like
		to

		list:

		- What is the functionality needed here, how is it
supposed to
		operate/being
		 
		implemented and how should we call it in order for
people to better

		 
		Best,

		      Rolf

		NEC Europe Limited | Registered Office: NEC House, 1
Victoria Road,
		London

		 

		mpls-tp mailing list
		 
		[email-masked]

		 

		mpls-tp mailing list
		 
		[email-masked]

		 
		mpls-tp mailing list
		 
		[email-masked]

		 

	 

	--

---

From: <[email-masked]>
Date: Thu, 16 Jul 2009 08:20:48 +0100

Nurit...this is not completely right.  Please see in-line.

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
	Sent: 16 July 2009 00:36
	To: ext Vishwas Manral; Rolf Winter
	Cc: [email-masked]
	Subject: Re: [mpls-tp] MEG - who, what and how

	Hi,

	If we have n MEs for p2mp transport path, so does it mean that
the root send individual monitoring message for each leave? I believe
the root send one message which is distributed to all leaves, so we
actually have one p2mp entity. 

	NH=> Yes, this is correct wrt to what we have.  However,
although the p2mp entity is a single connection/LSP it does represent N
root->leaf trails.  So, from the customer perspective at leaf point X,
he/she is only concerned as to whether the information flow root->leaf_X
is working correctly.....leaf_X does not care about the other root->leaf
information flows.

	This is quite an important concept to be clear on, since the
availabiliy and performance (error/loss/delay) behaviour for leaf X is
quite independent of that seen by any other leaf...so these have to
meassured independently.  I would hope this is intuitively obvious.

	Further, as I remarked earlier, a necessary condition for
deterministic resource management *per client service instance* is that
the server provides proper connections.....which by definition MUST only
have a single source......and yes I know we can construct mp2p and mp2mp
entities but I would hope it is again intuitively obvious that one
cannot deterministically assign/manage resource here.  If it's not
intuitively obvious then please look at G.800.

	If you do not agree with this then can I suggest you have a chat
with Andy Reid who is largely responible for all the major functional
arch definitions that have appeared in G.805 (co-cs mode only) and later
the more unified treatment in G.800 (unifies func arch specs that cover
all 3 modes).

	regards, Neil

	  Alos how do we know how many MEs we have in one MEG? We need
to know the type of the MEG, to know whether it groups two co-routed
unidirectional LSPs or maybe it groups N NEs of p2mp LSPs, etc.? We have
one entity which we actually monitor. We have a requirement to monitor
the following entities:

	I think we need to define ME per each of the entities above, and
I can see no justification to split it to multiple entities which are
grouped together in another entity.  

	In Ethernet we also had to talk about MEG level which in MPLS-TP
has no real meaning, because the LSP which is being monitored actually
presents it.......

	Why should we complicate it and have so many entities to
configure? 

	As I indicated in previous mails, I believe that we can have one
entity, ME per the entity which is being monitored, and this ME can be
of different types. 

	Best regards,

	Nurit

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Vishwas Manral
	Sent: Wednesday, July 15, 2009 9:12 PM
	To: Rolf Winter
	Cc: [email-masked]
	Subject: Re: [mpls-tp] MEG - who, what and how

	Hi Rolf,

	If I get you right you are stating that for P2MP case we will
have n

	ME's in the MEG and not a single ME. Is that correct? So an ME
is related

	to a trail relationship, while an MEG is related to a
connection.

	Thanks,

	Vishwas

	> I would like to close the discussion on this as this might
stall the work of a number of people. Based on the discussion we had I
think we're converging but I would like to spill it out and ask whether
this receives a broad consensus or not in order to move forward:

mainly for two reasons:

	> B) There is a draft out there (and I personally believe it is
an important one) that describes OAM based on Y.1731. I fear that other
(other than the ITU-T) elements and definitions might cause problems for
this work in terms of confusion but also in terms of functionality if we
are not careful

	> C) I think the OAM elements the ITU-T has defined are
versatile enough to not preclude any solution at this point which I
believe is also in important criterion for a framework.

confusion

(ME) in

MPLS-TP work.

Davari';

Davari';

consider...

entity". This

(MEs), which

MPLS-TP

transport

transport

entities and in

such just

PTN. MPLS-

unidirectional

paths

"transport

transport

MPLS-TP MS-PW

MPLS-TP

MPLS-TP

MPLS-TP

entity,

transport

MPLS-TP layer

for an

MEG and

are

entity in one

p2mp

unidirectional

terms in MPLS-

contain one

clearly

path layer

information

which is

following

connection or

contains

(MEG) term

confusion

MPLS-TP? If it

"somehow"

right

some

question.

would like

better

Road,

	mpls-tp mailing list

	[email-masked]

---

From: "Rolf Winter" <[email-masked]>
Date: Thu, 16 Jul 2009 11:45:07 +0200

Hi,

See inline:

>   1) to not confuse people
> [Sprecher, Nurit (NSN - IL/Hod HaSharon)] I think the people of the
> IETF are not confused. They may be confused to see that they have N MEs
> per p2mp transport paths one they send one message to monitor the p2mp
> transport paths.

Not sure I understand you correctly here. This is all conceptually simple and shouldn't confuse people no matter what their background is. As Italo has pointed out earlier, this is not the first time these concepts are used within the IETF. 

> type it is....and I think it is redundant in MPLS-TP, confuse and does

I am not sure about a MEG level either. I currently do not see what MEG type you refer to. Could you expand on that.

> important documents  that provide different proposals.

Correct, but it is important to create the framework to not preclude (reasonable) solutions. Do you see that happening? If so could you point to a specific example?

> definition  we do not aligned with the ITU-T's. Also there are other

Right, and this was partly a call for which one the group prefers. But the framework is still aligned in my opinion.
 
> [Sprecher, Nurit (NSN - IL/Hod HaSharon)] I think my view is clear.

It appears so :)

Best,

	Rolf

---

From: "Rolf Winter" <[email-masked]>
Date: Thu, 16 Jul 2009 11:56:10 +0200

Hi,

The MEG level is still under discussion and am also unclear about whether we need it or not. I think Ben put it best:

"The intent of the OAM framework draft is to outline/describe the OAM components required by MPLS-TP (as set out in the OAM requirements draft) and how OAM may be "modelled" (e.g. Concepts of MEs and MEGs etc.) in MPLS-TP."

Basically, a bunch of components and their interaction. No magic.

Best,

	Rolf

> Each MPLS LSP in itself is a maintenance entity. The entity consists of
> the 2 end-points (in case the LSP is P2P)

---

From: "Rolf Winter" <[email-masked]>
Date: Thu, 16 Jul 2009 11:58:31 +0200

Hi,

I am not the most savvy person when it comes to ITU-T speak and Neil has greatly confused me with his essay about connections. But I think that is what I meant.

Best,

	Rolf

> From: Vishwas Manral [mailto:[email-masked]]
> Sent: Mittwoch, 15. Juli 2009 20:12
> To: Rolf Winter
> Cc: Shahram Davari; [email-masked]; [email-masked]
> work of a number of people. Based on the discussion we had I think
> (other than the ITU-T) elements and definitions might cause problems
> for this work in terms of confusion but also in terms of functionality
> if we are not careful
> >

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 16 Jul 2009 15:33:34 +0200

Nurit,

> type it is....and I think it is redundant in MPLS-TP, confuse and does 

The transport entity, ME, MEG and MEG Level are abstract constructs that we
have defined to describe a specific application/behaviour. With respect to
MEG Level you will notice when you go over the different transport network
OAM specifications that there is more then one method to implement this MEG
Level.

- SDH VC-n: one or more bytes in the overhead at a fixed distance from the
frame start; supported are 2 MEG levels
- OTN ODUk: eight times 3-bytes in the overhead of the OTUk/ODUk at fixed
distances from the frame start; supported are 8 MEG levels
- ATM VP: cells with a specific VCI value (i.e. VCI=3, 4); supported are 2
MEG levels
- ATM VC: cells with a specific PTI value (i.e. PTI=100, 101); supported are
2 MEG levels
- Ethernet VLAN: frames with a specific MEL field value (i.e. MEL=000 to
111); supported are 8 MEG levels
- MPLS-TP Section, LSP and MS-PW: supported are infinite number of MEG
levels due to use of label stacking as MEG level encoding method.

Note that there is a major difference between the MEG Level as abstract
construct and the "MEG Level (MEL)" field in which for Ethernet the abstract
MEG Level is encoded. The MEG Level as abstract construct is necessary in
MPLS-TP OAM, the MEL field in a MPLS-TP packet is not necessary (but may be
present for PDU commonality and is then ignored in the receiver).

In ATM you find that e.g. the VCI field is associated with multiple
functions: e.g. 
- identification of a VC cell, 
- identification of an OAM cell, 
- identification of OAM MEG level, 
- etc.

The consequence of choosing the label stacking method to identify MEG levels
in MPLS-TP is that the label stack entry header is now associated with two
functions as well:
1) identification of client, transport of QoS information, loop mitigation
and 
2) identification of OAM MEG level. 

Where the addition of a new label stack entry header in the past was a
representation of the creation of a new (server layer) transport entity, the
addition of a new label stack entry header may now be associated with either
the creation of a new (server layer) transport entity, or the creation of a
MEG level within an existing transport entity. From network management
perspective those two cases have very different operational aspects
associated.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rolf Winter
Sent: donderdag 16 juli 2009 11:45
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Dieter Beller;
[email-masked]
Subject: Re: [mpls-tp] MEG - who, what and how

Hi,

See inline:

> IETF are not confused. They may be confused to see that they have N 

Not sure I understand you correctly here. This is all conceptually simple
and shouldn't confuse people no matter what their background is. As Italo
has pointed out earlier, this is not the first time these concepts are used
within the IETF. 

> Email which rather fits to the MEG concept of the ITU-T [Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)] we do not have such a requirement in 
> the IETF requirements drafts
> 

I am not sure about a MEG level either. I currently do not see what MEG type
you refer to. Could you expand on that.

> important documents  that provide different proposals.

Correct, but it is important to create the framework to not preclude
(reasonable) solutions. Do you see that happening? If so could you point to
a specific example?

> I fear that other (other than the ITU-T) elements and definitions 
> might cause problems for this work in terms of confusion but also in 
> terms of functionality if we are not careful
> 
> [Sprecher, Nurit (NSN - IL/Hod HaSharon)] well as the implementation 
> of the monitoring level is different in MPLS-TP than in Ethernet 

Right, and this was partly a call for which one the group prefers. But the
framework is still aligned in my opinion.

It appears so :)

Best,

	Rolf

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 16 Jul 2009 12:31:32 -0700

Hi Maarten,

   Thanks for the clarifications. See inline below.

> have defined to describe a specific application/behaviour.

ME & MEG, I understand as abstract concepts.

> MEG Level is encoded. 

> The MEG Level as abstract construct is necessary in
> MPLS-TP OAM,

I am not 100% convinced...probably my lack of knowledge. See more below on this.

> the MEL field in a MPLS-TP packet is not necessary (but may
> be

Ok.
 
> 2) identification of OAM MEG level.

Again, I'm not clear why you want to use label stacking to identify MEG level. I'm not clear as to why you want to identify the MEG level in the first place.

In case of MPLS-TP, each LSP by itself will have it's own OAM. Each LSP and end-to-end entity cares about it's own OAM. Whether that LSP goes over 2 other layers of LSPs (multiple levels of network elements) should not be a concern for that LSP. By identifying a MEG level for LSPs, you are introducing the concept of one layer knowing about the implicit presence of another layer. 

When you are performing OAM over a particular layer, the OAM PDU should have sufficient information for an end-point to identify the entity on which OAM is being performed on. If you say that MEG level is one way to identify the layer/entity, then MEG is a *solution* and not a *requirement*. 

If MEG level serves some other purpose, then could you help clarifying that.

Thanks
Nitin

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 16 Jul 2009 22:41:53 +0200

All,

As this is in line with what I already proposed several days ago:

I support this.

An additional benefit is that three SDOs will use the same concept.

Cheers, Huub.

================

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: <[email-masked]>
Date: Thu, 16 Jul 2009 22:01:31 +0100

I believe your concerns are well-founded Nitin.  We have looked closely
at TCM and in most technologies (any of the 3 modes) it is an
artificially imposed form of horizontal layer
peer-partitioning...however it is 'sold' as hierarchy but it is most
definitely not client/server hierarchy, but an arbitrarily imposed
partitioning of a single layer network.  This is one reason why we in BT
have major concerns about its practical viability, eg only true
end-points (ie network access points) in this single layer network
remain invariant over any failure/recovery events.

MPLS however does create a form of true hierarchy, which is quite
different to how TCM has been applied in other technologies as I noted
above.  Indeed it would be true/real client/server hierarchy *iff* each
LSP has its own functionally independent DP/CP/MP.  However, in the
original arch specification of MPLS it was assumed we could allow nested
LSPs to be sublayers within the same CP/MP domain, ie a "single CP" over
all nested LSPs, and this is what the S bit was to supposed to
represent.  Moreover, it is also why trying to create true client/server
isolation between LSPs belonging to *different MPLS network instances*
(ie MPLS network belonging to party A carried transparently over the
MPLS network belonging to party B) required the forced insertion of an
'ethernet PW functional breakwater' (to separate all 3 DP/CP/MP
functional planes in the 2 MPLS layer networks).....see the draft
Stewart/I kicked-off over a year ago on this
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-transport-04.tx
t

regards, Neil

> [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> Sent: 16 July 2009 20:32
> To: 'Maarten Vissers'; 'Sprecher, Nurit (NSN -IL/Hod 
> HaSharon)'; [email-masked]
> > The transport entity, ME, MEG and MEG Level are abstract 
> constructs that
> > we
> > The consequence of choosing the label stacking method to 
> identify MEG
> > levels
> Again, I'm not clear why you want to use label stacking to 
> identify MEG level. I'm not clear as to why you want to 
> identify the MEG level in the first place.
> 
> In case of MPLS-TP, each LSP by itself will have it's own 
> OAM. Each LSP and end-to-end entity cares about it's own OAM. 
> Whether that LSP goes over 2 other layers of LSPs (multiple 
> levels of network elements) should not be a concern for that 
> LSP. By identifying a MEG level for LSPs, you are introducing 
> the concept of one layer knowing about the implicit presence 
> of another layer. 
> 
> When you are performing OAM over a particular layer, the OAM 
> PDU should have sufficient information for an end-point to 
> identify the entity on which OAM is being performed on. If 
> you say that MEG level is one way to identify the 
> layer/entity, then MEG is a *solution* and not a *requirement*. 
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 17 Jul 2009 10:47:54 +0200

Neil,

Thanks for your comments.

Please see inline.

Best regards,

Nurit

From: ext [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 16, 2009 10:21 AM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] MEG - who, what and how

	

	Hi,

	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I agree and in the
p2mp entity we need monitor each root to leaf connectivity. Should we
define a specific entity to do so? I am not sure. In the p2mp entity, we
keep the FM/PM information per leaf.

	Note that this is a very important topic that I am not sure if
completely addressed in the OAM requirements draft.  

	[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I do not think we have
disagreement here, but as always I'll be glad to chat with Andy. 

	regards, Neil

	Best regards,

	Nurit

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

	Hi Rolf,

	Thanks,

	Vishwas

stall the work of a number of people. Based on the discussion we had I
think we're converging but I would like to spill it out and ask whether
this receives a broad consensus or not in order to move forward:

mainly for two reasons:

confusion

(ME) in

MPLS-TP work.

Davari';

Davari';

consider...

entity". This

(MEs), which

MPLS-TP

transport

transport

entities and in

such just

PTN. MPLS-

unidirectional

paths

"transport

transport

MPLS-TP MS-PW

MPLS-TP

MPLS-TP

MPLS-TP

entity,

transport

MPLS-TP layer

for an

MEG and

are

entity in one

p2mp

unidirectional

terms in MPLS-

contain one

clearly

path layer

information

which is

following

connection or

contains

(MEG) term

confusion

MPLS-TP? If it

"somehow"

right

some

question.

would like

better

Road,

	mpls-tp mailing list

	[email-masked]

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 10:00:56 +0100

Many thanks Nurit...I believe we (and probably most others) are pretty
well in agreement on most of this.   It is most important to
differentiate the trail (a specific source<=>sink case) and the
connection.  They are of course congruent in the p2p case but not in the
p2mp case.  All other constructs are not connections.  And a connection
is an a priori necessary requirement for deterministic client resource
assignment/management...and in particular the rather important
observation that in the general case the performance experienced by
client/customer X should not be dependent on the traffic behaviour of
client/customer Y.   If we do not pay attention to these important
points at the outset we will not be able to define useful SLAs later.
 
regards, Neil

	From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
	Sent: 17 July 2009 09:48
	To: Harrison,N,Neil,DEY2 R; [email-masked];
[email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] MEG - who, what and how

	Neil,

	Please see inline.

	Best regards,

	Nurit

	Sent: Thursday, July 16, 2009 10:21 AM
	To: Sprecher, Nurit (NSN - IL/Hod HaSharon);
[email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] MEG - who, what and how

		

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN -
IL/Hod HaSharon)
		Sent: 16 July 2009 00:36
		To: ext Vishwas Manral; Rolf Winter
		Cc: [email-masked]
		Subject: Re: [mpls-tp] MEG - who, what and how

		Hi,

		I think what we need to do is to comply with the
requirements of MPLS-TP.

		If we have n MEs for p2mp transport path, so does it
mean that the root send individual monitoring message for each leave? I
believe the root send one message which is distributed to all leaves, so
we actually have one p2mp entity. 

		[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I agree and in
the p2mp entity we need monitor each root to leaf connectivity. Should
we define a specific entity to do so? I am not sure. In the p2mp entity,
we keep the FM/PM information per leaf.

		Note that this is a very important topic that I am not
sure if completely addressed in the OAM requirements draft.  

		This is quite an important concept to be clear on, since
the availabiliy and performance (error/loss/delay) behaviour for leaf X
is quite independent of that seen by any other leaf...so these have to
meassured independently.  I would hope this is intuitively obvious.

		Further, as I remarked earlier, a necessary condition
for deterministic resource management *per client service instance* is
that the server provides proper connections.....which by definition MUST
only have a single source......and yes I know we can construct mp2p and
mp2mp entities but I would hope it is again intuitively obvious that one
cannot deterministically assign/manage resource here.  If it's not
intuitively obvious then please look at G.800.

		If you do not agree with this then can I suggest you
have a chat with Andy Reid who is largely responible for all the major
functional arch definitions that have appeared in G.805 (co-cs mode
only) and later the more unified treatment in G.800 (unifies func arch
specs that cover all 3 modes).

		[Sprecher, Nurit (NSN - IL/Hod HaSharon)] I do not think
we have disagreement here, but as always I'll be glad to chat with Andy.

		regards, Neil

		  Alos how do we know how many MEs we have in one MEG?
We need to know the type of the MEG, to know whether it groups two
co-routed unidirectional LSPs or maybe it groups N NEs of p2mp LSPs,
etc.? We have one entity which we actually monitor. We have a
requirement to monitor the following entities:

		I think we need to define ME per each of the entities
above, and I can see no justification to split it to multiple entities
which are grouped together in another entity.  

		In Ethernet we also had to talk about MEG level which in
MPLS-TP has no real meaning, because the LSP which is being monitored
actually presents it.......

		As I indicated in previous mails, I believe that we can
have one entity, ME per the entity which is being monitored, and this ME
can be of different types. 

		Best regards,

		Nurit

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Vishwas Manral
		Sent: Wednesday, July 15, 2009 9:12 PM
		To: Rolf Winter
		Cc: [email-masked]
		Subject: Re: [mpls-tp] MEG - who, what and how

		Hi Rolf,

		If I get you right you are stating that for P2MP case we
will have n

		ME's in the MEG and not a single ME. Is that correct? So
an ME is related

		Thanks,

		Vishwas

		> I would like to close the discussion on this as this
might stall the work of a number of people. Based on the discussion we
had I think we're converging but I would like to spill it out and ask
whether this receives a broad consensus or not in order to move forward:

		> A) The OAM framework drafts needs some re-writing in
order to align the terminology closer to what has been defined in the
ITU-T mainly for two reasons:

		>  2) based on the requirements that Neil has mentioned
in an earlier Email which rather fits to the MEG concept of the ITU-T

		> The (main) changes I see right now are to align ME
(e.g. restrict it to 2 MEPs) and include the MEG.

		> B) There is a draft out there (and I personally
believe it is an important one) that describes OAM based on Y.1731. I
fear that other (other than the ITU-T) elements and definitions might
cause problems for this work in terms of confusion but also in terms of
functionality if we are not careful

		> NEC Europe Limited | Registered Office: NEC House, 1
Victoria Road, London W3 6BL | Registered in England 2832014

		>> From: [email-masked]
<[email-masked]>

definitions of ME in

Shahram Davari';

Winter; mpls-

Shahram Davari';

entities (MEs), which

that in MPLS-TP

transport path can be

MPLS transport

MPLS-TP p2p

present in a PTN.

becomes a

MEs.

unidirectional

transport paths, etc.

MPLS-TP transport

the MPLS-TP

"unidirectional p2p

the MPLS-TP

associated

transport entity,

the MPLS-TP layer

contains one MEG and

MPLS-TP we are

p2p. There is no

definition a p2mp

unidirectional

just contain one

between one MEP

transport path layer

include two or more

originated, which is

boundary; and

connection or

single ME. For a

with P2MP.

issue, other times

MEG confusion

are "somehow"

concept? To some

drafts I would like

supposed to

people to better

Victoria Road,

		mpls-tp mailing list

		[email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 17 Jul 2009 13:18:45 +0200

Nitin,

> Again, I'm not clear why you want to use label stacking to identify MEG
level.
> I'm not clear as to why you want to identify the MEG level in the first
place.
>
> In case of MPLS-TP, each LSP by itself will have it's own OAM. Each LSP
and
> end-to-end entity cares about it's own OAM. Whether that LSP goes over 2
other
> layers of LSPs (multiple levels of network elements) should not be a
concern
> for that LSP. By identifying a MEG level for LSPs, you are introducing the
> concept of one layer knowing about the implicit presence of another layer.

>
> When you are performing OAM over a particular layer, the OAM PDU should
have
> sufficient information for an end-point to identify the entity on which
OAM
> is being performed on. If you say that MEG level is one way to identify
the
> layer/entity, then MEG is a *solution* and not a *requirement*. 

As indicated, the use of an MEL field is not required in MPLS-TP OAM PDU.
The MEG Level (e.g. NCM, TCM1, TCM2, LCM) is encoded as a position in the
label stack.

MEG levels do not create new layers. MEG levels create new maintenance
entities within a transport entity in one layer.

Example: there is a bidirectional p2p connection in a PW layer (i.e. a PW
connection), which is carried through two administrative domains. The PW
connection in the PW layer is monitored by the service provider and by each
operator and is protected in the domain of one of the operators.

The p2p connection in the PW layer has the following Maintenance Entity
Groups:
1) (service provider MEG) PW network connection monitoring (NCM) MEG between
the UNI-N ports A and Z
2) (network operator 1 MEG) PW tandem connection/segment monitoring (TCM/SM)
MEG between UNI-N port A and NNI port M
3) (network operator 2 MEG)PW tandem connection/segment monitoring (TCM/SM)
MEG between UNI-N port Z and NNI port N
4) (SNCP Working MEG) PW tandem connection/segment monitoring (TCM/SM) MEG
between NNI port B and NNI port K
5) (SNCP Protection MEG) PW tandem connection/segment monitoring (TCM/SM)
MEG between NNI port C and NNI port L

The encoding of those MEGs is done via label stack entry headers. One of
these label stack entry headers is called PW label, the others (if present)
are called LSP labels. Those LSP labels don't represent an p2p connection in
the LSP layer. Those LSP labels (if present) represent a MEG level in the
p2p connection in the PW layer.

It would be less confusing if the label stack entry headers that are added
for tandem connection/segment monitoring would not be called LSP label. They
should be called e.g. PW MEL label, LSP MEL label.

Regards,
Maarten

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: donderdag 16 juli 2009 21:32
To: 'Maarten Vissers'; 'Sprecher, Nurit (NSN - IL/Hod HaSharon)';
[email-masked]

Hi Maarten,

> The transport entity, ME, MEG and MEG Level are abstract constructs 
> that we have defined to describe a specific application/behaviour.

 
> Note that there is a major difference between the MEG Level as 
> abstract construct and the "MEG Level (MEL)" field in which for 
> Ethernet the abstract MEG Level is encoded.

> The MEG Level as abstract construct is necessary in MPLS-TP OAM,

I am not 100% convinced...probably my lack of knowledge. See more below on
this.

> the MEL field in a MPLS-TP packet is not necessary (but may be present 
> for PDU commonality and is then ignored in the receiver).

Ok.
 
> The consequence of choosing the label stacking method to identify MEG 
> levels in MPLS-TP is that the label stack entry header is now 
> associated with two functions as well:
> 1) identification of client, transport of QoS information, loop 
> mitigation and

Again, I'm not clear why you want to use label stacking to identify MEG
level. I'm not clear as to why you want to identify the MEG level in the
first place.

In case of MPLS-TP, each LSP by itself will have it's own OAM. Each LSP and
end-to-end entity cares about it's own OAM. Whether that LSP goes over 2
other layers of LSPs (multiple levels of network elements) should not be a
concern for that LSP. By identifying a MEG level for LSPs, you are
introducing the concept of one layer knowing about the implicit presence of
another layer. 

When you are performing OAM over a particular layer, the OAM PDU should have
sufficient information for an end-point to identify the entity on which OAM
is being performed on. If you say that MEG level is one way to identify the
layer/entity, then MEG is a *solution* and not a *requirement*. 

Thanks
Nitin