RE: How about one unified document?

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

> -----Original Message-----
> From: Stephen Nadas (RL/TNT) [mailto:[email protected]]
> Sent: Monday, July 30, 2007 1:12 PM
> To: Don Provan; [email protected]
> Cc: Radia Perlman
> Subject: RE: [VRRP] 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

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