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

From: "Dikshit, Saumya" <[email-masked]>
Date: Sat, 14 Aug 2021 05:59:52 +0000

Changing the subject line and resending, Please ignore the previous email. Apology for mixing up things]

Hello Authors of  draft-ietf-bess-evpn-irb-extended-mobility:

I have following queries and comments about this draft “draft-ietf-bess-evpn-inter-subnet-forwarding”.
Please help clarify.

>>>>Section https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.1<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.1>

MUST be at least equal to corresponding SYNC MAC sequence number
      if one is present.
Can we formally define what a “SYNC MAC sequence number” ?

>>>>Section https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.3<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.3>

“MAC Mx with a sequence number that is higher than or equal to
   sequence number assigned to a LOCAL route for MAC Mx:
   o  PE MUST trigger probe and deletion procedure for all LOCAL IPs
      associated with MAC Mx.
   o  PE MUST trigger deletion procedure for LOCAL MAC route for Mx.

”
As per rfc7423, if equal sequence number is received, then the one published with lower vtep-ip is retained, and the other one is withdrawn.
While this section talks about probing it again.
This should be called out in the Interop section as well, for the co-existence of old rule and newly defined

Quoting from  https://datatracker.ietf.org/doc/html/rfc7432#section-15<https://datatracker.ietf.org/doc/html/rfc7432#section-15>:

“If two (or more) PEs advertise the same MAC

   address with the same sequence number but different Ethernet segment

   identifiers, a PE that receives these routes selects the route

   advertised by the PE with the lowest IP address as the best route”

>>>> Section https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.6<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.6>

“   an inter-op scenario with a different implementation could arise,

   where a PE implementation non-compliant with this document or with

   RFC 7432<https://datatracker.ietf.org/doc/html/rfc7432> assigns and advertises independent sequence numbers to MAC

   and MAC+IP routes”
How do we expect this implementation to inter-op, as it may expect two different MAC-only and MAC-IP advertisement from remote peers as well.?
Can we paraphrase this ?

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

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

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

Thanks
Saumya.

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Tue, 17 Aug 2021 07:25:11 +0000

Hello Authors of draft-ietf-bess-evpn-irb-extended-mobility,

Please help me with below queries.

Thanks
Saumya.

From: BESS [mailto:[email-masked]] On Behalf Of Dikshit, Saumya
Sent: Saturday, August 14, 2021 11:30 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

”

   and MAC+IP routes”

      the host.”

“unfreezing the

Thanks
Saumya.

---

From: "Neeraj Malhotra (nmalhotr)" <[email-masked]>
Date: Tue, 17 Aug 2021 16:45:25 +0000

Hi Saumya,

Thanks for your comments/questions. Will respond by end of this week.

Thanks,
Neeraj

From: "Dikshit, Saumya" <[email-masked]>
Date: Tuesday, August 17, 2021 at 12:25 AM
To: "Dikshit, Saumya" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Few queries on draft-ietf-bess-evpn-irb-extended-mobility
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, August 17, 2021 at 12:25 AM

Thanks
Saumya.

>>>>Section https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.1

>>>>Section https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.3

”

Quoting from  https://datatracker.ietf.org/doc/html/rfc7432#section-15:

>>>> Section https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.6

   and MAC+IP routes”

>>>> Section https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-8.8

      the host.”

>>>> Section https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-10.4.1

“unfreezing the

>>>> Section " https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-extended-mobility-05#section-4.3.1" :

Thanks
Saumya.

---

From: "Dikshit, Saumya" <[email-masked]>
Date: Fri, 27 Aug 2021 06:32:27 +0000

Hi Neeraj,

Please provide your inputs on the below queries.

Thanks
Saumya.

From: Neeraj Malhotra (nmalhotr) [mailto:[email-masked]]
Sent: Tuesday, August 17, 2021 10:15 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,
Neeraj

From: "Dikshit, Saumya" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 17, 2021 at 12:25 AM
To: "Dikshit, Saumya" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Few queries on draft-ietf-bess-evpn-irb-extended-mobility
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, August 17, 2021 at 12:25 AM

Thanks
Saumya.

From: BESS [mailto:[email-masked]] On Behalf Of Dikshit, Saumya
Sent: Saturday, August 14, 2021 11:30 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility

”

   and MAC+IP routes”

      the host.”

“unfreezing the

Thanks
Saumya.

---

From: "Neeraj Malhotra (nmalhotr)" <[email-masked]>
Date: Sun, 29 Aug 2021 22:41:49 +0000

Hi Saumya,

Apologies for the delay, and many thanks for some good comments and questions. Please see answers inline:

[NM]: sure, will define in the next revision. It refers to sequence number received with the MAC SYNCed from another PE sharing the same ESI.

”

[NM]: sure, that’s a good point. Will clarify in the next revision – essentially, the rule in RFC 7432 still needs to be applied to equal sequence number scenario, but a probe must as well be done for all associated IPs to handle transient race conditions. If indeed the host is attached to the PE with lower VTEP IP, a successful probe will force a sequence number increment and resolve the race OR lead to duplicate detection.

   and MAC+IP routes”

[NM]: correct, for a scenario where no MAC route is advertised, a non-compliant implementation may send different sequence numbers for multiple MAC-IPs with the same MAC. Handling for such a scenario should be explicitly called out as well. Will add to next revision.

      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.

“unfreezing the

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

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

Thanks,
Neeraj