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

"Fedyk, Don" <don.fedyk@hpe.com> Thu, 14 December 2017 20:33 UTC

Return-Path: <don.fedyk@hpe.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 2FA7B127599 for <bess@ietfa.amsl.com>; Thu, 14 Dec 2017 12:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level:
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 2Ym3Uw1j2yMo for <bess@ietfa.amsl.com>; Thu, 14 Dec 2017 12:33:17 -0800 (PST)
Received: from g9t5008.houston.hpe.com (g9t5008.houston.hpe.com [15.241.48.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC4F21200C1 for <bess@ietf.org>; Thu, 14 Dec 2017 12:33:17 -0800 (PST)
Received: from G1W8106.americas.hpqcorp.net (g1w8106.austin.hp.com [16.193.72.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5008.houston.hpe.com (Postfix) with ESMTPS id 04DC44D; Thu, 14 Dec 2017 20:33:16 +0000 (UTC)
Received: from G9W4607.americas.hpqcorp.net (2002:10d8:a08e::10d8:a08e) by G1W8106.americas.hpqcorp.net (2002:10c1:483d::10c1:483d) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 14 Dec 2017 20:33:16 +0000
Received: from G9W9209.americas.hpqcorp.net (16.220.66.156) by G9W4607.americas.hpqcorp.net (16.216.160.142) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 14 Dec 2017 20:33:16 +0000
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (15.241.52.13) by G9W9209.americas.hpqcorp.net (16.220.66.156) with Microsoft SMTP Server (TLS) id 15.0.1178.4 via Frontend Transport; Thu, 14 Dec 2017 20:33:15 +0000
Received: from AT5PR8401MB0353.NAMPRD84.PROD.OUTLOOK.COM (10.169.2.143) by AT5PR8401MB0354.NAMPRD84.PROD.OUTLOOK.COM (10.169.2.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14 Dec 2017 20:33:14 +0000
Received: from AT5PR8401MB0353.NAMPRD84.PROD.OUTLOOK.COM ([fe80::8cfc:ebe:b596:a459]) by AT5PR8401MB0353.NAMPRD84.PROD.OUTLOOK.COM ([fe80::8cfc:ebe:b596:a459%18]) with mapi id 15.20.0302.014; Thu, 14 Dec 2017 20:33:14 +0000
From: "Fedyk, Don" <don.fedyk@hpe.com>
To: Marco Marzetti <marco@lamehost.it>, Thomas Morin <thomas.morin@orange.com>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] draft-ietf-bess-evpn-overlay-10 PMSI with Ingress Replication
Thread-Index: AQHTdM5LCyQuEnUoLEO2JOFxk4Zcf6NC2FuAgAALcQCAAFZkMA==
Date: Thu, 14 Dec 2017 20:33:14 +0000
Message-ID: <AT5PR8401MB0353B2B69B6F8D292FFB268BF60A0@AT5PR8401MB0353.NAMPRD84.PROD.OUTLOOK.COM>
References: <CAO367rVvmv4kyFbS8C=WEyZpXZZQUgLsFX1gscy49UNU2_pJvQ@mail.gmail.com> <1513258777.30252.11.camel@orange.com> <CAO367rWCvS2fOD43agch0Mpu1pOfoXYHkptJPfccJsPHc+vzZQ@mail.gmail.com>
In-Reply-To: <CAO367rWCvS2fOD43agch0Mpu1pOfoXYHkptJPfccJsPHc+vzZQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=don.fedyk@hpe.com;
x-originating-ip: [15.219.147.3]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AT5PR8401MB0354; 6:c7kp1w4OMVoVhfWyJ/NyDGhBrncBYFhH5JEdCelyhLRwBgcE3LpwimLB3sQK3F/w0Kx1pjXy45N6D2GGYWyV+pnSHyec2uKxw0qTG4OmObhCuS+Ta7yNbOoJKkiexrKdMWwHHYCCc6FO52EeXzgbDqph20D5fFApfBn5ffI9cofGjoaZZydDCAxW6FUqAQF3YSpddR74DeqT3psoFcHQky1Wf5JHNjRF7707TCWHRsXyYAiHHLjwh3RQkmNs1ezhGuJJmiBzqYQ96Kt0tzFOpMI46rbRpaWtCh3r9srVoORWxo1QARM5SnByZyjI6Uh+RjCw8FbOHtoVzwdqyQ7sDK92i11+dpHB1EEXW6JUW4Y=; 5:qcpwpHecXdmJIvX3xXEO4Tsms0vquQIxZpAWJbqlm/tUO52AA7ac7ancRHbYLgTtH8ICSQ7jimgG0v4iq+AAvYgRf/KITRefgdo5ZFDMK7MQSvki3tUrYGsK+R5mhuks8kxwxGPJS/ebH0WLxiB5PpmBgVfGC09hJR3I/Mvoy/8=; 24:YkuRTYYt67OetMyQyScoEFP+D1s9eAisxOhPNLT8P2gSUreyIGrzVgOYbrtKLCzFdAa0ME/kn/Nh6s9/KoX3o2BZni6lgaYBj/FEq7z2mNQ=; 7:bCZEAQfQKx3vBZhYz8sj/8hxzbMw8MHxjnceKVt4No5HDKq3pH3gY4Y8kPxPmcWBXqKJfRXZrwcYOvx0JG48iv+athaCewWjiWtYmBfYVTRawlYs03+IDbAYXAQR1ap4JsfFTsoLvKmTETeC8t8S1Nop5cPeXDgORtgQzVQ+zXA2oIuti7I7zJAwP0eQuo5Dl/FFENGh/P7HhqiutkdpEnH9O8gkjNQFvh7rDdm2poJTQep7qjYLfPngB21dLaTf
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 220a9083-e519-4a67-29e7-08d54331e6ad
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(48565401081)(2017052603307); SRVR:AT5PR8401MB0354;
x-ms-traffictypediagnostic: AT5PR8401MB0354:
x-microsoft-antispam-prvs: <AT5PR8401MB0354CAC656D3FFCC09A8A821F60A0@AT5PR8401MB0354.NAMPRD84.PROD.OUTLOOK.COM>
x-exchange-antispam-report-test: UriScan:(18271650672692)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231023)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011); SRVR:AT5PR8401MB0354; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AT5PR8401MB0354;
x-forefront-prvs: 05214FD68E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(39860400002)(396003)(24454002)(377424004)(189003)(199004)(105586002)(5250100002)(14454004)(33656002)(2950100002)(106356001)(478600001)(2900100001)(230783001)(6436002)(55016002)(229853002)(3280700002)(99286004)(97736004)(3660700001)(7736002)(6116002)(4001150100001)(102836003)(3846002)(790700001)(74316002)(5890100001)(81156014)(81166006)(8676002)(8936002)(9326002)(5660300001)(66066001)(68736007)(25786009)(4326008)(6246003)(316002)(236005)(59450400001)(9686003)(2906002)(6506007)(6306002)(54896002)(53546011)(110136005)(7696005)(86362001)(76176011)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR8401MB0354; H:AT5PR8401MB0353.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AT5PR8401MB0353B2B69B6F8D292FFB268BF60A0AT5PR8401MB0353_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 220a9083-e519-4a67-29e7-08d54331e6ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 20:33:14.3484 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR8401MB0354
X-OriginatorOrg: hpe.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Ah8ZK8wR_C_XZs5BJ43E4j5ktuc>
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: Thu, 14 Dec 2017 20:33:20 -0000

Hi

I came across this as well.  I would suggest that wording in draft-ietf-bess-evpn-overlay-10 be explicit on the expected behaviour.  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. If you are using point to point VXLAN/NVGRE  tunnels then ingress replication is default 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.

I can see two possible fixes:

-          Specify that the PMSI attribute MUST be set if there is an IMET route and specify correct attribute.

-          Allow that ingress replication is default when PMSI is absent but accept PMSI that specifies ingress replication.


Cheers
Don

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.com<mailto:thomas.morin@orange.com>> 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