Subject: [VRRP] How about one unified document?

From: Radia Perlman <[email-masked]>
Date: Wed, 11 Jul 2007 10:54:44 -0700

After discussion with Mukesh, we both agree that instead of a VRRP for 
IPv4 and
one for IPv6 and one for subsecond timers, it would be nice to obsolete 
all of those
with a single document that covers all.

Rather than finalizing the IPv6 document, it would be nice to use it as 
a base for
the unified document, adding in the subsecond timers as well as IPv4 
support into
one document. Then we'd have a unified protocol document as well as a 
unified MIB document.

What do people think? And if people think this is a good idea, would 
anyone like to
volunteer to be the editor of this document?

Radia & Mukesh

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: "Don Provan" <[email-masked]>
Date: Wed, 11 Jul 2007 11:11:07 -0700

> After discussion with Mukesh, we both agree that instead of a 
> VRRP for IPv4 and one for IPv6 and one for subsecond timers,
> it would be nice to obsolete all of those with a single document
> that covers all.

I've reached the same conclusion, but I'm worried about the fact
that I have no recollection for the arguments that led to the
IPv6 specific document to begin with.

> Rather than finalizing the IPv6 document, it would be nice to 
> use it as a base for the unified document, adding in the
> subsecond timers as well as IPv4 support into one document.
> Then we'd have a unified protocol document as well as a 
> unified MIB document.

The reason I think a unified document is a good idea at this
time is that the IPv6 document already has subsecond timers
well hashed out. So it should be a matter of explaining how
IPv4 addresses should be carried and, I would say, a section
on how to handle a world with both VRRPv2 vs. VRRPv3 on IPv4
networks.

I know little about the procedural issues here, but
"theoretically" the IPv4 changes shouldn't change the IPv6
VRRPv3 protocol, so it might be OK to allow the existing document
to continue on track, if anyone wants to push for that.

-don

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Mon, 16 Jul 2007 09:02:15 -0500

I am okay with this forward.  I'm also willing to edit the doc. 
Steve 

-----Original Message-----
From: Radia Perlman [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2007 1:55 PM
To: [email-masked]
Subject: [VRRP] How about one unified document?

After discussion with Mukesh, we both agree that instead of a VRRP for
IPv4 and
one for IPv6 and one for subsecond timers, it would be nice to obsolete
all of those with a single document that covers all.

Rather than finalizing the IPv6 document, it would be nice to use it as
a base for the unified document, adding in the subsecond timers as well
as IPv4 support into one document. Then we'd have a unified protocol
document as well as a unified MIB document.

What do people think? And if people think this is a good idea, would
anyone like to volunteer to be the editor of this document?

Radia & Mukesh

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Mon, 30 Jul 2007 15:11:38 -0500

Hi Don, 

What do you (and the list) think of this approach for a world with
both VRRPv2 vs. VRRPv3 on IPv4 networks.  It seems like either
ships-in-the-night (SITN) or interoperate are the possibilities. SITN
is simpler, of course.  SITN by protocol design means VRRPv3 drops
VRRPv2 version packets and never sends them.  VRRPv2 virtual
routers interoperate only with other VRRPv2 virtual routers.  Migrate
to VRRPv3 if and when sub-second IPv4 support and/or IPv6 support is 
needed.  

However, it seems that interop is not too hard, and would default to
SITN.  

Interop description

1) Imagine that the unified draft specifies VRRP packets version 3 (as
it does today in vrrp-ipv6-spec-08) for protecting IPv6 address(s) and
it also specifies VRRP packets version 4 to (sub-second) protect IPv4
address(s); version 4 looks just like section 5.1 (of
vrrp-ipv6-spec-08) except everywhere IPv6 is replaced by IPv4.  This
is what is used for subsecond IPv4 protection.

2) VRRPv3 Receives a VRRPv2 ADVERTISEMENT.

2a) If a new configuration variable INTEROP-SLOW (to be described in
the unified draft) is false, Drop it.  This would be SITN by
configuration (and default). 

It should be possible to apply this configuration variable
individually to IPv4 addresses.

2b) If the configuration variable INTEROP-SLOW is true, it enables
interoperation with VRRPv2.  Translate the received ADVERTISEMENT to
the corresponding version 4 and process accordingly.  The translation
is simple, mainly convert VRRPv2 Advert Int into centi-seconds and
process result.

3) VRRPv3 sends a VRRPv2 ADVERTISEMENT. 

3a) if INTEROP-SLOW is true, if and when this vitual router sends an
advertisement for the given protected IPv4 address, it translates it
to a type 2 (rfc3768) advertisement before sending it.

4) misc.  

4a) if INTEROP-SLOW is true, advertisement intervals MUST be given in
multiples of hundreds of centisecs.  (Alternately, rules for rounding
can be specified and MUST be implemented)

4b) if there is at least one VRRPv3 with INTEROP-SLOW true, then all
other VRRPv3 routers MUST have INTEROP-SLOW true for this address as
well.

4c) if INTEROP-SLOW configuration is everywhere false, this implements
ships-in-the-night between VRRPv2 and VRRPv3.

Regards,
Steve 
 
-----Original Message-----
From: Don Provan [mailto:[email-masked]] 
Sent: Wednesday, July 11, 2007 2:11 PM
To: [email-masked]
Cc: 'Radia Perlman'
Subject: RE: [VRRP] How about one unified document?

> IPv4 and one for IPv6 and one for subsecond timers, it would be nice 
> to obsolete all of those with a single document that covers all.

I've reached the same conclusion, but I'm worried about the fact that I
have no recollection for the arguments that led to the
IPv6 specific document to begin with.

> Rather than finalizing the IPv6 document, it would be nice to use it 
> as a base for the unified document, adding in the subsecond timers as 
> well as IPv4 support into one document.
> Then we'd have a unified protocol document as well as a unified MIB 
> document.

The reason I think a unified document is a good idea at this time is
that the IPv6 document already has subsecond timers well hashed out. So
it should be a matter of explaining how
IPv4 addresses should be carried and, I would say, a section on how to
handle a world with both VRRPv2 vs. VRRPv3 on IPv4 networks.

I know little about the procedural issues here, but "theoretically" the
IPv4 changes shouldn't change the IPv6
VRRPv3 protocol, so it might be OK to allow the existing document to
continue on track, if anyone wants to push for that.

-don

---

From: "Don Provan" <[email-masked]>
Date: Mon, 30 Jul 2007 14:35:33 -0700

Hi, Steve,

First of all, I think the protocols themselves should be entirely
and completely ships in the night. BUT, I agree it would not be
that hard for a v3 protocol *implementation* to support v2, and
we should have a section describing those issues.

Combined v2/v3 support should, first of all, be presented as
being only for backwards compatibility during upgrading; using
it in a permanent situation should be discouraged.

Consequently, I think the spec's advice should be simplistic: an
implementation MAY implement a configuration flag that tells it
to listen for and send both v2 and v3 advertisements. When
configured this way and the master, it MUST send both types at
the configured rate, even if sub-second. When not master, it
should time out based on the rate advertised by the master --
I believe the v3 spec already calls for this, except we want it
to (when so configured) adjust its timeout rate for v2 masters
as well as or v3.

At the same time, I'm not too comfortable with a slow master, so
we should recommend against configuring a VR with one router using
a slower transmit rate then the others but a higher priority. The
v2 router interacting with a sub-second v3 router is the most
important example of that, of course. In fact, I'd have no problem
prohibiting this kind of configuration if everyone's willing.

And a system configured to listen to both v2 and v3 should
ignore v2 packets from the current master if it's also
getting v3 packets from it. Except 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.

One more thing: you mentioned VRRPv4 packets. Is that necessary?
I'd assumed both IPv4 and IPv6 would carry VRRPv3 packets and
assume they're talking about the networking version that the
packets were sent over.

-don

> From: Stephen Nadas (RL/TNT) [mailto:[email-masked]]
> Sent: Monday, July 30, 2007 1:12 PM
> To: Don Provan; [email-masked]
> Cc: Radia Perlman

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Tue, 31 Jul 2007 12:21:50 -0500

Hi Don,

Thanks for responding to my strawman.  I agree with most of 
your suggestions, and have some comments & questions.  Please 
see inline, below. 

Regards,
Steve 

> Sent: Monday, July 30, 2007 5:36 PM
> To: Stephen Nadas (RL/TNT); [email-masked]
> Cc: 'Radia Perlman'
> First of all, I think the protocols themselves should be 
> entirely and completely ships in the night. BUT, I agree it 
> would not be that hard for a v3 protocol *implementation* to 
> support v2, and we should have a section describing those issues.
> 
> being only for backwards compatibility during upgrading; 
> using it in a permanent situation should be discouraged.
> 

I agree.

> Consequently, I think the spec's advice should be simplistic: 
> an implementation MAY implement a configuration flag that 
> tells it to listen for and send both v2 and v3 
> advertisements. When configured this way and the master, it 
> MUST send both types at the configured rate, even if 
> sub-second. 

I am a little concerned that a v3 sending at 1 centi-sec could  
overwhelm a v2 with potentially unclear results.  But given the 
previous paragraphs cautions about running this way during upgrade, 
this should be a temporary condition so I am okay.  To me, it 
seems prudent, in the upgrade cases, to initially run the v3 rtrs 
with lower frequencies (eg 100 centi-sec) until the v2 rtrs are 
upgraded.  Then, once one has convinced oneself that all is working, 
unconfigure v2 support and then increase the vrrp v3 frequency as 
desired.  Perhaps some description along these lines should go into 
the draft.         
   
> When not master, it should time out based on the 
> rate advertised by the master -- I believe the v3 spec 
> already calls for this, except we want it to (when so 
> configured) adjust its timeout rate for v2 masters as well as or v3.
> 
> At the same time, I'm not too comfortable with a slow master, 
> so we should recommend against configuring a VR with one 
> router using a slower transmit rate then the others but a 
> higher priority. 

I agree that don't understand the rationale for the normal 
master (highest priority) to run at, say, 20 centisec, but when it 
fails the backup that takes over runs at 10 centisec.  Is this what 
you mean by "not too comfortable"?   

> The
> important example of that, of course. In fact, I'd have no 
> problem prohibiting this kind of configuration if everyone's willing.

I think that I am missing something here.  How would we prohibit 
"this kind of configuration"?  Is this back to your 1st paragraph?

> agree on whether they're supporting v2 routers.

I agree. 

> assume they're talking about the networking version that the 

Yes, you are right of course. 

> > is simpler, of course.  SITN by protocol design means VRRPv3 drops
[snipped]

---

From: "Don Provan" <[email-masked]>
Date: Tue, 31 Jul 2007 12:19:11 -0700

> desired.  Perhaps some description along these lines should go into 

Good point. As I see it there are three reasonable possibilities:

1. v2 and v3 sent at the same rate, so the admin better be sure
the v2's aren't overwhelmed. One way to help avoid the v2's being
overwhelmed is to suggest the upgrade procedure you described:
keeping the v3 nodes at or close to second rates until the v2's
are gone.

2. v3 sent at rate, v2 sent at the configured rate rounded up to
seconds. This doesn't completely avoid the problem of overwhelming
v2 nodes, but it reduces the overhead to spotting the version in
order to reject the packet. I didn't mention this approach before
because #1 is simpler to implement, and I definitely see no reason
to recommend multiple possibilities.

3. Simply say that v2 cannot share a VR with v3.

I think these are all perfectly valid, so I'm OK with any of these
so long as we pick just *one* and stick with it. Currently, I still
think #1 is best, with the warning about v2 overhead and your
suggestion of lower rates during the transition. As long as
this is just a suggested practices section, we don't have to be
too rigid about the details, particularly as long as we're clear
that the v2/v3 node should do nothing that would break the v2
protocol. (hmmmm.... now that I said that, perhaps #2 is the
right choices....)

> you mean by "not too comfortable"?   

Yes, that's what I meant. My mental experiments tells me that
higher priority nodes with slower transmission rates are
unstable because low priority nodes configured to faster rates
could come on line and decide they should be masters before they
heard anything from the higher priority master with a slower rate.
I think the spec still claims differing rates are a mistake even
though the protocol can now deal with them, so I probably
shouldn't have brought this up, but I couldn't help myself because
I'm a big fan of differing rates, so long as the rates are in
priority order. It really has nothing to do with IPv4 in v3....

> "this kind of configuration"?  Is this back to your 1st paragraph?

By "prohibit", I just meant put something into the v2 section
along the lines of "A v2-only implementation should *never* be
given a higher priority than a v2/v3 implementation it is
interacting with if the v2/v3 rate is subsecond."

-don