Subject: Re: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

From: Neeraj Malhotra <[email-masked]>
Date: Sat, 2 Oct 2021 16:59:34 -0700

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 <[email-masked]>
wrote:

> Thanks again Neeraj J
>
> Please see Inline below with [SD2]
>
>
>
> Regards,
>
> Saumya.
>
>
>
> *From:* Neeraj Malhotra (nmalhotr) [mailto:[email-masked]]
> *Sent:* Friday, September 10, 2021 3:41 PM
> *To:* Dikshit, Saumya <[email-masked]>;
> [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Mon, 4 Oct 2021 05:16:03 +0000

Hi Neeraj,

Thanks for incorporating the comments.

Regards,
Saumya.

From: Neeraj Malhotra [mailto:[email-masked]]
Sent: Sunday, October 3, 2021 5:30 AM
To: Dikshit, Saumya <[email-masked]>
Cc: Neeraj Malhotra (nmalhotr) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

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 <[email-masked]<mailto:[email-masked]>> wrote:
Thanks again Neeraj ☺
Please see Inline below with [SD2]

Regards,
Saumya.

From: Neeraj Malhotra (nmalhotr) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, September 10, 2021 3:41 PM
To: Dikshit, Saumya <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Few queries on draft-ietf-bess-evpn-irb-extended-mobility

Hi Saumya,

>>>> 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.”

[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.

>>>> Section " https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-4.3.1<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.

“[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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>