Subject: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 17 Jan 2012 14:17:40 +0200

Hi all,
I'd like to point to a discrepancy between the definitions of the Maintenance Entity (ME) for MPLS-TP that I've encountered when reading two related documents:

RFC 6371<http://tools.ietf.org/html/rfc6371> provides the following definition in Section 3.1:

MPLS-TP OAM operates in the context of Maintenance Entities (MEs) that define a relationship between two points of a transport path to which maintenance and monitoring operations apply.

The latest version of the Rosetta stone draft provides the following definition in Section 3.43.

A Maintenance Entity can be viewed as the association of two (or more) Maintenance End Points (MEPs), that should be configured and managed in order to bound the OAM responsibilities of an OAM flow across a network or sub-network, i.e. a transport path or segment, in the specific layer network that is being monitored and managed.

These definitions seem to differ:  the 6371 definition allows exactly two points (later defined as MEPs) in an ME, while the Rosetta stone draft allows two or more such points. E.g., a P2MPMPLS-TP LSP can be treated as a single ME by the Rosetta stone definition but not by the 6371 one.

It would be nice to know which definition is correct, and why. If 6371 is wrong, we should file an Erratum on it.

Regards, and lots fo thanks in advance,
     Sasha

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: binny jeshan <[email-masked]>
Date: Tue, 17 Jan 2012 18:09:07 +0530

Hello Sasha,

Are we now bringing some relation between MEG and the ME?

Section 3.1 also says,

In between MEPs, there are zero or more intermediate points, called Maintenance
   Entity Group Intermediate Points (MIPs).  MEPs and MIPs are
   associated with the MEG and can be shared by more than one ME in a
   MEG.

Regards,
Binny.

On 17 January 2012 17:47, Alexander Vainshtein <
[email-masked]> wrote:

> Hi all,****
>
> I’d like to point to a discrepancy between the definitions of the
> Maintenance Entity (ME) for MPLS-TP that I’ve encountered when reading two
> related documents:****
>
> ** **
>
> RFC 6371 <http://tools.ietf.org/html/rfc6371> provides the following
> definition in Section 3.1:****
>
> ** **
>
> *MPLS-TP OAM operates in the context of Maintenance Entities (MEs) that
> define a relationship between two points of a transport path to which
> maintenance and monitoring operations apply.*
>
> ** **
>
> The latest version of the Rosetta stone draft provides the following
> definition in Section 3.43.****
>
> ** **
>
> *A Maintenance Entity can be viewed as the association of two (or more) Maintenance End Points (MEPs), that should be configured and managed in order to bound the OAM responsibilities of an OAM flow across a network or sub-network, i.e. a transport path or segment, in the specific layer network that is being monitored and managed.*
>
> ** **
>
> These definitions seem to differ:  the 6371 definition allows exactly two
> points (later defined as MEPs) in an ME, while the Rosetta stone draft
> allows two or more such points. E.g., a P2MPMPLS-TP LSP can be treated as a
> single ME by the Rosetta stone definition but not by the 6371 one. ****
>
> ** **
>
> It would be nice to know which definition is correct, and why. If 6371 is
> wrong, we should file an Erratum on it.****
>
> ** **
>
> Regards, and lots fo thanks in advance,****
>
>      Sasha****
>
> ** **
>
> This e-mail message is intended for the recipient only and contains
> information which is CONFIDENTIAL and which may be proprietary to ECI
> Telecom. If you have received this transmission in error, please inform us
> by e-mail, phone or fax, and then delete the original and all copies
> thereof.
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 17 Jan 2012 15:27:09 +0200

Binny hi,
There is supposed to be some relationship between ME and MEG.
But it depends, among other things, on the ME definition.

E.g., according to the Rosetta stone draft, a P2MP MPLS-TP LSP can be treated as a single ME, but in the 6371 definition it has to be treated as a MEG comprised of multiple MEs that all share a common MEP at the root of the P2MP LSP.

I am not even sure if MEG is really required with the Rosetta stone draft definition.

Regards,
     Sasha

From: binny jeshan [mailto:[email-masked]]
Sent: Tuesday, January 17, 2012 2:39 PM
To: Alexander Vainshtein
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) ([email-masked]); David Allan I ([email-masked]); BUSI, ITALO (ITALO) ([email-masked]); Loa Andersson ([email-masked]); [email-masked]; [email-masked]; Stewart Bryant ([email-masked])
Subject: Re: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

Hello Sasha,

Section 3.1 also says,

   MEG.

Regards,
Binny.

On 17 January 2012 17:47, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
I'd like to point to a discrepancy between the definitions of the Maintenance Entity (ME) for MPLS-TP that I've encountered when reading two related documents:

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

---

From: David Allan I <[email-masked]>
Date: Tue, 17 Jan 2012 10:01:08 -0500

I believe 6371 should be correct, as LSP availability state is pairwise, else multiple MEPs is simply a MEG.

So you are correct in noting that if Rosetta is deemed correct, MEG becomes a redundant definition...

Dave

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, January 17, 2012 5:27 AM
To: binny jeshan
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) ([email-masked]); David Allan I; BUSI, ITALO (ITALO) ([email-masked]); Loa Andersson ([email-masked]); [email-masked]; [email-masked]; Stewart Bryant ([email-masked])
Subject: RE: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

Binny hi,

Regards,
     Sasha

Hello Sasha,

Section 3.1 also says,

   MEG.

Regards,
Binny.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 17 Jan 2012 17:47:41 +0200

Dave,
Lots of thanks for a prompt response.

Not sure I fully understand the explanation though - could you please elaborate?

One point that looks non-trivial to me is the concept of the same MEP being shared by multiple MEs in a MEG.
This concept is necessary in the 6371 definition since the MEP at the root of the P2MP LSP will always send OAM packets to all the leaf MEPs (there is no other way for the OAM packets to fate-share with the data packets).
At the same time to me it implies that ME (in its present form) is a redundant notion. E.g., does this definition preclude declaring a pair of leaf MEPs of a P2MP LSP being an ME? If it does, deducing this from the text of the RFC is non-trivial IMO. Or do I miss something trivial?

Regards,
     Sasha

From: David Allan I [mailto:[email-masked]]
Sent: Tuesday, January 17, 2012 5:01 PM
To: Alexander Vainshtein; binny jeshan
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) ([email-masked]); BUSI, ITALO (ITALO) ([email-masked]); Loa Andersson ([email-masked]); [email-masked]; [email-masked]; Stewart Bryant ([email-masked])
Subject: RE: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

Dave

Regards,
     Sasha

Hello Sasha,

Section 3.1 also says,

   MEG.

Regards,
Binny.

---

From: David Allan I <[email-masked]>
Date: Tue, 17 Jan 2012 11:07:58 -0500

HI Sasha:

My way of thinking of it is that yes, the root will attempt to send OAM packets to all leaves, but all leaves do not collectively fate share, nor will have identical performance characteristics. Each effectively has a unique relationship with the root, hence ME. A MEG is the set of such relationships for an LSP. That the set of MEs in the MEG will have some common components is an artifact of the effeciency introduced by the use of multicast.

At the time, it seemed to me to be the only rational way to properly deconstruct the terminology.

cheers
Dave

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Tuesday, January 17, 2012 7:48 AM
To: David Allan I
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) ([email-masked]); BUSI, ITALO (ITALO) ([email-masked]); Loa Andersson ([email-masked]); [email-masked]; [email-masked]; Stewart Bryant ([email-masked]); binny jeshan
Subject: RE: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

Dave,

Regards,
     Sasha

Dave

Regards,
     Sasha

Hello Sasha,

Section 3.1 also says,

   MEG.

Regards,
Binny.

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 17 Jan 2012 11:45:27 -0500

Dear All,
I concur with Dave. PM is, AFAIK, p2p relationship, hence it is ME relationship in context of RFC 6371.
RFC 6428 refers to MEG as single OAM object for co-routed or associated bi-directional LSPs (Section 3.7, third para). In regard to MEs co-routed p2p LSP is presented as single ME while associated p2p LSP, IMO, presented as two MEs.
I think that ME definition in Rossetta Stone can be modified and definition of MEG, consistent with RFC 6371, added.

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Tuesday, January 17, 2012 8:08 AM
To: Alexander Vainshtein
Cc: [email-masked]; BUSI, ITALO (ITALO) ([email-masked]); [email-masked]; Stewart Bryant ([email-masked])
Subject: Re: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

HI Sasha:

cheers
Dave

Dave,

Regards,
     Sasha

Dave

Regards,
     Sasha

Hello Sasha,

Section 3.1 also says,

   MEG.

Regards,
Binny.

---

From: <[email-masked]>
Date: Tue, 17 Jan 2012 19:18:25 +0000

Dave and Greg are right.  And Dave's explanation below gives the reasons why mtce and performance relationships are between a specific source trail term pt and a specific sink trail term pt.  If one did not have such pairwise relationships then on the partial failure of a p2mp connection how could one define what an availability metric meant?  Similar considerations apply to the (up-state) variance in performance (errors/loss/delay) that one can experience between different source to sink pairs in a p2mp connection.

regards, Neil

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: 17 January 2012 16:45
To: David Allan I; Alexander Vainshtein
Cc: [email-masked]; Stewart Bryant ([email-masked]); BUSI, ITALO (ITALO) ([email-masked]); [email-masked]
Subject: Re: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

Dear All,

    Regards,
        Greg

cheers
Dave

Regards,
     Sasha

Dave

Regards,
     Sasha

Hello Sasha,

Section 3.1 also says,

   MEG.

Regards,
Binny.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 18 Jan 2012 07:35:41 +0200

Dear Greg, Dave and all,
I do not have a strong opinion regarding which document has it right.

I have a couple of minor comments/questions?:

 1.  I have not found any explicit linkage between the type of the monitored bi-directional LSP (co-routed or associated) and the number of MEs associated with the LSP in RFC 6428. In particular, this document discusses coordinated vs. independent modes of running BFD in G-ACh, but neither is this distinction explicitly related to the distinction between co-routed vs. associated bidirectional LSPs, nor are BFD sessions identified with MEs. Greg, could you please elaborate? Further, I think that some LSP performance measurements for a co-routed bi-directional LSP (packet loss, unidirectional delay and unidirectional delay variation) can be quite different for the two directions of LSP (e.g., due to congestion in one of the directions created by unidirectional P2P and/or P2MP LSPs using the same links, or simply due to the difference in BW required in these two directions). Does this imply that the two directions of such an LSP should be treated as two MEs?
 2.  I do not think that the source MEP sharing by multiple MEs in a P2MP LSP is an artifact of multicast. To the best of my understanding, there is no way to send OAM packets to just one specific leaf MEP of an MPLS-TP P2MP LSP in a fate-sharing way. Dave, do I miss something?

Regards, and lots of thanks in advance,

     Sasha

________________________________
From: Gregory Mirsky [[email-masked]]
Sent: Tuesday, January 17, 2012 6:45 PM
To: David Allan I; Alexander Vainshtein
Cc: [email-masked]; BUSI, ITALO (ITALO) ([email-masked]); [email-masked]; Stewart Bryant ([email-masked])
Subject: RE: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

Dear All,

    Regards,
        Greg

HI Sasha:

cheers
Dave

Dave,

Not sure I fully understand the explanation though – could you please elaborate?

Regards,
     Sasha

Dave

Regards,
     Sasha

Hello Sasha,

Section 3.1 also says,

   MEG.

Regards,
Binny.

On 17 January 2012 17:47, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
I’d like to point to a discrepancy between the definitions of the Maintenance Entity (ME) for MPLS-TP that I’ve encountered when reading two related documents: