Re: New Version Notification for draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt

Excellent!

Thanks

Gyan

On Sat, Apr 9, 2022 at 1:02 PM Acee Lindem (acee) <acee@cisco.com> 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 <hayabusagsm@gmail.com>
> *Date: *Sunday, April 3, 2022 at 6:00 PM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *Routing WG <rtgwg@ietf.org>rg>, rtgwg-chairs <rtgwg-chairs@ietf.org>
> *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) <acee@cisco.com> wrote:
>
> Hi Gyan,
>
>
>
> *From: *Gyan Mishra <hayabusagsm@gmail.com>
> *Date: *Sunday, April 3, 2022 at 2:45 AM
> *To: *Acee Lindem <acee@cisco.com>
> *Cc: *Routing WG <rtgwg@ietf.org>rg>, rtgwg-chairs <rtgwg-chairs@ietf.org>
> *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=
> 40cisco.com@dmarc.ietf.org> 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, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
> 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
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
> --
>
> *Error! Filename not specified.* <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*