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.

My suggestion is to leave it up to the implementation. Are you
disagreeing with that? If so, what are your reasons for wanting
to *force* all implementations to support Accept_Mode=On only?

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

Traceroute allows the user to remain unaware of any router address.

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

I disagree completely. This is exactly where it is crucial to use an
IP address actually owned by the system being addressed. A network
operator must know about the VRRP arrangement. And he should always
know exactly what hardware he is talking to. Just to offer one simple
and obvious example: using the virtual router's IP address will hide
a primary router failure.

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

Well, no, there's really no relation at all between packets going
to ARP and packets going to IP, but it's not really relevant,
anyway. The point isn't where the packet can and cannot go; the
point is the difference between a minor addition to an existing
database vs. adding an entirely new end point to the system.

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

Huh? Conceptually, it's just another ARP target entry: "If someone
asks for the location of VR IP address a.b.c.d, respond with VR
MAC address u:v:w:x;y:z." It even turns out that it can be added
permanently to all the VRs since the mapping itself never changes.

It's true that I had to tweak Linux because it didn't support such
entries out-of-the-box. Earlier Unix implementations did support
them natively: they were called "published" entries.

> Actually, it is simplest implementation when all the IP packet's
> process is the same without particular process.

Maybe for you. For my system, adding an end point and, even
harder, *removing* an end-point were major headaches, hard
enough that I considered not supporting Accept=Yes at all.

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

It's easy way to slip into this kind of thinking by thinking
of VRRP as something being added to an existing router.
But actually these statements don't really fit the VRRP model
when it's considered from a protocol engineering perspective.
From VRRP's point of view, the VR IP address really *is* just
for routing packets. VRRP's use of the VR IP address is
entirely independent of any use of the address as an
end-point.

In other words, it is absolutely clear that VRRP does not
*demand* upper layer support. In fact, except for a couple
minor areas such as this one, the VRRP spec doesn't mention
upper layers. So the question to me is only whether any
specific site wants the VR IP address to share *a second*,
logically unrelated role as an access point to one or more
IP stacks. Personally, I think that's generally inadvisable,
but I'm willing to leave it up to each customer and allow
him to buy and configure his VRRP support to satisfy his
decision.

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

The bottom line is whether you want to force *me* to abandon
Accept_Mode, or you just want the freedom to abandon it yourself.
I support that latter, but oppose the former.

Thank you for bringing these issues up. The truly *virtual*
nature of the virtual router can be confusing, so I
appreciate the opportunity to discuss and clarify the
virtual router's relation to physical devices.

-don


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