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

["BUSI ITALO" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
On Behalf Of Maarten Vissers
	Sent: Wednesday, July 15, 2009 11:04 AM
	To: [e-mail]
	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: [e-mail] [mailto:[e-mail]]
On Behalf Of Maarten Vissers
	Sent: dinsdag 14 juli 2009 9:18
	To: 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'ext Shahram
Davari'; 'Rolf Winter'; [e-mail]
	Subject: Re: [mpls-tp] MEG - who, what and how
	
	
	Nurit,
	 
	See inline..

________________________________

	From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[e-mail]] 
	Sent: maandag 13 juli 2009 20:07
	To: ext Maarten Vissers; ext Shahram Davari; Rolf Winter;
[e-mail]
	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:[e-mail]] 
	Sent: Monday, July 13, 2009 3:43 PM
	To: Sprecher, Nurit (NSN - IL/Hod HaSharon); 'ext Shahram
Davari'; 'Rolf Winter'; [e-mail]
	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: [e-mail] [mailto:[e-mail]]
On Behalf

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

	Sent: zondag 12 juli 2009 9:51

	To: ext Shahram Davari; Rolf Winter; [e-mail]

	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: [e-mail] [mailto:[e-mail]]
On Behalf

	Of ext Shahram Davari

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

	To: Rolf Winter; [e-mail]

	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: [e-mail] [mailto:[e-mail]]
On Behalf

	Of Rolf Winter

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

	To: [e-mail]

	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

	[e-mail]

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

	 

	 

	_______________________________________________

	mpls-tp mailing list

	[e-mail]

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

	_______________________________________________

	mpls-tp mailing list

	[e-mail]

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