Hi Alexander, > On Jan 19, 2023, at 4:07 PM, Alexander Okonnikov > <[email protected]> wrote: > > Hi Acee, > > Is intent of the -bis in updating language, or technical > changes/clarifications are accepted as well? > > One of my concerns is in calculating checksum (section 5.2.8 of RFC 5798 and > the -bis): > > "The checksum is the 16-bit one's complement of the one's complement sum of > the entire VRRP message starting with the version field and a "pseudo-header" > as defined in Section 8.1 of [RFC2460]." > > The section doesn't specify which family it is applicable for - IPv6 only or > both. As far as it doesn't specific on families, we may conclude that > pseudo-header to be taken into account while computing checksum for IPv6 as > well as for IPv4 transport. But, if so, then in IPv4 case at least > referencing to RFC 2460 looks like inapplicable. Furthermore, if checksum to > be calculated with IPv4 pseudo-header, then that pseudo-header should be > defined or referenced. My understanding/guessing is that pseudo-header not to > be used in IPv4 case (VRRPv2 behavior preserved in VRRPv3 for IPv4), but in > order to avoid this ambiguity it would be better to specify the rules for > calculating checksum for IPv4 and for IPv6 more precisely.
I agree. We’ll update this to use RFC 8200 for IPv6 and update the applicability of the pseudo header for IPv4. > > Regarding terminology - if we now have active router, while not to introduce > standby in place of backup? 'Standby' looks like more appropriate term. I disagree strongly. “Backup” is just as accurate as “Standby” and has the benefit of being the existing term for routers backing up the Active Router. The only reason to use “Standby” would be if we were looking for affinity with the proprietary HSRP protocol and we are not. Thanks, Acee > > Thank you. > > BR > Alexander Okonnikov > >> 19 янв. 2023 г., в 22:38, Acee Lindem <[email protected]> написал(а): >> >> This version includes some more minor editorial changes as well as an update >> to my Email address. At this point, I think it is ready but could benefit >> from more eyes. >> >> Yingzhen, Jeff - can you request the appropriate directorate reviews? >> >> >> Thanks, >> Acee >> >>> On Jan 19, 2023, at 1:55 PM, [email protected] wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Routing Area Working Group WG of the IETF. >>> >>> Title : Virtual Router Redundancy Protocol (VRRP) Version 3 >>> for IPv4 and IPv6 >>> Authors : Acee Lindem >>> Aditya Dogra >>> Filename : draft-ietf-rtgwg-vrrp-rfc5798bis-01.txt >>> Pages : 42 >>> Date : 2023-01-19 >>> >>> Abstract: >>> This document defines the Virtual Router Redundancy Protocol (VRRP) >>> for IPv4 and IPv6. It is version three (3) of the protocol, and it >>> is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and >>> in "Virtual Router Redundancy Protocol for IPv6". VRRP specifies an >>> election protocol that dynamically assigns responsibility for a >>> virtual router to one of the VRRP routers on a LAN. The VRRP router >>> controlling the IPv4 or IPv6 address(es) associated with a virtual >>> router is called the VRRP Active Router, and it forwards packets sent >>> to these IPv4 or IPv6 addresses. VRRP Active Routers are configured >>> with virtual IPv4 or IPv6 addresses, and VRRP Backup Routers infer >>> the address family of the virtual addresses being advertised based on >>> the IP protocol version. Within a VRRP router, the virtual routers >>> in each of the IPv4 and IPv6 address families are independent of one >>> another. The election process provides dynamic failover in the >>> forwarding responsibility should the Active Router become >>> unavailable. For IPv4, the advantage gained from using VRRP is a >>> higher-availability default path without requiring configuration of >>> dynamic routing or router discovery protocols on every end-host. For >>> IPv6, the advantage gained from using VRRP for IPv6 is a quicker >>> switchover to Backup Routers than can be obtained with standard IPv6 >>> Neighbor Discovery mechanisms. >>> >>> The VRRP terminology has been updated conform to inclusive language >>> guidelines for IETF technologies. The IETF has designated National >>> Institute of Standards and Technology (NIST) "Guidance for NIST Staff >>> on Using Inclusive Language in Documentary Standards" for its >>> inclusive language guidelines. This document obsoletes VRRP Version >>> 3 [RFC5798]. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-vrrp-rfc5798bis/ >>> >>> There is also an HTML version available at: >>> https://www.ietf.org/archive/id/draft-ietf-rtgwg-vrrp-rfc5798bis-01.html >>> >>> A diff from the previous version is available at: >>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-rtgwg-vrrp-rfc5798bis-01 >>> >>> >>> Internet-Drafts are also available by rsync at >>> rsync.ietf.org::internet-drafts >>> >>> >>> _______________________________________________ >>> rtgwg mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/rtgwg >> >> _______________________________________________ >> rtgwg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtgwg > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
