Hi Neeraj, Please provide your inputs on the below queries.
Thanks Saumya. From: Neeraj Malhotra (nmalhotr) [mailto:nmalh...@cisco.com] Sent: Tuesday, August 17, 2021 10:15 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 your comments/questions. Will respond by end of this week. Thanks, Neeraj From: "Dikshit, Saumya" <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>> Date: Tuesday, August 17, 2021 at 12:25 AM To: "Dikshit, Saumya" <saumya.diks...@hpe.com<mailto:saumya.diks...@hpe.com>>, "draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>" <draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org>> Cc: "bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>" <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: RE: Few queries on draft-ietf-bess-evpn-irb-extended-mobility Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>> Resent-To: <apjo...@cisco.com<mailto:apjo...@cisco.com>>, <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, <jdr...@juniper.net<mailto:jdr...@juniper.net>>, <ar9...@att.com<mailto:ar9...@att.com>>, <saja...@cisco.com<mailto:saja...@cisco.com>>, <nmalh...@cisco.com<mailto: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<mailto:draft-ietf-bess-evpn-irb-extended-mobil...@ietf.org> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; bess@ietf.org<mailto: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<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.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
