Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Sat, 13 January 2018 01:21 UTC

Return-Path: <sajassi@cisco.com>
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 C3692126BF7 for <bess@ietfa.amsl.com>; Fri, 12 Jan 2018 17:21:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IFInI6498mOK for <bess@ietfa.amsl.com>; Fri, 12 Jan 2018 17:21:27 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF3B126B6E for <bess@ietf.org>; Fri, 12 Jan 2018 17:21:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16820; q=dns/txt; s=iport; t=1515806487; x=1517016087; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ad+mbrf7+IqlWjHSGnrfSI26NJG9eNbIcnwtsozrGVQ=; b=AlV8yjC74euS9SvNHarbDjvvX/FKV8+n6hAqgyHxny4dLV2ilLhmrfEg KZkI2Kdm5lLD9rKeIchA9iB1M4sX68W8nfqZQa3sHUUEl5f9I11VEw4yJ 8WiDn/x/fA8v8BpF8FlzW3ne24sPUngWDiayfMuien4JrDm6+l99mU3t6 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAQDMXlla/4QNJK1UChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDQWZ0JweEDIokjmKCApcsFIICChgLhRgCGoQnPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUjAQEBAQMBASEROhcEAgEIEQQBAQECAiMDAgICJQsUAQgIAgQBEoozE?= =?us-ascii?q?K4wgieKPwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+DLYIVg0ApgXeBDoMvAQE?= =?us-ascii?q?CGYEjAQcLATYVgmsxgjQFo2QCiAqNP4IZijKHRY0+iToCERkBgTsBHzlgcG8VP?= =?us-ascii?q?SoBgX+CVByBZ3iJUoElgRcBAQE?=
X-IronPort-AV: E=Sophos;i="5.46,351,1511827200"; d="scan'208";a="56049391"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jan 2018 01:21:21 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w0D1LKW0006668 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 13 Jan 2018 01:21:21 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 12 Jan 2018 20:21:19 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1320.000; Fri, 12 Jan 2018 20:21:19 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication
Thread-Index: AQHTdM5LxSlRFluwPkmVHdFfkfBaXw==
Date: Sat, 13 Jan 2018 01:21:19 +0000
Message-ID: <D104679D-4FF8-4D4F-9CB3-16D478794937@cisco.com>
References: <CAO367rVvmv4kyFbS8C=WEyZpXZZQUgLsFX1gscy49UNU2_pJvQ@mail.gmail.com> <1513258777.30252.11.camel@orange.com> <CAO367rWCvS2fOD43agch0Mpu1pOfoXYHkptJPfccJsPHc+vzZQ@mail.gmail.com> <AT5PR8401MB0353B2B69B6F8D292FFB268BF60A0@AT5PR8401MB0353.NAMPRD84.PROD.OUTLOOK.COM> <1513334544.6588.9.camel@orange.com> <MWHPR05MB355144EB0007DE112C09F34BC70B0@MWHPR05MB3551.namprd05.prod.outlook.com> <AT5PR8401MB035389AC482DEFA78909334FF60B0@AT5PR8401MB0353.NAMPRD84.PROD.OUTLOOK.COM> <1513356144.6588.38.camel@orange.com> <37A2C852-9730-4944-8205-88ACE9112990@cisco.com> <5c71355d-d55d-d74b-73dc-dc924a756ec9@nokia.com>
In-Reply-To: <5c71355d-d55d-d74b-73dc-dc924a756ec9@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.29.0.171205
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.76.52]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6ACF4CBF1728C442B9AF6D5875EB1AF0@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/dv5E2GmVPGabEFsIQtYq5w4aNgw>
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 <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jan 2018 01:21:30 -0000

Hi Martin,

On second thought, I replaced that paragraph with the following one to better clarify the need for IMET route for setting up different underlay tunnels for locally-assigned VNIs versus globally-assigned VNIs.


  “In case of VxLAN and NVGRE encapsulation with locally-assigned VNIs,
   just as in [RFC7432], each PE MUST advertise an IMET route to other
   PEs in an EVPN instance for the multicast tunnel type that it uses
   (i.e., ingress replication, PIM-SM, PIM-SSM, or Bidir-PIM tunnel).
   However, for globally-assigned VNIs, each PE MUST advertise IMET
   route to other PEs in an EVPN instance for ingress replication or
   PIM-SSM tunnel, and MAY advertise IMET route for PIM-SM or Bidir-PIM
   tunnel. In case of PIM-SM or Bidir-PIM tunnel, no information in the
   IMET route is needed by the PE to setup these tunnels. “


Cheers,
Ali

On 12/15/17, 10:24 AM, "BESS on behalf of Martin Vigoureux" <bess-bounces@ietf.org on behalf of martin.vigoureux@nokia.com> wrote:

    if the intent was to help people better understand the reasoning behind 
    the design, is it really best to remove it?
    Wouldn't a rephrasing be more appropriate?
    
    -m
    
    Le 2017-12-15 à 19:21, Ali Sajassi (sajassi) a écrit :
    > Hi Thomas,
    > 
    > On 12/15/17, 8:42 AM, "BESS on behalf of Thomas Morin" <bess-bounces@ietf.org on behalf of thomas.morin@orange.com> wrote:
    > 
    >      
    >      Here I would suggest to authors to consider purely removing this
    >      paragraph, not because it would be wrong or ambiguous (as said above, I
    >      don't think it is), but because as far as I can tell it has never meant
    >      to specify anything not already implied by RFC7432, but was here only
    >    to help understand.
    >    
    > OK, I will remove it in the next rev.
    >    
    > Cheers,
    > Ali
    >      
    >      Best,
    >      
    >      -Thomas
    >      
    >      
    >      
    >      
    >      -----Original Message-----
    >      > From: John E Drake [mailto:jdrake@juniper.net]
    >      > Sent: Friday, December 15, 2017 9:52 AM
    >      > To: EXT - thomas.morin@orange.com <thomas.morin@orange.com>om>; Fedyk,
    >      > Don <don.fedyk@hpe.com>om>; Marco Marzetti <marco@lamehost.it>
    >      > Cc: bess@ietf.org
    >      > Subject: RE: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress
    >      > Replication
    >      >
    >      > Thomas,
    >      >
    >      > I completely agree w/ your email, below.
    >      >
    >      > Yours Irrespectively,
    >      >
    >      > John
    >      >
    >      >
    >      > > -----Original Message-----
    >      > > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Thomas Morin
    >      > > Sent: Friday, December 15, 2017 5:42 AM
    >      > > To: Fedyk, Don <don.fedyk@hpe.com>om>; Marco Marzetti <marco@lamehost.
    >      > > it>
    >      > > Cc: bess@ietf.org
    >      > > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with
    >      > > Ingress
    >      > > Replication
    >      > >
    >      > > Hi Don,
    >      > >
    >      > > Fedyk, Don, 2017-12-14 20:33:
    >      > > > I think the gray area is that this draft talks about BUM traffic
    >      > > > and
    >      > > > ingress replication and then has a section on Multicast tunnels
    >      > > > which excludes ingress replication traffic from the tunnels.
    >      > >
    >      > > No, ingress replication is not excluded at all:
    >      > >
    >      > >    The following tunnel types as defined in [RFC6514] can be used
    >      > > in
    >      > >    the PMSI tunnel attribute for VXLAN/NVGRE:
    >      > >
    >      > >          + 3 - PIM-SSM Tree
    >      > >          + 4 - PIM-SM Tree
    >      > >          + 5 - BIDIR-PIM Tree
    >      > >          + 6 - Ingress Replication
    >      > >
    >      > > > If you are using point to point VXLAN/NVGRE  tunnels then
    >      > > > ingress
    >      > > > replication is default [...]
    >      > >
    >      > > This formulation surprises me: that some implementations behave as
    >      > > you
    >      > > describe is possibly true (this seems to be the case of the
    >      > > implementation that triggered this discussion), but I don't know
    >      > > about
    >      > > any text in the specs we are discussing that would imply such a
    >      > > 'default'.
    >      > >
    >      > > You might have implementations that in the absence of any local
    >      > > configuration for an EVPN instance on which type of tunnel to use
    >      > > for
    >      > > BUM, will default to ingress replication: this is fine, out of the
    >      > > scope of what is specified for interop, and not breaking other
    >      > > implementations (as long, of course, that what is chosen locally
    >      > > is
    >      > > then advertised as expected in a PMSI Tunnel Attribute).
    >      > >
    >      > >
    >      > > > but IMET is being used to identify the NVE IP.    I read RFC7432
    >      > > > and
    >      > > > RFC6514 in this area and thought that the PMSI attribute MUST be
    >      > > > set
    >      > > > when there is an Inclusive Multicast Ethernet tag IMET.
    >      > >
    >      > > Yes!  (the text of RFC7432 quoted by Ali reminds us that)
    >      > >
    >      > >
    >      > > > I can see two possible fixes:
    >      > > > -          Specify that the PMSI attribute MUST be set if there
    >      > > > is an
    >      > > > IMET route and specify correct attribute.
    >      > >
    >      > > Given the content of RFC7432 and the fact that this is a normative
    >      > > ref
    >      > > of draft-ietf-bess-evpn-overlay, I think that we don't need to
    >      > > repeat
    >      > > this MUST in draft-ietf-bess-evpn-overlay.  That is, unless we
    >      > > explicitly identify an ambiguous piece of text.
    >      > >
    >      > > > -          Allow that ingress replication is default when PMSI is
    >      > > > absent but accept PMSI that specifies ingress replication.
    >      > > >
    >      > >
    >      > > I don't think we should do that. It would overnight make non-
    >      > > compliant
    >      > > pre- standard implementation of draft-ietf-bess-evpn-overlay,
    >      > > without
    >      > > a rationale to do so except coping with an implementation that
    >      > > assumed a bit too much.
    >      > >
    >      > > Best,
    >      > >
    >      > > -Thomas
    >      > >
    >      > >
    >      > >
    >      > > > From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Marco
    >      > > > Marzetti
    >      > > > Sent: Thursday, December 14, 2017 9:21 AM
    >      > > > To: Thomas Morin <thomas.morin@orange.com>
    >      > > > Cc: bess@ietf.org
    >      > > > Subject: Re: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with
    >      > > > Ingress Replication
    >      > > >
    >      > > > 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
    >      > >
    >      > > <thomas.morin@orange.co
    >      > > > m> 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
    >      > >
    >      > > _______________________________________________
    >      > > BESS mailing list
    >      > > BESS@ietf.org
    >      > > https://urldefense.proofpoint.com/v2/url?u=https-
    >      > > 3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Sc
    >      > > bfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-
    >      > > s_xXXup3HzvBSMRj5VE&m=tHiUTn9_QXrhs3cw-
    >      > > Dn9_qwR3VK2xWv72DcpoOfR_SI&s=VxylPoVhzXC58hBsqToxzhUK6-3kfy-
    >      > > ktUi7A9KZDcs&e=
    >      
    >      _______________________________________________
    >      BESS mailing list
    >      BESS@ietf.org
    >      https://www.ietf.org/mailman/listinfo/bess
    >      
    > 
    > _______________________________________________
    > BESS mailing list
    > BESS@ietf.org
    > https://www.ietf.org/mailman/listinfo/bess
    > 
    
    _______________________________________________
    BESS mailing list
    BESS@ietf.org
    https://www.ietf.org/mailman/listinfo/bess