|
Robert, Thank you very much for the review. Great points. Please see in-line with [Jorge]. All the changes will be included in the next revision. Thank you! Jorge
From: Robert Sparks via Datatracker <noreply@xxxxxxxx>
Reviewer: Robert Sparks [Jorge] we simplified the abstract as follows, hopefully it addresses your comment: Ethernet Virtual Private Network (EVPN) uses MAC/IP Advertisement routes to advertise locally learned MAC and IP addresses associated to host or routers. The remote Provider Edge (PE) routers may use this information to populate their Address Resolution Protocol (ARP) or Neighbor Discovery (ND) tables and then reply locally to ARP Requests or Neighbor Solicitation messages on behalf of the owner of the IP address. However, the information conveyed in the MAC/IP route may not be enough for the remote PE to reply to local ARP or ND requests. This document defines an Extended Community that is advertised along with an EVPN MAC/IP Advertisement route and carries information relevant to the ARP/ND resolution, so that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP Requests or Neighbor Solicitations with the correct information.
[Jorge] ok, section 3.2 changed as follows: 3.2. Reception of the EVPN ARP/ND Extended Community
In addition to the procedures specified in [RFC7432] a PE receiving a
MAC/IP Advertisement route will process the EVPN ARP/ND Extended
Community as follows:
o The R, O and I Flags MUST be ignored if they are advertised along
with an EVPN MAC/IP Advertisement route that does not contain an
IP (IPv4 or IPv6) address. Otherwise they are processed as
follows.
o R and O Flags processing:
* If the EVPN MAC/IP Advertisement route contains an IPv6 address
and the EVPN ARP/ND Extended Community, the PE MUST add the R
and O Flags to the ND entry in the ND or proxy-ND table and use
that information in Neighbor Advertisements when replying to a
Solicitation for the IPv6 address.
* If no EVPN ARP/ND Extended Community is received along with the
route, the PE will add the default R and O Flags to the entry.
The default R Flag SHOULD be an administrative choice. The
default O Flag SHOULD be 1.
* A PE MUST ignore the received R and O Flags for an EVPN MAC/IP
Advertisement route that contains an IPv4->MAC pair.
o I Flag processing:
* A PE receiving an EVPN MAC/IP Advertisement route containing an
IP->MAC and the I Flag set SHOULD install the IP->MAC entry in
the ARP/ND or proxy-ARP/ND table as an "Immutable binding".
This Immutable binding entry will override an existing non-
immutable binding for the same IP->MAC. The absence of the
EVPN ARP/ND Extended Community in a MAC/IP Advertisement route
indicates that the IP->MAC entry is not an "Immutable binding".
* Receiving multiple EVPN MAC/IP Advertisement routes with I=1
for the same IP but different MAC is considered a
misconfiguration.
* A PE originating an EVPN MAC/IP Advertisement route for
IP1->MAC1 with I=1 MAY also originate the route with the Static
bit set (in the MAC Mobility Extended Community). In such a
case, the IP1->MAC1 binding is not only immutable but it cannot
Rabadan, et al. Expires March 5, 2021 [Page 6]
Internet-Draft EVPN Neighbor Advertisement Flags September 2020
move as well. Even so, if an update for the same IP1->MAC1
immutable and static, is received from a different PE, one of
the two routes will be selected, as in the [RFC7432] case where
two MAC/IP routes with Static bit are received for the same MAC
from different PEs.
In a situation where a host (with an IP->MAC that is configured as
Immutable binding in the attached PE) is allowed to move between PEs
(that is, the associated MAC is non-static), PEs can receive multiple
MAC/IP advertisement routes for the same IP->MAC. In such
situations, MAC mobility procedures as in [RFC7432] dictate the
reachability of the MAC.
As an example of the use of the I Flag, consider PE1, PE2 and PE3 are
attached to the same BD. PE1 originates an EVPN MAC/IP Advertisement
route for IP1->MAC1 with I=1; later on, PE2 also originates an EVPN
MAC/IP Advertisement route IP1->MAC1 with a higher sequence number
and I=1. Then all the EVPN PEs attached to the same BD SHOULD retain
their IP1->MAC1 ARP/ND binding but update MAC1's forwarding
destination to PE2. If for some reason, PE3 originates an EVPN MAC/
IP Advertisement route for IP1->MAC2 (even with a higher sequence
number), then the EVPN PEs in the BD SHOULD NOT update their
IP1->MAC1 ARP/ND bindings, since IP1 is bound to MAC1 (MAC2 SHOULD
still be programmed in the layer-2 BDs). This is considered a
misconfiguration in PE3.
The use of the Flag I=1 assumes that a given IP is always bound to
the same MAC address, and therefore the mobility procedures described
in [I-D.ietf-bess-evpn-irb-extended-mobility] for "Host IP move to a
new MAC" will not apply.
[Jorge] ok, removed
[Jorge] ok, changed to: Bit 4 of the Flags field is defined as the "Immutable ARP/ND Binding
Flag". When set, the egress PE indicates that the IP->MAC pair sent
in an EVPN MAC/IP Advertisement route (along with the Extended
Community) is a configured ARP/ND entry. The IP address in the EVPN
MAC/IP Advertisement route can only be bound together with the MAC
address specified in the same route.
[Jorge] good point, changed as suggested.
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
