Subject: [bess] AD Review of draft-ietf-bess-evpn-prefix-advertisement-09

From: Alvaro Retana <[email-masked]>
Date: Tue, 13 Feb 2018 10:09:18 -0800

Dear authors:

I just finished reading this document.  I am glad to finally get to process
it -- thank you for the work!

I do have a long list of comments (see below).  Many of my major ones are
related to the use of Normative Language and some other clarifications,
including places where I think the technology might still be underspecified.

Central to the technology specified in this document is the use of an
Overlay Index.  The use cases make clear the use, but there is no place
where it is discussed what it is (except for "An Overlay Index is a
next-hop that requires a recursive resolution...", which doesn't provide
significant information) or how/when to use it (except for the use cases in
Section 4).   I think the readability would be improved if there was a
section (or paragraph) that explicitly talked about the concept.
Suggestion: put it somewhere in Section 2.1, *before* the name is
introduced ("...associated to an Overlay Index that can be a VA IP address,
a floating IP address, a MAC address or an ESI.").

Thanks!

Alvaro.

Major:

M1. Support for RT-5

M1.1. Section 3 says:

   The support for this new route type is OPTIONAL.

   Since this new route type is OPTIONAL, an implementation not
   supporting it MUST ignore the route, based on the unknown route type
   value, as specified by Section 5.4 in [RFC7606].

(1) I understand what you mean by "OPTIONAL" above -- from an IETF process
point of view it means that you're not formally Updating rfc7432, so EVPN
compliant implementations (according to rfc7432) may not support this new
route.  However, from the point of view of this specification, the support
cannot be optional because otherwise then there would be no point in
writing this document; IOW, if you want to use RT-5, then you MUST support
it.

(2) You cannot specify in this document what implementations not supporting
this specification should do (much less use a MUST to describe that),
because, by definition, those implementations don't know about this
document.  The text above just repeats what rfc7606 already says...so in
reality you seem to be making a statement about backwards compatibility:
nothing bad will happen if an implementation not supporting this
specification receives the new route because of rfc7606.

Suggestion:
NEW>
   According to Section 5.4 in [RFC7606], a node that doesn't recognize the
RT-5 will ignore it.  Add something about backwards compatibility...

[This change would also allow rfc7606 to become an Informative Reference.]

M1.2. I do have a question.  If the operation of the network, for instance
in the case described in 2.2, depends on the RT-5, but a node ignores it
(because it doesn't support it yet), what is the effect?  I'm assuming that
the result will be that none of the routes associated to vIP23 will be
known, so no traffic will be sent to it (even if the ownership is known).
That seems to mean that all nodes (NVEs) MUST support RT-5 for the system
to work, right?  (This relates back to the "OPTIONAL" nature in the text
above.)  Please include this operational consideration somewhere.

M2. Section 3.1 (IP Prefix Route Encoding)

M2.1. "RD, Ethernet Tag ID and MPLS Label fields will be used as defined in
[RFC7432] and [EVPN-OVERLAY]."  Both documents use those fields in
different ways depending on the route type and the application -- you need
to be more specific.  Note also that a couple of bullets later there is a
specification for the MPLS Label field.

M2.1.1. Depending on the specifics, we may need EVPN-OVERLAY to be a
Normative reference.

M2.2. "The IP Prefix will be a 32 or 128-bit field (ipv4 or ipv6). The size
of this field does not depend on the value of the IP Prefix Length field."
 Does that mean that the IP Prefix Length field can be set (for example) to
a number > 32 while the IP Prefix and GW IP Address fields both contain
IPv4 addresses?  That doesn't make sense, but the text currently allows it!

M2.3. BTW, there's nothing in the document that talks about what should be
an error and what do to about them.  An example is the case above...another
one would be if the IP Prefix Length is set to anything > 128...etc.

M2.4. [minor] I noticed that rfc7432 uses IP Address Length/IP Address
instead of IP Prefix Length/IP Prefix...and that the setting and meaning
are slightly different.  For my own education, why the change?  Having
discrete values for the length, for example, seems cleaner and simpler than
a range...

M2.5. [minor] s/GW IP (Gateway IP Address)/GW (Gateway) IP Address field

M2.6. [minor] The figure shows the lengths in octets, but the description
talks about bits for the IP addresses.  Please be consistent.

M2.7. [minor] The figures in 3 and 3.1 don't have names.

M3. Section 3.2 says that "an Overlay Index can be an ESI, IP address in
the address space of the tenant or MAC address".  How do I know which one?
Table 1 provides an answer, but I think there are a couple of
inconsistencies and contradictions...and several open questions:

M3.1. From 3.2:

   The ESI and GW IP fields MAY both be zero, however they MUST NOT
   both be non-zero at the same time. A route containing a non-zero GW
   IP and a non-zero ESI (at the same time) will be treated as-
   withdraw.

M3.1.1. [minor] s/treated as-withdraw/treat-as-withdraw ...and please add a
reference to rfc7606 after "treat-as-withdraw".]

M3.1.2. The "MAY" above is out of place because it just represents a fact,
the Normative part is covered by the "MUST NOT". s/MAY/may

M3.1.3. The text above (and the table) reflect that if the ESI or the GW IP
are non-zero, then the other one must be 0.  However, 3.1 says that the GW
IP "SHOULD be zero if it is not used as an Overlay Index."  The problem
here is that if the GW IP is not used as an Overlay Index, then it may
still be non-zero (because the SHOULD leaves that door open), and if the
ESI is also non-zero (because it is the Overlay Index) then we should
treat-as-withdraw. IOW, I think that the "SHOULD" should be a "MUST" -- or
are there cases where the GW IP would be non-zero (if it is not the Overlay
Index)?

M3.2. Table 1 is missing the combination where ESI is Zero, GW-IP is
Non-Zero and the MAC is Non-Zero.  I would assume that the result is still
GW-IP.  If that is the case, then explicitly indicating it would be
beneficial.  Suggestion: "If either the ESI or GW-IP are non-zero, then one
of them will be the Overlay Index, regardless of whether the EC is present
or the value of the Label..."

M3.3. The Notes for Table 1 mention a couple of examples of invalid MAC
addresses, but it doesn't explain what a valid one is.  I hope that
draft-ietf-bess-evpn-inter-subnet-forwarding talks about that, but I
couldn't find anything there right away.  It would be ideal to put a
reference, and (if not in the other draft) to remember to add it...

M3.4. The only requirement for the ESI or GW-IP seems to be a non-zero
value...but that is obviously not enough.  I hope that rfc7432 contains
something along the lines of a valid ESI and maybe even something about IP
addresses in the EVPN context...  Please reference that.

M3.5. For the cases where both ESI and GW-IP are zero, the zero/zero MAC
and Label combination is missing.  Section 3.1 says that "If the received
MPLS Label value is zero, the route MUST contain an Overlay Index...", but
if the other 3 values are all zero, now what?  Should a route in those
conditions result also in treat-as-withdraw?

M3.6. If the Router's MAC Extended Community is present, but the address is
invalid, does that translate to zero or non-zero in the table?

M3.7. The second Note on the Table says that "Overlay Index may be the
RT-5's MAC address or None, depending on the local policy of the receiving
NVE/PE", but a few paragraphs before (still in 3.2) the text says that
"Overlay Index for a given IP Prefix is set by local policy at the NVE that
originates an RT-5 for that IP Prefix".  That results in a contradiction
(or at least an incomplete specification of that case): is the policy set
at the originator or the receiver?  What if they conflict?

M3.8. [minor] At the start of 3.2 it says that an "Overlay Index can be an
ESI, IP address in the address space of the tenant or MAC address"...but
towards the end of that section the text says that "The Overlay Index is
None...different Overlay Indexes supported by RT-5 (GW IP, ESI, MAC or
None)".  It seems to me that the Overlay Index is not really "None", but
that there is no Overlay Index in some cases...is that correct?  Please
clarify.

M3.9. "Any other use-case using a given Overlay Index, SHOULD follow the
procedures described in this document for the same Overlay Index."  Why is
"SHOULD" used?  Are there use cases that are not applicable to this
specification?  If so, please mention them.  If not, or if you don't know,
then why keep the "SHOULD", or even make that statement at all?

M4. From 3.2: "Irrespective of the recursive resolution, if there is no IGP
or BGP route to the BGP next-hop of an RT-5, BGP SHOULD fail to install the
RT-5 even if the Overlay Index can be resolved."  Why is that a "SHOULD"
and not a "MUST"?  Are there cases for which the RT-5 would be installed?

M5. Section 4 is introduced by saying that it "describes some use-cases".
I take that to mean that it includes examples of how the technology
specified in Section 3 is used.  That seems to be correct, except that the
use cases in the 4.4.* sections contain Normative Language.  In general,
please let the examples be examples and keep the Normative nature in the
specification part of the document.   Some specifics...

M5.1. Both 4.4.1 and 4.4.2 end with: "An EVPN IP-VRF-to-IP-VRF
implementation is REQUIRED to support the ingress and egress procedures
described in this section."  Not only does that sound obvious (otherwise
this document wouldn't exist), but I don't know what the Normative
requirement is beyond supporting RT-5 as described in this document.  The
text seems superfluous to me.

M5.2. Section 4.4.3 ends with: "This model is OPTIONAL for an EVPN
IP-VRF-to-IP-VRF implementation."  The optional nature of any of the
procedures should be reflected in Section 3.  The text also seems
superfluous to me.

M5.3. Section 4.4.1 contains the following Normative text:

 o The second one is the Router's MAC Extended Community as per
   [EVPN-INTERSUBNET] containing the MAC address associated to
   the NVE advertising the route. This MAC address identifies the
   NVE/DGW and MAY be re-used for all the IP-VRFs in the NVE. The
   Router's MAC Extended Community MUST be sent if the route is
   associated to an Ethernet NVO tunnel, for instance, VXLAN. If
   the route is associated to an IP NVO tunnel, for instance
   VXLAN GPE with IP payload, the Router's MAC Extended Community
   SHOULD NOT be sent.

Section 3.1 just says that RT-5 "MAY be sent along with a Router's MAC
Extended
Community" (and not "MUST" as it says above).  However, I see nothing
(related to the Normative Language) that this text specifies that is not
already in, or contradicts, 3.*, is that true?  If so, then you should be
able to just use lower case for the rfc2119 keywords.

M5.3.1. "GW IP= SHOULD be set to 0"  s/SHOULD be set to 0/set to 0

M5.4. Section 4.4.2 also has Normative language:

M5.4.1. In some cases (for example: "Label value SHOULD be zero..."), the
Normative language seems to just indicate a fact, not a specification.
Later again: "Label= SHOULD be set to 0."   s/SHOULD/should

M5.4.2. "The Router's MAC Extended Community SHOULD NOT be sent in this
case."  This is another example of a fact...going back to Table 1, (IIRC)
it doesn't matter if the MAC EC is present...  s/SHOULD NOT/should not

M5.4.3. "This route-target MAY be the same as the one used with the RT-5."
 This sounds like another fact to me.  s/MAY/may

M5.5. Normative Language in Section 4.4.3

M5.5.1. "SHOULD be set to 0": sounds like a statement of fact
s/SHOULD/should

M5.5.2. "This MAC address MAY be re-used for all the IP-VRFs in the NVE."
 s/MAY/may

M6. The Security Considerations Section only says that "The security
considerations discussed in [RFC7432] apply to this document."  Ok, fine,
but why?  Is it because this document doesn't add new functionality?  No.
Is it because this document uses the same procedures? Not really.  Why?

Are there considerations specific to the new RT-5?  Maybe not...but at
least say so.

What about the dependency between RT-5 and other route types (RT-2 or RT-1)
in some use cases: where if both are not present then it doesn't work..?
Could that be considered a security issue?  Can a router in the middle of
the network drop RT-5 (or RT-2/RT-1) and cause the resulting routing to
either not be possible or be different?  Is there anything that can be done
to mitigate that?  [Note: just thinking out loud.  It seems to be possible
to filter out RT-5 (or any type) routes...]

M7. The Reference to EVPN-INTERSUBNET should be Normative because the
Router's MAC Extended Community is used here.

Minor:

P1. The text uses "will be" in several places.  Being more prescriptive
(and using rfc2119 Normative language, if needed) is the right way to
clearly specify the expected behavior.   Please revise.

P2. While the bess reader will understand when the text talks about "BD-10
route-target", it will not be straight forward for the typical reader to
connect the two because a BD is defined as a "broadcast domain" and the
relationship to a RT is not clear.  Please add text to the terminology
section to make the connection.

P3. In 4.2, vIP23 is used as the floating IP.  But simply "IP23" is used in
the description -- so the Figure and the description don't match.  Note
that 2.1 uses vIP23 throughout.

P4. In 4.3, this "MAY" is out of place: "the VNI MAY directly identify the
egress interface".  Not only is it part of an example (no place for
Normative language), but it is just stating a fact.  s/MAY/may

P5. References: RFC4364 can be Informative.

Nits:

N1. Move Section 6 (Conventions used in this document) up into the
Terminology Section.  And please use the template from rfc8174.

N2. SN and DGW are used in many places, but were not introduced/defined.

N3. Please don't use "we"; e.g. s/we assume/it is assumed

N4. s/M3"/M3

N5. "...this route is used to address the current and future inter-subnet
connectivity requirements"  Future requirements?  Now do you know that? ;-)

N6. s/"EVPN Route Types/"EVPN Route Types"

N7. In 3.1: s/IP Prefix advertisement route NLRI/IP Prefix Route Type

N8. s/ipv4/IPv4

N9. s/ipv6/IPv6

N10. Ethernet Tag ID is used un some places, and Eth-Tag ID in others.

N11. In the use cases, the "M" variable is not defined.

N12. Please expand GARP.

N13. The narrative/format of the use cases in 4.1-4.3 is different than
what is in 4.4.* -- it would be nice for the format to be consistent.

N14. Figure 7 has "IP10", but the text talks about "IP1".

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 27 Feb 2018 21:41:30 +0000

Hi Alvaro,

Thank you so much for such a thorough review.
You had very good points here (see in-line for my replies).
I posted rev 10 addressing all your comments.
Thank you!
Jorge

From: Alvaro Retana <[email-masked]>
Date: Tuesday, February 13, 2018 at 7:09 PM

Dear authors:

I just finished reading this document.  I am glad to finally get to process it -- thank you for the work!

I do have a long list of comments (see below).  Many of my major ones are related to the use of Normative Language and some other clarifications, including places where I think the technology might still be underspecified.

Central to the technology specified in this document is the use of an Overlay Index.  The use cases make clear the use, but there is no place where it is discussed what it is (except for "An Overlay Index is a next-hop that requires a recursive resolution...", which doesn't provide significant information) or how/when to use it (except for the use cases in Section 4).   I think the readability would be improved if there was a section (or paragraph) that explicitly talked about the concept.  Suggestion: put it somewhere in Section 2.1, *before* the name is introduced ("...associated to an Overlay Index that can be a VA IP address, a floating IP address, a MAC address or an ESI.").

[JORGE] Done. Please check out the new paragraph in section 2.1.

Thanks!

Alvaro.

Major:

M1. Support for RT-5

M1.1. Section 3 says:

(1) I understand what you mean by "OPTIONAL" above -- from an IETF process point of view it means that you're not formally Updating rfc7432, so EVPN compliant implementations (according to rfc7432) may not support this new route.  However, from the point of view of this specification, the support cannot be optional because otherwise then there would be no point in writing this document; IOW, if you want to use RT-5, then you MUST support it.

(2) You cannot specify in this document what implementations not supporting this specification should do (much less use a MUST to describe that), because, by definition, those implementations don't know about this document.  The text above just repeats what rfc7606 already says...so in reality you seem to be making a statement about backwards compatibility: nothing bad will happen if an implementation not supporting this specification receives the new route because of rfc7606.

Suggestion:

NEW>

   According to Section 5.4 in [RFC7606], a node that doesn't recognize the RT-5 will ignore it.  Add something about backwards compatibility...

[JORGE] good point. I added:

   According to Section 5.4 in [RFC7606], a node that doesn't recognize

   the Route Type 5 (RT-5) will ignore it. Therefore an NVE following

   this document can still be attached to a BD where an NVE ignoring RT-

   5s is attached to. Regular [RFC7432] procedures would apply in that

   case for both NVEs. In case two or more NVEs are attached to

   different BDs of the same tenant, they MUST support RT-5 for the

   proper Inter-Subnet Forwarding operation of the tenant.

M1.2. I do have a question.  If the operation of the network, for instance in the case described in 2.2, depends on the RT-5, but a node ignores it (because it doesn't support it yet), what is the effect?  I'm assuming that the result will be that none of the routes associated to vIP23 will be known, so no traffic will be sent to it (even if the ownership is known).  That seems to mean that all nodes (NVEs) MUST support RT-5 for the system to work, right?  (This relates back to the "OPTIONAL" nature in the text above.)  Please include this operational consideration somewhere.

[JORGE] see above, last sentence.

M2.1. "RD, Ethernet Tag ID and MPLS Label fields will be used as defined in [RFC7432] and [EVPN-OVERLAY]."  Both documents use those fields in different ways depending on the route type and the application -- you need to be more specific.  Note also that a couple of bullets later there is a specification for the MPLS Label field.

[JORGE] added:

RD and Ethernet Tag ID will be used as defined in [RFC7432] and

     [EVPN-OVERLAY]. The MPLS Label field is set to either an MPLS label

     or a VNI, as described in [EVPN-OVERLAY] for other EVPN route

     types.

M2.1.1. Depending on the specifics, we may need EVPN-OVERLAY to be a Normative reference.

[JORGE] added as a Normative reference.

M2.2. "The IP Prefix will be a 32 or 128-bit field (ipv4 or ipv6). The size of this field does not depend on the value of the IP Prefix Length field."  Does that mean that the IP Prefix Length field can be set (for example) to a number > 32 while the IP Prefix and GW IP Address fields both contain IPv4 addresses?  That doesn't make sense, but the text currently allows it!

[JORGE] changed to:

   o The IP Prefix will be a 4 or 16-octet field (ipv4 or ipv6). The

     size of this field MUST NOT be 4 octets if the IP Prefix Length

     value is greater than 32 bits.

M2.3. BTW, there's nothing in the document that talks about what should be an error and what do to about them.  An example is the case above...another one would be if the IP Prefix Length is set to anything > 128...etc.

[JORGE] added some in section 3.1.

M2.4. [minor] I noticed that rfc7432 uses IP Address Length/IP Address instead of IP Prefix Length/IP Prefix...and that the setting and meaning are slightly different.  For my own education, why the change?  Having discrete values for the length, for example, seems cleaner and simpler than a range…

[JORGE] At the beginning there were (tons of) discussions about whether we should allow lengths different than 32 or 128 in RT-2s, in order to convey prefixes or subnets, an not only host IP addresses. The RT-5 came up as part of those discussions. We wanted to make sure people knew RT-5 could convey any prefix length rather than only 32 or 128 as in RT-2. Hence we named the route and the fields "IP Prefix". Given that it is implemented everywhere now using these names, I wouldn't change the terminology of the fields or the route itself.

[JORGE] done

M2.6. [minor] The figure shows the lengths in octets, but the description talks about bits for the IP addresses.  Please be consistent.

[JORGE] done.

[JORGE] done.

M3. Section 3.2 says that "an Overlay Index can be an ESI, IP address in the address space of the tenant or MAC address".  How do I know which one?  Table 1 provides an answer, but I think there are a couple of inconsistencies and contradictions...and several open questions:

M3.1. From 3.2:

   withdraw.

M3.1.1. [minor] s/treated as-withdraw/treat-as-withdraw ...and please add a reference to rfc7606 after "treat-as-withdraw".]

[JORGE] done.

M3.1.2. The "MAY" above is out of place because it just represents a fact, the Normative part is covered by the "MUST NOT". s/MAY/may

[JORGE] done.

M3.1.3. The text above (and the table) reflect that if the ESI or the GW IP are non-zero, then the other one must be 0.  However, 3.1 says that the GW IP "SHOULD be zero if it is not used as an Overlay Index."  The problem here is that if the GW IP is not used as an Overlay Index, then it may still be non-zero (because the SHOULD leaves that door open), and if the ESI is also non-zero (because it is the Overlay Index) then we should treat-as-withdraw. IOW, I think that the "SHOULD" should be a "MUST" -- or are there cases where the GW IP would be non-zero (if it is not the Overlay Index)?

[JORGE] good point, done.

M3.2. Table 1 is missing the combination where ESI is Zero, GW-IP is Non-Zero and the MAC is Non-Zero.  I would assume that the result is still GW-IP.  If that is the case, then explicitly indicating it would be beneficial.  Suggestion: "If either the ESI or GW-IP are non-zero, then one of them will be the Overlay Index, regardless of whether the EC is present or the value of the Label..."

[JORGE] note that the table shows "the different RT-5 field combinations allowed by this specification", however I added your suggestion, it is a good one.

M3.3. The Notes for Table 1 mention a couple of examples of invalid MAC addresses, but it doesn't explain what a valid one is.  I hope that draft-ietf-bess-evpn-inter-subnet-forwarding talks about that, but I couldn't find anything there right away.  It would be ideal to put a reference, and (if not in the other draft) to remember to add it…

[JORGE] done.

       Non-Zero indicates that the extended

       community is present and carries a valid MAC address. The

       encoding of a MAC address MUST be the 6-octet MAC address

       specified by [802.1Q] and [802.1D-REV]. Examples of invalid MAC

       addresses are broadcast or multicast MAC addresses.

M3.4. The only requirement for the ESI or GW-IP seems to be a non-zero value...but that is obviously not enough.  I hope that rfc7432 contains something along the lines of a valid ESI and maybe even something about IP addresses in the EVPN context...  Please reference that.

[JORGE] I added a reference to RFC7432 for the ESI. For the GW IP I added "and will encode a valid IP address" (as in RFC7432).

M3.5. For the cases where both ESI and GW-IP are zero, the zero/zero MAC and Label combination is missing.  Section 3.1 says that "If the received MPLS Label value is zero, the route MUST contain an Overlay Index...", but if the other 3 values are all zero, now what?  Should a route in those conditions result also in treat-as-withdraw?

[JORGE] as said above, the table shows only the relevant combinations. I added this:

"If the received Label is zero and the route does not contain an Overlay Index, it will be treat-as-withdraw [RFC7606]. "

M3.6. If the Router's MAC Extended Community is present, but the address is invalid, does that translate to zero or non-zero in the table?

[JORGE] as the text indicates: "Non-Zero indicates that the extended community is present and carries a valid MAC address." I added also: "The route will be treat-as-withdraw in case of an invalid MAC address."

M3.7. The second Note on the Table says that "Overlay Index may be the RT-5's MAC address or None, depending on the local policy of the receiving NVE/PE", but a few paragraphs before (still in 3.2) the text says that "Overlay Index for a given IP Prefix is set by local policy at the NVE that originates an RT-5 for that IP Prefix".  That results in a contradiction (or at least an incomplete specification of that case): is the policy set at the originator or the receiver?  What if they conflict?

[JORGE] I modified this paragraph:

"**  In this case, the Overlay Index may be the RT-5's MAC address or None, depending on the local policy of the receiving NVE/PE. Note that the advertising NVE/PE that sets the Overlay Index SHOULD advertise an RT-2 for the MAC Overlay Index if there are receiving NVE/PEs configured to use the MAC as the Overlay Index."

Note that the idea is to allow the models 4.4.2 and 4.4.3 interoperate. There are implementations that support it.

M3.8. [minor] At the start of 3.2 it says that an "Overlay Index can be an ESI, IP address in the address space of the tenant or MAC address"...but towards the end of that section the text says that "The Overlay Index is None...different Overlay Indexes supported by RT-5 (GW IP, ESI, MAC or None)".  It seems to me that the Overlay Index is not really "None", but that there is no Overlay Index in some cases...is that correct?  Please clarify.

[JORGE] correct. Added:

Table 1 shows the different RT-5 field combinations allowed by this specification and what Overlay Index must be used by the receiving NVE/PE in each case. Those cases where there is no Overlay Index, are indicated as "None" in Table 1. If there is no Overlay Index the receiving NVE/PE will not perform any recursive resolution, and the actual next-hop is given by the RT-5's BGP next-hop.

M3.9. "Any other use-case using a given Overlay Index, SHOULD follow the procedures described in this document for the same Overlay Index."  Why is "SHOULD" used?  Are there use cases that are not applicable to this specification?  If so, please mention them.  If not, or if you don't know, then why keep the "SHOULD", or even make that statement at all?

[JORGE] true. Removed the statement.

M4. From 3.2: "Irrespective of the recursive resolution, if there is no IGP or BGP route to the BGP next-hop of an RT-5, BGP SHOULD fail to install the RT-5 even if the Overlay Index can be resolved."  Why is that a "SHOULD" and not a "MUST"?  Are there cases for which the RT-5 would be installed?

[JORGE] changed to MUST

M5. Section 4 is introduced by saying that it "describes some use-cases".  I take that to mean that it includes examples of how the technology specified in Section 3 is used.  That seems to be correct, except that the use cases in the 4.4.* sections contain Normative Language.  In general, please let the examples be examples and keep the Normative nature in the specification part of the document.   Some specifics...

M5.1. Both 4.4.1 and 4.4.2 end with: "An EVPN IP-VRF-to-IP-VRF implementation is REQUIRED to support the ingress and egress procedures described in this section."  Not only does that sound obvious (otherwise this document wouldn't exist), but I don't know what the Normative requirement is beyond supporting RT-5 as described in this document.  The text seems superfluous to me.

[JORGE] ok

M5.2. Section 4.4.3 ends with: "This model is OPTIONAL for an EVPN IP-VRF-to-IP-VRF implementation."  The optional nature of any of the procedures should be reflected in Section 3.  The text also seems superfluous to me.

[JORGE] ok, removed and added this to section 3 - "This case in Table 1 is used in the IP-VRF-to-IP-VRF implementations described in 4.4.1 and 4.4.3. The support of a MAC Overlay Index in this model is OPTIONAL."

   SHOULD NOT be sent.

Section 3.1 just says that RT-5 "MAY be sent along with a Router's MAC Extended

Community" (and not "MUST" as it says above).  However, I see nothing (related to the Normative Language) that this text specifies that is not already in, or contradicts, 3.*, is that true?  If so, then you should be able to just use lower case for the rfc2119 keywords.

[JORGE] fixed

M5.4.1. In some cases (for example: "Label value SHOULD be zero..."), the Normative language seems to just indicate a fact, not a specification.  Later again: "Label= SHOULD be set to 0."   s/SHOULD/should

[JORGE] fixed

M5.4.2. "The Router's MAC Extended Community SHOULD NOT be sent in this case."  This is another example of a fact...going back to Table 1, (IIRC) it doesn't matter if the MAC EC is present...  s/SHOULD NOT/should not

[JORGE] fixed

M5.4.3. "This route-target MAY be the same as the one used with the RT-5."  This sounds like another fact to me.  s/MAY/may

[JORGE] fixed

M5.5.1. "SHOULD be set to 0": sounds like a statement of fact s/SHOULD/should

[JORGE] fixed

M5.5.2. "This MAC address MAY be re-used for all the IP-VRFs in the NVE."  s/MAY/may

[JORGE] fixed

M6. The Security Considerations Section only says that "The security considerations discussed in [RFC7432] apply to this document."  Ok, fine, but why?  Is it because this document doesn't add new functionality?  No.  Is it because this document uses the same procedures? Not really.  Why?

Are there considerations specific to the new RT-5?  Maybe not...but at least say so.

What about the dependency between RT-5 and other route types (RT-2 or RT-1) in some use cases: where if both are not present then it doesn't work..?  Could that be considered a security issue?  Can a router in the middle of the network drop RT-5 (or RT-2/RT-1) and cause the resulting routing to either not be possible or be different?  Is there anything that can be done to mitigate that?  [Note: just thinking out loud.  It seems to be possible to filter out RT-5 (or any type) routes...]

[JORGE] I modified the section. Let me know what you think.

M7. The Reference to EVPN-INTERSUBNET should be Normative because the Router's MAC Extended Community is used here.

[JORGE] fixed

Minor:

P1. The text uses "will be" in several places.  Being more prescriptive (and using rfc2119 Normative language, if needed) is the right way to clearly specify the expected behavior.   Please revise.

[JORGE] done.

P2. While the bess reader will understand when the text talks about "BD-10 route-target", it will not be straight forward for the typical reader to connect the two because a BD is defined as a "broadcast domain" and the relationship to a RT is not clear.  Please add text to the terminology section to make the connection.

[JORGE] done.

P3. In 4.2, vIP23 is used as the floating IP.  But simply "IP23" is used in the description -- so the Figure and the description don't match.  Note that 2.1 uses vIP23 throughout.

[JORGE] fixed

P4. In 4.3, this "MAY" is out of place: "the VNI MAY directly identify the egress interface".  Not only is it part of an example (no place for Normative language), but it is just stating a fact.  s/MAY/may

[JORGE] fixed

[JORGE] fixed

Nits:

N1. Move Section 6 (Conventions used in this document) up into the Terminology Section.  And please use the template from rfc8174.

[JORGE] fixed

[JORGE] fixed

[JORGE] fixed

N4. s/M3"/M3

[JORGE] fixed

N5. "...this route is used to address the current and future inter-subnet connectivity requirements"  Future requirements?  Now do you know that? ;-)

[JORGE] removed "current and future" :-)

[JORGE] fixed

[JORGE] fixed

N8. s/ipv4/IPv4

N9. s/ipv6/IPv6

[JORGE] fixed

[JORGE] fixed

[JORGE] done.

N12. Please expand GARP.

[JORGE] done.

N13. The narrative/format of the use cases in 4.1-4.3 is different than what is in 4.4.* -- it would be nice for the format to be consistent.

[JORGE] hmmm… the use-case is different, but still a walkthrough in the same direction, described in a similar way.

[JORGE] fixed