Subject: [VRRP] FW: [OPS-DIR] http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-spec-02.txt on the agenda of the IESG telechat

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Nov 2008 14:15:17 +0100

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Thursday, November 06, 2008 9:41 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: Re: [OPS-DIR]
http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-spec-02.txt
on the agenda of the IESG telechat

On Tue, 4 Nov 2008, Romascanu, Dan (Dan) wrote:
> Has anybody in OPS-DIR looked at
> http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-spec-02.tx
> t witch is on the agenda of the IESG telechat this week? It has two 
> sections related to Operational Issues and Operation over FDDI, Token 
> Ring and LAN Emulation. At least the latest seems strange to me - has 
> anybody seen any FDDI, Token Ring or LANE lately to care about it in a
> 2009 deployment? It would be good if somebody in OPS-DIR can have a 
> look on the document as a whole.

The origins of that part of the spec seem to be from its predecessor
documents.  Even though VRRPv2 is Draft Standard, the only
implementation report is for Proposed Standard, from 10 years ago. So,
it's not clear how many implementations there are anymore for these link
layer technologies; I'm pretty sure nobody is building new ones in any
case.  The only case to be made for keeping these in the spec is that
there is no previous spec for IPv6 for these link layers, but none of
the text there seems to be specific to IPv4 either.  So I'd be inclined
to remove this from the RFC.

Other comments:

Accept_Mode defaulting to false seems unrealistic at least in
deployments I've seen.  Using accept-data config knob seems very common.
Unless enable Accept_Mode, when the virtual address moves to the Backup,
the virtual address no longer responds to ping; I've also seen an
implementation to reject pings to the virtual IP when it's in Master
mode, but this seems like an implementation bug if so (I'd like a
confirmation if this is the case).

In any case, this restriction makes troubleshooting and deployment a
pain; hosts and management systems often ping the gateway address to see
if the network is working, and this kills that assumption.

Unless the WG has recently discussed and reached consensus that
Accept_Mode should still default to false, I'd consider revisiting this
position.

Another feature that at least one vendor implements (and we use) is
so-called Backup VRRP router passive ARP learning.  This is very useful,
because otherwise when you switch from active to backup, the backup
doesn't know ARP bindings for IP addresses and this increases the time
needed to converge.  (The same feature should apply to ND I
think.) This would seem to be something that could be worth adding or at
least discussing in the spec.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 6 Nov 2008 07:33:31 -0600

Hi Pekka, 

Thank you for your comments.  We will look into them.  Just FYI, there
was recent discussion on VRRP list about what the default setting for
accept mode should be. 

Regards, 
Steve   

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, November 06, 2008 08:15
> To: [email-masked]
> Subject: [VRRP] FW: 
> [OPS-DIR]http://www.ietf.org/internet-drafts/draft-ietf-vrrp-u
nified-spec-02.txton the agenda of the IESG telechat
> The origins of that part of the spec seem to be from its 
> predecessor documents.  Even though VRRPv2 is Draft Standard, 
> the only implementation report is for Proposed Standard, from 
> 10 years ago. So, it's not clear how many implementations 
> there are anymore for these link layer technologies; I'm 
> pretty sure nobody is building new ones in any case.  The 
> only case to be made for keeping these in the spec is that 
> there is no previous spec for IPv6 for these link layers, but 
> none of the text there seems to be specific to IPv4 either.  
> So I'd be inclined to remove this from the RFC.
> 
> Other comments:
> 
> Unless enable Accept_Mode, when the virtual address moves to 
> the Backup, the virtual address no longer responds to ping; 
> I've also seen an implementation to reject pings to the 
> virtual IP when it's in Master mode, but this seems like an 
> implementation bug if so (I'd like a confirmation if this is 
> the case).
> 
> In any case, this restriction makes troubleshooting and 
> deployment a pain; hosts and management systems often ping 
> the gateway address to see if the network is working, and 
> this kills that assumption.
> 
> Unless the WG has recently discussed and reached consensus 
> that Accept_Mode should still default to false, I'd consider 
> revisiting this position.
> 
> Another feature that at least one vendor implements (and we 
> use) is so-called Backup VRRP router passive ARP learning.  
> This is very useful, because otherwise when you switch from 
> active to backup, the backup doesn't know ARP bindings for IP 
> addresses and this increases the time needed to converge.  
> (The same feature should apply to ND I
> think.) This would seem to be something that could be worth 
> adding or at least discussing in the spec.
> 
> -- 
> Systems. Networks. Security. -- George R.R. Martin: A Clash 
> of Kings _______________________________________________
> vrrp mailing list
> [email-masked]