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

["Acee Lindem (acee)" <[e-mail]>]

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 <[e-mail]>
Date: Sunday, April 3, 2022 at 6:00 PM
To: Acee Lindem <[e-mail]>
Cc: Routing WG <[e-mail]>rg>, rtgwg-chairs <[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

From: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Date: Sunday, April 3, 2022 at 2:45 AM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>
Cc: Routing WG <[e-mail]<mailto:[e-mail]>>, rtgwg-chairs <[e-mail]<mailto:[e-mail]>>
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=[e-mail]<mailto:[e-mail]>> 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, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtgwg
--

Error! Filename not specified.<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347