Hi Saumya, Many thanks for a detailed review and discussion. I have incorporated the points from this discussion in the latest revision (07).
Thanks, Neeraj On Sat, Sep 11, 2021 at 12:37 AM Dikshit, Saumya <saumya.diks...@hpe.com> wrote: > Thanks again Neeraj J > > Please see Inline below with [SD2] > > > > Regards, > > Saumya. > > > > *From:* Neeraj Malhotra (nmalhotr) [mailto:nmalh...@cisco.com] > *Sent:* Friday, September 10, 2021 3:41 PM > *To:* Dikshit, Saumya <saumya.diks...@hpe.com>; > draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org > *Cc:* bess-cha...@ietf.org; bess@ietf.org > *Subject:* Re: Few queries on draft-ietf-bess-evpn-irb-extended-mobility > > > > > > Hi Saumya, > > > > Thanks for the nudge đ Please see inline below with [NM2], > > > > *>>>> > Section > https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.8 > <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.8>* > > *âFollowing a host move from PE1 to PE2, the host's MAC is* > > * discovered at PE2 as a local MAC via a data frames received from* > > * the host.â* > > Do we need to call out the misconfiguration case, where a probe may lead to > DUP responses, > > one from the (local learning) access side and other one across the fabric > (overlay tunnel). > > > > [NM]: Implementation donât normally handle ARP from the core side to protect > against such mis-configurations. This is an optional section that includes > suggestions for better convergence. Hence, want to refrain from being too > prescriptive about how n implementation may choose to protect from such > mis-configurations. > > [SD] Without Arp-suppression, the neighbor learnings can happen from the > fabric as well. Even without Arp-suppression, the first response can come > from the fabric (and also via the EVPN control plane). Even GARPs, can be > (selectively) allowed to flood over the fabric as well. I know few of the > campus deployments tend to do this. Hence the ask to capture this case > explicitly. > > > > [NM2]: Regardless of ARP suppression being enabled or not, with a > distributed anycast gateway, if the probe is flooded across the fabric, and > there is a DUP host, ARP response from the DUP host should be consumed > locally by the PE and not forwarded across the fabric. > > [SD2] this is where I beg to differ. In non-anycast (but same subnet > gateways) or anycast, if the ARP-request is generated by the remote host > (same EVI/L2-VNI), the arp response will be (copied + fwded-to-fabric) on > the first-hop-vtep (from the responding host). Hence the confusion. > > > > Once this happens, sequence number based EVPN duplicate detection will > apply. In other words, even if the host is DUP and ARP is flooded, one > should not expect duplicate ARP response from the fabric side (barring a > bug in the implementation). That said, for the specific convergence > scenario mentioned here, one can also choose to implement the probe to be > directed on the MAC port and not flooded. Regardless, this is an > informational section focused on convergence aspects that are local to an > implementation and donât necessarily require any standardization. > > [SD2] if this is intended as a reference/informational section, +1 on > skipping the probing details. > > > > Bringing in a discussion on duplicate scenarios here, IMO, will make it > rather confusing. > > > > *>>>> > Section > https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-10.4.1 > <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-10.4.1>* > > *âunfreezing the* > > * route at the FROZEN location will result in the route being* > > * advertised with a higher sequence number.â* > > Why are we tying probing with âunfreezingâ ? FROZEN will typically > indicate dropping of flows. Probing can still go on in parallel ? > > Can this be called out explicitly. > > > > [NM]: There is no probing requirement for unfreezing. This section is just > explaining, how the unfreezing will resolve the scenario following removal > of duplicate host from location A, regardless of whether the freezing and > unfreezing is done at location A OR B (since duplicate procedure could > cause freezing to happen at any of location A OR B). Hope, this clarifies. > > [SD] I think I did not put I across clearly. What I meant to convey is, > that the probing can happen in tandem while the MAC was designated as > DUPLICATE/FROZEN. It need not wait for an explicit higher sequence number > to trigger the same. This help would expedite the convergence. > > > > [NM2]: Periodic probing based on ARP refresh timers is completely > independent and has no overlap with this, if that is what you are referring > to? > > [SD2] +1 if both are to be called out differently. > > > > Above refers to event driven probing that is triggered by a route with a > higher sequence number. > > [SD2] +1, if this is the crux is *â**event driven probingâ* . Then we > need to call out this probing as with higher sequence number. But meanwhile > a probe based on MAC/ARP/ND (local learnings) entry expiry may kick in. > > > > Besides this, no one is continuously probing all hosts in the system. > > [SD2] +1 Itâs done on the MAC/ARP/ND (local learnings) entry expiry and I > would say event-driven. > > > > Perhaps, still missing the point? > > > > >>>> Section " > https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-4.3.1"; > : > > *" [IP7, M1] is learnt as a new route at* > > * [PE3, PE4] and advertised to remote PEs with a sequence number of 0.* > > * As a result, L3 reachability to IP7 would be established across the* > > * overlay, however, MAC mobility procedure for MAC1 will not trigger as* > > * a result of this MAC-IP route advertisement"* > > > > If a host is moved with the same MAC, the following is still being > following in current implementation(s): > > - Either "MAC-only-route" or "MAC-IP-route" advertisement, the sequence > number is bumped in both cases > > - On receiving side, > > - the sequence-number is picked up from "MAC-only-route" or > "MAC-IP-route" and applied to MAC learnings > > - the bumped up sequence number leads a withdraw of "MAC-only" or > "MAC-IP-route" from the inferior (earlier) publisher > > > > Kindly help explain, if the text mentioned in âsection 4.3.1â is creating > some doubts regarding the way things operate with current standards. > > Though I definitely believe that this literature does away with lot of > existing ambiguities. > > I think we need to paraphrase this section atleast. > > > > [NM]: If the MAC-IP following a host move is learnt with a different IP, > this draft explicitly calls out the procedure to associate sequence number > with the MAC + inheritance to ensure that sequence number is indeed > incremented even with a different IP. If an implementation is already doing > this, then we are good. Some early implementations assigned independent > sequence numbers to each MAC+IP key that had problems in IP change > scenarios. > > [SD] I just wanted to indicate that the following statement(s) is not always > true. As I mentioned above that in few of my known implementations, MAC+IP > sequence number is leveraged to derive the sequence number for the MAC as > well and hence leveraged to derive host move (in case of MAC movement). It > will be great if this can be called out specifically in this example. For > example âwould not be sufficientâ can be changed to âmay not be sufficientâ, > as we know few of implementations which do the derivation as I mentioned (for > MAC moves/dups). > > *â**[IP7, M1] is learnt as a new route at [PE3, PE4] and advertised to remote > PEs with a sequence number of 0.â* > > *âHowever, in* > > * the absence of an additional MAC only route advertisement, a single* > > * sequence number advertised with a combined MAC+IP route would not be* > > * sufficient* *to update MAC reachability across the overlay.â* > > > > [NM2]: ack. I can change the text in the next revision to âmay not be > sufficientâ. > > [SD2] +1 thanks > > > > Thanks, > > Neeraj > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
