Re: [bess] Genart early review of draft-ietf-bess-rfc7432bis-08

["Ali Sajassi (sajassi)" <[e-mail]>]

Hi Stewart,

Thanks for your review and your comments. I have incorporated them in the next revision of this draft (rev09). Please refer to my comments marked with “Ali>” below for more details:

From: Stewart Bryant via Datatracker <[e-mail]>
Date: Monday, April 29, 2024 at 8:49 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Genart early review of draft-ietf-bess-rfc7432bis-08
Reviewer: Stewart Bryant
Review result: Ready with Issues

This is a well written document with a few issues that are editorial in nature.

Firstly id-nits picks up a number of issues that need to be addressed:

== Missing Reference: 'RFC4448' is mentioned on line 1115, but not defined
Ali> Done

== The expression 'MAY NOT', while looking like RFC 2119 requirements text,
     is not defined in RFC 2119, and should not be used.  Consider using 'MUST
     NOT' instead (if that is what you mean).

     Found 'MAY NOT' in this paragraph:

     *  If a network (inclusive of all PE and P nodes) uses entropy
     labels per [RFC6790] for ECMP load balancing, then the control word MAY
     NOT be used.
Ali> Change it to lower case

 -- The draft header indicates that this document obsoletes RFC7432, but the
     abstract doesn't seem to mention this, which it should.
Ali> Added it to the abstract

  -- The draft header indicates that this document updates RFC8214, but the
     abstract doesn't seem to mention this, which it should.
Ali> Added it to the abstract

=======
1.1.  Summary of changes from RFC 7432
I wondered if the authors planned to keep this section or whether it was just
used for development purposes? If it is planned to keep it it might be less
intrusive to the flow of the text if it were made an appendix with a forward
reference.
Ali> Done

========
   This means that for a given <EVI, BD>, a given MAC address is only
   reachable only via the PE announcing the associated MAC/IP
SB> too many onlys
Ali> Removed the first one.

========
18.1.  Flow Label
SB> There are many flow labels in different IETF protocols and so it took a few
moments to figure out what was going on here. I gather that this is essentially
a FAT label and given that what follows is a PW structure I wonder why the name
was changed.

Ali> Since FAT(Flow Aware Transport) is defined in context of PWs in RFC 6391, we wanted to avoid any confusion since we are not using PWs. Also, the authors thought the concept of flow label is simple enough to be covered by itself in that section.

SB> In any case I thing that it would be helpful to the user to include a stack
diagram to show how it works rather than requiring the reader to figure it it
out form some mildly dense text.

========

   IANA has allocated the following EVPN Extended Community sub-types in
   [RFC7153], and this document is the only reference for them, in
   addition to [RFC7432].
SB> Given that this RFC obsoletes RFC7432 it seems wrong to call that up in the
IANA section as a reference. Once this document is published RFC7432 cases to
exist as normative text so it cannot be referred to as a definitive reference.

      0x00     MAC Mobility                 [RFC7432]
      0x01     ESI Label                    [RFC7432]
      0x02     ES-Import Route Target       [RFC7432]
Ali> Updated the text accordingly to remove [RFC7432].

SB> Also the registries are already created so the IANA section of this
document should I would have thought be an instruction to change the defining
reference from RFC7432 to this document. SB> Again the following language is
strange relative to an existing registry and my previous comments apply to this
text.
   This document creates a registry called "EVPN Route Types".  New
   registrations will be made through the "RFC Required" procedure
   defined in [RFC8126].  The registry has a maximum value of 255.
   Registrations carried forward from [RFC7432] are as follows:

      0     Reserved                           [RFC7432]
      1     Ethernet Auto-discovery            [RFC7432]
      2     MAC/IP Advertisement               [RFC7432]
      3     Inclusive Multicast Ethernet Tag   [RFC7432]
      4     Ethernet Segment                   [RFC7432]
Ali> Updated the text accordingly

============
SB> The acknowledgements section is very strange.
Appendix A.  Acknowledgments for This Document (2022)
Ali> Removed “2022”, so that it implies the acknowledgement is for this document.

SB> It is not clear what version this applies to, if you keep it should have an
RFC reference Appendix B.  Contributors for This Document (2021)

   In addition to the authors listed on the front page, the following
   co-authors have also contributed to this document:
SB> No names are in this section. Is it needed?
Ali> You’re right. This section is not needed and it is removed.

Appendix C.  Acknowledgments from the First Edition (2015)
SB> Why not do the acknowledgements in narrative text rather than a set of
appendixes?
Ali>  moved the new acknowledgement (for the bis document) in narrative text and moved all the old acknowledgements and old contributors/authors to the appendix.

========
SB> The way that the previous authors acknowledgements are done is also very
confusing making it harder than needed to identify the authors of this text. I
am also not sure that their contact details are still needed as this text
replaces the previous documents and if they are really needed they are on file
in the archived RFCs. SB> Please consider simplifying and possibly using a
narrative text approach.

Ali> Simplified it and removed the affiliation and email addresses for old author list.