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
