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. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
