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

From: "Rolf Winter" <[email-masked]>
Date: Fri, 10 Jul 2009 16:59:35 +0200

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

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 10 Jul 2009 10:01:37 -0700

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,

Best,

	Rolf

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

---

From: [email-masked]
Date: Sat, 11 Jul 2009 14:21:08 +0800

shahram,
 I don't completely your opinions, IMO. regardless of p2p connection path 
or p2mp connection path. it only need a sinle ME and a single MEG. 
SO for p2p connection or p2mp connection path. each MEG only contains a 
single ME. 
do you think my understanding is true?

regards
liu

"Shahram Davari" <[email-masked]> 
发件人:  [email-masked]
2009-07-11 01:01

收件人
"Rolf Winter" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题
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.

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 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 12 Jul 2009 09:50:46 +0200

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)

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

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 12 Jul 2009 16:22:13 +0200

All,

For the sake of simplicity:

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

Right!

This has the advantage that we do have a single definition of
MEG, ME, MEL, MEP and MIP in PT.
And avoid having to write a draft about interpretation like OAM.

And in addition ASON and GMPLS are using these terms.

MEG = Maintenance Entity Group
ME  = Maintenance Entity
MEL = MEG Level
MEP = MEG End Point
MIP = MEG Intermediate Point

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 12 Jul 2009 08:54:57 -0700

Hi,

I agree with Hubb/ Shahram on this.

Thanks,
Vishwas

On Sun, Jul 12, 2009 at 7:22 AM, Huub van Helvoort<[email-masked]> wrote:
>> 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:
>>

---

From: "Rolf Winter" <[email-masked]>
Date: Mon, 13 Jul 2009 10:16:37 +0200

Shahram,

That is not quite the point that I wanted to make. I know there is a definition for it. The wider question would be whether:

A. the concept is really needed as it does appear in a few drafts but mostly as editorial notes questioning whether something has to be done about it or not.

B. the concept is really a 1:1 mapping and as such applicable to MPLS-TP

C. we are losing ourselves in too many entities that we introduce while we could get away with much less

Best,

	Rolf

> Behalf Of Shahram Davari
> Sent: Freitag, 10. Juli 2009 19:02

---

From: <[email-masked]>
Date: Mon, 13 Jul 2009 09:38:21 +0100

Rolf,

A key point here, which is largely what Huub has already said but in a
different way, is that although a connection MUST have a single source
(see my earlier mail for why, eg wrt deterministic resource management)
we can clearly have p2p and p2mp connection entities.  However a trail
(which is the monitored entity) is a *specific source to sink pair*
relationship.  There is only one such trail relationship in a p2p
connection but there are N such trail relationships in a p2mp connection
entity with N sink end points.

Note:  A mp2p or mp2mp entity cannot and must not be called a
connection...sure they can be created, but they do not allow
deterministic management of resource.  Which is of course why MPLS-TP
will not have such entities.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rolf Winter
> Sent: 13 July 2009 09:17
> To: Shahram Davari; [email-masked]
> That is not quite the point that I wanted to make. I know 
> there is a definition for it. The wider question would be whether:
> 
> A. the concept is really needed as it does appear in a few 
> drafts but mostly as editorial notes questioning whether 
> something has to be done about it or not.
> 
> C. we are losing ourselves in too many entities that we 
> introduce while we could get away with much less
> 
> Best,
> 
> 	Rolf
> 
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
>  
>

---

From: "Rolf Winter" <[email-masked]>
Date: Mon, 13 Jul 2009 10:39:54 +0200

Hi,

I generally I agree that we should not introduce widely differing terminologies ending up causing confusion all over the place. Let me resort to quotation to make myself clear:

The OAM framework draft defines:

  "A Maintenance Entity can be viewed as the association of two (or
   more) Maintenance End Points (MEPs). An example of an ME with more
   than two MEPs is a point-to-multipoint ME monitoring a point-to-
   multipoint transport path (or point-to-multipoint tandem connection)."

How does that differ from a MEG in the P2MP case? It does by having only a single ME but is the general functionality the same? If so do we need the MEG?

I think the definition of ME here already diverts from what the ITU-T specs tell us. I am not saying it's good, I am not saying it's bad. I am just saying it is. My point is, if we already have something that gives us what we need in terms of functionality in the IETF MPLS-TP documents (not the ITU-T documents), then do we need more?

Best,

	Rolf

> Behalf Of Huub van Helvoort
> Sent: Sonntag, 12. Juli 2009 16:22
> To: Shahram Davari
> Cc: [email-masked]
> > 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:
> >

---

From: "Rolf Winter" <[email-masked]>
Date: Mon, 13 Jul 2009 10:43:34 +0200

Neil,

Thank you. This is part of what I have asked in another Email thread and should be part of the OAM requirements draft IMO. You are saying that in a the P2MP ALL source-sink relationships MUST be separately OAM-able. If that is the case, I think the solution will be clear.

It's always good to hear from operators. Please continue :)

Thanks,

	Rolf

> From: [email-masked] [mailto:[email-masked]]
> Sent: Montag, 13. Juli 2009 10:38
> To: Rolf Winter; [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] MEG - who, what and how
> 
> Rolf,
>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 13 Jul 2009 12:41:02 +0200

Neil,

> Note:  A mp2p or mp2mp entity cannot and must not be called a
connection...
> sure they can be created, but they do not allow deterministic management
> of resource.  

Most people refer to p2p, p2mp, mp2p, rmp and mp2mp transport entities as
"p2p, p2mp, mp2p, rmp and mp2mp connections".

All those "p2p/p2mp/mp2p/rmp/mp2mp connections" can be equipped with
deterministic management of their resources, when those resources are
provided as p2p traffic engineered link connections. This is in operation
today in some networks.

Example: a "mp2mp connection" consists of a number of p2p link connections
which interconnect a set of (p2p and) mp2mp matrix connections. The p2p link
connections are traffic engineered, including bandwidth reservation and
traffic conditioning (CIR only, CIR+EIR, or EIR only) at their input port.
This traffic conditioning is performed at the egress ports in the network
elements, deploying in case of Ethernet the clause 8.6.5/802.1Q function
located on the egress port. 

This traffic engineering of e.g. mp2mp and rmp connections provides very
deterministic management of the resources of those mp2mp and rmp
connections. Operators that deploy such traffic engineering are able to
provide QoS guarantees to their customers (e.g. ISPs, businesses). Those
(CIR only, or CIR+EIR) traffic engineered mp2mp and rmp connections support
"premium E-LAN" and "premium E-Tree" services.

Note that the transfer of user frames and OAM frames through such traffic
engineered mp2mp or rmp connections are subject to traffic conditioning at
the input port of each p2p link connection. Frames may be discarded when
frame rate exceeds the link connection rate (similar to such discarding in
physical LAN networks when frame rate exceeds PHY rate).

Error performance monitoring (frame loss) is guaranteed in those traffic
engineered mp2mp and rmp connections on a per p2p link connection basis.
Connectivity is guaranteed between the endpoints of the mp2mp or rmp
connection.

> Which is of course why MPLS-TP will not have such entities. 

Wrong conclusion in my opinion. The use of "platform label space" creates
automatically "mp2p connections" in MPLS-TP. Only if MPLS-TP would deploy
only per interface label space you would not get by default mp2p
connections.

Example: a MPLS-TP node has a switch fabric interconnecting e.g. 10 ports;
with platform label space you can send packets with label Y into any of the
10 ports and all those packets will be output on e.g. port 7 with label X
(if connection is administered as input label: Y, output port: 7, output
label: X).

You can **restrict** the use of such mp2p matrix connection by sending
packets with label Y only on e.g. input port 3. The mp2p connection then
**behaves for its client** as a p2p connection.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: maandag 13 juli 2009 10:38
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] MEG - who, what and how

Rolf,

A key point here, which is largely what Huub has already said but in a
different way, is that although a connection MUST have a single source (see
my earlier mail for why, eg wrt deterministic resource management) we can
clearly have p2p and p2mp connection entities.  However a trail (which is
the monitored entity) is a *specific source to sink pair* relationship.
There is only one such trail relationship in a p2p connection but there are
N such trail relationships in a p2mp connection entity with N sink end
points.

Note:  A mp2p or mp2mp entity cannot and must not be called a
connection...sure they can be created, but they do not allow deterministic
management of resource.  Which is of course why MPLS-TP will not have such
entities.

regards, Neil

> That is not quite the point that I wanted to make. I know there is a 
> definition for it. The wider question would be whether:
> 
> A. the concept is really needed as it does appear in a few drafts but 
> mostly as editorial notes questioning whether something has to be done 
> about it or not.
> 
> > multipoint ETH connectivity.

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 13 Jul 2009 12:46:40 +0200

Rolf,

As Shahram and Huub have indicated the OAM draft should use (or refer) to
the original Y.1731 ME and MEG definitions. It seems that the currect text
in the OAM draft has merged these two definitions. What should be done in
such case is to define ME (between two MEPs) and ME Group (between n MEPs).

Regards,
Maarten  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rolf Winter
Sent: maandag 13 juli 2009 10:40
To: [email-masked]; Shahram Davari
Cc: [email-masked]
Subject: Re: [mpls-tp] MEG - who, what and how

Hi,

I generally I agree that we should not introduce widely differing
terminologies ending up causing confusion all over the place. Let me resort
to quotation to make myself clear:

How does that differ from a MEG in the P2MP case? It does by having only a
single ME but is the general functionality the same? If so do we need the
MEG?

I think the definition of ME here already diverts from what the ITU-T specs
tell us. I am not saying it's good, I am not saying it's bad. I am just
saying it is. My point is, if we already have something that gives us what
we need in terms of functionality in the IETF MPLS-TP documents (not the
ITU-T documents), then do we need more?

Best,

	Rolf

> This has the advantage that we do have a single definition of MEG, ME, 
> MEL, MEP and MIP in PT.
> 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:
> >
> operate/being implemented and how should we call it in order for 
> people to better understand what its purpose really is?
> >
> > Best,
> >
> >
> > 	Rolf
> >

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 13 Jul 2009 14:42:40 +0200

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). 

When n=2, the bidirectional "mp2mp transport entity" becomes a bidirectional
"p2p transport entity" with one MEG and  2*(2-1) = 2 MEs. 

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. 

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.

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-----
Of ext Shahram Davari

Rolf,

5.2 ME Group (MEG)
multipoint ETH connectivity containing n end-points, a MEG contains
n*(n-1)/2 MEs.

Regards,
Shahram

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

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

---

From: "Rolf Winter" <[email-masked]>
Date: Mon, 13 Jul 2009 17:14:29 +0200

Hey Shahram,

> Another reason we need the MEG concept is that MEG also includes MIPs,
> while
> ME does not.

That's what you say. That's not what the OAM framework draft says :)

I think we are getting to the bottom of this. And I don't think this is generally a big issue. All I want out of this discussion is a consistent view of the OAM framework together with all the other drafts. What I would like is consensus in this group on how to go forward with this. I think to some extent, see an earlier Email I've sent, the OAM requirements draft will need to express the right set of requirement from which to derive this in terms of functionality. The rest will be terminology and I hope we can avoid something like the earlier dispute about co-routed and associate bi-directional (please).

Best,

	Rolf

> Behalf
> Sent: July-13-09 1:40 AM
> > > For a point-to-point ETH connection, a MEG contains a single ME.
> For
> > a multipoint ETH
> the
> people

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 13 Jul 2009 11:01:27 -0700

I agree with Nurit.

Thanks,
Shahram 

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

Nurit,

Regards,
Maarten

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

Hi,

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

Rolf,

5.2 ME Group (MEG)

Regards,
Shahram

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

Hi,

Best,

	Rolf

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 13 Jul 2009 20:07:08 +0200

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,

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.

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

[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.

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?

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. 

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. 

Regards,

Maarten

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

Hi,

and

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,

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,

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.

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:

operate/being

Best,

      Rolf

London

 

mpls-tp mailing list

[email-masked]

 

mpls-tp mailing list

[email-masked]

mpls-tp mailing list

[email-masked]

---

From: <[email-masked]>
Date: Mon, 13 Jul 2009 19:33:19 +0100

Well said Nurit...I agree with you, esp on the reason we are restricting
attention in MPLS-TP to p2p and p2mp transport entity constructs.  And
you will find Andy Reid of BT also strongly agrees on this point....when
you get down to the (info theory) detail (as Andy as done in G.800) this
is only way one can create resource determinisim...which is rather
important for a transport network and a whole raft of important
operational/service considerations that follow from this, and this is
why MPLS-TP is quite rightly only focussing on p2p and p2mp.  There is
more than to networking than simply firing off a load of CV OAM packets
between a set of access points!
 
regards, Neil  

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
	Sent: 13 July 2009 19:07
	To: ext Maarten Vissers; ext Shahram Davari; Rolf Winter;
[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,

	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

	[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.

	[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.

	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. 

	[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. 

	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

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

	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)

	conditions:

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

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,

	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 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:

	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]

---

From: <[email-masked]>
Date: Tue, 14 Jul 2009 00:09:59 +0100

Rolf,

Speaking for myself as a co-author of the OAM framework. 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.

Now the reality is the OAM framework is probably lagging a little behind and
is not fully aligned in terms of terminology with ITU (and probably some of
the other MPLS-TP drafts) yet. That will be fixed as we go forward (I, at
least, was not a expert in ITU OAM terminology coming into this)

Ben

On 13/07/2009 16:14, "Rolf Winter" <[email-masked]> wrote:

> I think we are getting to the bottom of this. And I don't think this is
> generally a big issue. All I want out of this discussion is a consistent view
> of the OAM framework together with all the other drafts. What I would like is
> consensus in this group on how to go forward with this. I think to some
> extent, see an earlier Email I've sent, the OAM requirements draft will need
> to express the right set of requirement from which to derive this in terms of
> functionality. The rest will be terminology and I hope we can avoid something
> like the earlier dispute about co-routed and associate bi-directional
> (please).
> 
> 
> Best,
> 
>         Rolf
> 
> 
>> Regards,
>> Shahram
>>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 14 Jul 2009 01:28:30 +0200

Hi Ben,
I think we should consider which of the entities it makes sense to
define in MPLS-TP. 
I do not think we have a target to fully adopt the ITU-T entities and
terminology. 
We have the requirements for MPLS-TP which integrate also the
requirements of the ITU-T. 
In the framework and the solutions we need (1) to re-use (as far as
practically possible) existing MPLS mechanisms, and (2) ensure complete
interoperability with IP/MPLS. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext [email-masked]
Sent: Tuesday, July 14, 2009 2:10 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MEG - who, what and how

Rolf,

Speaking for myself as a co-author of the OAM framework. 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.

Now the reality is the OAM framework is probably lagging a little behind
and
is not fully aligned in terms of terminology with ITU (and probably some
of
the other MPLS-TP drafts) yet. That will be fixed as we go forward (I,
at
least, was not a expert in ITU OAM terminology coming into this)

Ben

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

---

From: <[email-masked]>
Date: Tue, 14 Jul 2009 01:14:33 +0100

Nurit,

I did not mean to imply otherwise.

The entities described will be driven by the entities required to meet the
OAM requirements.

We will use the minimum possible set of terminology to describe those
entities.

We will align that terminology with existing IETF and ITU (as appropriate)
terminology as far as practically possible.

Hope that clears up any confusion from my previous mail.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 14 Jul 2009 09:17:50 +0200

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,

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

Nurit,

[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.

[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".

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.

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] 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-----

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: "Rolf Winter" <[email-masked]>
Date: Tue, 14 Jul 2009 10:00:39 +0200

Ben,

I completely agree. But I think we have to understand that the only sensible approach is to 

a) derive this from the requirements which I think are still a bit underspecified
B) not model the framework so as to preclude a set of solutions prematurely as I don't think we are quite there yet to make such hard decisions

I brought this to the attention of the list (or rather the OAM framework authors decided so) as this is an issue that is much wider than the OAM framework draft itself, i.e. a set of drafts are and will be affected by this. 

Best,

	Rolf

> Behalf Of [email-masked]
> Sent: Dienstag, 14. Juli 2009 01:10
> To: Rolf Winter; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> >> single ME but is the general functionality the same? If so do we
> need
> >> the
> >> MEG?
> >>
> >> I think the definition of ME here already diverts from what the ITU-
> T
> >> specs
> >> saying it is. My point is, if we already have something that gives
> us
> >> what
> On
> >>> the MEG confusion maybe. The question is, does one need this
> concept
> >> at
> >>> functionality question. Since this seem to be at least considered
> by
> >> a

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 14 Jul 2009 21:02:28 +0200

Hi Maarten,

Thanks for you response.

Please see inline <NS>.

Best regards,

Nurit

Sent: Tuesday, July 14, 2009 10:18 AM

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'; 'Rolf

Nurit,

[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.

<NS> we need to be very careful to explicitly indicate what we are
referring to. In the IETF MPLS-TP mailing list we were referring to
MPLS-TP transport entities which are p2p or p2mp. Although you are
pushing for a new work on the ITU-T SG15 on PTN, we still do not have
such a recommendation which defines all these entities. I think in the
discussions on MPLS-TP we should focus on what is required in MPLS-TP.
Talking about "n-port mp2mp transport entity" is something very
confusing in MPLS-TP discussions. 

[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. 

<NS> PW (SS or MS) is one of the clients of MPLS-TP transport layer.  

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". 

<NS> we need to differentiate between the cases of unidirectional p2p,
associated bidirectional p2p and co-routed bidirectional p2p. The type
of the ME should indicate actually what kind of information we need to
keep. 

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

one MEG and one ME.

[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. 

<NS> In ITU-T documents. We need to consider if this is really needed in
MPLS-TP. It may be that if we have a ME and it is clear what kind of ME
we have (e.g. unidirectional P2p ME, associated bidirectional p2p ME,
co-routed bidirectional p2p ME, unidirectional p2mp, etc.), we do not
need more entities.  MEG does not provide enough information. In p2p for
example you need more information in order to know what kind of
information is needed to monitor and maintain. 

A co-routed bidirectional p2p transport path contains one MEG and two
MEs. 

<NS> I am not sure why we need so many entities. We could just simplify
it. 

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.

MEs. 

[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. 

<NS> I cannot understand how this relate to my comment on n-port p2mp. 

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

<NS> we are now in the definition part and I do not think we have an
agreement here. 

<NS> This is a new issue,  what kind of MEGs we can have?

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: "Adrian Farrel" <[email-masked]>
Date: Tue, 14 Jul 2009 22:12:09 +0100

Hi,

While I appreciate the need for discussion of mp2p and mp2mp services in 
transport PSNs, I believe this is architectural and functional requirements 
work that should be carried out in the ITU-T before it is discussed further 
in the IETF.

The scope of the current MPLS-TP work is clearly set out in 
draft-ietf-mpls-tp-requirements-09.txt which has received approval from the 
ITU-T community. That document requires support for P2P and P2MP services, 
but does not require any other type of multipoint service. At this stage it 
is a distraction from the work of the IETF to debate these other services on 
the MPLS-TP list, and I would ask the participants to take their discussions 
elsewhere (perhaps to an appropriate ITU-T mail exploder).

(Discussions of what is a MEG in the MPLS-TP context are, of course, still 
very welcome.)

Many thanks,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 15 Jul 2009 11:04:16 +0200

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..

  _____  

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

Nurit,

one MEG and one ME.

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: "BUSI ITALO" <[email-masked]>
Date: Wed, 15 Jul 2009 15:06:55 +0200

For information, the terms ME and MEG are also used in the scope of
L2VPN OAM:
http://tools.ietf.org/html/draft-ietf-l2vpn-oam-req-frmk-10
<http://tools.ietf.org/html/draft-ietf-l2vpn-oam-req-frmk-10>  

Italo

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Maarten Vissers
	Sent: Wednesday, July 15, 2009 11:04 AM
	To: [email-masked]
	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

	Nurit,

	[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.

	[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".

	one MEG and one ME.

	[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.

	MEs. 

	[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] 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-----

	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: "Rolf Winter" <[email-masked]>
Date: Thu, 16 Jul 2009 11:51:37 +0200

Nurit,

This is right to the point I think. This is what the requirements documents states. Use MPLS and ensure what we propose is compatible. Whenever MPLS as specified does not meet transport requirements we need to make adjustments/extensions. I personally think OAM is where transport networks have special requirements. Resorting to specs that have dealt with these requirements seems a sensible approach to me. Whether we need to fully adopt them or partly is a different question and we need to figure this one out.

Best,

	Rolf

> Sent: Dienstag, 14. Juli 2009 01:29
> To: [email-masked]; Rolf Winter; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]