Dear authors Many thanks for the great work and I certainly support the adoption.
Comments / Questions: I have been trying to understand the IPv6 way and something is a bit unclear to me about the link-local address. If I get it correctly, each router as (at least one) owned link-local address on each interface, and then there's a shared link-local address that is accepted by all the VRRP routers of a VRID on a segment. I understand that the latter is used as anycast. Hoping I'm correct, I find that " In the IPv6 case, i.e., IPvX is IPv6 everywhere in the figure, each router has a link-local IPv6 address on the LAN interface " Followed by " In an IPv6 VRRP environment, each router has the exact same Link-Local IPv6 address. " Is a bit misleading. Clarifying that the router ends up with at least one owned LLA and as many anycast LLAs as VRIDs (assuming I got it correctly) would help. About ND/ARP caches ND has a lot more dynamics than ARP and probably more addresses. If there's no sync between the active and backup, the moment of the switch will be followed by packet losses (for cache miss) and churn (to recreate the caches). Since this is all "slow path", it might have significant impact on the overall time till packets are forwarded as normal. As long as RFC 8505 is not supported (which has an abstract repo for all the mappings that could be used to update the backup), there's no need for a perfect sync anyway since it is a cache. But it would be neat that the backup has a mostly up-to-date cache before the active dies. A suggestion could be that the active forwards the valid ARP replies / unicast NAs that it receives to the other VRRP routers in the same VRID. Ideally we'd define a per VRID link scope multicast address that embeds the VRID. But then we all know that it's a broadcast anyway, so a practical suggestion would be to unicast the received NAs to all the other routers. Does that make sense? Keep well, Pascal From: rtgwg <[email protected]> On Behalf Of Yingzhen Qu Sent: jeudi 7 avril 2022 22:27 To: [email protected] Cc: rtgwg-chairs <[email protected]> Subject: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis Dear RTGWG, The authors have requested the RTGWG to adopt: draft-addogra-rtgwg-vrrp-rfc5798bis ( https://datatracker.ietf.org/doc/draft-addogra-rtgwg-vrrp-rfc5798bis/ ) The draft was presented at IETF 113 RTGWG session. Please indicate support or no-support of WG adoption of this draft by April 22nd, 2022. If you are listed as a document author or contributor please respond to this email stating of whether or not you are aware of any relevant IPR. The response needs to be sent to the RTGWG mailing list. The document will not advance to the next stage until a response has been received from each author and each individual that has contributed to the document. Thanks, Yingzhen
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
