Subject: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis

From: Yingzhen Qu <[email-masked]>
Date: Thu, 7 Apr 2022 13:26:57 -0700

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/ <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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 7 Apr 2022 13:33:12 -0700

I read the draft and support its adoption by the RTGWG. This is an
important work and I thank the authors for taking up the task.

Regards,
Greg

On Thu, Apr 7, 2022 at 1:27 PM Yingzhen Qu <[email-masked]> wrote:

> draft-addogra-rtgwg-vrrp-rfc5798bis  ( https://datatracker.ietf.org/doc/draft-addogra-rtgwg-vrrp-rfc5798bis/ )
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 8 Apr 2022 14:06:27 +0000

As co-author, I support WG adoption.

There is no new IPR for this draft but it should inherit all the IPR from RFC 5798.

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-vrrp-unified-spec

Acee

From: rtgwg <[email-masked]> on behalf of Yingzhen Qu <[email-masked]>
Date: Thursday, April 7, 2022 at 4:27 PM
To: Routing WG <[email-masked]>
Cc: rtgwg-chairs <[email-masked]>
Subject: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis

Dear RTGWG,

Thanks,

Yingzhen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 12 Apr 2022 18:09:20 +0000

Hi Routing WG,
We had a lot more support at the IETF 113 RTGWG session for VRRP to use inclusive language, i.e., no longer refer to the “Master” or “Master Router”. Please reiterate your support on this list.
Thanks,
Acee

Dear RTGWG,

Thanks,

Yingzhen

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Apr 2022 07:39:49 +0000

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-masked]> On Behalf Of Yingzhen Qu
Sent: jeudi 7 avril 2022 22:27
To: [email-masked]
Cc: rtgwg-chairs <[email-masked]>
Subject: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis

Dear RTGWG,

Thanks,

Yingzhen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Apr 2022 15:00:30 +0000

Hi Pascal,

Thanks for your support and comments. See inline.

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wednesday, April 13, 2022 at 3:40 AM
To: "[email-masked]" <[email-masked]>, rtgwg-chairs <[email-masked]>
Cc: Routing WG <[email-masked]>
Subject: RE: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, Acee Lindem <[email-masked]>
Resent-Date: Wednesday, April 13, 2022 at 3:40 AM

Dear authors

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.

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

Dear RTGWG,

Thanks,

Yingzhen

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Apr 2022 16:32:12 +0000

Hallo Acee

For Q1, sorry I’m lost now.

Which are both VRIDs?

“

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-masked]>
Sent: mercredi 13 avril 2022 17:01
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis

Hi Pascal,

From: "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, April 13, 2022 at 3:40 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, rtgwg-chairs <[email-masked]<mailto:[email-masked]>>
Cc: Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>
Resent-Date: Wednesday, April 13, 2022 at 3:40 AM

Dear authors

Comments / Questions:

About ND/ARP caches

Does that make sense?

Thanks,
Acee

Keep well,

Pascal

From: rtgwg <[email-masked]<mailto:[email-masked]>> On Behalf Of Yingzhen Qu
Sent: jeudi 7 avril 2022 22:27
To: [email-masked]<mailto:[email-masked]>
Cc: rtgwg-chairs <[email-masked]<mailto:[email-masked]>>
Subject: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis

Dear RTGWG,

Thanks,

Yingzhen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 13 Apr 2022 17:36:00 +0000

Hi Pascal

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wednesday, April 13, 2022 at 12:32 PM
To: Acee Lindem <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Routing WG <[email-masked]>
Subject: RE: WG Adoption Call for draft-addogra-rtgwg-vrrp-rfc5798bis

Hallo Acee

Which are both VRIDs?

“

I was trying to capture the second part of the above. Anyway, I like this text better and will use it.

“

Yes – I will add the part about unsolicited NAs. I’ll also discuss with Aditya as to what our IOS-XE implementation does.

Thanks,
Acee

Keep safe;

Pascal

Hi Pascal,

Dear authors

Comments / Questions:

About ND/ARP caches

Does that make sense?

Thanks,
Acee

Keep well,

Pascal

Dear RTGWG,

Thanks,

Yingzhen