Re: FW: New Version Notificationfordraft-ietf-vrrp-unified-spec-01
"Don Provan" <[email protected]> Mon, 31 Mar 2008 15:09:08 -0700
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
I think we're on the same page. I believe I wrote the passage in question, and I agree that there's no particular reason to think such configurations would be permanently unstable. Steve can decide whether to improve it. -don > -----Original Message----- > From: Radia Perlman [mailto:[email protected]] > Sent: Monday, March 31, 2008 11:12 AM > To: don provan > Cc: 'Stephen Nadas'; 'Venu Ullanatt'; [email protected] > Subject: Re: [VRRP] FW: New Version > Notificationfordraft-ietf-vrrp-unified-spec-01 > > > That was just a suggestion, softening the language, since I > had to think > for a bit > if it would be permanently unstable (which I think it won't be). > But if you want it to be scary to convince people they really > don't want > to do this, > then that's fine. > > Radia > > don provan wrote: > > Do we need to go into details? > > > > "Higher priority routers SHOULD NOT be configured with > > slower transmission rates than lower priority backup > > routers." > > > > The intent of the passage was too suggest such > > configurations might actually be dangerous, but the > > real point is that they're pointless: there's really > > no legitimate reason I can think of that a failure > > of the highest priority router should cause a > > *reduction* in the time-to-failover between lower > > priority routers. > > -don > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > On Behalf Of > > Radia Perlman > > Sent: Saturday, March 29, 2008 6:52 PM > > To: Stephen Nadas > > Cc: Venu Ullanatt; [email protected] > > Subject: Re: [VRRP] FW: New Version Notificationfor > > draft-ietf-vrrp-unified-spec-01 > > > > I read the document and I think it is excellent and ready > for last call. > > There were a couple of insignificant > > typos here and there, not worth mentioning, for instance, a > few lines before > > section 5 it says "the details of a load balancing" > > where the "a" should be removed....as I said...not worth mentioning. > > > > There was one place though (section 5.2.7) where you say > > "Note that higher priority Master routers with slower > transmission > > rates than their Backup routers are unstable. This is > because low > > priority nodes configured to faster rates could come online and > > decide they should be masters before they have heard > anything from > > the higher priority master with a slower rate." > > > > I think the wording might be unnecessarily scary. It might > be nice to add an > > extra sentence saying "Note that this situation is only > temporary. As soon > > as the lower priority node hears the VRRP message of the > Master, the lower > > priority node will cease attempting to be master, until the > actual Master > > goes down." > > > > Radia > > > > Stephen Nadas wrote: > > > >> Hi Mukesh and Radia, > >> > >> I have just posted -01 addressing the comments received on > the list > >> (and a couple of small things we found ourselves.) I think this > >> version is ready for WG last call. > >> > >> Thanks, > >> Steve > >> > >> > >> > >>> -----Original Message----- > >>> From: IETF I-D Submission Tool [mailto:[email protected]] > >>> Sent: Wednesday, March 19, 2008 3:24 PM > >>> To: Stephen Nadas > >>> Subject: New Version Notification for > draft-ietf-vrrp-unified-spec-01 > >>> > >>> > >>> A new version of I-D, draft-ietf-vrrp-unified-spec-01.txt > has been > >>> successfuly submitted by Stephen Nadas and posted to the IETF > >>> repository. > >>> > >>> Filename: draft-ietf-vrrp-unified-spec > >>> Revision: 01 > >>> Title: Virtual Router Redundancy Protocol > >>> Version 3 for IPv4 and IPv6 > >>> Creation_date: 2008-03-19 > >>> WG ID: vrrp > >>> Number_of_pages: 44 > >>> > >>> Abstract: > >>> This memo 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 on > >>> draft-ieft-vrrp-ipv6-spec-08.txt. 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 Master, and forwards packets sent to these IPv4 or > >>> IPv6 addresses. VRRP Master 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 fail over in the forwarding > >>> responsibility should the Master 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 switch over > to back up > >>> routers than can be obtained with standard IPv6 Neighbor Discover > >>> (RFC 4861) mechanisms. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat. > >>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> vrrp mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/vrrp > >> > >> > > > > _______________________________________________ > > vrrp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/vrrp > > > > _______________________________________________ > > vrrp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/vrrp > > _______________________________________________ vrrp mailing list [email protected] https://www.ietf.org/mailman/listinfo/vrrp