Excellent! Thanks
Gyan On Sat, Apr 9, 2022 at 1:02 PM Acee Lindem (acee) <[email protected]> wrote: > Hi Gyan, > > On doing some research, I think it makes sense to remove these appendixes > and legacy technologies. I discussed IEEE 802.5 with Paul Congdon and this > standard is deemed “inactive/withdrawn” by the IEEE. For example, > https://standards.ieee.org/ieee/802.5v/1125/ > > Also, as you noted, you can’t buy new products supporting these > technologies any more. > > Thanks, > > Acee > > > > *From: *Gyan Mishra <[email protected]> > *Date: *Sunday, April 3, 2022 at 6:00 PM > *To: *Acee Lindem <[email protected]> > *Cc: *Routing WG <[email protected]>, rtgwg-chairs <[email protected]> > *Subject: *Re: New Version Notification for > draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt > > > > Hi Acee > > > > Understood. > > > > Thanks > > > > Gyan > > > > On Sun, Apr 3, 2022 at 2:33 PM Acee Lindem (acee) <[email protected]> wrote: > > Hi Gyan, > > > > *From: *Gyan Mishra <[email protected]> > *Date: *Sunday, April 3, 2022 at 2:45 AM > *To: *Acee Lindem <[email protected]> > *Cc: *Routing WG <[email protected]>, rtgwg-chairs <[email protected]> > *Subject: *Re: New Version Notification for > draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt > > > > > > Hi Acee > > > > I just read the draft and it looks very good. > > > > Just one comment on the Appendix A as those technologies are obsolete I > think we can remove. > > > > I can remove the section about emulated ATM LANs since they are out of > scope. However, for Token Ring and FDDI, there isn’t any move in the INT > area to obsolete the RFCs related these technologies. > > > > FDDI: RFC 1188 and RFC 2467 > > Token Ring: RFC 2470 > > > > How do others feel? > > > > Thanks, > > Acee > > > > > > Kind Regards > > > > Gyan > > On Sat, Apr 2, 2022 at 4:48 PM Acee Lindem (acee) <acee= > [email protected]> wrote: > > Chairs, > > This is the version for which I'd like to request WG adoption. I believe > now I have not only changed the terminology to be inclusive but made it > significantly more consistent throughout the document. I've also reworded > to avoid the usage of "black hole" for an unreachable destination. > > I've also made the document more readable by eliminating awkward sentence > construction and run-on sentences connected by semicolons. > > Thanks, > Acee > > > > On 4/2/22, 4:42 PM, "[email protected]" <[email protected]> > wrote: > > > A new version of I-D, draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt > has been successfully submitted by Acee Lindem and posted to the > IETF repository. > > Name: draft-addogra-rtgwg-vrrp-rfc5798bis > Revision: 06 > Title: Virtual Router Redundancy Protocol (VRRP) Version > 3 for IPv4 and IPv6 > Document date: 2022-04-02 > Group: Individual Submission > Pages: 40 > URL: > https://www.ietf.org/archive/id/draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt > Status: > https://datatracker.ietf.org/doc/draft-addogra-rtgwg-vrrp-rfc5798bis/ > Html: > https://www.ietf.org/archive/id/draft-addogra-rtgwg-vrrp-rfc5798bis-06.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-addogra-rtgwg-vrrp-rfc5798bis > Diff: > https://www.ietf.org/rfcdiff?url2=draft-addogra-rtgwg-vrrp-rfc5798bis-06 > > 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 carried based on > the transport protocol. Within a VRRP router, the virtual routers > in > each of the IPv4 and IPv6 address families are a domain unto > themselves and do not overlap. 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. This document obsoletes VRRP > Version 3 [RFC5798]. > > > > > The IETF Secretariat > > > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > > -- > > *Error! Filename not specified.* <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
