[bess] Benjamin Kaduk's Discuss on draft-ietf-bess-nsh-bgp-control-plane-15: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Sun, 21 June 2020 21:12 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6EC3A0028; Sun, 21 Jun 2020 14:12:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-nsh-bgp-control-plane@ietf.org, bess-chairs@ietf.org, bess@ietf.org, slitkows.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.3.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <159277396487.18148.5164699784201867162@ietfa.amsl.com>
Date: Sun, 21 Jun 2020 14:12:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/rK8Exwcl6VJS3we2jHFpDc5v80g>
Subject: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-nsh-bgp-control-plane-15: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 21 Jun 2020 21:12:45 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-bess-nsh-bgp-control-plane-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-nsh-bgp-control-plane/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think we may still need some text changes to clarify how the joint list of SFIR-RD and SFIR Pool Identifier Extended Communities is constructed and interpreted, and potentially need to register an RD Type matching the other (TBD6+TBD7) values we allocate. (I'm also not entirely clear how the IPv6 addresses interact with 8-byte RDs.) A longer description of these topics is written up at https://mailarchive.ietf.org/arch/msg/bess/wVDRF4ni0bGhNazvWoFi8BwJ_Vg/ but is not quite appropriate for this standalone context. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [retaining the note that I support Roman's Discuss] New comments on the -15 Section 2.2 o The Special Purpose SFT values range is assigned through Standards Action. Values in that range are used for special SFC operations and do not apply to the types SF that may be placed on the SFC. I'm not sure I understand what it means to "place a SF on the SFC". Also, nit: missing "of"? o The First Come First Served range tracks assignments of STF values made by any party that defines an SF type. Reference through an Internet-Draft is desirable, but not required. Maybe "Internet-Draft or other stable written specification?" Section 8.10 The IPv6 examples seem to show RDs that are 127-bit IPv6 prefixes, but an 8-octet RD doesn't seem to have space for that? Section 8.10.4 SFP4: RD = 2001:db8::198:51:100:1/104, SPI = 18, [SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1], [SI = 250, {SFT = 43, RD = 2001:db8::192:0:2:2/2, SFT = 44, RD = 2001:db8::192:0:2:3/8 } ] [...] When the packets are returned to SFF1 by the SFI the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next hop SFF to execute the next hop in the path selecting between all SFF2 that support an SF of type 43 and SFF3 that supports an SF of type 44. These may be completely different functions that are to I see a specific (nonzero) RD for SFT=43, so I don't understand why this is a choice of "all SFF2 that support an SF of type 43". Section 9 You say that RFC 4760 has additional relevant security measures but I'm not sure which measures you're referring to (having skimmed all of 4760). This document does not fundamentally change the security behavior of BGP deployments which depend considerably on the network operator's nit(?): maybe comma before "which"? perception of risk in their network. It may be observed that the application of the mechanisms described in this document are scoped to a single domain as implied by [RFC8300] noted in Section 2.1. I can't tell if this means section 2.1 of 8300 or this document.
- [bess] Benjamin Kaduk's Discuss on draft-ietf-bes… Benjamin Kaduk via Datatracker
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Adrian Farrel
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… John E Drake
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [bess] Benjamin Kaduk's Discuss on draft-ietf… John E Drake