Re: [VRRP] Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec
Adrian Farrel <Adrian.Farrel@huawei.com> Wed, 02 December 2009 22:07 UTC
Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: vrrp@core3.amsl.com
Delivered-To: vrrp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8EF3A6903; Wed, 2 Dec 2009 14:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.293
X-Spam-Level:
X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSdrfH0mQpEp; Wed, 2 Dec 2009 14:07:22 -0800 (PST)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id DCD733A6899; Wed, 2 Dec 2009 14:07:21 -0800 (PST)
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KU100KILPG1AF@usaga01-in.huawei.com>; Wed, 02 Dec 2009 14:07:14 -0800 (PST)
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KU1001B9PFU3D@usaga01-in.huawei.com>; Wed, 02 Dec 2009 14:07:13 -0800 (PST)
Date: Wed, 02 Dec 2009 22:06:54 +0000
From: Adrian Farrel <Adrian.Farrel@huawei.com>
To: Stephen Nadas <stephen.nadas@ericsson.com>, dromasca@avaya.com
Message-id: <BF6D313D77284585B2D5501FC11B0FE8@your029b8cecfe>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <29C5D10600F84DBEB20371F86A5C39B5@your029b8cecfe>
Cc: Radia.Perlman@Sun.COM, iesg@ietf.org, vrrp@ietf.org
Subject: Re: [VRRP] Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec
X-BeenThere: vrrp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <Adrian.Farrel@huawei.com>
List-Id: Virtual Router Redundancy Protocol <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2009 22:07:23 -0000
Dan has gone all silent on us. :-) Stephen, there was one action that had not been done - moving text from the appendix to the Operational Issues section. Can I suggest you do this in a new revision (unless you want to give me some text to include as an RFC Editor note) and then we will have a perfect hand with which to beat Dan. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" <Adrian.Farrel@huawei.com> To: "Stephen Nadas" <stephen.nadas@ericsson.com>; <dromasca@avaya.com> Cc: <Radia.Perlman@Sun.COM>; <vrrp@ietf.org>; <iesg@ietf.org>; "Mukesh Gupta" <mukesh@juniper.net> Sent: Wednesday, November 25, 2009 9:54 PM Subject: Dan's Discuss and Comment on draft-ietf-vrrp-unified-spec > Hi Dan, > > Just trying to chase you as the holder of the last Discuss on > draft-ietf-vrrp-unified-spec. > > A new revision (-04) was posted on 23 October to address other Discusses > and it includes the resolutions noted below. One issue remains for your > agreement and would need a further revision. > > Here are your Discuss and Comment with responses (thanks to Stephen). > > **Discuss** > >> 1. The version management and transition plan for VRRP is unlear to me. >> The Introduction section mentions that this is 'version three (3) of the >> protocol and it is based on VRRP (version 2) for IPv4 that is defined >> in RFC 3768 and on draft-ieft-vrrp-ipv6-spec-08.txt'. However RFC 3768 >> does not make the claim to be VRRPv2, itlooks like this terminology was >> decided later and is defined here for the first time. On the other hand >> draft-ieft-vrrp-ipv6-spec-08.txt which VRRPv3 is based upon is just an >> informative reference and is actually an expired I-D? Should not this >> document update RFC 3768, and should not at least part of the migration >> and coexistence issues in Appendix A be moved to the Operational >> Issues section? > > You are right about 3768. This I-D is now marked "obsoletes 3768" > > The authors propose to move the following material from Appendix A to > create new text in the Operational Issues section. Is that good enough? > > VRRPv3 support of VRRPv2 > > VRRPv2 and VRRPv3 interoperation is OPTIONAL. Mixing VRRPv2 and > VRRPv3 should only be done when transitioning from VRRPv2 to VRRPv3. > Mixing the two versions should not be considered a permanent > solution. > > An implementation MAY implement a configuration flag that tells it to > listen for and send both VRRPv2 and VRRPv3 advertisements. > > When configured this way and the Master, it MUST send both types at > the configured rate, even if sub-second. > > When configured this way and the Backup, it should time out based on > the rate advertised by the master; in the case of a VRRPv2 master > this means it must translate the timeout value it receives (in > seconds) into centi-seconds. Also, a backup should ignore VRRPv2 > advertisements from the current master if it is also receiving VRRPv3 > packets from it. It MAY report when a v3 master is *not* sending v2 > packets: that suggests they don't agree on whether they're supporting > v2 routers. > >> 2. I do not understand what is the logic of including a section 9 >> 'Operation over FDDI, Token Ring, and ATM LANE' in this >> document. Has anybody heard about a deployment of any of these >> layer 2 networks lately, and with VRRP atop of them? > > This has been moved to an appendix (Appendix B) in the latest revision. > The rationale is that some future L2 may come someday and this thinking > may be useful. It seems not to hurt anything to keep is as an appendix. > >> 3. 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. > > The WG chairs polled the VRRP mailing list on this issue. > > The consensu conclusion was to keep Accept_Mode as a configurable > parameter that defaults to False. > > **Comment** > >> 1. Appendix B and part of Appendix C excepting the part refering >> to changes from RFC 3768 should be dropped at publication. > > This has been done in the latest revision. > >> 2. Another feature that at least one vendor implements 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. > > The WG chairs and the document author are keen to avoid feature creep in > this document and also want to get this RFC published sooner rather than > later. Since this new feature is not required for interoperability, they > propose that (if there is WG interest) it should be brought forward in a > separate I-D. > > Cheers, > Adrian > >
- [VRRP] Dan's Discuss and Comment on draft-ietf-vr… Adrian Farrel
- Re: [VRRP] Dan's Discuss and Comment on draft-iet… Adrian Farrel
- Re: [VRRP] Dan's Discuss and Comment on draft-iet… Romascanu, Dan (Dan)
- Re: [VRRP] Dan's Discuss and Comment on draft-iet… Stephen Nadas