BGP Color-Aware Routing (CAR)
draft-ietf-idr-bgp-car-16

Thank you to Yoav Nir for his secdir review.  

old (and they have been addressed)
--------------------------
These are definitely nits:  

Section 1.1, abbreviations:  Alphabetize the list?  Please add NLRI,  (what is the 'I' in AFI/SAFI?)

Section 2.9:  In this section there is a mix of field definitions that either define the length of the field plus a description of the contents, or just a description of the contents.  For example, 2.9.1 key length states a 1 octet field etc. but 2.9.2.1 length states 'variable, MUST be a multiple of 3. Since there are ascii art figures of the actual packet fields, maybe this isn't confusing.  Consider listing the field length where it is reasonable.
-------------------
new.  (apologies)


Section 12, para 1:  This seems like a weird way to state that the security considerations and issues haven't changed.  If it is true that adding these new definitions, please explain why they don't change the security considerations.  (if the following paragraphs explain this situation, please reorganize them to make it more obvious).

# Internet AD comments for draft-ietf-idr-bgp-car-13
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S1, S1.1, S2.9.3, S2.9.5

* "Color is a 32-bit numerical value" ->
  "Color is a non-zero 32-bit numerical value"

  ... since RFC 9256 S2.1 is mentioned (it defines color as non-zero).

I have been following and reading the draft during its lifecycle in the WG.

Thank you to Joel Halpern for the GENART review.

Thank you for addressing my DISCUSS feedback.

** (as Joel noted in his GENART review) What’s the experiment to motivate the experimental status?  What does success look like?

# Éric Vyncke, INT AD, comments for draft-ietf-idr-bgp-car-15
CC @evyncke

Thank you for the work put into this document. Due to time constraints, I have only browsed this document, sorry about this light review.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Sue Hares for the shepherd's very detailed write-up including the WG consensus *and* the justification of the intended status, it is also quite old, i.e., I wonder whether things have changed since April 2024.

I hope that this review helps to improve the document,

Regards,

-éric


## COMMENTS (non-blocking)

### Section 1

The letter "E" is used, but I failed to see its definition. Same for "E2" in section 1.1. Even saying 'E' = edge would help.

### Section 1.1

Unsure how to read `Where the network uses SRv6, the operators have agreed to trust each other's specification of SRv6 SIDs.` In the case of multiple operators, I would assume that *all* transport (bein plain IP or SR MPLS or SRv6) relies on a trust relationship. Unsure what is a specification of SRv6 SIDs, suggest using "allocation" ?

### Section 2.5

Should a reference be added for SRv6 Flex Algo ? Same later for "TEA".

### Section 2.9.2.1 (and possible other places)

Even if somehow obvious, please state the unit for the Length field.

### Section 2.9.2.3

s/a stack of 128-bit SRv6 SIDs/an ordered list of 128-bit SRv6 SIDs/ ? SRH is not about 'stack' of labels.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

Thanks for working on this document. And if I take the word "transport" as defined in the terminology section then I agree with our TSVART reviewer Brian Trammell (Thanks Brian) that there are now issues surfaced with this document from transport protocol perspective. 

However, Roman has very good comments and discuss points, I am supporting his discuss.