Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Thu, 29 August 2019 19:02 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 60F4E120B5A for <bess@ietfa.amsl.com>; Thu, 29 Aug 2019 12:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 header.b=WHSr11XJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Pmh7qdfC
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 EpS5z313w8iB for <bess@ietfa.amsl.com>; Thu, 29 Aug 2019 12:02:37 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5F2120989 for <bess@ietf.org>; Thu, 29 Aug 2019 12:02:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27519; q=dns/txt; s=iport; t=1567105356; x=1568314956; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ogwSOYftoZFGnBSNqBvmH2FgJcNICqBJoXq/RDl0kHA=; b=WHSr11XJ8Cqx+cX+sRXY2msEnUSSdJqm+2k7XLlPlIIXl891N9a7NwQu D3SJtlKqi4HlGNRnWKZjfo5Otz7isF3O62odsU6Eu2nqoJ3z2zrnWqOWi b/h8qlGBSEAlFK/8ygkAvrPwIC00qZGlr20rhfqrDjTTJ5aFcGxrhTt4r M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AcP9xdxFqNIE8iExdhudLCJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeXjbSUhB8VqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAACBIGhd/40NJK1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4EWLyQsA21WIAQLKgqEF4NHA4pwgjcliWCOCoFCgRADVAk?= =?us-ascii?q?BAQEMAQEYAQoKAgEBhD8CF4JCIzgTAgMIAQEEAQEBAgEGBG2FLgyFSgEBAQE?= =?us-ascii?q?DAQEQER0BASwLAQ8CAQgRAwECKAMCAgIfBgsUCQgCBA4FIoMAAYEdTQMdAQI?= =?us-ascii?q?MoRACgTiIYXOBMoJ8AQEFgUZBQIJFDQuCFgMGgTSLdxiBf4ERJwwTgU5+PoI?= =?us-ascii?q?aRwEBAwGBKgESATYJDQmCVTKCJow5QgKCKYUalwxACQKCHoZuiRMFUoN7G4I?= =?us-ascii?q?yhzSNIYFWjQoJghKGOYIAjkgCBAIEBQIOAQEFgWchKj1xcBU7KgGCQYJCOIM?= =?us-ascii?q?6hRSFP3KBKYwggSIBgSIBAQ?=
X-IronPort-AV: E=Sophos;i="5.64,444,1559520000"; d="scan'208,217";a="316288426"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 19:02:35 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x7TJ2ZrM007573 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Aug 2019 19:02:35 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 14:02:35 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 14:02:33 -0500
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 14:02:33 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LiAu1oDv7xoQpyTgMzoNHZI9YnLBozxxYtSCDK8UpVELrsqNy32HUPttNljQNMO4odC7fzqjdOMr3s4reElYxKli4Nicdybspvml1gF2rzQDBzqyqejKSProkQ3062UCbmIBzaO0OdBwBkB+o5wcJK8v1AFpv/LHtixz8VpdoGu4V+oGbmXWTttwxLreVwm+/xxL7G6YDzOiVtDtHIYFhSbfjV9vSxM+jC5oT+hhQzQzyS5nEVIwI9QdZ3pBP1POeyOlWoRgXcc/IN7MoM36y9WX9H9XfAvdmA6aulMNKaMVU1M/oKjbN37H2IU+YBmsYJBB8oLJ4la3tTMY/PE9mQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogwSOYftoZFGnBSNqBvmH2FgJcNICqBJoXq/RDl0kHA=; b=EwieTlX1uTc0Lo2jBqrsrOky3arOsAPoTrCQC6FyZsDwGEfijj7xJ20yb77cJQprYMCPqr29E15GJQ2FfzKCTNouv3I/QFsToHJvVaMVUWwAdE5ZMW3wxNJz4YMUCw4hiNJPiwOWSkEUKsEnTVXzTnkCf0SHBXufl4j7rGDpd0oo0rNeTGdF05jey6nheONxuHAF0/pOmp8waN8xtYNj329Xw2Bo1fwBklSZfveZ71LP3HlrnArcGMJj45ctV3EgJz4MhQU1Qacj5/Su48dGQhoE5lWCBATJgmtQf+wTqYqzaANIri5vxkWY0hb6CtjolREf3qyNnKFfDPBGJDuztQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogwSOYftoZFGnBSNqBvmH2FgJcNICqBJoXq/RDl0kHA=; b=Pmh7qdfCPKbhMW0a1lGRerJXwfTSZ26gsEFR+nLKKCGD7QjTX6rtLjKbrF1PXFu125xqSpJER6Kxiq/lWknVL1r6ud3+blP5lDi46556521tNPQKg0+Dbq3mb+FlHkAhuhHyUYILklj1PHUwUYv7oU51b+3xPNVX9odmx37BB1E=
Received: from BN8PR11MB3699.namprd11.prod.outlook.com (20.178.218.208) by BN8PR11MB3586.namprd11.prod.outlook.com (20.178.219.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.18; Thu, 29 Aug 2019 19:02:32 +0000
Received: from BN8PR11MB3699.namprd11.prod.outlook.com ([fe80::c8c5:dd16:d210:fa35]) by BN8PR11MB3699.namprd11.prod.outlook.com ([fe80::c8c5:dd16:d210:fa35%7]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 19:02:32 +0000
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Siddhesh Dindorkar <siddhesh.dindorkar@nuagenetworks.net>
CC: Stephane Litkowski <slitkows.ietf@gmail.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
Thread-Index: AQHVVzf2boZ3++H5OkmQd45nQM7H0acPKWwAgAH7NQCAAPA0gA==
Date: Thu, 29 Aug 2019 19:02:31 +0000
Message-ID: <70984A8D-F5C6-4176-896D-183633CD21BD@cisco.com>
References: <CAKVaF1T08KLHtj6V56OynuwOcWSxugTZkRQd044GMdm-Or5MdA@mail.gmail.com> <3F9EEF1B-2209-403A-A31C-1C59DD434280@cisco.com> <CAPpMEKw3x+1YSJ2TwsTV4-Y1Ps2UL4X1Eu2hy6yxaD6KiS88QQ@mail.gmail.com>
In-Reply-To: <CAPpMEKw3x+1YSJ2TwsTV4-Y1Ps2UL4X1Eu2hy6yxaD6KiS88QQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sajassi@cisco.com;
x-originating-ip: [128.107.241.186]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b22593a2-ffa7-4073-4d76-08d72cb37246
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN8PR11MB3586;
x-ms-traffictypediagnostic: BN8PR11MB3586:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BN8PR11MB358658C8FD29889CCB34D517B0A20@BN8PR11MB3586.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 0144B30E41
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(376002)(366004)(396003)(346002)(39860400002)(136003)(65514003)(51914003)(189003)(199004)(486006)(66066001)(6512007)(54896002)(606006)(14444005)(256004)(64756008)(66946007)(2906002)(6246003)(76116006)(2616005)(7736002)(11346002)(236005)(476003)(446003)(6916009)(76176011)(66446008)(5070765005)(66476007)(6486002)(91956017)(6306002)(5660300002)(478600001)(316002)(33656002)(99286004)(6116002)(58126008)(54906003)(71190400001)(229853002)(6436002)(8936002)(14454004)(66556008)(53936002)(81156014)(4326008)(8676002)(186003)(102836004)(71200400001)(26005)(25786009)(6506007)(53546011)(86362001)(966005)(36756003)(3846002)(81166006)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3586; H:BN8PR11MB3699.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: uaPYm/entXyvJKgR3wzBLdDfw8VBkX1O5neCyrMatx64N2yA1gjAQlr/EjHovwaXvoaHJi36YPzOK5s2g5n4dIoCn+o7QBuBE3MLla4lY6SQ7BFc6HaMahKqP9fgYM0z2Fwm2uYOxAP6tK/4po+zX/oj9hF34SK8M8aLVWZD4nz7jhxUGz3F3hqG+TXkNhODmvVil7bjfEkR6N38ZNs+zV8yJtXbyaFF3k7CyNIBKjhKIm6jOWpTAzGQcSKPNzblnCPH6YlmxB+F9fRA6456duaevZS9eknKeWWRPC11YWy/Ni7TfPnzknqzNbJjrI6gRUWhXos2iVV1TCf+2skkOptAMew5++RsM7sv/C2EOdkocyustf+SH1LRzSVq1nyUvc1F9vsW8gVLJjW0z3927I/4/c5uFImB9DhX0PD85DY=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_70984A8DF5C64176896D183633CD21BDciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b22593a2-ffa7-4073-4d76-08d72cb37246
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 19:02:32.2013 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 71M62QgyBmdgNySpx7qA2OAS/bf1PWn7ULYuthG8NGBq6tpCXnSSbaO+Chb8Mf5AzJ0DAUFmtcMr7153+hZmNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3586
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/BcNnIc52uBQ9Vuwiwj0g5Tmt_TE>
Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Aug 2019 19:02:41 -0000

Hi Siddhesh,  wrt point #3, my point is that there is no guarantee that a given RR vendor implement/support this opaque route. Even if they do, it will take an update to get this feature. For the update of RR, the provider (cloud, sp, Enterprise) has a process in place. This same process that is used for RR upgrade to support this opaque route, can be used to support new routes. I understand that with the opaque route, you upgrade once and the subsequent new routes can be supported transparently but how often do you we introduce new routes. Furthermore, it is better to have a new routes that has multi-vendor interop support than the one that doesn’t have. Do you know of any providers that says I am OK with vendor lock-in?

If you look at the history here, we have done pretty well with collaborating together and coming up with the new routes that has multiple vendor support from the beginning. All EVPN route types from RT-5 onward fall into this category. With SD-WAN related stuff, you can come with a single extensible route that is future proof (in terms of RR).

I am just concern that introduction of opaque route will open a Pandora’s box that cannot be closed.

Cheers,
Ali

From: Siddhesh Dindorkar <siddhesh.dindorkar@nuagenetworks.net>
Date: Wednesday, August 28, 2019 at 2:43 PM
To: Cisco Employee <sajassi@cisco.com>
Cc: Stephane Litkowski <slitkows.ietf@gmail.com>om>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

Hi Ali, thanks for the detailed comments. We understand your view and those were the discussion points within us as well. However, in reference to your RR point #3, one of the reason for a vendor specific evpn route type is to be able to do prototyping within small scale deployements which use other vendor RRs. Even if we have RFCs for new route types, other vendors may not implement them if they dont need those usecases and/or is not a release priority. Hence again comes the restriction in using other vendor RR until the new route type is implemented by the RR vendor.

Best,
Siddhesh


On Tue, Aug 27, 2019 at 3:27 PM Ali Sajassi (sajassi) <sajassi@cisco.com<mailto:sajassi@cisco.com>> wrote:
Hi Jorge,

I will support this draft if it is modified to specify the routes for SD-WAN application specifically as opposed to have an opaque route. My concerns are the following:


  1.  The main idea of standardization is interoperability among vendors and this draft doesn’t give us that.
  2.  Also I don’t think having such a draft can facilitate prototyping. This draft has been around for several years and your prototyping should have been independent of this draft since I am not aware of any other major vendor implemented or deployed this draft.
  3.  Even if this draft becomes an RFC, there is no guarantee that in a given network the RR will be compliant with it as we have experienced such things first hand in the field
  4.  Making dependency of an IETF draft on IEEE process is not a good thing – i.e., an new vendor that wants to implement it now needs to apply for an IEEE OUI.  OUI gets allocated to the vendor with Ethernet PHY for MAC addresses and not as route distinguisher. I am not sure how IEEE will look at this. Have you discussed your application with them (e.g., OUI for non-related Ethernet PHY/MAC)
  5.  RR can be used as store and forward mechanism for data that didn’t use BGP before. I have already seen that some people want to use BGP for passing configuration, stats, diagnostics info, etc. With now defining an opaque route, there will be no check on the contents of the route and anyone can put anything they want even if it is not best suited to do them in BGP.

So, frankly, I don’t see any positives here but just negatives. Can you replace the opaque route with the actual routes. At the end of the day, we have to do it for multi-vendor interop anyway. So, the sooner, the better. If single-vendor deployment is sufficient which is typically the case for Enterprises, then there is no need to standardize such draft.

Cheers,
Ali


From: BESS <bess-bounces@ietf.org<mailto:bess-bounces@ietf.org>> on behalf of Stephane Litkowski <slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com>>
Date: Tuesday, August 20, 2019 at 2:16 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: [bess] WG adoption call and IPR poll for draft-rabadan-bess-vendor-evpn-route-07

Hi,

This email begins a two-weeks WG adoption poll for draft-rabadan-bess-vendor-evpn-route-07 [1]
Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this Document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document won't progress without answers from all the authors and contributors.
Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

This poll for adoption closes on 2nd September 2019.

Regards,
Stephane and Matthew

[1] https://datatracker.ietf.org/doc/draft-rabadan-bess-vendor-evpn-route/
_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess