Re: How about one unified document?

Bob,

You raise some interesting points, but the WG seems to have
consensus on this and the ADs said "it is the
right thing to do". There are very motivated people working
on the document and we don't believe it will take a long time. Also,
this should not interfere with getting VRRP for IPv4 to standard.

And actually, the points you raise argue that we *should* make a unified
document, because we believe there will be implementations that will
want to simultaneously support IPv4, IPv6, and subsecond timers, and any
possible interactions between these would be much better thought through
while writing the document than for each implementor to try to figure it
out independently.

And we already have a unified MIB for IPv4 and IPv6.

Radia & Mukesh

Bob Hinden wrote:
> Hi,
>
> On Jul 11, 2007, at 10:54 AM, Radia Perlman wrote:
>
>> 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?
>
> 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.
>
>  - 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.
>
>  - 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.
>
>  - 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.
>
> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/vrrp