Re: VRRPv3 Implementation Report

Don, 

Yes, I agress with that leave it up to the implementation, because your implementation 
is easy to support Accept_Mode=On, and our implementation is easy to support 
Accept_Mode=Off, and this mode is not the focus characteristic of VRRP. So I 
suggest that this Accept_Mode is Optional in the draft. 

FYI: The requirement of VRRP IP's operation is really offered by our customer. There
are layers management of network.

Thank for your reply! Best regards!

Lin.


----- Original Message ----- 
From: "don provan" <[email protected]>
To: "'Lin Tao'" <[email protected]>; "'Mukesh Gupta'" <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Friday, October 17, 2008 1:37 AM
Subject: RE: [VRRP] 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