Re: VRRPv3 Implementation Report

I can understand these practice, because of we had similar practice in the past. But for the follow reason, we chose to discard it.

1. Requirement: In the practical networks, the user down of the VRRP virtual router merely look at the gate way IP address, and he didn't care whether or not the gate way has a VRRP implementation. On the contraty, the user always check the connectivity by "ping" - a common tool used icmp. There have requirement that network operator can manage the device through the VIP(VRRP virtual router's IP address) by the TELNET, Tracert, SNMP, etc.

2. Practice: ARP is a component of IP stack. If the packet has been sent to ARP, than it's not complicated to send it to IP, and so on. If the packet is only processed by ARP, the additional judgement must be implemented to judge whether the destined address is the VIP, it cause complication and heavy burden. Actually, it is simplest implementation when all the IP packet's process is the same without particular process.

3. Design of Procotol: The aim of the VRRP is to provide a redundancy router forwarding packet, not the practice. It is not concerned by forwarding whether or not the high level application packet destined to the VIP is processed. Actually, these packet is used by management. It's not convenient that these packet is discarded.

There is the same reason for IPv6. So we propose to abandon this Accept_Mode. Please review our opinnion. Thank you very much.


----- Original Message ----- 
From: "Don Provan" <[email protected]>
To: "'Mukesh Gupta'" <[email protected]>; "'Lin Tao'" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Thursday, October 16, 2008 3:23 AM
Subject: RE: [VRRP] VRRPv3 Implementation Report


> Well, I understand the point about Accept_Mode, but my sentiments
> run exactly the opposite way. While for practical reasons Accept_Mode
> being off can be harder to implement on some systems, logically the
> difference in simplicity is enormous: with Accept_Mode=Off, the *only*
> impact of VRRP on the IPv4 code is the addition of a single ARP entry.
> Accept_Mode=On forces VRRP to add and remove an IP end point, a
> significantly more heavy handed operation. (But, as it happens, the
> *only* available approach on some systems, which is what makes it
> seem simpler in practice.)
> 
> But I don't do any IPv6 work, which is where Lin is coming from,
> so perhaps this division isn't as clear cut there?
> 
> Anyway, I think what I'd suggest is to make this clearly an
> implementation decision, specifically allowing each implementation
> to chose which modes to support, whether an option is presented to
> the user at all, and, if it is, which is the default. With the spec
> having described the feature, I do not think leaving those choices up
> to the implementation introduces any additional operational problems.
> 
> I haven't worked on VRRP code for a while, but when I did, what I
> found was that in my very limited data set (3 or 4 implementation),
> in practice, the implementations have been making this choice,
> anyway, providing whichever approach they could based on the
> features of the IP stack they were using. So I don't think explicitly
> leaving the decision up to the implementer actually changes anything:
> implementers are not always able to support the feature no matter
> what the spec says.
> 
> -don
> 
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]On Behalf Of
>> Mukesh Gupta
>> Sent: Tuesday, October 14, 2008 10:43 PM
>> To: Lin Tao
>> Cc: [email protected]; [email protected]
>> Subject: Re: [VRRP] VRRPv3 Implementation Report
>> 
>> 
>> [Copying the WG]
>> 
>> Lin,
>> 
>> It's good to hear about your implementation and your comments. I will
>> let Steve, the author/editor of the unified VRRP draft, 
>> respond to your
>> technical comments.
>> 
>> It would be good to receive information about the 
>> implementation of the
>> unified draft (draft- ietf-vrrp-unified-spec-02.txt). When do 
>> you think
>> you would be implementing the new draft?
>> 
>> Steve, have you guys implemented the unified draft?
>> 
>> Regards
>> Mukesh
>> 
>> > -----Original Message-----
>> > From: Lin Tao [mailto:[email protected]]
>> > Sent: Tuesday, October 14, 2008 2:23 AM
>> > To: Mukesh Gupta; [email protected]
>> > Cc: [email protected]
>> > Subject: Re: [VRRP] VRRPv3 Implementation Report
>> > 
>> > Dear Mukesh Gupta:
>> >     I'm a developer in H3C. We have implemented
>> draft-ietf-vrrp-ipv6-spec-08 in our
>> > Comware, and have paid attention to draft-ietf-vrrp-unified-spec-02.
>> There are some
>> > improvement, we shall develope it.
>> >     There is a new concept "Accept_Mode" in 6.1. In our opinion, the
>> Default would be True.
>> > Though the address is not its own, but there is requirement that the
>> operator can manage the
>> > router by connecting to this vrrp address when a virtual router in
>> Master, i.e. this address
>> > can be thought as the virtual route's own address.
>> >     Furthermore, we could think about wiping this mode away, and it
>> will bring benifit in
>> > implementation because of Simple design.
>> >     Sincerely look forward to your reply.
>> > 
>> >    Accept_Mode             Controls whether a virtual 
>> router in Master
>> >                            state will accept packets 
>> addressed to the
>> >                            address owner's IPvX address as 
>> its own if
>> it
>> >                            is not the IPvX address owner.  
>> Default is
>> >                            False.
>> > 
>> >                            Note: IPv6 Neighbor Solicitations and
>> >                            Neighbor Advertisements should not be
>> dropped
>> >                            when Accept_Mode is False.
>> > 
>> > FYI: This is our implementation.
>> > ========================================
>> > Name of Implementation:  VRRP in Comware
>> > Platform: Comware
>> > Organization: H3C Technologies Co.
>> > Origin of Code: Internal development
>> > Information supplied by: Lin Tao [email protected]
>> > Tested Interoperability: None yet.
>> > ========================================
>> > 
>> > 
>> > 
>> > ----- Original Message -----
>> > From: Mukesh Gupta
>> > To: [email protected]
>> > Cc: Ross Callon
>> > Sent: Saturday, October 11, 2008 8:40 AM
>> > Subject: [VRRP] VRRPv3 Implementation Report
>> > 
>> > 
>> > Hi All,
>> > 
>> > The chairs are putting together an implementation report for VRRPv3
>> unified draft (draft-
>> > ietf-vrrp-unified-spec-02.txt).  If you have one or if you know of
>> any, please let us know
>> > before 10/31/08.
>> > 
>> > Here is the information that is required.
>> > 
>> > ========================================
>> > Name of Implementation:
>> > Platform:
>> > Organization:
>> > Origin of Code:
>> > Information supplied by:
>> > Tested Interoperability:
>> > ========================================
>> > 
>> > You can take a look at
>> http://www.ietf.org/IESG/Implementations/rfc-2338-
>> > implementation.txt for examples.
>> > 
>> > Regards
>> > Mukesh
>> > 
>> > 
>> > 
>> > 
>> > 
>> > _______________________________________________
>> > vrrp mailing list
>> > [email protected]
>> > https://www.ietf.org/mailman/listinfo/vrrp
>> _______________________________________________
>> vrrp mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/vrrp
>
_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp