RE: How about one unified document?

I am very sorry, the previous e-mail got away a little too early.  I
meant to save it but sent it instead.  

The unfinished sentence is a completed thought below. 

Thanks and regards,
Steve  

> -----Original Message-----
> From: Stephen Nadas (RL/TNT) 
> Sent: Monday, August 06, 2007 11:26 AM
> To: 'Bob Hinden'; [email protected]
> Cc: Radia Perlman
> Subject: RE: [VRRP] 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

To finish my thought: Otoh, I think the implementations exist and it
seems (to me) that what is mainly needed for implementors are mature
enough drafts and I think the unified draft can reach this state very
quickly. 
    
> 
> >   - 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
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/vrrp
> > 

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