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
Date: Monday, April 29, 2024 at 8:49 AM
To: gen-...@ietf.org
Cc: bess@ietf.org , draft-ietf-bess-rfc7432bis@ietf.org
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 , 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
