Sinbad | 13 Mar 06:37 2008
Picon

virtual-ip question

hi,
should we allow to configure the virtual-ip other than the network mask that was configured on the interface that vrrp session was bound to.

forexample:

<interface 1>
     ip address 1.1.1.1/24
<vrrp session 1>
   bound-to interface 1
   virtual-ip 2.2.2.2 backup -> should this be allowed , because here session is bound to interface 1 , which is configured with 1.1.1.1/24

thanks
prashanth

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp
Stephen Nadas | 19 Mar 20:27 2008
Picon

FW: New Version Notification for draft-ietf-vrrp-unified-spec-01

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:idsubmission <at> ietf.org] 
> 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
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Radia Perlman | 30 Mar 03:51 2008
Picon

Re: FW: New Version Notification for 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:idsubmission <at> ietf.org] 
>> 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
> 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

Mukesh Gupta | 30 Mar 19:12 2008

WG Last Call for draft-ietf-vrrp-unified-spec-01.txt

Folks,

The chairs and the authors think that the draft
http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-spec-01.txt
is ready for the WG last call.

This email starts the WG last call for the draft. Please review it and
send your comments to vrrp <at> ietf.org.

The last call will end on April 14th.

Regards
Radia & Mukesh
_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

don provan | 31 Mar 02:59 2008
Picon

Re: FW: New Version Notificationfor draft-ietf-vrrp-unified-spec-01

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: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of
Radia Perlman
Sent: Saturday, March 29, 2008 6:52 PM
To: Stephen Nadas
Cc: Venu Ullanatt; vrrp <at> ietf.org
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:idsubmission <at> ietf.org]
>> 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
> 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

_______________________________________________
vrrp mailing list
vrrp <at> ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

Radia Perlman | 31 Mar 20:11 2008
Picon

Re: FW: New Version Notificationfor draft-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: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] On Behalf Of
> Radia Perlman
> Sent: Saturday, March 29, 2008 6:52 PM
> To: Stephen Nadas
> Cc: Venu Ullanatt; vrrp <at> ietf.org
> 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:idsubmission <at> ietf.org]
>>> 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
>> 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
>
> _______________________________________________
> 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

Don Provan | 1 Apr 00:09 2008
Picon

Re: FW: New Version Notificationfordraft-ietf-vrrp-unified-spec-01

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:Radia.Perlman <at> sun.com]
> Sent: Monday, March 31, 2008 11:12 AM
> To: don provan
> Cc: 'Stephen Nadas'; 'Venu Ullanatt'; vrrp <at> ietf.org
> 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: vrrp-bounces <at> ietf.org [mailto:vrrp-bounces <at> ietf.org] 
> On Behalf Of
> > Radia Perlman
> > Sent: Saturday, March 29, 2008 6:52 PM
> > To: Stephen Nadas
> > Cc: Venu Ullanatt; vrrp <at> ietf.org
> > 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:idsubmission <at> ietf.org]
> >>> 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
> >> 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
> >
> > _______________________________________________
> > 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


Gmane