[bess] Mirja Kühlewind's No Objection on draft-ietf-bess-fat-pw-bgp-03: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-bess-fat-pw-bgp-03: 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-fat-pw-bgp/



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

I would be really happy if the document could say lightly more about how flow
labels are supposed to be assigned. Is the assumption that all packets of an
TCP flow get the same flow label assigned?

Just a comment, no action required: Given there are only 4 unsigned bits left
and the registry policy is "IETF review", I actually don't think a registry is
necessarily needed. The remaining bits could just be assigned by additional
RFCs that update RFC4761.

Some nits, minor comments:

1) sec 1: Please spell out "ASBR"

2) sec 3: "a PE sending a Control Flags field with T = 1 and
   receiving a Control Flags field with R = 1 MUST include a flow label
   in the Pseudowire packet."
   Must this be a MUST or could this be a SHOULD?

3) In sec 2 there is this text:
"the remaining bits, designated Z, MUST
   be set to zero when sending and MUST be ignored when receiving this
   Extended Community."
 In the IANA Consideration section there is this text:
"As per [RFC4761] and this document, the remaining bits are
   unassigned, and MUST be set to zero when sending and MUST be ignored
   when receiving the Layer2 Info Extended Community."

I think the text in section 2 is actually incorrect because it should not
talked about the bits that are marked Z but rather about bits that are not
assigned in the newly created registry because otherwise you'd need to update
this RFC (and RFC4761) every time you assign a new bit.

Further I don't think this need to be mentioned in the IANA section and should
only be correctly specified in section 2. Except you would like IANA to note
this on the registration page but then you should say that...