Subject: Re: [VRRP] How about one unified document?

From: Bob Hinden <[email-masked]>
Date: Wed, 1 Aug 2007 22:40:32 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: Radia Perlman <[email-masked]>
Date: Thu, 02 Aug 2007 09:56:46 -0700

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:
>> 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
> 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.
>
> state of IPv4 address allocation, I think vendors will want a finished 
> VRRP for IPv6 specification much sooner.
>
> specification, deciding if there is enough interest to finish the 
> sub-second timers for IPv4 specification, and then close the working 
> group.
>
> Bob
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 2 Aug 2007 10:23:18 -0700

Radia,

> consensus on this and the ADs said "it is the

How was the consensus determined?  I only see responses from two  
people to your question (besides mine) on the mailing list.   Not  
exactly an overwhelming response.  Also, the group hasn't meet at an  
IETF meeting in a while.  To me it's hard see how a consensus can be  
declared with so few responses.  I suspect there are a lot more  
people on the mailing list.

It might be good for someone to take a first cut at a unified VRRP  
specification as an individual draft and then ask the question.

> on the document and we don't believe it will take a long time. Also,

I note the last VRRP for IPv6 draft was published in February.

> this should not interfere with getting VRRP for IPv4 to standard.

I assume you mean VRRP for IPv6.  How will this not interfere with  
getting VRRP for IPv6 to be a standard?  Your email said:

"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."

> while writing the document than for each implementor to try to  

Is there any data from the people who have implemented the current  
VRRP specification that they want a unified specification?

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

OK, my error.

Bob

>>> After discussion with Mukesh, we both agree that instead of a  
>>> VRRP for IPv4 and
>>> one document. Then we'd have a unified protocol document as well  
>>> as a unified MIB document.
>>>
>> I have been thinking about this and I don't think it is a good  
>> idea.  My reasons include:
>>
>> standard.  The new document will, of course, have to start at  
>> Propose Standard.  To me this is a step in the wrong direction.
>>
>> cause confusion for implementers and their customers.  There will  
>> be inevitable small differences between the two that will cause  
>> 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.
>>
>> hard to resist the "let's add this feature" temptation.  I don't  
>> see any significant benefit in doing this.
>>
>> Creating a unified document will delay it for a long time.  Given  
>> the state of IPv4 address allocation, I think vendors will want a  
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Mon, 6 Aug 2007 10:25:59 -0500

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   

>   - 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.
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Mon, 6 Aug 2007 10:38:24 -0500

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-masked]
> 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 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. 
    
> > cause confusion for implementers and their customers.
> that will 
> > cause confusion and may even lead to interoperability problems.
> > 
> > (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 
> 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.     
> 
> 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.   
> 
> >

---

From: "Stephen Nadas (RL/TNT)" <[email-masked]>
Date: Mon, 6 Aug 2007 10:44:53 -0500

Hi Bob and list,
 
> 
> It might be good for someone to take a first cut at a unified 
> VRRP specification as an individual draft and then ask the question.
> 

We are actively working on such a draft; I am hoping (but not promising)
to be able to make this available within a couple of weeks.  

[snipped]
> Is there any data from the people who have implemented the 
> current VRRP specification that they want a unified specification?
> 

Please see my previous email(s). 

[snipped]

Thanks and regards,
Steve

---

From: "Mukesh Gupta" <[email-masked]>
Date: Tue, 7 Aug 2007 21:43:16 -0700

Bob,

> people on the mailing list.

The consensus was determined based on a few positive responses, a few
private email exchanges, a few hallway discussions during the last IETF
and not even a single negative response.  It was first proposed by Don
on 4/15 and we have not heard a single person on the list saying that it
is a bad idea so far including the ADs who supported the idea as soon as
they heard about it.

Note that consensus is always determined on the mailing list so the WG
not having had a face to face meeting has nothing to do with the
consensus.

> specification as an individual draft and then ask the question.

Sure.  The current editors are planning to submit it as an individual
draft and we will circulate the idea on the list again before we accept
it as a WG draft.

> VRRP specification that they want a unified specification?

Steve already replied to the list about this.

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

We went through the same discussions while making a decision about the
unified MIB and all the same arguments apply to the unified protocol
document.

Regards
Mukesh