Hi Benjamin, A new revision has been published with yours and Warren’s suggestions (rev 08). Please see in-line with [jorge2].
Thank you! Jorge From: Benjamin Kaduk <[email protected]> Date: Monday, October 12, 2020 at 2:17 AM To: Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]> Cc: The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Bocci, Matthew (Nokia - GB) <[email protected]> Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-na-flags-06: (with COMMENT) Hi Jorge, Thanks for all the explanations and updates; there are just three points remaining that I have any comment on (inline). On Fri, Oct 09, 2020 at 10:56:35AM +0000, Rabadan, Jorge (Nokia - US/Mountain View) wrote: > Hi Bejamin, > > Thanks for reviewing! > > Please see my comments in-line with [jorge]. > > Thanks. > Jorge > > > From: Benjamin Kaduk via Datatracker <[email protected]> > Date: Wednesday, September 23, 2020 at 6:08 AM > To: The IESG <[email protected]> > Cc: [email protected] > <[email protected]>, [email protected] > <[email protected]>, [email protected] <[email protected]>, Bocci, Matthew (Nokia > - GB) <[email protected]>, Bocci, Matthew (Nokia - GB) > <[email protected]> > Subject: Benjamin Kaduk's No Objection on draft-ietf-bess-evpn-na-flags-06: > (with COMMENT) > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bess-evpn-na-flags-06: 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-evpn-na-flags/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Should we say anything about how the ARP/ND Extended Community is > ignored in the absence of a sibling MAC/IP Advertisement Extended > Community? > [jorge] sure, I added: > “Only one EVPN ARP/ND Extended Community is expected to be received along > with an EVPN MAC/IP Advertisement route. If more than one ARP/ND Extended > Community is received, the PE MUST consider only the first one on the list > for processing purposes and MUST NOT propagate the rest of the ARP/ND > Extended Communities.” > > > Should we remind the reader how the recipient knows that a given ARP/ND > Extended Community is associated to the coresponding MAC/IP > Advertisement Extended Community? > [jorge] the above text should clarify how to make that association if there > are multiple ARP/ND ext communities in the same update as the route. If there > is only one, there should not be any ambiguity. Let me know if I’m missing > something please. > > > There seems to be some latent risk in defining an "immutable" flag with > no defined way of clearing or unsetting it (e.g., having it time out). > We should either document what the operator should do when a formerly > immutable mapping needs to change or document the risk in the security > considerations section. (This is, I think, related to Rob's Discuss.) > [jorge] good point, same as Rob’s discuss. I replied to his discuss and added > this sentence: > “Note that if a configured IP1->MAC1 changes to point to a new MAC address, > i.e., IP1->MAC2, the EVPN MAC/IP Advertisement route for IP1->MAC1 will be > withdrawn before the EVPN MAC/IP Advertisement route for IP1->MAC2 is > advertised.” > Is that ok? > > > Section 1 > > procedure. However, the information conveyed in the EVPN MAC/IP > Advertisement route may not be enough for the remote PE to reply to > local ARP or ND requests. For example, if a PE learns an IPv6->MAC > > This makes it sound like we're rectifying a deficiency of the core spec, > and therefore might want to have an Updates: (or rather, "see also") > relationship to it. > [jorge] the current plan as discussed with our AD (Martin) is to make this > draft normative for draft-ietf-bess-evpn-proxy-arp-nd, and mark the latter as > “updates RFC7432”. > > > Advertisement routes. Similarly, other information relevant to the > host advertised in the MAC/IP Advertisement route may be needed. > > (editorial) either we know what this "other information" is and could > list it explicitly (or by section reference), or we don't, and the > solution is incomplete. > [jorge] good point, thanks. The idea behind is that the other non-assigned > flags can be used in the future to indicate information relevant to the host > identified by the IP->MAC pair. Since that is not really needed, I removed > that sentence. > > > Section 1.1 > > Proxy-ARP/ND: function on the EVPN PEs by which received Address > Resolution Protocol (ARP) Requests or Neighbor Solicitation (NS) > messages are replied locally by the PE, without the need to flood the > > nit: "replied to" > [jorge] fixed, thanks. > > > Section 2 > > Should we explicitly say that this is a transitive extended community? > [jorge] ok, added: > “This document defines a transitive EVPN Extended Community …” > > > O - Override Flag (corresponds to Bit 22 of the Extended Community) > Bit 6 of the Flags field is defined as the "Override Flag". An > egress PE will normally advertise IPv6->MAC pairs with the O Flag > set, and only when IPv6 "anycast" is enabled in the BD or interface, > the PE will send an IPv6->MAC pair with the O Flag = 0. The ingress > PE will install the ND entry with the received O Flag and will use > this information when replying to a Neighbor Solicitation for the > IPv6 address. [...] > > > I'm not 100% sure I understand what this is saying. > My current understanding is that: at present (in the absence of this > extended community), a PE has to use heuristics to set the O flag in NA > messages, with the heuristic being "normally set the O flag, but when > the BD/interface has anycast enabled, clear the O flag". The new > behavior when the information in this extended community is available, > is then to "always send the value received from the extended community". > [jorge] yes, I added this to clarify: > “..and will always use this O Flag value when replying to a Neighbor > Solicitation for the IPv6 address…” > > > However, if my understanding (above) is correct, that doesn't seem quite > right, since it's generally not safe to set the O flag in such an > "anycast" scenario. Am I missing something? > [jorge] sorry, not sure if I understand... suppose you have two hosts > connected to the same broadcast domain, h1 and h2. If h2 sends a NS message, > h1 can reply with O=1 or O=0. If that BD is now EVPN enabled, the NS and NA > messages are translated into MAC/IP routes with the flags in the ext > community. To me both cases are equally safe or unsafe? Let me know if I’m > missing something please. It is probably me who is missing something. I was not sure what was different between the case of "anycast with no EVPN" and "anycast with EVPN". I guess, in the former case the PE is responsible for figuring out what value to put in the O flag, and thus is responsible if anything goes wrong, but in the latter case the PE is just deferring to the other node, so if a "bad" value is put in the O flag this is due to an error at a different layer -- the PE (and, thus, the new behavior in this document) does not need to take particular care for whether anycast is enabled. [jorge2] Yes, that’s what I think. > > 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. > > nit: I'm not sure I understand what "can only be bound together with" > means here. (What would the other option be?) > [jorge] I added this to clarify: > “In this case, the IP address in the EVPN MAC/IP Advertisement route can only > be bound together with the MAC address specified in the same route, and not > with any other MAC addresses received in a different route without the I Flag > set.” > > > Section 3.1 > > Just to check my understanding: the dynamic learning here only applies > to NA messages received from the CE directly, not those received from > other EVPN routers? (Do we need to say that explicitly?) > [jorge] correct, however not sure we need to say it explicitly. Other specs > such as draft-ietf-bess-evpn-proxy-arp-nd specify all that. > > > o This Extended Community does not change the procedures described > in [RFC7432]. Specifically the procedures for advertising the MAC > Mobility Extended Community along with the MAC/IP Advertisement > route are not changed. > > (side note) I'm not entirely sure how one might expect the MAC Mobility > processing to have changed as a result of the addition of the ARP/ND > Extended Community, but there doesn't seem to be any real harm in > mentioning it like this. > [jorge] it’s just an extra clarification just in case the reader is > wondering. I think it’s worth mentioning. > > > Section 3.2 > > * 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. > > editorial: "add the R and O Flags" could sound like they are always set > to 1; perhaps "propagate the value of the R and O flags from the ARP/ND > Extended Community to the ND entry"? > [jorge] good point, I changed it to: > “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 Flag values to the ND > entry in the ND or proxy-ND table, and propagate the value of the R and O > flags from the ARP/ND Extended Community to the Neighbor Advertisements when > replying to a Solicitation for the IPv6 address.” > > > 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. > > I couldn't find much discussion of this scenario in RFC 7432 by > searching for "static" or "sticky"; could you help point me in the right > direction? > [jorge] the static flag is defined in RFC7432, section 15.2. It does not > explain explicitly how the selection works for two MAC/IP routes with the > same MAC (different RD) from two different PEs, it’s up to the > implementation. The point here is that implementations should do the same for > the I flag. Okay, I think maybe I understand what is happening here (and, to be honest, the 7432 reference makes more sense to me now, on the second reading). For both sticky MAC addresses and for ARP/ND routes with the I flag, if an implementation gets two different ones, it has to pick one to use. In 7432 that is left implicit, but here we say it explicitly (which is good). When in such a position of needing to pick one, the PE has to alert the operator that something weird is going on -- this is what the 7432 reference is saying. But in some sense these are two independent actions, they just occur in the same situation. So perhaps it is more clear to say "... one of the two routes will be selected. This case is analogous to the [RFC7432] case when two MAC/IP routes with the Static bit set are received, and the PE likewise MUST alert the operator of such a situation."? [jorge2] yes, good point thanks. I took your suggestion. > > 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. > > I don't really understand the motivation for SHOULD NOT, here. It seems > like a PE would need to violate some other part of the spec in order to > do so, so just "will not" would be workable. > (I'm also left to assume that the route from PE3 sets I=0, which might > be worth making explicit.) > [jorge] good one, changed it to: > “If for some reason, PE3 originates an EVPN MAC/IP Advertisement route for > IP1->MAC2 with I=0 (even with a higher sequence number), then the EVPN PEs in > the BD will 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. > > Do we want to say anything about how things should behave if the > assumption is violated? > [jorge] probably not, the use of the I flag in the spec means an IP cannot > move to a new MAC. Maybe we will need to make it also explicit in > I-D.ietf-bess-evpn-irb-extended-mobility. > > > Section 4 > > It seems like this mechanism (or rather, RFC 7432's MAC/IP > Advertisement) doesn't really affect the spoofability of ND; the same > information (actually the same, now that this mechanism exists to send > the R/O flags) is being conveyed just over a different protocol, and > DAD/mobility should still work the same way. There's an extra > translation step at the PEs the introduces an opportunity for > translation errors but that's not very noteworthy. > > The I flag is somewhat different, as I mentioned at the top of my > comments. > > Similarly, the receiver of a NA message with the wrong R flag, may > update its Default Router List incorrectly adding or removing an > entry. > > I suggest adding at the end of the sentence ", which could for example > lead to sending traffic to a node that is not a router, causing the > traffic to be dropped". > [jorge] added, thank you > > > Section 5 > > Given the email discussion regarding the use of flag position 5, should > a note be left in the registry about that informal usage? > [jorge] yes, but this document should not say anything, right? Let me know. This document is creating the registry, so it is a natural time to place a comment in the registry. It is not the only way that such a note could be added, but since the registration procedure is Standards Action it may be prudent to make such a directive to IANA while we have a proposed standard document (this one) already in the works. [jorge2] OK, sounds good to me. I added the following note in the IANA section, let me know if this is good enough: Note that the Flag position 5 is left unassigned and not used in this specification since it was previously requested by [I-D.rbickhart-evpn-ip-mac-proxy-adv]. Thanks again, Ben
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
