RE: How about one unified document?

Hi Bob and list, 

We have implemented fast-timers-02 and we want a standardized protocol
supporting sub-second timers for IPv4 going forward.  

Earlier Don Provan had agreed to progress that draft, he looked at it,
concluded that it was easier and better to make a unified draft and
argued for this on this list.  I agree with his reasoning; I think it
will in the long run be better to have one protocol that just behaves
correctly depending upon whether it is in protecting IPv4 or IPv6
addresses.       

Please see my other comments inline.  

Thanks and regards,
Steve   

> 
> I have been thinking about this and I don't think it is a 
> good idea.   
> My reasons include:
> 
>   - The basic VRRP (for IPv4) is broadly implemented and at 
> Draft standard.  The new document will, of course, have to 
> start at Propose Standard.  To me this is a step in the wrong 
> direction.
> 

I agree that to get to the end goal, the unified approach will take
longer to push through the full stand.  Otoh, I think the
implementations are    

>   - A new unified document will be a lot more complicated and 
> will cause confusion for implementers and their customers.  
> There will be inevitable small differences between the two 
> that will cause confusion and may even lead to 
> interoperability problems.
> 
>   - There are a number of difference between the two versions 
> (IPv4 and IPv6) due to the way ARP (IPv4) and Neighbor 
> Discovery (IPv6) work.  I think this may even affect the VRRP 
> state machine.  I think it will hard to do a combined 
> specification that will make the differences clear.  Again, 
> this will likely cause confusion for people implementing the protocol.
> 

I don't see this confusion or complexity.  It seems to me that the two
protocols are very similar and, more or less, just one an extra level of
test is needed at certain points in the state machine actions to
distinguish between IPv4 and IPv6 and then drive the necessary ARP vs ND
machinery.  The only other item is accept mode which it seems could just
as well apply to IPv4.  Of course by default it is off (as it already
is) and in the context of VRRPv2 and VRRPv3 in IPv4 mode it cannot be
on; I am fine with Don's approach of making the support of vrrpv2-vrrpv3
interop as optional.     

>   - There is a risk that in creating the unified document a 
> new incompatible version of VRRP for IPv4 will be created.  
> It will be hard to resist the "let's add this feature" 
> temptation.  I don't see any significant benefit in doing this.

I agree there is some risk of "feature creep" but by adopting clear
re-charter language and adopting a Don's approach (and remaing
disiciplined about it) wrt to the unified draft, I think can be
managed/mitigated.   

> 
>   - Given the differences in the protocol, I don't think 
> creating a unified VRRP specification will result in a 
> unified MIB.  I doubt anyone who has an implementation for 
> the current will want to implement a new unified MIB.
> 
>   - The VRRP for IPv6 specification is close to being finished.   
> Creating a unified document will delay it for a long time.  
> Given the state of IPv4 address allocation, I think vendors 
> will want a finished VRRP for IPv6 specification much sooner.

We have implemented -08. 

> 
> Overall, this seems like a lot of work, little if any 
> technical benefit, and a lot of negatives.
> 
> Further, the VRRP working group not very active.  This would 
> be a big undertaking for a working group that has very light 
> traffic on the mailing list and hasn't meet at an IETF in a 
> long time.  I think the working group would be better off 
> finishing the VRRP for IPv6 specification, deciding if there 
> is enough interest to finish the sub- second timers for IPv4 
> specification, and then close the working group.
> 
> Bob
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> vrrp mailing list
> vrrp <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/vrrp
> 

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