Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Gregory Mirsky <gregory.mirsky@ericsson.com> Wed, 13 March 2013 22:37 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 3C34F21F8A99 for <mpls@ietfa.amsl.com>; Wed, 13 Mar 2013 15:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 OdejQRRqgcDB for <mpls@ietfa.amsl.com>; Wed, 13 Mar 2013 15:36:56 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id DA71411E8103 for <mpls@ietf.org>; Wed, 13 Mar 2013 15:36:51 -0700 (PDT)
X-AuditID: c6180641-b7faf6d00000096b-c3-5140ff821536
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BF.07.02411.38FF0415; Wed, 13 Mar 2013 23:36:51 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 18:36:50 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Shahram Davari <davari@broadcom.com>
Thread-Topic: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)
Thread-Index: AQHOIDqiu6Z2uMbcmE2nvQTGP+NdF5ikNXVg
Date: Wed, 13 Mar 2013 22:36:49 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF112070535@eusaamb103.ericsson.se>
References: <512C960E.70109@pi.nu> <4A6CE49E6084B141B15C0713B8993F281BD962A2@SJEXCHMB12.corp.ad.broa> <4A6CE49E6084B141B15C0713B8993F281BD9AAF4@SJEXCHMB12.corp.ad.broa> <XNM1$7$0$0$$6$1$2$A$5004088U513f719e@hitachi.com> <4A6CE49E6084B141B15C0713B8993F281BD9AB6D@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11206FBD5@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F281BD9BA48@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF112070391@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F281BD9BB39@SJEXCHMB12.corp.ad.broadcom.com>, <7347100B5761DC41A166AC17F22DF1120703DD@eusaamb103.ericsson.se> <0D4312C0-ED50-4839-B1B0-9D4BF696F88E@broadcom.com> <7347100B5761DC41A166AC17F22DF1120704C4@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F281BD9BD97@SJEXCHMB12.corp.ad.broadcom.com>
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD9BD97@SJEXCHMB12.corp.ad.broadcom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.135]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF112070535eusaamb103ericsso_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZXLrHW7f5v0OgwdRVchbrez0tmm+dZbe4 /uU9k8WSlx3sFt8vLWGxuLV0JasDm8es+2fZPFrPrGHxWLLkJ5PHl8uf2QJYorhsUlJzMstS i/TtErgytmy4zlbw7yBzxYZ3s5gbGK/3MHcxcnJICJhIHNm6jBXCFpO4cG89WxcjF4eQwBFG ibXP9rNCOMsZJeY8280CUsUmYCTxYmMPO4gtIqAhcfDWFWaQImaB7UwSty/PZAJJCAuUSUx/ tooVoqhc4vv9i4xdjBxAtpHEr6cCIGEWAVWJ/vZ+RhCbV8Bb4tSbeYwQyy6ySSxt/wDWyykQ LrG3ZT7YMkag876fWgM2n1lAXOLWk/lMEGcLSCzZcx7qHVGJl4//Qb2jLPF9ziMWkL3MAvkS P7vjIXYJSpyc+YRlAqPoLCSTZiFUzUJSBVGiI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i 5CgtTi3LTTcy3MQIjMljEmyOOxgXfLI8xCjNwaIkzhvqeiFASCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA2OysHbytas3wnV/c00K8N/t5viLa2Pehd77yofYdH/taTE2WRl7t2m3sv9+tgoz mTb1y0nVAukNjgEZP6bpn66ybr4UIHgsYFPlxh1rJ4U6xT49wc6y2S5p714ZhbK8X1Mm7jjy 6unJqdtbZDeYp4qt+r5ng+ba9WbpVzmy95e5ph2bdUKU67YSS3FGoqEWc1FxIgDhol14lwIA AA==
Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "mpls-ads@tools.ietf.org" <mpls-ads@tools.ietf.org>, "draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org" <draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>
Subject: Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)
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: Wed, 13 Mar 2013 22:37:02 -0000

Hi Shahram,
I think that we came to state of declaring personal preferences and discussing specifics of various implementations.

    Best regards,
        Greg

________________________________
From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Wednesday, March 13, 2013 3:31 PM
To: Gregory Mirsky
Cc: hideki.endo.es@hitachi.com; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org; mpls-ads@tools.ietf.org
Subject: RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Hi Greg,

Correct, but we can't define a MEP that can only support a subset of OAM specially the less desirable ones. Besides Synthetic loss is not accurate and as far as I know, not many users are interested in Synthetic loss.

Thx
SD

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, March 13, 2013 3:13 PM
To: Shahram Davari
Cc: hideki.endo.es@hitachi.com; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org; mpls-ads@tools.ietf.org
Subject: RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)

Hi Shahram,
as indicated before, Synthetic LM is viable option and will work just fine from UP MEP. Would you agree?

    Regards,
        Greg

________________________________
From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Wednesday, March 13, 2013 2:21 PM
To: Gregory Mirsky
Cc: hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com>; mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>; mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>
Subject: Re: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)
Greg,

First of all MPLS-TP LM can use direct Loss measurement of RFC6374.

Secondly I am not asking on what is your implementation. I am asking logically how do you do LM for LSP UPMEP. You have to let the data packets go through forwarding and queuing and be actually delivered to the egress interface before you can increment receive LM counter. Just examining the forwarding result is not enough since for example the link between egress line card and the fabric can be broken or have errors.



Regards,
Shahram


On Mar 13, 2013, at 1:06 PM, "Gregory Mirsky" <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>> wrote:
Hi Shahram,
I believe that MPLS-TP LM is what is called Synthetic Loss Measurement and does not require reporting in-profile counters. If my understanding is correct, then I don't see how location of UP MEP in relation to PW A and PW B is important. Besides, could you refer me to definition of in-profile and out-ot-profile in regard to MPLS-TP. Much obliged.
As for your challenge I do have solution but, I believe, it is HW specific. Sorry if you can not do that.

    Regards,
        Greg

________________________________
From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Wednesday, March 13, 2013 12:55 PM
To: Gregory Mirsky; hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>; mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>
Subject: RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)
Greg,
We have a fundamental difference of opinion.  I have been involved in the OAM for over a decade now and one of the fundamental architectural requirements is that OAM packets MUST follow the data packets in the network and inside a switch/router up to the observation point (MEP). So it is not acceptable for data packets to be on Interface A and for MEP to be on Interface B.
In the example I gave, can you please tell me how you can do Loss Measurement for the LSP with UP-MEP? How do you increment the LSP UP-MEP receive LM counters for packets received from PW-A and PW-B? and where is the LSP-UP-MEP located?
Thx
Shahram
From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, March 13, 2013 12:42 PM
To: Shahram Davari; hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>; mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>
Subject: RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)
Hi Shahram,
UP MEP, whether as defined by RFC 6371 or as defined elsewhere, e.g. IEEE 802.1ag, is not required to be co-located with an ingress to monitored service, e.g. attachement circuit, but with logical interface that represents monitored service. Location of UP MEP is undefined as long as it complies with where is sends to and receives from OAM packets/frames. In case of MPLS this element if MPLS forwarding function, in case of Ethernet - Bridge Relay Entity. For MPLS, as long as OAM packets sent to forwarding and get proper encapsulation, IMHO, we have ourselves an UP MEP. How packet being bounced within a node to get such treatment, I think, is implementation specific.
    Regards,
        Greg
________________________________
From: Shahram Davari [mailto:davari@broadcom.com]
Sent: Wednesday, March 13, 2013 11:59 AM
To: Gregory Mirsky; hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>; mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>
Subject: RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)
Greg,
RFC6371 is very high level and does not define whether UP MEP applies to LSP or PW.  Assume there are 2 ingress interfaces A & B. Each interface maps Ethernet traffic to its own PW (PW-A and PW-B). Now assume both these PWs go inside the same LSP that exists Interface C. Now please explain if we were to have an UP-MEP for LSP then on which interface would that LSP UP-MEP reside? Interface A? B? C?
This simple example shows you can't have an LSP UP-MEP.
Thx
SD
From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Tuesday, March 12, 2013 11:56 AM
To: Shahram Davari; hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>; mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>
Subject: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map)
Dear All,
What would be the most appropriate subject to continue this discussion? I'll give it a try, please feel free to change it.
I think that there's nothing that can preclude from supporting UP MEP on MPLS-TP LSP, according to UP MEP definition of RFC 6371, even when multpiple PWs mapped to that LSP. Same, I think, is the true for  p2mp PW. Note that service, VPWS, is not part of MPLS-TP architecture.
        Regards,
                Greg
-----Original Message-----
From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org] On Behalf Of Shahram Davari
Sent: Tuesday, March 12, 2013 11:30 AM
To: hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>; mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>
Subject: Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hideki,
So far no RFC or draft has talked about Down or UP MEP for LSPs. But if you think about it logically LSPs can't have UP-MEP because LSP can carry many PWs and each PW may enter the LSP from a different port/interface.  PWs can have UP-MEP but only for P2P services (VPWS), otherwise they can't have UP-MEP either (same as LSP).
My suggestion is to correct figures and change UP-MEPs to Down-MEPs for LSPs. Also to mention UP-MEP is out of scope.
Thx
SD
-----Original Message-----
From: hideki.endo.es@hitachi.com<mailto:hideki.endo.es@hitachi.com> [mailto:hideki.endo.es@hitachi.com]
Sent: Tuesday, March 12, 2013 11:20 AM
To: Shahram Davari
Cc: loa@pi.nu<mailto:loa@pi.nu>; mpls@ietf.org<mailto:mpls@ietf.org>; mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>
Subject: Re:Re: [mpls] 2nd working group last call ondraft-ietf-mpls-tp-mip-mep-map
Hi Shahram,
Just one comment.
>I would also argue that LSPs can't have UP-MEPs, since PWs from many ingress ports can enter an LSP  and therefore the LSP can't start on the ingress interface.
I think this depends on implementations.
Any RFC don't restrict to DOWN-MEPs in an LSP.
Anyway, MEP mechanism is out of scope in this draft as you said.
Thanks,
Hideki Endo
>Hi,
>
>Although I mentioned I am Ok with the draft to be advanced to RFC, but after reviewing it in more details it appears that the draft, in spite of its name, does talk about UP-MEP at all and only talks about UP-MIP, while the figures show UP-MEPs for LSPs.  Even if the scope of the draft is UP-MIP, considering that there can't be a MIP without a MEP,  the draft should have some wording regarding UP-MEPs and their applicability to LSPs and PWs. I would also argue that LSPs can't have UP-MEPs, since PWs from many ingress ports can enter an LSP  and therefore the LSP can't start on the ingress interface.
>
>A quick fix at this point is to mention UP-MEP is out of scope and change the figures to only show Down-MEPs. A better fix is to elaborate on UP-MEP and its applicability and placement, etc.
>
>Regards,
>Shahram
>
>
>
>-----Original Message-----
>From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org] On Behalf Of
>Shahram Davari
>Sent: Wednesday, March 06, 2013 11:30 AM
>To: Loa Andersson; mpls@ietf.org<mailto:mpls@ietf.org>
>Cc: <mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>;
>draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>
>Subject: Re: [mpls] 2nd working group last call on
>draft-ietf-mpls-tp-mip-mep-map
>
>My Comments are addressed and I support this draft to be published as Informational  RFC.
>
>Thx
>Shahram
>
>-----Original Message-----
>From: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org] On Behalf Of
>Loa Andersson
>Sent: Tuesday, February 26, 2013 3:02 AM
>To: mpls@ietf.org<mailto:mpls@ietf.org>
>Cc: <mpls-ads@tools.ietf.org<mailto:mpls-ads@tools.ietf.org>>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>;
>draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org<mailto:draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>
>Subject: [mpls] 2nd working group last call on
>draft-ietf-mpls-tp-mip-mep-map
>
>Working Group,
>
>draft-ietf-mpls-tp-mip-mep-map-05.txt has been updated after a previous
>last call, due to the nature a and extent of the updates we have chosen
>to start a 2nd wg last call.
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-05
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-mip-mep-map-05
>
>Please send your comments, including approval of the documents and the
>updates to the mpls working group list (mpls@ietf.org<mailto:mpls@ietf.org>)
>
>This working group last call ends March 13, 2013.
>
>/Loa
>for the MPLS working group co-chairs
>--
>
>
>Loa Andersson                        email: loa@mail01.huawei.com<mailto:loa@mail01.huawei.com>
>Senior MPLS Expert                          loa@pi.nu<mailto:loa@pi.nu>
>Huawei Technologies (consult)        phone: +46 739 81 21 64
>_______________________________________________
>mpls mailing list
>mpls@ietf.org<mailto:mpls@ietf.org>
>https://www.ietf.org/mailman/listinfo/mpls
>
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org<mailto:mpls@ietf.org>
>https://www.ietf.org/mailman/listinfo/mpls
>
>
>_______________________________________________
>mpls mailing list
>mpls@ietf.org<mailto:mpls@ietf.org>
>https://www.ietf.org/mailman/listinfo/mpls
>
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls