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

[Alexander Vainshtein <[e-mail]>]

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 [[e-mail]]
Sent: Tuesday, January 17, 2012 6:45 PM
To: David Allan I; Alexander Vainshtein
Cc: [e-mail]; BUSI, ITALO (ITALO) ([e-mail]); [e-mail]; Stewart Bryant ([e-mail])
Subject: RE: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

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: [e-mail] [mailto:[e-mail]] On Behalf Of David Allan I
Sent: Tuesday, January 17, 2012 8:08 AM
To: Alexander Vainshtein
Cc: [e-mail]; BUSI, ITALO (ITALO) ([e-mail]); [e-mail]; Stewart Bryant ([e-mail])
Subject: Re: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

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:[e-mail]]
Sent: Tuesday, January 17, 2012 7:48 AM
To: David Allan I
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) ([e-mail]); BUSI, ITALO (ITALO) ([e-mail]); Loa Andersson ([e-mail]); [e-mail]; [e-mail]; Stewart Bryant ([e-mail]); binny jeshan
Subject: RE: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

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:[e-mail]]
Sent: Tuesday, January 17, 2012 5:01 PM
To: Alexander Vainshtein; binny jeshan
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) ([e-mail]); BUSI, ITALO (ITALO) ([e-mail]); Loa Andersson ([e-mail]); [e-mail]; [e-mail]; Stewart Bryant ([e-mail])
Subject: RE: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

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:[e-mail]]
Sent: Tuesday, January 17, 2012 5:27 AM
To: binny jeshan
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) ([e-mail]); David Allan I; BUSI, ITALO (ITALO) ([e-mail]); Loa Andersson ([e-mail]); [e-mail]; [e-mail]; Stewart Bryant ([e-mail])
Subject: RE: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone
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:[e-mail]]
Sent: Tuesday, January 17, 2012 2:39 PM
To: Alexander Vainshtein
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) ([e-mail]); David Allan I ([e-mail]); BUSI, ITALO (ITALO) ([e-mail]); Loa Andersson ([e-mail]); [e-mail]; [e-mail]; Stewart Bryant ([e-mail])
Subject: Re: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone

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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls


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.

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.


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.