[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VRRP] FW: [OPS-DIR]http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-spec-02.txton the agenda of the IESG telechat
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
> -----Original Message-----
> From: vrrp-bounces at ietf.org [mailto:vrrp-bounces at ietf.org] On
> Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, November 06, 2008 08:15
> To: vrrp at ietf.org
> 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
>
>
>
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas at netcore.fi]
> Sent: Thursday, November 06, 2008 9:41 AM
> To: Romascanu, Dan (Dan)
> Cc: ops-dir at ietf.org
> Subject: Re: [OPS-DIR]
> http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-sp
ec-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
> vrrp at ietf.org
> https://www.ietf.org/mailman/listinfo/vrrp
>
_______________________________________________
vrrp mailing list
vrrp at ietf.org
https://www.ietf.org/mailman/listinfo/vrrp