[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.