Skip to main content

Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
draft-ietf-rtgwg-vrrp-rfc5798bis-18

Yes

Jim Guichard

No Objection

(Andrew Alston)
(Lars Eggert)
(Martin Duke)
(Paul Wouters)

Note: This ballot was opened for revision 13 and is now closed.

Jim Guichard
Yes
Éric Vyncke
No Objection
Comment (2024-01-04 for -17) Sent
I am afraid that I cannot offer a detailed review of this document, i.e., I will rely on Dave Thaler's intdir review at https://datatracker.ietf.org/doc/review-ietf-rtgwg-vrrp-rfc5798bis-15-intdir-telechat-thaler-2023-12-27/
(and I have seen that Acee and Dave have discussed the topics).

After reading Erik Kline's ballot review, I second his points.
Roman Danyliw
No Objection
Comment (2024-01-03 for -16) Not sent
Thank you to Mališa Vučinić for the SECDIR review.
Andrew Alston Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Erik Kline Former IESG member
No Objection
No Objection (2024-01-02 for -16) Sent
# Internet AD comments for draft-ietf-rtgwg-vrrp-rfc5798bis-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

* Thanks to Dave Thaler for the INT-DIR review.

## Comments

### S5.1.2.2, S8.2.4

* Super-nit-y, but RFC 5952 S4.3 indicates lowercase (ff02:...).

### S6.4.3

* "MUST respond to ND Neighbor Solicitation message"

  I think it might be helpful to reiterate here that the (R)outer Flag MUST
  be set in these messages (similar to the text in S6.4.1).

## Nits

### S1.4

* "will normally take more than 10 seconds to learn the default
   routers on a LAN"

  I found this wording to be misleading.  Hosts regularly learn default
  routers as soon as they join the network.  I think this text might actually
  mean something more like: "to learn *about a change in* the default routers
  on a LAN" and/or (possibly) "to learn *all* the default routers on a LAN".

  I see that 5798 had somewhat similarly worded text, so no strong feelings
  about changing this; just for your consideration.

### S5.1.1.3, S5.1.2.3, S7.1, S9

* Up to you, but RFC 5082 might be cite-able here, if it helps anything.

### S5.2.5

* "is ignored" -> "MUST be ignored", in order to use standards terminology?

### S6.4.3

* "the primary IPvX Address of the sender is greater than the local primary
   IPvX Address"

  I assume the comparison function implied here means "when IPvX addresses
  are treated as network-byte order unsigned integers"?

### S8.1.1

* Super nit-y, but you might consider:

  "running between a group of routers" ->
  "running among a group of routers"

### S8.3.2

* "Skew_Time is inversely proportional to the priority"

  Strictly speaking I think this isn't quite true (given the formula in
  S6.1, it's linear but with a negative coefficient?).  But it's been a long,
  long time since I've had any proper maths course, so maybe ignore me.

  "Skew_Time decreases with increasing priority", perhaps.  Or
  just leave it as is, since the figurative meaning is correct.

### S9

* If it helps, perhaps drop a reference to RFC 9099 S2.3, for some IPv6
  link-layer security considerations discussion.
John Scudder Former IESG member
No Objection
No Objection (2024-01-03 for -17) Sent
Thanks for doing this work!

I have a few small comments below, I hope they're helpful.

### Section 4.1

“The IPvX example above shows a Virtual Router configured to cover the IPv4 address owned by Router-1 (VRID=1, IPvX_Address=A)”

Shouldn’t that be “IPvX” not “IPv4”?

### Section 6.4.3

Pretty nitty, the RFCEd would presumably catch this, and I’m puzzled how it would have happened, but “@ Discard ADVERTISEMENT” isn’t at the same indent level as all the other @ items (it should be one space further in).

### Section 8.2.4

“Additional configuration MAY be required in order for Unsolicited Neighbor Advertisements to update the corresponding neighbor cache.”

Did you really intend the BCP 14-style MAY there? If so, OK, but it reads as though a lowercase “may” would do the job.
Lars Eggert Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection (for -16) Not sent

                            
Murray Kucherawy Former IESG member
No Objection
No Objection (2024-01-04 for -17) Sent
In Section 2.5, there's this:

 The Active Router SHOULD observe that this situation is occurring and log the problem.

I understand "SHOULD log", but I don't understand "SHOULD observe".  How about:

 The Active Router SHOULD log the problem if it observes that this situation is occurring.
Paul Wouters Former IESG member
No Objection
No Objection (for -17) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2024-01-02 for -15) Sent
Thanks for updating and clarifying the VRRP v3 spec to keep it current.

Regards,
Rob