Re: [bess] Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway

Linda Dunbar <linda.dunbar@futurewei.com> Mon, 08 June 2020 18:21 UTC

Return-Path: <linda.dunbar@futurewei.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 7DA5A3A0DCD; Mon, 8 Jun 2020 11:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 FZ6dtTRIRAsl; Mon, 8 Jun 2020 11:21:15 -0700 (PDT)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2104.outbound.protection.outlook.com [40.107.237.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 234263A0DB8; Mon, 8 Jun 2020 11:21:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cninZUJpD7gI/a4qsrPXcgzF6OyCtlU+HS5HrcW98/wUV9z+ry7ZViWCQrveS/6zyZLmBsWU7gW4X9fzIKlxwBpBnhBM7+f/dBbHLf6gztc4nHCqmhQ9mQedP6uCmlM8wXjDf4ui0N2d362xSsAQ+xNo9cUO3dssBNMDdmROM2lY1ZzFwH0PRBuTaR63Qgp5Dtnez1wpZ5x1TFCMfheowr376qcMOvbkzHLnlEClRmd3lh9QVYE+X5WZFMkuVXbnznGscInWJyuC6DTEY/pRHE7bWsfYWRjRXl/vDhXFLbPnfEy7XmF8czzwGtnscXPwVZ8Y0kJM7k9pRnZSq+GItw==
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=22/miAqwUgwH4FTw4IczI5TgIX3jUq9ZFSQxSS89xmI=; b=CMUO8GAMuLCnF5wpWCjF/zswDx9o+GVtHlL6eVoQNWWsNcpFVlCTmN1duDnZTM1tfW9JiTjd7higcohPLfJpSowfm9pbGHJ1LNCDrM59Np7HDtNRmy60agIWwfR2enlEwWIX5nYbLFzw0BrHDdGn5L2mTdf16qxiaxZeqINZQGaHKQriC0ZpFovmCV40xImdp4DcNk+yRPzO7JA2Ua76dX8/ToJCiOSF3S+jwQ9IWLoIlLkZUhmRoERf3jBhoDhwpeuYo+YSnuEtymFiS2Ufmkj0FfhZJLdXa7Otkb6tkSWDu+UtoCYdmEKay2EpjFWPwxjcFhRjAo3T8f9UYHcHKA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=22/miAqwUgwH4FTw4IczI5TgIX3jUq9ZFSQxSS89xmI=; b=ZDborI+rJ7EqvI86UMlBLtOR2iXJYI8fdibJZzz0d3vGVe9UE5w6AbN5muJTCogNKyp+SkJ+q5MAEQwz2UoDXjrcFIZtw0w5WevJwOzxklj9HfDhVjJ9jv90T7niiNYXXS/EM/9UbVP9z8AFaCirJT+wcG1KOUz1CWv0CfZzuZU=
Received: from SN6PR13MB2334.namprd13.prod.outlook.com (2603:10b6:805:55::16) by SA0PR13MB4063.namprd13.prod.outlook.com (2603:10b6:806:94::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.9; Mon, 8 Jun 2020 18:21:12 +0000
Received: from SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::783f:2d78:2f9f:3116]) by SN6PR13MB2334.namprd13.prod.outlook.com ([fe80::783f:2d78:2f9f:3116%7]) with mapi id 15.20.3088.016; Mon, 8 Jun 2020 18:21:12 +0000
From: Linda Dunbar <linda.dunbar@futurewei.com>
To: Robert Raszuk <robert@raszuk.net>, "slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>
CC: "draft-ietf-bess-datacenter-gateway@ietf.org" <draft-ietf-bess-datacenter-gateway@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, BESS <bess@ietf.org>
Thread-Topic: [bess] Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway
Thread-Index: AdY6lGqXGWjWV+CqS8WbE9b/W2m5wwC2hkkAAAMCZAAAET6VQA==
Date: Mon, 08 Jun 2020 18:21:12 +0000
Message-ID: <SN6PR13MB2334B7460BBF6EEFC93681EB85850@SN6PR13MB2334.namprd13.prod.outlook.com>
References: <07cf01d63a95$fcbf6c70$f63e4550$@olddog.co.uk> <00c901d63d6e$84e9cca0$8ebd65e0$@gmail.com> <CAOj+MMFPTJZQM=9sCcbjZ986n5suWFmaJS7iruyv8exfMq9yeA@mail.gmail.com>
In-Reply-To: <CAOj+MMFPTJZQM=9sCcbjZ986n5suWFmaJS7iruyv8exfMq9yeA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=futurewei.com;
x-originating-ip: [72.180.73.64]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8f1de628-f918-4f13-b4b2-08d80bd8b998
x-ms-traffictypediagnostic: SA0PR13MB4063:
x-microsoft-antispam-prvs: <SA0PR13MB40632E7986DDD41090DFD09385850@SA0PR13MB4063.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 042857DBB5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1VE/HR6xOsnm+3ShQxLFN9OcHIMzQpmr7TuMjhP4CV356kfg9h/M+qA467CqxPNms3kZv4/rjgwVxVBFQh4fxdCRmX/Jv3NOR+C1cwWAjbZcTCJDQzCfzhyvSxZYimGkbmRuw0bRB53e4lqHp6MLjjTJ71TwAhst5uspovj4uRproitNJ1G9zjFzeh3R/BsvYkjFcS92E4IuwlAaMdp3yp/Zuap4AcoDIQpFi5iFckOfjnI6rgWi8uQpUUYyTaYOPabQIanVlw0AMKiPwP7emg9adM30ffdeJgokb1H6n3utoLCeZO6knt5oWYYwDmm/jvdTOj0S4627Y4pbm/QR9ZNRjPXWYuRa5LXnpFugXsBIHHBSuIhe+POrMXv4rnlIiiq6/KmiUZjxXKue5nlEHw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR13MB2334.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(366004)(136003)(396003)(39840400004)(44832011)(33656002)(5660300002)(66946007)(76116006)(64756008)(66556008)(66476007)(66446008)(316002)(71200400001)(52536014)(8676002)(8936002)(110136005)(83380400001)(478600001)(53546011)(7696005)(2906002)(55016002)(186003)(86362001)(26005)(6506007)(4326008)(966005)(9686003)(54906003)(66574014)(166002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: 5m1tHsQFFBrxKqjdrH9sSE3bxpmagv3Xi9jv0Z5WRoaVpB+sZqIxBdZ/vt9sbtqBNDGkN7yJ+bbsPugE9j2ziXwG0Otr/qF+ii089K8lRu2TMVSf2Y/oI/7B3JsRNciXGZx+oF/sJ+P7fgtn8F2Rj6/LfbjVjQT+OkLLPVymN7n3XDX0tdf6hwmyCV8NLo7PmhVTJY1A2wJM3jXLgOyi1PV8SabkoI834TqesK66sqVl/vuL7UsBvkSAe0IeAFUMPpLwyNMbTPIB4jyXOOW0FLEGb2ZmsTjt5Q9/y5qI1emDtxNplVvrW0L320A66v04pN7dy4qQOevwNNHK5YRez71zpESFJmLhYQj5cEod6yEf8QBBqebkhgFfswuPUI8ZBNXZZWqWsWJB6pSufDZkBNIARc23Rn6As5YFnDXplULx8nnRikqBxi7fIod/f8X9bLB+CS+HFAbCdLUnAhkdxFxoNm1V5ZCZclka4sGJUYE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_SN6PR13MB2334B7460BBF6EEFC93681EB85850SN6PR13MB2334namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8f1de628-f918-4f13-b4b2-08d80bd8b998
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 18:21:12.5910 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CCFwbvzaN69dY2iCWbtscRlwf8HBBAnzaC86Jk1VoOAy5+xXPaHGTRKVadBLzFo66m1JMQEMYPDJfNXjYoX8dQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR13MB4063
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/GqbDX2JhYXNvWLWV8hUw7YMWSw0>
Subject: Re: [bess] Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway
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: Mon, 08 Jun 2020 18:21:18 -0000

Stephan and Robert,

The draft proposed scheme  is orthogonal to the RTC, correct ?  If a GW’s RTC didn’t show that it is interested in a specific RT, the advertisements  from other nodes won’t sent to that GW.

Adrian:
On page 6, the second Bullet says that
“Each GW constructs an import filtering rule to import any route that carries a route target with the same SR domain identifier that the GW itself uses”

How about routes associated to a VPN and to a SR domain? The VPN and the SR might use different RTs. Can you have two different Route Target in one advertisement?

Thank you
Linda Dunbar

From: BESS <bess-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Monday, June 8, 2020 4:53 AM
To: slitkows.ietf@gmail.com
Cc: draft-ietf-bess-datacenter-gateway@ietf.org; Adrian Farrel <adrian@olddog.co.uk>; bess-chairs@ietf.org; BESS <bess@ietf.org>
Subject: Re: [bess] Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway

Stephane,

Two points ...

1. It is not clear to me that draft-ietf-bess-datacenter-gateway recommends to use RTC for anything - do they ? If not there is no issue.

2. Also note that RTC can be enabled on a per AF basis hence even if you use it say for SAFI 128 you do not need to use it for SAFI 1.

As a general comment I do not see any issues using RTs on non VPN SAFIs.

Thx,,
R.


On Mon, Jun 8, 2020 at 10:26 AM <slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail..com>> wrote:
Hi Adrian,

My point is really tied to what will happen when RTC is enabled (considering
draft-ietf-idr-rtc-no-rt). The behavior will be to drop the routes that
don't have an RT which will break existing Internet families behavior.
" When RTC is applied, on a particular BGP session, to routes of other
   address families, the default behavior MUST be that routes without
   any RTs are not distributed on that session.  This default "default
   behavior" applies to all AFI/SAFIs for which a different default
   behavior has not been defined."

Let me run this to IDR to get their feedback (as draft-ietf-idr-rtc-no-rt is
owned by IDR).

Stephane

-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Sent: jeudi 4 juin 2020 19:31
To: slitkows.ietf@gmail.com<mailto:slitkows.ietf@gmail.com>
Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>;
draft-ietf-bess-datacenter-gateway@ietf.org<mailto:draft-ietf-bess-datacenter-gateway@ietf.org>
Subject: Closing on Stephane's open issue with
draft-ietf-bess-datacenter-gateway

Hi,

John and I had a chat today about what we perceive is Stephane's open issue.

What we think the concern is is that we are using RTs in conjunction with
normal (i.e., non-VPN) routes. We do this to allow gateways to filter their
imports based on the RT that applies to the SR domain that it serves.

An option was to use the Route Origin extended community instead.

RFC 4360, which introduces both the Route Target and the Route Origin
extended communities and gives some guidance. Loosely expressed, the RT says
which routers should import, the RO says which routers have advertised. In
both cases, the text suggests that "One possible use of the community is
specified in RFC4364" which implies that there are other acceptable uses.

4364 implies that the RO is used "to uniquely identify the set of routes
learned from a particular site." That is (my words), to apply a filter on
top of the RT to prevent re-import by a site of routes that match the RT and
that were advertised by other entry points to the site. Indeed, the RO would
seem to be used (in the 4364 case) only when the RT is also in use.

We appreciate that the distinction is pretty delicate, but we think we are
right to use RT in this case because we are filtering to import, not to
avoid importing. Furthermore, if we used the RO then, to be consistent with
4364, we would still be using the RT anyway.

That, we think, disposes of the "RT or RO?" question.

Now, we can go back to the original formulation of the question: is it OK to
use RT with "non-VPN IP addresses"? Well, we consulted around a bit
privately amongst some BGP experts, and we couldn't find anyone to say it
was actually a problem. And (of course) no one raised the issue in WG last
call - but Matthew might claim that is because the document was only lightly
reviewed, and Stephane might claim that this is because he had already
raised the point. Obviously, some of the authors know a bit about BGP, and
Eric was a lead author on 4364 and drove a lot of the details of what we
wrote.

Two points in closing:
- If someone can show that we break something, we will have to fix it.
- If the chairs want to run this point past IDR and BESS explicitly, that
would be fine.

Hope this helps.

Best,
Adrian


_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cad50a306080b4d730e2008d80b91cdf1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637272068158897675&sdata=QE%2FS5mnOvPTQ5u%2FgTSaMTrzhOpv4YuxPUf8ALjWCTFA%3D&reserved=0>