Re: [VRRP] A newly proposed draft

Stephen Nadas <stephen.nadas@ericsson.com> Mon, 26 October 2009 13:53 UTC

From: Stephen Nadas <stephen.nadas@ericsson.com>
To: Dacheng Zhang <zhangdacheng@huawei.com>, "vrrp@ietf.org" <vrrp@ietf.org>
Date: Mon, 26 Oct 2009 09:53:05 -0400
Thread-Topic: [VRRP] A newly proposed draft
Thread-Index: AcpUvr4RDVUviC2SS4q+8FTKFloztABfjeNA
Message-ID: <450AE4BEC513614F96969DDA34F3593401160DDF99@EUSAACMS0701.eamcs.ericsson.se>
References: <003801ca54be$be890290$6c0c6f0a@china.huawei.com>
In-Reply-To: <003801ca54be$be890290$6c0c6f0a@china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Radia.Perlman@Sun.COM" <Radia.Perlman@Sun.COM>
Subject: Re: [VRRP] A newly proposed draft
Precedence: list

Hi Dacheng,

I read the draft. For me, the terminology was a little confusing as this draft uses the term "VR" to mean a router that is supporting one of several "different L3 address spaces" (and is not the same as VRRPs use of the term...)

If I understand it correctly, this draft proposes to standardize a mechanism so that VRs (meaning different L3 address spaces) can reuse the VRRP session of some other VR (that is, an VRRP session running in yet another L3 address space) when it makes sense in the network design to do so.

I guess my thinking is that this is basically wanting to standardize behaviour inside the node and so I don't see it as a protocol.

The draft says that this provides VRRP protocol simplification. I do not see this as I think at least one VR (meaning one of different L3 address spaces) is running regular VRRP. So the protocol is not simpler. I think perhaps the draft means to say that the protocol is simpler for the "slaves". But I guess I think this can be done in other ways (for example, by some entity in the router registering interest in some VRRP session and getting notified when the VRRP master fails and taking actions at that time (in this case issuing Grat ARPs.)) A similar mechanism is needed for routers to propagate a BFD session failure to interested parties in the router - I don't think this is standardized.

The draft also clams a reduction of VRRP traffic (and the benefits that brings) for a routers supporting a set of L3 address spaces when it happens that the different "VRs" are topologically arranged to take advantage of this (one example is as given in the draft: when there are sessions on different VLAN that are also in different "VRs" to the same router.) I agree that this type of approach can save signalling bandwidth; however, I'm not sure it needs to be standardized.

Thanks,
Steve

________________________________

From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Dacheng Zhang
Sent: Saturday, October 24, 2009 11:29 AM
To: vrrp@ietf.org
Cc: Radia.Perlman@Sun.COM
Subject: [VRRP] A newly proposed draft

Hi, all:

We just proposed a new draft about a simplified vrrp protocol in IETF 76, which aims to reduce the overhead brought by vrrp signaling packets in certain cases. Could you please give us some comments and let us know whether you like the proposed idea. The draft is appended with the email.

Thank you in advance.

Dacheng

[VRRP] A newly proposed draft Dacheng Zhang
Re: [VRRP] A newly proposed draft Stephen Nadas