Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-rfc5549revision-04: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 24 Aug 2020 13:18:40 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-rfc5549revision-04: No Objection

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-rfc5549revision/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The IANA Considerations need to be updated to reflect that this is a
"bis" of 5549, and is not making the allocation de novo.  I.e., it
should be "update the reference for the existing registration".

RFC 5549 says that the "Length of Next Hop Address" field for AFI/SAFI
1/128 is "16 or 32", but this document says that it is "24 or 48", which
has no overlap.  Is this a breaking change?  Ah, I guess this is
essentially errata report 5253
(https://www.rfc-editor.org/errata/eid5253).  I'd suggest that we note
that this update includes addressing that errata report.

I would also suggest a brief note that the main nature of the update is
to add support for AFI/SAFI 1/129 (as that seems to be the bulk of the
diff between RFC 5549 and this document); I believe Alvaro has asked for
something similar as well.

Other than that, just a few very minor comments for your consideration
(and for which no reply is necessary).

Section 1

   There are situations such as those described in [RFC4925] and in
   [RFC5565] where carriers (or large enterprise networks acting as

nit: the transition into this paragraph is a bit abrupt, wth the
previous paragraphs talking about existing AFI/SAFIs that already are
flexible about IPv4 vs IPv6 based on length, but now we're back into
describing a problem statement for which the solution looks quite
similar.

Section 4

I'm happy to see that the format of the Capability Value field
explicitly indicates the NLRI AFI/SAFI and nexthop AFI triples
supported, so there is no deployability concern about using the same
capability code value to indicate support for new SAFI types.

Section 5

   When a next hop address needs to be passed along unchanged (e.g., as
   a Route Reflector (RR) would do), its encoding MUST NOT be changed.
   If a particular RR client cannot handle that encoding (as determined
   by the BGP Capability Advertisement), then the NLRI in question
   cannot be distributed to that client.  For sound routing in certain
   scenarios, this will require that all the RR clients be able to
   handle whatever encodings any of them may generate.

This is good advice; I wonder if it is worth a brief mention in the
security considerations as well.

Section 10.1

In my reading, the places where we reference RFC 4291 do not require it
to be a normative reference.

Section 10.2

I agree with Alvaro about draft-ietf-idr-dynamic-cap.