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