Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3AC1200CF for ; Thu, 14 Dec 2017 06:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lamehost-it.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 087134y3hMhl for ; Thu, 14 Dec 2017 06:20:36 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1BB12420B for ; Thu, 14 Dec 2017 06:20:36 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id g10so8050808qtj.12 for ; Thu, 14 Dec 2017 06:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamehost-it.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6Nkg2LzRX3Mwg8EBcu9qFIaVUVevZhTC59L+ajOHuFo=; b=lwNKOjQ+t2Yla4CnEvQdTrSwwX25G82/7Ik+d4+AaI39tjvu7PXHxSLlmnN3+n1Tju 4ARRzOIhyRVxS5+RF4DTCUjOBZrBEUSravfogCW58qNGSbHcN9sSIybUDpCZ16lNfsVy vB/MepMkhFysLYxUoF9xogS/9Hc6MkWKq53Jy4WFuRti8b7wNJSnviIRqqIKAW3grimy 4hARrxfTaxYZq9iPGEb0+/lEobNnJl0kn2PiMPn8Lqghlm4O9dVVeaq+X8EwlIZmoS8i sE+vghIBD//JH+M8TL8G18bFMadzhen3VsdUmYVhq1AmBJ0Eu18CsiFGacnM5/KRj8Eg C07A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6Nkg2LzRX3Mwg8EBcu9qFIaVUVevZhTC59L+ajOHuFo=; b=KE9aVehwCOpkNigFQ+SND63Arl9cNgn5s/tKQpvFfCqEZLglL3nwM3neFFxfpo2qr+ lshVJCkwTgpvju31LPPzG5PFB/99DwdMs02+0llTyKw4D0Et0Rsb7FM2Ayd2yH6CHMzF bE7TuJto9Fttrc8r9xynrV2y9Sb4IXVCPPO45Bfbgj3zG8PiYLGglezNMAl6OBdU4D3O DEY++54QJAQXudP8rXVsnfP6y1Qlh0Cj67I2sBvbos12YXJGwzRcfZ0iuMSgGQzJTAbE Bjx6IqmSsEWg2Dz5pVlrfY1S4xNhC+qBCnKWjtVQjArYAw/VZ1GQmSmLo5eKbfK4elZ1 Pcug== X-Gm-Message-State: AKGB3mJG5/lAb2/KtG1qHkIfByn+Tb3TJHa2xbcYs2LItNnOGhXCYyFl 5qxxs8Hidb1KqV28NA8VmCQegvfftfy4kani53TMLg== X-Google-Smtp-Source: ACJfBovxDsdHiWOqIS+geize34StfTt60MstMULIR0/kT3tzIU1rOJgdUjUk4dD6tGc0khHz/IJbWk375cQ0CgObRbE= X-Received: by 10.200.58.231 with SMTP id x94mr15637627qte.245.1513261235023; Thu, 14 Dec 2017 06:20:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.26.105 with HTTP; Thu, 14 Dec 2017 06:20:34 -0800 (PST) In-Reply-To: <1513258777.30252.11.camel@orange.com> References: <1513258777.30252.11.camel@orange.com> From: Marco Marzetti Date: Thu, 14 Dec 2017 15:20:34 +0100 Message-ID: To: Thomas Morin Cc: bess@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1254c85dcab405604d9684" Archived-At: Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 14:20:39 -0000 --94eb2c1254c85dcab405604d9684 Content-Type: text/plain; charset="UTF-8" Hello, I have encountered an implementation that is not attaching any PMSI to the IMET. The authors think they don't really need it because they only support Ingress Replication. Such behavior breaks interoperability with other implementations that are dropping the NLRI if PMSI is not attached. So i looked at draft-ietf-bess-evpn-overlay-10 and noticed that there's no clear indication of what the proper behavior is. As said i assumed i had to look at RFC7432 and RFC6514 (and i did it), but i wasn't 100% sure and i preferred to ask. Onestly you already made my day by confirming what i thought. My suggestion was to make things more clear, but i admit that it could look redundant. Thanks On Thu, Dec 14, 2017 at 2:39 PM, Thomas Morin wrote: > Hi Marco, > > Marco Marzetti, 2017-12-14 12:25: > > I am writing this email asking you to clarify what's the suggested > > behavior when PMSI Tunnel Type is set to "Ingress Replication" (type > > 6) as draft-ietf-bess-evpn-overlay-10 only suggests what to do with > > multicast tunnel trees. > > > > I think the originating PE should conform with RFC6514 and RFC7432 > > (from which you've taken inspiration) and always (RFC2119 MUST) > > attach PMSI Tunnel attribute with the Tunnel Type set to Ingress > > Replication and Tunnel Identifier set to a routable address of the PE > > itself (more specifically NVE's IP address). > > > > Is that correct? > > In that case i suggest to add the following line at the end of > > Section 9. > > """ > > For Ingress Replication the PE should follow what's stated in RFC6514 > > Section 5 . > > """ > > The text of section 9 lists "Ingress Replication" in the list of tunnel > types that can be used. My understanding is that, in the absence of > anything being specifically said for Ingress Replication, an > implementation should follow what is said in RFC7432 and RFC6514. (What > other specs could it follow to implement this supported type ? RFC7432 > and RFC6514 are more than an inspiration here, these are specs that the > document refers to explicitly) > > So I'm not sure that it is useful or needed to add text. > > Can you perhaps expand on why the current text would possibly be > ambiguous, misleading or incomplete...? > > -Thomas > > -- Marco --94eb2c1254c85dcab405604d9684 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I have encountered an implementa= tion that is not attaching any PMSI to the IMET.
The authors thin= k=C2=A0they=C2=A0don't really need it because=C2=A0they only= support Ingress Replication.
Such behavior breaks interoperabili= ty with other implementations that are dropping the NLRI if PMSI is not att= ached.

So i looked at=C2=A0draft-ietf-bess-evpn-ov= erlay-10 and noticed that there's no clear indication of what the prope= r behavior is.
As said i assumed i had to look at=C2=A0RFC7432 and RFC6514 (and i did it), but i wasn't= 100% sure and i preferred=C2=A0to ask.

Onest= ly you already made my day by confirming what i thought.
<= span style=3D"font-size:12.8px">My suggestion was to make things more clear= , but i admit that it could look redundant.

T= hanks




=



On Thu, Dec 14, 2017 at 2:39 PM, Thoma= s Morin <thomas.morin@orange.com> wrote:
Hi Marco,

Marco Marzetti, 2017-12-14 12:25:
> I am writing this email asking you to clarify what= 9;s the suggested
> behavior when PMSI Tunnel Type is set to "Ingress Replication&quo= t; (type
> 6) as draft-ietf-bess-evpn-overlay-10 only suggests what to do wi= th
> multicast tunnel trees.
>
> I think the originating PE should conform with RFC6514 and RFC7432
> (from which you've taken inspiration) and always (RFC2119 MUST) > attach PMSI Tunnel attribute with the Tunnel Type set to Ingress
> Replication and Tunnel Identifier set to a routable address of the PE<= br> > itself (more specifically NVE's IP address).
>
> Is that correct?
> In that case i suggest to add the following line at the end of
> Section 9.
> """
> For Ingress Replication the PE should follow what's stated in RFC6= 514
> Section 5 .
> """

The text of section 9 lists "Ingress Replication" in the l= ist of tunnel
types that can be used. My understanding is that, in the absence of
anything being specifically said for Ingress Replication, an
implementation should follow what is said in RFC7432 and RFC6514. (What
other specs could it follow to implement this supported type ? RFC7432
and RFC6514 are more than an inspiration here, these are specs that the
document refers to explicitly)

So I'm not sure that it is useful or needed to add text.

Can you perhaps expand on why the current text would possibly be
ambiguous, misleading or incomplete...?

-Thomas




--
Marco
--94eb2c1254c85dcab405604d9684--