Subject: Re: [VRRP] VRRPv3 Implementation Report

From: "Mukesh Gupta" <[email-masked]>
Date: Tue, 14 Oct 2008 22:42:55 -0700

[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-masked]]
> Sent: Tuesday, October 14, 2008 2:23 AM
> To: Mukesh Gupta; [email-masked]
> Cc: [email-masked]
> 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-masked]
> Tested Interoperability: None yet.
> ========================================
> 
> 
> 
> ----- Original Message -----
> From: Mukesh Gupta
> To: [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/vrrp
_______________________________________________
vrrp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vrrp

---

From: "Don Provan" <[email-masked]>
Date: Wed, 15 Oct 2008 12:23:00 -0700

WARNING: contains banned part

Subject: RE: [VRRP] VRRPv3 Implementation Report
From: "Don Provan" <[email-masked]>
To: "'Mukesh Gupta'" <[email-masked]>, "'Lin Tao'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Wed, 15 Oct 2008 12:23:00 -0700

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

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mukesh Gupta
> Sent: Tuesday, October 14, 2008 10:43 PM
> To: Lin Tao
> Cc: [email-masked]; [email-masked]

---

From: Lin Tao <[email-masked]>
Date: Thu, 16 Oct 2008 19:34:03 +0800

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.

---

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 16 Oct 2008 07:13:25 -0500

Lin, 

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

Nothing prevents your implementation from defaulting to Accept Mode yes.
The spec provides the ability to do what you want. 

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

I don't understand what you mean by "abandon".  The point of the unified
draft was to make things the same for v4 and v6 and with this in mind,
it was easier to add accept-mode to IPv4 than not to, with the intention
that it would default to False precisely for the reasons Don gives
below.      

> > seem simpler in practice.)

[snip]

Thanks,
Steve

---

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 16 Oct 2008 07:19:10 -0500

Hi Mukesh, 

> Steve, have you guys implemented the unified draft?

No.  It was in our plans (and may still be), but this work got
deprioritized because of changes.  

Thanks, 
Steve

---

From: "don provan" <[email-masked]>
Date: Thu, 16 Oct 2008 10:37:32 -0700

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

> 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

---

From: "Don Provan" <[email-masked]>
Date: Thu, 16 Oct 2008 12:00:06 -0700

Subject: RE: [VRRP] VRRPv3 Implementation Report
From: "Don Provan" <[email-masked]>
To: "'Stephen Nadas'" <[email-masked]>, "'Lin Tao'" <[email-masked]>, "'Mukesh Gupta'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Date: Thu, 16 Oct 2008 12:00:06 -0700

> Nothing prevents your implementation from defaulting to 
> Accept Mode yes. The spec provides the ability to do what
> you want.

Well, the draft specifically says "Default is False".
And although it doesn't say so explicitly, I think the
specs could be interpreted as *requiring* Accept Mode
as a configurable control. (I know I read it that way
in the earlier RFCs, even as I pondered ignoring the
requirement....)

If either or both of these are intended to be only
recommendations, any future version of the spec should
say that explicitly. I think I've already made it clear
that I would support that position.

-don

---

From: "Stephen Nadas" <[email-masked]>
Date: Thu, 16 Oct 2008 14:31:17 -0500

I probably should have said nothing prevents an implementation from
providing a config control and some recommendation and/or rationale for
users to turn it to True.     

It is my thinking that without such a config control the default is
False.  I think spec says this, and i would prefer to leave it as is.   

I could be persuaded to add text along suggested lines if VRRP list so
indicates.    

Thanks, 
Steve 

> From: Don Provan [mailto:[email-masked]] 
> Sent: Thursday, October 16, 2008 15:00
> To: Stephen Nadas; 'Lin Tao'; 'Mukesh Gupta'
> Cc: [email-masked]; [email-masked]
> > Nothing prevents your implementation from defaulting to Accept Mode 
> > yes. The spec provides the ability to do what you want.
> 
> And although it doesn't say so explicitly, I think the specs 
> could be interpreted as *requiring* Accept Mode as a 
> configurable control. (I know I read it that way in the 
> earlier RFCs, even as I pondered ignoring the
> requirement....)
> 
> recommendations, any future version of the spec should say 
> that explicitly. I think I've already made it clear that I 
> would support that position.
> 
> -don
>

---

From: Lin Tao <[email-masked]>
Date: Mon, 20 Oct 2008 15:25:36 +0800

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.

---

From: "don provan" <[email-masked]>
Date: Mon, 20 Oct 2008 11:45:46 -0700

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

Lin,

Perhaps you should tell us more about this requirement, then.
The management techniques I've seen over the years always
involve managing physical nodes to insure they are operating
as expected or accessing services to make sure they are
performing correctly. In VRRP, the former is accomplished
by using an address actually owned by the box, and the latter
is accomplished by confirming that packet forwarding is
operating *through* the box, perhaps by pinging or otherwise
accessing *an external* address.

You apparently are seeing a third possibility revealed by
VRRP that involves accessing a virtual node for reasons
*other* than using the virtual service it is providing,
so I think it's important for us to all understand the
requirement that calls for that.

-don

---

From: Lin Tao <[email-masked]>
Date: Wed, 22 Oct 2008 10:49:41 +0800

Don,

The simplest requirement is "PING" that used to test the connectivity 
of the gateway by the end user or network operator.

When the VRRP is implemented, the network is mostly stable, the 
VR switchover is short and unusually. So the operator can take VRRP
 IP when he only need a simply operator such as looking at routing
 table or cpu usage of the Master router.

A new requirement of VRRP IP is TUNNEL. We can use the VRRP
IP as the source of TUNNEL, so that the peer node couldn't see the 
switchover. We also know that the packet must be sent to the IP Stack
in TUNNEL forward for encapsulation or decapsulation.

Lin.

---

From: "Mukesh Gupta" <[email-masked]>
Date: Thu, 30 Oct 2008 23:33:03 -0700

[speaking as a WG member]

The Nokia Security Appliances that I worked on quite a while back also
allowed the management operations using the VR IP addresses. The support
was added because some customers asked for it.

The same Nokia appliances also allowed the operators to use the virtual
IP address of a IP Cluster (not VRRP but similar protocol) as the
service end point for routing protocols (e.g. OSPF, RIP, BGP). So I
think this use of the VR IP address should be considered valid.

What do others think?

Regards
Mukesh
 
-----Original Message-----
From: don provan [mailto:[email-masked]] 
Sent: Thursday, October 30, 2008 12:28 PM
To: 'Lin Tao'; Mukesh Gupta
Cc: [email-masked]; [email-masked]
Subject: RE: [VRRP] VRRPv3 Implementation Report

Thanks for the info. That's just what I was looking for.

I think the management issues are a matter of taste, so we don't
need to go over that any more: I say management operations using
the VR IP address tend to obscure reality and other approaches
give a clearer picture, but you find using the VR IP address for
managing/monitoring the network is useful.

The part about tunneling brings up a different point for us to
consider: should VR IP addresses be used as service end points?
I've never given that any thought. What's the group wisdom about
that? Does it matter whether the service is part of the routing
infrastructure, as in this case? In this use of the VR IP
address valid, and, if so, is it important enough to force
implementations to support or even, as Lin is suggesting, always
do ACCEPT_MODE?

-don

> Lin Tao
> Sent: Tuesday, October 21, 2008 7:50 PM
> To: don provan; 'Mukesh Gupta'

---

From: Lin Tao <[email-masked]>
Date: Fri, 31 Oct 2008 16:22:21 +0800

I agree it. The requirement is really exist, so we must consider it.

Considering it is difficult to do this in a implementation, the ACCEPT_MODE
can be deleted from this draft. 

Best Regards

Lin.

----- Original Message ----- 
From: "Mukesh Gupta" <[email-masked]>
To: "don provan" <[email-masked]>; "Lin Tao" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, October 31, 2008 2:33 PM
Subject: RE: [VRRP] VRRPv3 Implementation Report

What do others think?

Regards
Mukesh
 
-----Original Message-----
From: don provan [mailto:[email-masked]] 
Sent: Thursday, October 30, 2008 12:28 PM
To: 'Lin Tao'; Mukesh Gupta
Cc: [email-masked]; [email-masked]
Subject: RE: [VRRP] VRRPv3 Implementation Report

-don

---

From: "don provan" <[email-masked]>
Date: Thu, 30 Oct 2008 12:28:16 -0700

-don

---

From: "Peter Hunt" <[email-masked]>
Date: Fri, 31 Oct 2008 12:18:16 -0700

I think that having the Master be able to respond to packets sent to
the virtual IP address is very useful, and that the current
ASSERT_MODE setting in the draft addresses that need.

If I understand correctly, Lin's concern with the current draft is
that having to provide the behaviour of ACCEPT_MODE = FALSE
complicates the protocol implementation, and most users will set
ACCEPT_MODE to TRUE anyway. So can we just remove the setting
altogether and always accept traffic?

I think being able to refuse traffic to the VIP has two (minor) benefits:
1) it provides a way for VRRPv3 to behave like VRRPv2, so that people
who "trade up" don't get any nasty surprises.
2) It reinforces the notion that the VIP is really a forwarding
address, not a local address. Once you start to blur this distinction,
you can inadvertently raise expectations about retaining TCP
connections, VPN tunnels, etc.

An alternative to removing the setting altogether would be to make
ACCEPT_MODE be an optional setting, but require that implementations
that do not support it behave as if ACCEPT_MODE is TRUE.

This would introduce a wrinkle that anyone wanting to preserve VRRPv2
behaviour would need to select a VRRPv3 implementation that supported
the ACCEPT_MODE setting. But that's probably not the end of the world.

Regards,
Peter