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

Gregory Mirsky <gregory.mirsky@ericsson.com> Tue, 17 January 2012 16:46 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C8E21F86CF for <mpls@ietfa.amsl.com>; Tue, 17 Jan 2012 08:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IRsRyPLvQ-S for <mpls@ietfa.amsl.com>; Tue, 17 Jan 2012 08:46:00 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id CDBC921F86DC for <mpls@ietf.org>; Tue, 17 Jan 2012 08:45:59 -0800 (PST)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q0HGjX85000340; Tue, 17 Jan 2012 10:45:34 -0600
Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.105]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 17 Jan 2012 11:45:28 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: David Allan I <david.i.allan@ericsson.com>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Date: Tue, 17 Jan 2012 11:45:27 -0500
Thread-Topic: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone
Thread-Index: AczVFRaim0qumYG1SIif/F35xnVycAABc+jwAANli/AAAVD0AAAAtJrgAAEbe2A=
Message-ID: <FE60A4E52763E84B935532D7D9294FF1322AEB260B@EUSAACMS0715.eamcs.ericsson.se>
References: <A3C5DF08D38B6049839A6F553B331C760115EDDBDDDB@ILPTMAIL02.ecitele.com> <CAHcPYOwY6aKJ08CYOn=jC6ObA+eMgOSkz+13DMQB8bboNyrXZQ@mail.gmail.com> <A3C5DF08D38B6049839A6F553B331C760115EDDBDE37@ILPTMAIL02.ecitele.com> <60C093A41B5E45409A19D42CF7786DFD522A1E9A83@EUSAACMS0703.eamcs.ericsson.se> <A3C5DF08D38B6049839A6F553B331C760115EDDBDEE8@ILPTMAIL02.ecitele.com> <60C093A41B5E45409A19D42CF7786DFD522A1E9B84@EUSAACMS0703.eamcs.ericsson.se>
In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD522A1E9B84@EUSAACMS0703.eamcs.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF1322AEB260BEUSAACMS0715e_"
MIME-Version: 1.0
Cc: "mpls@ietf.org" <mpls@ietf.org>, "Stewart Bryant (stbryant@cisco.com)" <stbryant@cisco.com>, "BUSI, ITALO (ITALO) (italo.busi@alcatel-lucent.com)" <italo.busi@alcatel-lucent.com>, "huubatwork@gmail.com" <huubatwork@gmail.com>
Subject: Re: [mpls] Maintenance Entity definition for MPLS-TP: a discrepancy between RFC 6371 and draft-ietf-mpls-rosetta-stone
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2012 16:46:04 -0000

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: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of David Allan I
Sent: Tuesday, January 17, 2012 8:08 AM
To: Alexander Vainshtein
Cc: mpls@ietf.org; BUSI, ITALO (ITALO) (italo.busi@alcatel-lucent.com); huubatwork@gmail.com; Stewart Bryant (stbryant@cisco.com)
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:Alexander.Vainshtein@ecitele.com]
Sent: Tuesday, January 17, 2012 7:48 AM
To: David Allan I
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) (nurit.sprecher@nsn.com); BUSI, ITALO (ITALO) (italo.busi@alcatel-lucent.com); Loa Andersson (loa@pi.nu); huubatwork@gmail.com; mpls@ietf.org; Stewart Bryant (stbryant@cisco.com); 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:david.i.allan@ericsson.com]
Sent: Tuesday, January 17, 2012 5:01 PM
To: Alexander Vainshtein; binny jeshan
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) (nurit.sprecher@nsn.com); BUSI, ITALO (ITALO) (italo.busi@alcatel-lucent.com); Loa Andersson (loa@pi.nu); huubatwork@gmail.com; mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
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:Alexander.Vainshtein@ecitele.com]
Sent: Tuesday, January 17, 2012 5:27 AM
To: binny jeshan
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) (nurit.sprecher@nsn.com); David Allan I; BUSI, ITALO (ITALO) (italo.busi@alcatel-lucent.com); Loa Andersson (loa@pi.nu); huubatwork@gmail.com; mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
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:binnyjeshan@gmail.com]
Sent: Tuesday, January 17, 2012 2:39 PM
To: Alexander Vainshtein
Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon) (nurit.sprecher@nsn.com); David Allan I (david.i.allan@ericsson.com); BUSI, ITALO (ITALO) (italo.busi@alcatel-lucent.com); Loa Andersson (loa@pi.nu); huubatwork@gmail.com; mpls@ietf.org; Stewart Bryant (stbryant@cisco.com)
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 <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> 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
mpls@ietf.org<mailto:mpls@ietf.org>
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.