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

Pablo Frank <pabloisnot@gmail.com> Thu, 14 March 2013 17:48 UTC

Return-Path: <pabloisnot@gmail.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 D1D8E11E8110 for <mpls@ietfa.amsl.com>; Thu, 14 Mar 2013 10:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 69nWoMxeJNnw for <mpls@ietfa.amsl.com>; Thu, 14 Mar 2013 10:48:01 -0700 (PDT)
Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 85AF011E80E9 for <mpls@ietf.org>; Thu, 14 Mar 2013 10:48:01 -0700 (PDT)
Received: by mail-vc0-f171.google.com with SMTP id ha11so590508vcb.16 for <mpls@ietf.org>; Thu, 14 Mar 2013 10:48:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y7RyCTY296YPFYHGp0+paSFJRmxStDEXeCidLeX6v4k=; b=Ymsj52c2SANvgG7IyJd4VW8EH77ckefiuNFDYmCuuvQ//ul6XT4Dhdv76Q5aLEYOjL vVeyYbxJ20fpRekFmRCSUIIPmKZVy+g5i0gkGo316WcvK34SbvRoew+Ho8Tv8pngXEVe RKKnDw1rP4U5KReKfY+q8NrGXbL1YCR0H9EXlT+yfUn+E4wzPzi4Nr3aiShNtTcKaeNw 6ghpAm7/nbYV2kmXpnFUf7Nimg+kkyCXKkzIHyuCW7c7jqeRZYJW5jx3IPW50rue8oV8 Mvbh76iql8bB4UcLznmIiqJni4vozT42qhS2fIgXJklfKa29SS2vA0NfdPu6TqmUhG8I S/ew==
MIME-Version: 1.0
X-Received: by 10.220.223.202 with SMTP id il10mr2934456vcb.4.1363283280852; Thu, 14 Mar 2013 10:48:00 -0700 (PDT)
Received: by 10.52.97.97 with HTTP; Thu, 14 Mar 2013 10:48:00 -0700 (PDT)
In-Reply-To: <4A6CE49E6084B141B15C0713B8993F281BD9BB39@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.broadcom.com> <7347100B5761DC41A166AC17F22DF11206FBD5@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F281BD9BA48@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF112070391@eusaamb103.ericsson.se> <4A6CE49E6084B141B15C0713B8993F281BD9BB39@SJEXCHMB12.corp.ad.broadcom.com>
Date: Thu, 14 Mar 2013 13:48:00 -0400
Message-ID: <CAGEmCZx+hM2oATCu4ESLGep6wWchaz-8W7nEMu9FEQTfEbjvaw@mail.gmail.com>
From: Pablo Frank <pabloisnot@gmail.com>
To: Shahram Davari <davari@broadcom.com>
Content-Type: multipart/alternative; boundary="14dae9cdc487af28a704d7e61fb9"
Cc: "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org" <draft-ietf-mpls-tp-mip-mep-map@tools.ietf.org>, "mpls-ads@tools.ietf.org" <mpls-ads@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@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: Thu, 14 Mar 2013 17:48:04 -0000

Shahram,

I think you ask an interesting fundamental question below. i.e. what is the
interface that an LSP up-MEP really associated with?  IMHO, it's not the
PWE interfaces.  A MEP cannot live on multiple interfaces simultaneously.
 Furthermore, a MEP that is meant to monitor a tunnel has no business
operating on an interface in a completely different network layer.  We know
that an up-MEP must appear before the "forwarding" function but I struggle
to find a good definition for what the MPLS forwarding function really
encompasses.

If I look to RFC 3031, one is tempted to define the MPLS forwarding
function as the combination of the ILM/FEC+NHLFE.  A related question is
"where does the LSP begin"?  According to 3031, the new label is imposed by
the NHLFE.  So does that mean that tunnels begin *after* the forwarding
function, or is it "during"/"before"?  If it's after, then I have a hard
time accepting that an up-MEP for tunnels even exists.  OTOH, something
like a P2MP LSP does not fit well with this model.  Surely in P2MP, the act
of multicasting the frame is part of the forwarding function?

IEEE 802.1q solves this problem by creating a virtual interface (i.e. the
CBP) inside an IB-BEB for the tunnel up-MEPs to live on.  I know of no
equivalent concept in MPLS so we would likely have to define something to
be able to move forward on the concept of an LSP up-MEP.  But it seems to
me that if an LSP up-MEP exists, it sits on some-yet-to-be-determined
object that is somewhere between the PWE interfaces and the MPLS forwarding
function.

I suspect that we'll get nowhere if we focus on implementation-specific
perspectives.  The answer has to be derived from the architecture of MPLS
and PWEs.

regards,
Pablo

On Wed, Mar 13, 2013 at 3:55 PM, Shahram Davari <davari@broadcom.com> wrote:

>  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
> *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:* 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 <davari@broadcom.com>]
> *Sent:* Wednesday, March 13, 2013 11:59 AM
> *To:* Gregory Mirsky; 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:* 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<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<mpls-bounces@ietf.org>]
> On Behalf Of Shahram Davari****
>
> Sent: Tuesday, March 12, 2013 11:30 AM****
>
> To: 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: 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<hideki.endo.es@hitachi.com>
> ]****
>
> Sent: Tuesday, March 12, 2013 11:20 AM****
>
> To: Shahram Davari****
>
> Cc: loa@pi.nu; mpls@ietf.org; mpls-ads@tools.ietf.org;
> mpls-chairs@tools.ietf.org; 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<mpls-bounces@ietf.org>]
> On Behalf Of ****
>
> >Shahram Davari****
>
> >Sent: Wednesday, March 06, 2013 11:30 AM****
>
> >To: Loa Andersson; mpls@ietf.org****
>
> >Cc: <mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org; ** **
>
> >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<mpls-bounces@ietf.org>]
> On Behalf Of ****
>
> >Loa Andersson****
>
> >Sent: Tuesday, February 26, 2013 3:02 AM****
>
> >To: mpls@ietf.org****
>
> >Cc: <mpls-ads@tools.ietf.org>; mpls-chairs@tools.ietf.org; ** **
>
> >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)****
>
> >** **
>
> >This working group last call ends March 13, 2013.****
>
> >** **
>
> >/Loa****
>
> >for the MPLS working group co-chairs****
>
> >--****
>
> >** **
>
> >** **
>
> >Loa Andersson                        email: loa@mail01.huawei.com****
>
> >Senior MPLS Expert                          loa@pi.nu****
>
> >Huawei Technologies (consult)        phone: +46 739 81 21 64****
>
> >_______________________________________________****
>
> >mpls mailing list****
>
> >mpls@ietf.org****
>
> >https://www.ietf.org/mailman/listinfo/mpls****
>
> >** **
>
> >** **
>
> >_______________________________________________****
>
> >mpls mailing list****
>
> >mpls@ietf.org****
>
> >https://www.ietf.org/mailman/listinfo/mpls****
>
> >** **
>
> >** **
>
> >_______________________________________________****
>
> >mpls mailing list****
>
> >mpls@ietf.org****
>
> >https://www.ietf.org/mailman/listinfo/mpls****
>
> >** **
>
>  ****
>
>  ****
>
> _______________________________________________****
>
> mpls mailing list****
>
> mpls@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/mpls****
>
>  ****
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>