[bess] draft-ietf-bess-evpn-ipvpn-interworking chair review

"Stephane Litkowski (slitkows)" <slitkows@cisco.com> Fri, 11 December 2020 15:35 UTC

Return-Path: <slitkows@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 6BB383A0CC1; Fri, 11 Dec 2020 07:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 header.b=XldzuiOj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=n83oZFrn
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 mk85VMBo8GQv; Fri, 11 Dec 2020 07:35:54 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE763A0CC0; Fri, 11 Dec 2020 07:35:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24782; q=dns/txt; s=iport; t=1607700953; x=1608910553; h=from:to:cc:subject:date:message-id:mime-version; bh=j0P5c8R9DzfSHkt1Dbmj1NN0+UYxV0oDAY8NiX0QW1c=; b=XldzuiOjs9BHcPF8TxGjQSQD166E055Y+Sfliowgin5V+OzoqOHVWxap emRKP1NiovyKIvia8hB2dGDkYTBwpgqCZO2uHDAzsFPREHF/KRvc/KGXg fDMlt+WS7Ssg3g76bPnJymqvvFqMShTzgiCm4cLU0+qYB5fJNa5v3th+4 Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3AvPl0MBcdXYEBcf/dYFG2gNIRlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQB9fa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQBykdNf/5RdJa1iHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE9BgELAYEiL1EHdVsvLgqHfQONW5kNgS6BJQNUCwEBAQ0BAS0CBAE?= =?us-ascii?q?BhEoCgX8CJTYHDgIDAQELAQEFAQEBAgEGBHGFYQELhXUWFQYTAQE3AREBQEA?= =?us-ascii?q?mAQQODQwHB4MFgX5XAy4Bo3QCgTyIaXSBATODBAEBBYUNGIIQCYE4AYJ0ilI?= =?us-ascii?q?bgUE/gRFDhykqDIM8giyBaRo+BjAwBBQbFC+BKAINKQEPGTiPLAY+iiCDMpo?= =?us-ascii?q?tCoJ0m2mDJYomhViPF5QBggKaWYRLAgQCBAUCDgEBBYFdATKBV3AVO4JpUBc?= =?us-ascii?q?CDY4hg3GKWHQ3AgYKAQEDCXyHFoE0ATFfAQE?=
X-IronPort-AV: E=Sophos;i="5.78,411,1599523200"; d="scan'208,217";a="814736728"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Dec 2020 15:35:33 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BBFZXrp030182 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Dec 2020 15:35:33 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 11 Dec 2020 09:35:33 -0600
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 11 Dec 2020 09:35:15 -0600
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 11 Dec 2020 09:35:15 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=htMFjuv7dihT7Sw1ycWTtuSyzgDo7O5s2o9aqr9CWicdk3rplttcJA/91Zd7zwtg0oDBfRZX1Wk3StKh7XOjtG0ldcKpiVvvbWsga8iCrF91hXgMS9ScHDVZMsPWCJSeGZ+H2Fr0fEfFbf4uoDFA3mhjopmyWXHsv1wp1PGiK++D4R8haP+bEpvGVJGhJprkfVctc9RoqSMpT+N+z1SKrXX/4Bwdq0Pm+nkhNSlRgrpZhy5prDd5V0bi+nt8mHoeAELfo1ORClN26TEoQ4wDsbiqkVrohTmyDoz9lQ52wkRonavRs34K1irxOBe5expBxm6U/pX5wfkzsSzMkgKMFA==
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=1MHRuPSDsCE5al6hfPLskIyWrmvp/isvoHebnAUmnbY=; b=oMNoCnPO8El8A80IFPQKpvaXM0pWE8/Hkg3okeOW6DUTl6GLA+s7lzk+wjLZG/QIvHiO/6VKAlF/eWF/kaZO2AKIe1ZYxLsvIVYgLS1jtR6772Yep53CqgVEH/jJ/xk156wZC29ZMC9Eg1m3IfpIp351R3NvEZ/jOMxFWtAiE/1+urGyfCy80rAV9DQoRadCpCDEXsZjwhFTSZ+w6bsnOqR3Vg4vM7wk6Zu5MWF/yixQqRNVV2oWnuTuS2/d/kauzZPBYv0EWnfzgMKEmSlyfhFAYTh3EgfFpdHxkPi82/WO8bhoHyuhG7Q7oJvc6IcYw/5YlFJb8L78qrt3HLMu/A==
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=1MHRuPSDsCE5al6hfPLskIyWrmvp/isvoHebnAUmnbY=; b=n83oZFrnEUnY/2+v2xOT5q/FcYvVccu/l72k+8sETDaojawzkSooImi+bQrJoECM+nC8dryTwupSPjNraqSUz4F0xQ6gDWQBtT3oQYInkvmzFxJ5TF0JrFWZ9joiOdMITnu/E8SvrfuC8+7ruh66cVFqVyCd8UN1VP3eVUIr6eI=
Received: from SJ0PR11MB5136.namprd11.prod.outlook.com (2603:10b6:a03:2d1::18) by BY5PR11MB4007.namprd11.prod.outlook.com (2603:10b6:a03:189::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.17; Fri, 11 Dec 2020 15:35:14 +0000
Received: from SJ0PR11MB5136.namprd11.prod.outlook.com ([fe80::b568:2abe:32e7:6e92]) by SJ0PR11MB5136.namprd11.prod.outlook.com ([fe80::b568:2abe:32e7:6e92%4]) with mapi id 15.20.3632.021; Fri, 11 Dec 2020 15:35:14 +0000
From: "Stephane Litkowski (slitkows)" <slitkows@cisco.com>
To: "draft-ietf-bess-evpn-ipvpn-interworking@ietf.org" <draft-ietf-bess-evpn-ipvpn-interworking@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>
Thread-Topic: draft-ietf-bess-evpn-ipvpn-interworking chair review
Thread-Index: AdbPxaFpRGL7dHhhQA2qKZV1+IXpHA==
Date: Fri, 11 Dec 2020 15:35:14 +0000
Message-ID: <SJ0PR11MB5136CFF7BC3D523B2BCFFC69C2CA0@SJ0PR11MB5136.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.33]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 37c77cba-7eb7-4dbd-df55-08d89dea5af7
x-ms-traffictypediagnostic: BY5PR11MB4007:
x-microsoft-antispam-prvs: <BY5PR11MB40071D29AF190092A4C8AEE4C2CA0@BY5PR11MB4007.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6108;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: L4n4MMyZp7InQMa3EcrISCGf+hxM3kBr+k35W5+pXZinOSDT4WZE4Gx0TqEUTgf55gToBLZNfvPI0m6BLtcLjsD3nMtMY3rzBtHBggB8yPBLLACFQUM25TaCngAX1ye49zo0tRLRpkGQDWuVUWYoszm8Eq73cPJJ0CffuxyUBH1wdd0qNmz13BkbcZSxTcdi7+JxqZlQs14i3oRQ6P+myxQ0+qCJyURVxdRcFV2l4tiKy0O1Qnefpd3b8f9/WPaZw5BeDHl6+EmZLtNnR/N+j1V3ox2gamS2IQALHETnu3kr9UAr3941KS+lQ2QPj73u3iFEcRNd+O35enQ3SCN/7Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB5136.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(39860400002)(396003)(376002)(33656002)(8936002)(83380400001)(478600001)(450100002)(4326008)(71200400001)(86362001)(316002)(186003)(2906002)(64756008)(26005)(66556008)(66946007)(7696005)(66446008)(6916009)(66476007)(54906003)(6506007)(52536014)(8676002)(5660300002)(55016002)(76116006)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?qs1/ML9szbUKc85uIsrqE95q966prIngQx8jxp9uX/ZWoTc+WwKKBEfmjy8L?= =?us-ascii?Q?bqSK9UOBXr4SYdkH8m300qjNcS++WQ2aQp1PWO/vNQG2+c97rMvj3zZZ26GQ?= =?us-ascii?Q?NQxrCFOJ3/AyTOl4f6QlRaK9Wz6EXynrAAO3Q05uSiOlxLfDfAn+d7njcP4p?= =?us-ascii?Q?hhRj+lXk9mo618hE8uSApIHewgyvZPL+Rop7AlpH2OIEGmmb8ut23EgXtPjq?= =?us-ascii?Q?59H/yr0sf9UQU7MyYVz3oEkqndV1wqNhE8tKfqhe2Mt099aGgdTSpnQIaOK9?= =?us-ascii?Q?s/wkX2CxkxYcUS0vs5D0uID5nWHHkpS7pPi1JFUgEesUFnsAb5aTbfLvf8ka?= =?us-ascii?Q?1hDrtUyskrHXGPm9RblVW9GOq92fk7tMXGSCqPBAdmvcJ9Vzy4/KTrLvUOZj?= =?us-ascii?Q?YAB8lGphIdGge++t9uSFA5Ffwpo9OdXwkovURxUbNGWIJmTApDW0La6LS/UV?= =?us-ascii?Q?v6JDrDk1jDAlzFM59c04rxPtqcGlz2GTUUgeQIWfQI3+64L89O0Sd+VdgSOj?= =?us-ascii?Q?M6e7adq4FtZIq37q6+r8H+K6KuBKoZDqh6Rp4OkWbmAMjGn0oGMLVlEOsfv2?= =?us-ascii?Q?dKi+J/Kn9f2zlPkugbi1jzs2A7RzNbAY+6BFB/Edgt02woiq/wgOgGCNYbtt?= =?us-ascii?Q?A2+ByLHp094aBnPfnnNSXczXsFinKutuRD2Z79csV8HN1JdqArMqD9qN3ICs?= =?us-ascii?Q?A5y2e3lKwDt57yi6X2A18adW5jpJNz9fTy1NqkAzs6LHQoyQam8E4EeiL/Dl?= =?us-ascii?Q?yyvj4HhjLZKD4HJaks3OFHwfTwcwrPa+zL5POnvj+B6JZ8Ez1h+ZvMljfdIZ?= =?us-ascii?Q?T+GvERitUFcRcnRvpzk3hWWofhUVpvDbwt3a+IA+NdpfOgSE74L++5jufhKF?= =?us-ascii?Q?Fm+ZZ+C1t/pPxFKXypTQALLN5VgRH4yuUq3gQDNgx3hsjmpEbcshL4VZQJhi?= =?us-ascii?Q?LCSpMyAbazaOH2+pPCiwMgRTcByqUroqQMnAJYPBHvg=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SJ0PR11MB5136CFF7BC3D523B2BCFFC69C2CA0SJ0PR11MB5136namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5136.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 37c77cba-7eb7-4dbd-df55-08d89dea5af7
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2020 15:35:14.6370 (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: tZ/njDtIeTg/y3zyZzDXjlaIptsKMN6SKoJ+Zv+TSDRwba3yA+7dJyD9kLwduG9rYEAGnyB6MJ6iervWNal30Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4007
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/2lWCGWpIf_RiWzmjtd1mRgEYGhM>
Subject: [bess] draft-ietf-bess-evpn-ipvpn-interworking chair review
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: Fri, 11 Dec 2020 15:35:57 -0000

Hi Authors,


Please find below my chair review related to draft-ietf-bess-evpn-ipvpn-interworking.

BTW, you need to refresh the draft now, it has expired.

Section 3:

  *   Nit:
s/uniqueness of the DOMAIN- ID/uniqueness of the DOMAIN-ID/


  *   a) I agree with DJ's comment on: "This attribute list may contain zero, one or more segments". It is actually one or more.
  *   The section 3 contains both normative and non-normative language. If section 3 is intended to detail the normative behavior of adding/modifying D-PATH, it must use normative for any of the normative procedure. For instance b) may require normative language. While it is very good to have an example in b), one or more clear normative rules are required before talking about the example.
  *   b) talks about domain-ids attached to IP-VRF, this is fine. However, the text should provide a wider view so people don't think that this is the only option. Domain-Ids may be assigned at VRF level, but also at more a higher level (BGP peer), or even lower level (bgp community...). We should not limit implementations here in the granularity domain-ids are defined.
  *   c) I don't see why "MUST NOT", it does not hurt to have a DOMAIN-ID associated with non ISF world (routes learned from IGP, static)... there could be design where people do BGP one leg and non-BGP on the other leg. We should probably relax that.

Would you mind adding a beautiful ASCII-ART for the attribute format ? It's usually good to have when reading to see the attribute format rather than having to read the text.


You need to define the error handling procedures for D-PATH as per RFC7606 (you should have it as normative ref too).


Section 3.1
This sentence is misleading and does not match with the normative behavior of Section 3) d)

"In general, any interworking PE that imports an ISF route MUST flag

   the route as "looped" if its D-PATH contains a <DOMAIN-ID:ISF_SAFI_TYPE> segment, where DOMAIN-ID matches a local DOMAIN-ID

   in the tenant IP-VRF."

I don't see the value of this section beyond providing an example. The normative behavior is already given in Section 3) d). Can't the example be packed under d).

Also the pointed sentence still refers to a DOMAIN-ID per VRF, which is not good for a generic statement. My domain ID info could from the BGP peer config. Again, this option of per VRF is fine, but this is not the only one that can be implemented.


Section 4.1:
I don't see why "no-propagation-mode" is the default mode. This is breaking existing propagation of attributes from SAFI 1 to SAFI 128. When we have a CE running BGP with a PE, the PE propagates the attributes (CTs, ASPATH, MED...) coming from the CE.
This section creates some ambiguity about the D-PATH attribute. Based on Section 3, D-PATH will be necessarily sent but received D-PATH may be dropped and new one created but the text of section 4.1 makes me think that it's not the case in no-propagation mode.
I think setting D-PATH is orthogonal to the attribute propagation.
As section 4.1 tells, people may still want to rely on existing SoO for instance in some case in this case D-PATH may not be added.
I think section 3 and 4.1 have to be more clear on the normative procedures about D-PATH addition/modification.

Section 4.2:
Isn't it dangerous to try to define which attributes needs to be propagated, and which one should not be ? We are always creating new attributes, should people update this doc each time a new attribute comes ? I don't really see how this could be managed.

Isn't there an indentation issue starting "When propagating an ISD route to a different ISF SAFI..." ?

The considerations about ASPATH look really implementation details to me (at least the way it is written). Basically the ASPATH propagation rules doesn't change and the gateway function itself does not modify the ASPATH.

Similarly, for the IBGP-only path attributes, the word "copy" looks really implementation dependent. Why not telling that the advertised route should keep the received iBGP-only attribute ?
You should also clarify considerations regarding rfc6368.


Section 4.3:
Shouldn't we just follow existing aggregation rules of each attribute ? Again, what happens when new attributes are coming in. I don't think that the gateway function has actually something to change in the aggregation process. Aggregation is happening in the VRF, there is no change compared to what is existing today, for VRF, it's just IP prefix aggregation.


However, as we are defining D-PATH, we can define aggregation rules related to D-PATH.



Section 5:


"For a given prefix advertised in one or more non-EVPN ISF routes, the

   BGP best path selection procedure will produce a set of "non-EVPN

   best paths".  For a given prefix advertised in one or more EVPN ISF

   routes, the BGP best path selection procedure will produce a set of

   "EVPN best paths". >

I think the EVPN vs non EVPN paths is a bit misleading. Couldn't we simplify say that we have best path selection at ISF level which inserts routes in IP-VRF and then we have a new selection at VRF level.

Regarding the new tie-breakers:
It s not clear to me which steps tie breaks an IPVPN path vs an EVPN path (composite PE case) that are equivalent (only ISF changes).



Section 7:

I agree with Suresh's comment about the unclarity of the first bullet.
This document makes ISF 1 in the picture, so all the procedures defined in the document are applicable to all the combinations of ISFs including SAFI1 <-> SAFI 128. So the text must be written carefully.


Section 10:  This section should be at the top of the document.

Section 11:
You need a security consideration section.

Section 15:
IMO, intersubnet forwarding and prefix-adv drafts must be normative as they are key components of the solution.



Pls update the draft and then I'll ask IDR to have a review on the draft as well.


Brgds,

Stephane