RE: How about one unified document?

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 protected]] 
Sent: Wednesday, July 11, 2007 2:11 PM
To: [email protected]
Cc: 'Radia Perlman'
Subject: RE: [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.

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

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