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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 2 Apr 2022 20:47:56 +0000

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-masked]" <[email-masked]> 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

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 2 Apr 2022 17:37:37 -0700

Acee,

Thanks for the great work!
I’ll start adoption call coming week.

Cheers,
Jeff

> On Apr 2, 2022, at 13:48, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Chairs,
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 3 Apr 2022 02:44:43 -0400

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.

Kind Regards

Gyan
On Sat, Apr 2, 2022 at 4:48 PM Acee Lindem (acee) <acee=
[email-masked]> 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
>
>
>
>     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:
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 3 Apr 2022 18:33:12 +0000

Hi Gyan,

From: Gyan Mishra <[email-masked]>
Date: Sunday, April 3, 2022 at 2:45 AM
To: Acee Lindem <[email-masked]>
Cc: Routing WG <[email-masked]>, rtgwg-chairs <[email-masked]>
Subject: Re: New Version Notification for draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt

Hi Acee

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-masked]<mailto:[email-masked]>> wrote:
Chairs,

Thanks,
Acee

On 4/2/22, 4:42 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

    Abstract:

    The IETF Secretariat

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg
--

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

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 3 Apr 2022 17:59:57 -0400

Hi Acee

Understood.

Thanks

Gyan

On Sun, Apr 3, 2022 at 2:33 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Gyan,
>
>
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Sunday, April 3, 2022 at 2:45 AM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *Routing WG <[email-masked]>, rtgwg-chairs <[email-masked]>
> *Subject: *Re: New Version Notification for
> draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt
>
>
>
>
>
> Hi Acee
>
>
>
> 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.
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 9 Apr 2022 17:02:33 +0000

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

Date: Sunday, April 3, 2022 at 6:00 PM

Hi Acee

Understood.

Thanks

Gyan

On Sun, Apr 3, 2022 at 2:33 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Sunday, April 3, 2022 at 2:45 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Routing WG <[email-masked]<mailto:[email-masked]>>, rtgwg-chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-addogra-rtgwg-vrrp-rfc5798bis-06.txt

Hi Acee

How do others feel?

Thanks,
Acee

Kind Regards

Gyan

Thanks,
Acee

    Abstract:

    The IETF Secretariat

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

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 Apr 2022 13:40:07 -0400

Excellent!

Thanks

Gyan

On Sat, Apr 9, 2022 at 1:02 PM Acee Lindem (acee) <[email-masked]> 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/
>
> *Date: *Sunday, April 3, 2022 at 6:00 PM
> *Error! Filename not specified.* <http://www.verizon.com/>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

*M 301 502-1347*