6 Aug 2007 17:25
RE: How about one unified document?
Stephen Nadas (RL/TNT <stephen.nadas <at> ericsson.com>
2007-08-06 15:25:59 GMT
2007-08-06 15:25:59 GMT
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