Hi Saumya, Thanks for your comments/questions. Will respond by end of this week.
Thanks, Neeraj From: "Dikshit, Saumya" <saumya.diks...@hpe.com> Date: Tuesday, August 17, 2021 at 12:25 AM To: "Dikshit, Saumya" <saumya.diks...@hpe.com>, "draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org" <draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org> Cc: "bess-cha...@ietf.org" <bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org> Subject: RE: Few queries on draft-ietf-bess-evpn-irb-extended-mobility Resent-From: <alias-boun...@ietf.org> Resent-To: <apjo...@cisco.com>, <jorge.raba...@nokia.com>, <jdr...@juniper.net>, <ar9...@att.com>, <saja...@cisco.com>, <nmalh...@cisco.com> Resent-Date: Tuesday, August 17, 2021 at 12:25 AM Hello Authors of draft-ietf-bess-evpn-irb-extended-mobility, Please help me with below queries. Thanks Saumya. From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Dikshit, Saumya Sent: Saturday, August 14, 2021 11:30 AM To: draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org Cc: bess-cha...@ietf.org; bess@ietf.org Subject: [bess] Few queries on draft-ietf-bess-evpn-irb-extended-mobility 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 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 “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: “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 “ 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 “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 “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"; >>>> : " [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.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
