Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2ndworking grouplast
"Shahram Davari" <davari@broadcom.com> Wed, 13 March 2013 22:57 UTC
Return-Path: <davari@broadcom.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 E871521F8570 for <mpls@ietfa.amsl.com>; Wed, 13 Mar 2013 15:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 xFTvwiLGZkby for <mpls@ietfa.amsl.com>; Wed, 13 Mar 2013 15:57:34 -0700 (PDT)
Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC94921F84EF for <mpls@ietf.org>; Wed, 13 Mar 2013 15:57:33 -0700 (PDT)
Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 13 Mar 2013 15:53:15 -0700
X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2
Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Wed, 13 Mar 2013 15:57:26 -0700
Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Wed, 13 Mar 2013 15:57:25 -0700
From: Shahram Davari <davari@broadcom.com>
To: "hideki.endo.es@hitachi.com" <hideki.endo.es@hitachi.com>
Thread-Topic: Re:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2ndworking grouplast
Thread-Index: AQHOIDyva+F+WxtKU02e1GYIicPsdJikOojw
Date: Wed, 13 Mar 2013 22:57:25 +0000
Message-ID: <4A6CE49E6084B141B15C0713B8993F281BD9BE7E@SJEXCHMB12.corp.ad.broadcom.com>
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.broa> <7347100B5761DC41A166AC17F22DF11206FBD5@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F281BD9BA48@SJEXCHMB12.corp.ad.broa> <XNM1$7$0$0$$6$1$2$A$5004099U5140fe12@hitachi.com> <4A6CE49E6084B141B15C0713B8993F281BD9BDE1@SJEXCHMB12.corp.ad.broa> <XNM1$7$0$0$$6$1$2$A$5004100U514101c0@hitachi.com>
In-Reply-To: <XNM1$7$0$0$$6$1$2$A$5004100U514101c0@hitachi.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.16.203.100]
MIME-Version: 1.0
X-WSS-ID: 7D5FDCD13C01423342-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 2ndworking grouplast
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:57:35 -0000
Hideki, The question is if the span of PWs and the LSP are the same (they start and end on same interface), then what is the point of monitoring the LSP? You can just monitor the PW. And I completely disagree that just because something is possible it has to be standardized. We need simple methods that are as generic as possible in standards. LSP UPMEP in my opinion adds a lot of complexity for not much apparent gain. Thx Shahram -----Original Message----- From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] Sent: Wednesday, March 13, 2013 3:47 PM To: Shahram Davari Cc: gregory.mirsky@ericsson.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:RE: Re:RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2ndworking grouplast Sharam, Yes niche, but possible. If there are any possibilities, we MUST NOT preclude the possibilities in an international standard. Thanks, Hideki Endo >Hideki, > >Correct, but such LSP that can only accept packets from a single interface is very niche application and not generic enough to define an UPMEP for it. We need a definition that is applicable to LSPs in general. > >Thx >SD > >-----Original Message----- >From: hideki.endo.es@hitachi.com [mailto:hideki.endo.es@hitachi.com] >Sent: Wednesday, March 13, 2013 3:31 PM >To: Shahram Davari >Cc: gregory.mirsky@ericsson.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:RE: On Up and Down MEP in MPLS-TP (RE: [mpls] 2nd working grouplast call o > >Sharam, > >Very simple question. > >>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. >Why is this assumption mandatory? > >"Assume there are 1 ingress interfaces A. Two VLAN flows in the interface A are mapped > to different PWs (PW-A and PW-B). Now assume both these PWs go inside the same LSP." >In this case, UP-MEP of the LSP can be at interface A, right? > >Thanks, >Hideki Endo > > >>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 >>Cc: mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org; 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 >> >> > > >
- [mpls] 2nd working group last call on draft-ietf-… Loa Andersson
- Re: [mpls] 2nd working group last call on draft-i… hideki.endo.es
- Re: [mpls] 2nd working group last call on draft-i… Shahram Davari
- Re: [mpls] 2nd working group last call on draft-i… Pablo Frank
- Re: [mpls] 2nd working group last call on draft-i… Shahram Davari
- Re: [mpls] 2nd working group last call ondraft-ie… hideki.endo.es
- Re: [mpls] 2nd working group last call ondraft-ie… Shahram Davari
- [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd wor… Gregory Mirsky
- Re: [mpls] 2nd working group last call on draft-i… Rolf Winter
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Zhenlong Cui
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Gregory Mirsky
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Gregory Mirsky
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Zhenlong Cui
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Gregory Mirsky
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… hideki.endo.es
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Gregory Mirsky
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… hideki.endo.es
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Gregory Mirsky
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] 2nd working group last call on draft-i… Loa Andersson
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… hideki.endo.es
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE: 2nd… Pablo Frank
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE:2ndw… hideki.endo.es
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE:2ndw… Shahram Davari
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE:2ndw… Gregory Mirsky
- Re: [mpls] On Up and Down MEP in MPLS-TP (RE:2ndw… Shahram Davari