Hallo Acee For Q1, sorry I’m lost now.
+ In an IPv6 VRRP environment, each router will support transmission and + reception for the Link-Local IPv6 addresses associated with both VRIDs. Which are both VRIDs? “ 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 “ I expected something like: “ In the IPv6 case, i.e., IPvX is IPv6 everywhere in the figure, each router has its own link-local IPv6 address (LLA) on the LAN interface for the VRRP protocol and an LLA per VRID that is shared with the other routers that serve the same VRID “ For the latter thing, I agree it’s not in and an optimization. But that optimization might be more important for v6 due to the higher amount of address churn. We’ll see it when a large router falls, mostly if the traffic back went through that router. Even if traffic back came through the backup (which thus has a cache entry), building that additional cache entry is churn and packet loss, that the unicast NA from the other router would have avoided. If the goal is to reduce undue broadcast (which happens for any IPv6 multicast) what we really want unicast MAC forwarding / ingress replication of the relayed NA. If we do ingress MAC replication, the mcast group we choose does not really matter since the router will only pass the NA message to its peers in the VRID. For the group, all routers works (since RFC 9131) , all VRRP routers might be better scoped, and a new group per VRID even better if there are many VRIDs. We have plenty of space in IANA for that anyway. The key is that your RFC refers to RFC 9131 to indicate that the unsolicited NA must be accepted. Keep safe; Pascal From: Acee Lindem (acee) <[email protected]> Sent: mercredi 13 avril 2022 17:01 To: Pascal Thubert (pthubert) <[email protected]>; [email protected] Cc: [email protected] Subject: Re: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis Hi Pascal, Thanks for your support and comments. See inline. From: "Pascal Thubert (pthubert)" <[email protected]<mailto:[email protected]>> Date: Wednesday, April 13, 2022 at 3:40 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, rtgwg-chairs <[email protected]<mailto:[email protected]>> Cc: Routing WG <[email protected]<mailto:[email protected]>> Subject: RE: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis Resent-From: <[email protected]<mailto:[email protected]>> Resent-To: <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, Acee Lindem <[email protected]<mailto:[email protected]>> Resent-Date: Wednesday, April 13, 2022 at 3:40 AM 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. Hopefully, this will be enough to clarify. @@ -591,8 +594,9 @@ Legend: router. </t> <t> - In an IPv6 VRRP environment, each router has the exact same - Link-Local IPv6 address. Router-1 is said to be the IPv6 address owner + In an IPv6 VRRP environment, each router will support transmission and + reception for the Link-Local IPv6 addresses associated with both VRIDs. + Router-1 is said to be the IPv6 address owner of IPv6 A, and Router-2 is the IPv6 address owner of IPv6 B. A virtual router is then defined by associating a unique identifier (the virtual router ID) with the address owned by a router. 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? This could be a nice optimization but it seems it would be new work – unless we just say the Active Router optionally sends them to the MAC address associated with 224.0.0.2/ff02::2. Thanks, Acee Keep well, Pascal From: rtgwg <[email protected]<mailto:[email protected]>> On Behalf Of Yingzhen Qu Sent: jeudi 7 avril 2022 22:27 To: [email protected]<mailto:[email protected]> Cc: rtgwg-chairs <[email protected]<mailto:[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
