Re: [bess] Closing on Stephane's open issue with draft-ietf-bess-datacenter-gateway
slitkows.ietf@gmail.com Mon, 08 June 2020 08:26 UTC
Return-Path: <slitkows.ietf@gmail.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 BE79A3A09D7; Mon, 8 Jun 2020 01:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 iHOa81dUjyRb; Mon, 8 Jun 2020 01:26:37 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010763A09D5; Mon, 8 Jun 2020 01:26:36 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id q11so16395765wrp.3; Mon, 08 Jun 2020 01:26:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=LvoQtmFYxex3rSjly/NCMjF3T7M8i5COuzcjbcJGu2s=; b=NL+IWzubkkaKQBJJ5JOoNTN4sdaRaORYH0u2KIETyX2vjxIo3CQzWUnvZkd4pX6bdw Lm1TT+tbAw17b/BwqlRsf3yq1tCwheeehnbFA+tn3IopTq0UX8OvuEPF9IJfeKp/j7Sc QUbzHKY/sAba1ETu91ADGWD6o+hvs8lQmVBAkyXdoDoykaavJbFBZ2APSMQ/pKejUUOM QWcYzvycuXUriWcHo2r15fJ/cEUiO5TdPAt6zEgz9KGh9F1wm2tCoYIDkYaEKV1x1BLm VliPAbUPw0B/FvDlBhMcn7/lAYWiZE0u4M1LarpWKlU3vHP0V6ucxprVuUTB3dY0BRKD sMtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=LvoQtmFYxex3rSjly/NCMjF3T7M8i5COuzcjbcJGu2s=; b=sjDXRqHF06y0TNQoj2c+4Avsi5sxZ1NsLcJCTdBMXuGMHiXXz5AN6Q87EFWXg163rj GftjcznOtAodsQFX0fCjStqav+/iLqpvbxgDRQ4q0JBXk5jefPUfFydDpWAiRGAf0Qky JXk9Nzg5ox11rHUE2zH4wkfMy1kH8T10XWWsinHWx08i/e0AkSaZB7OleE2hFYptj7LW KH+wMMj0Dl8HE35CTGCrwf/ozvRXOUOQzs3i74Ox4MoJ3U0+yPDlfJLATrfxEbgV5CGM XWAfsGAYrA4RX3bLOIYmAjEWHg2zdlpWcv6dcw5OR+Rv7N3dT5VLAV7sFk9EFsluwVoi Lngg==
X-Gm-Message-State: AOAM531/2ruLYxIf6CJQF9942ciHjG0TwD6ISy/gHC6WTdvKrCDfaNlk eWIn/9NYJZ4ej28kqGlzIZtnGQY=
X-Google-Smtp-Source: ABdhPJyS4fOo3b/7cD+bX928REscwEPfEjciDTgfx4d18ls1Hc97Gs7NGGgU4yDJIh4v2euBe05iwg==
X-Received: by 2002:a5d:5744:: with SMTP id q4mr21512952wrw.137.1591604795409; Mon, 08 Jun 2020 01:26:35 -0700 (PDT)
Received: from SLITKOWS3YYU6 ([173.38.220.53]) by smtp.gmail.com with ESMTPSA id d17sm24971647wrg.75.2020.06.08.01.26.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jun 2020 01:26:34 -0700 (PDT)
From: slitkows.ietf@gmail.com
To: adrian@olddog.co.uk
Cc: bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-datacenter-gateway@ietf.org
References: <07cf01d63a95$fcbf6c70$f63e4550$@olddog.co.uk>
In-Reply-To: <07cf01d63a95$fcbf6c70$f63e4550$@olddog.co.uk>
Date: Mon, 08 Jun 2020 10:26:32 +0200
Message-ID: <00c901d63d6e$84e9cca0$8ebd65e0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLsNOicxczrDRMFs5ul7jzb5fuPl6aicjDw
Content-Language: fr
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/qhDqUshKGXEk6A8Rh1oo3GEDUg4>
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 08:26:39 -0000
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> Sent: jeudi 4 juin 2020 19:31 To: slitkows.ietf@gmail.com Cc: bess-chairs@ietf.org; bess@ietf.org; 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] Closing on Stephane's open issue with draf… Adrian Farrel
- Re: [bess] Closing on Stephane's open issue with … slitkows.ietf
- Re: [bess] Closing on Stephane's open issue with … Robert Raszuk
- Re: [bess] Closing on Stephane's open issue with … Linda Dunbar
- Re: [bess] Closing on Stephane's open issue with … Adrian Farrel