From vrrp-bounces@ietf.org Fri Oct 10 17:39:57 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDD7C3A6AEE; Fri, 10 Oct 2008 17:39:57 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6E493A6822 for ; Fri, 10 Oct 2008 17:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un1l837fJvOb for ; Fri, 10 Oct 2008 17:39:56 -0700 (PDT) Received: from ca-bay-exch-01.tropos.com (ca-bay-exch-01.tropos.com [12.108.168.189]) by core3.amsl.com (Postfix) with ESMTP id 34BF43A6AEE for ; Fri, 10 Oct 2008 17:39:56 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 10 Oct 2008 17:40:42 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: VRRPv3 Implementation Report thread-index: AckrOf1yEL0vyJROQSeGGrop58BZhA== From: "Mukesh Gupta" To: Cc: Ross Callon Subject: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1439196592==" Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. --===============1439196592== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C92B39.FDCD5FE4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C92B39.FDCD5FE4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 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. =20 Here is the information that is required. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name of Implementation:=20 Platform:=20 Organization:=20 Origin of Code: Information supplied by: Tested Interoperability: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 You can take a look at http://www.ietf.org/IESG/Implementations/rfc-2338-implementation.txt for examples. =20 Regards Mukesh =20 =20 ------_=_NextPart_001_01C92B39.FDCD5FE4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
/font>

Name of =
Implementation:

Platform: =

Organization: =

Origin of =
Code:

Information =
supplied by:

Tested =
Interoperability:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
/font>

You can take a =
look at http://www.ietf.org/IESG/Implementations/rfc-2338-implementation.txt=
 for examples.

Regards

Mukesh

------_=_NextPart_001_01C92B39.FDCD5FE4-- --===============1439196592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp --===============1439196592==-- From vrrp-bounces@ietf.org Tue Oct 14 22:42:02 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7FC3A6960; Tue, 14 Oct 2008 22:42:02 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8A93A683F for ; Tue, 14 Oct 2008 22:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dH3Y89LFd1Q2 for ; Tue, 14 Oct 2008 22:42:00 -0700 (PDT) Received: from ca-bay-exch-01.tropos.com (ca-bay-exch-01.troposnetworks.com [12.108.168.189]) by core3.amsl.com (Postfix) with ESMTP id 6C9B13A67EC for ; Tue, 14 Oct 2008 22:42:00 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 22:42:55 -0700 Message-ID: In-Reply-To: <00d301c92dde$6d19d950$0611990a@h3c.huawei3com.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [VRRP] VRRPv3 Implementation Report thread-index: Ackt3mnsG6fXqaAhSyqdW6/WXL5weQAqcanw From: "Mukesh Gupta" To: "Lin Tao" Cc: vrrp@ietf.org, wangju@h3c.com Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org [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:lint@h3c.com] > Sent: Tuesday, October 14, 2008 2:23 AM > To: Mukesh Gupta; draft-ietf-vrrp-unified-spec@tools.ietf.org > Cc: wangju@h3c.com > 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 lint@h3c.com > Tested Interoperability: None yet. > ======================================== > > > > ----- Original Message ----- > From: Mukesh Gupta > To: vrrp@ietf.org > 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 > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Wed Oct 15 23:35:00 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B853A6B40; Wed, 15 Oct 2008 23:35:00 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021063A6B56 for ; Wed, 15 Oct 2008 23:34:59 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbADm7EdNrmK for ; Wed, 15 Oct 2008 23:34:58 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1224138899-3195-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from stimpy.bivio.net (stimpy.bivio.net [216.142.75.227]) by core3.amsl.com (Postfix) with ESMTP id 50EBC3A6B40 for ; Wed, 15 Oct 2008 23:34:55 -0700 (PDT) Received: from dprovan1 ([192.168.24.163]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id m9FJNKmS024103; Wed, 15 Oct 2008 12:23:21 -0700 From: "Don Provan" To: "'Mukesh Gupta'" , "'Lin Tao'" Date: Wed, 15 Oct 2008 12:23:00 -0700 Message-ID: <00c801c92efb$70352590$a318a8c0@corp.networkrobots.com> X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Cc: wangju@h3c.com, vrrp@ietf.org Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format... ------------=_1224138899-3195-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1224138899-3195-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from stimpy.bivio.net (stimpy.bivio.net [216.142.75.227]) by core3.amsl.com (Postfix) with ESMTP id 50EBC3A6B40 for ; Wed, 15 Oct 2008 23:34:55 -0700 (PDT) Received: from dprovan1 ([192.168.24.163]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id m9FJNKmS024103; Wed, 15 Oct 2008 12:23:21 -0700 From: "Don Provan" To: "'Mukesh Gupta'" , "'Lin Tao'" Cc: , Subject: RE: [VRRP] VRRPv3 Implementation Report Date: Wed, 15 Oct 2008 12:23:00 -0700 Message-ID: <00c801c92efb$70352590$a318a8c0@corp.networkrobots.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C9_01C92EC0.C3D64D90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 Importance: Normal X-MS-TNEF-Correlator: 00000000442D192E89A78942830185E84677F83A246B5904 This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01C92EC0.C3D64D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 V2VsbCwgSSB1bmRlcnN0YW5kIHRoZSBwb2ludCBhYm91dCBBY2NlcHRfTW9kZSwgYnV0IG15IHNl bnRpbWVudHMNCnJ1biBleGFjdGx5IHRoZSBvcHBvc2l0ZSB3YXkuIFdoaWxlIGZvciBwcmFjdGlj YWwgcmVhc29ucyBBY2NlcHRfTW9kZQ0KYmVpbmcgb2ZmIGNhbiBiZSBoYXJkZXIgdG8gaW1wbGVt ZW50IG9uIHNvbWUgc3lzdGVtcywgbG9naWNhbGx5IHRoZQ0KZGlmZmVyZW5jZSBpbiBzaW1wbGlj aXR5IGlzIGVub3Jtb3VzOiB3aXRoIEFjY2VwdF9Nb2RlPU9mZiwgdGhlICpvbmx5Kg0KaW1wYWN0 IG9mIFZSUlAgb24gdGhlIElQdjQgY29kZSBpcyB0aGUgYWRkaXRpb24gb2YgYSBzaW5nbGUgQVJQ IGVudHJ5Lg0KQWNjZXB0X01vZGU9T24gZm9yY2VzIFZSUlAgdG8gYWRkIGFuZCByZW1vdmUgYW4g SVAgZW5kIHBvaW50LCBhDQpzaWduaWZpY2FudGx5IG1vcmUgaGVhdnkgaGFuZGVkIG9wZXJhdGlv bi4gKEJ1dCwgYXMgaXQgaGFwcGVucywgdGhlDQoqb25seSogYXZhaWxhYmxlIGFwcHJvYWNoIG9u IHNvbWUgc3lzdGVtcywgd2hpY2ggaXMgd2hhdCBtYWtlcyBpdA0Kc2VlbSBzaW1wbGVyIGluIHBy YWN0aWNlLikNCg0KQnV0IEkgZG9uJ3QgZG8gYW55IElQdjYgd29yaywgd2hpY2ggaXMgd2hlcmUg TGluIGlzIGNvbWluZyBmcm9tLA0Kc28gcGVyaGFwcyB0aGlzIGRpdmlzaW9uIGlzbid0IGFzIGNs ZWFyIGN1dCB0aGVyZT8NCg0KQW55d2F5LCBJIHRoaW5rIHdoYXQgSSdkIHN1Z2dlc3QgaXMgdG8g bWFrZSB0aGlzIGNsZWFybHkgYW4NCmltcGxlbWVudGF0aW9uIGRlY2lzaW9uLCBzcGVjaWZpY2Fs bHkgYWxsb3dpbmcgZWFjaCBpbXBsZW1lbnRhdGlvbg0KdG8gY2hvc2Ugd2hpY2ggbW9kZXMgdG8g c3VwcG9ydCwgd2hldGhlciBhbiBvcHRpb24gaXMgcHJlc2VudGVkIHRvDQp0aGUgdXNlciBhdCBh bGwsIGFuZCwgaWYgaXQgaXMsIHdoaWNoIGlzIHRoZSBkZWZhdWx0LiBXaXRoIHRoZSBzcGVjDQpo YXZpbmcgZGVzY3JpYmVkIHRoZSBmZWF0dXJlLCBJIGRvIG5vdCB0aGluayBsZWF2aW5nIHRob3Nl IGNob2ljZXMgdXANCnRvIHRoZSBpbXBsZW1lbnRhdGlvbiBpbnRyb2R1Y2VzIGFueSBhZGRpdGlv bmFsIG9wZXJhdGlvbmFsIHByb2JsZW1zLg0KDQpJIGhhdmVuJ3Qgd29ya2VkIG9uIFZSUlAgY29k ZSBmb3IgYSB3aGlsZSwgYnV0IHdoZW4gSSBkaWQsIHdoYXQgSQ0KZm91bmQgd2FzIHRoYXQgaW4g bXkgdmVyeSBsaW1pdGVkIGRhdGEgc2V0ICgzIG9yIDQgaW1wbGVtZW50YXRpb24pLA0KaW4gcHJh Y3RpY2UsIHRoZSBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBiZWVuIG1ha2luZyB0aGlzIGNob2ljZSwN CmFueXdheSwgcHJvdmlkaW5nIHdoaWNoZXZlciBhcHByb2FjaCB0aGV5IGNvdWxkIGJhc2VkIG9u IHRoZQ0KZmVhdHVyZXMgb2YgdGhlIElQIHN0YWNrIHRoZXkgd2VyZSB1c2luZy4gU28gSSBkb24n dCB0aGluayBleHBsaWNpdGx5DQpsZWF2aW5nIHRoZSBkZWNpc2lvbiB1cCB0byB0aGUgaW1wbGVt ZW50ZXIgYWN0dWFsbHkgY2hhbmdlcyBhbnl0aGluZzoNCmltcGxlbWVudGVycyBhcmUgbm90IGFs d2F5cyBhYmxlIHRvIHN1cHBvcnQgdGhlIGZlYXR1cmUgbm8gbWF0dGVyDQp3aGF0IHRoZSBzcGVj IHNheXMuDQoNCi1kb24NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2 cnJwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2cnJwLWJvdW5jZXNAaWV0Zi5vcmddT24gQmVo YWxmIE9mDQo+IE11a2VzaCBHdXB0YQ0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE0LCAyMDA4 IDEwOjQzIFBNDQo+IFRvOiBMaW4gVGFvDQo+IENjOiB2cnJwQGlldGYub3JnOyB3YW5nanVAaDNj LmNvbQ0KPiBTdWJqZWN0OiBSZTogW1ZSUlBdIFZSUlB2MyBJbXBsZW1lbnRhdGlvbiBSZXBvcnQN Cj4gDQo+IA0KPiBbQ29weWluZyB0aGUgV0ddDQo+IA0KPiBMaW4sDQo+IA0KPiBJdCdzIGdvb2Qg dG8gaGVhciBhYm91dCB5b3VyIGltcGxlbWVudGF0aW9uIGFuZCB5b3VyIGNvbW1lbnRzLiBJIHdp bGwNCj4gbGV0IFN0ZXZlLCB0aGUgYXV0aG9yL2VkaXRvciBvZiB0aGUgdW5pZmllZCBWUlJQIGRy YWZ0LCANCj4gcmVzcG9uZCB0byB5b3VyDQo+IHRlY2huaWNhbCBjb21tZW50cy4NCj4gDQo+IEl0 IHdvdWxkIGJlIGdvb2QgdG8gcmVjZWl2ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgDQo+IGltcGxl bWVudGF0aW9uIG9mIHRoZQ0KPiB1bmlmaWVkIGRyYWZ0IChkcmFmdC0gaWV0Zi12cnJwLXVuaWZp ZWQtc3BlYy0wMi50eHQpLiBXaGVuIGRvIA0KPiB5b3UgdGhpbmsNCj4geW91IHdvdWxkIGJlIGlt cGxlbWVudGluZyB0aGUgbmV3IGRyYWZ0Pw0KPiANCj4gU3RldmUsIGhhdmUgeW91IGd1eXMgaW1w bGVtZW50ZWQgdGhlIHVuaWZpZWQgZHJhZnQ/DQo+IA0KPiBSZWdhcmRzDQo+IE11a2VzaA0KPiAN Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IExpbiBUYW8gW21haWx0 bzpsaW50QGgzYy5jb21dDQo+ID4gU2VudDogVHVlc2RheSwgT2N0b2JlciAxNCwgMjAwOCAyOjIz IEFNDQo+ID4gVG86IE11a2VzaCBHdXB0YTsgZHJhZnQtaWV0Zi12cnJwLXVuaWZpZWQtc3BlY0B0 b29scy5pZXRmLm9yZw0KPiA+IENjOiB3YW5nanVAaDNjLmNvbQ0KPiA+IFN1YmplY3Q6IFJlOiBb VlJSUF0gVlJSUHYzIEltcGxlbWVudGF0aW9uIFJlcG9ydA0KPiA+IA0KPiA+IERlYXIgTXVrZXNo IEd1cHRhOg0KPiA+ICAgICBJJ20gYSBkZXZlbG9wZXIgaW4gSDNDLiBXZSBoYXZlIGltcGxlbWVu dGVkDQo+IGRyYWZ0LWlldGYtdnJycC1pcHY2LXNwZWMtMDggaW4gb3VyDQo+ID4gQ29td2FyZSwg YW5kIGhhdmUgcGFpZCBhdHRlbnRpb24gdG8gZHJhZnQtaWV0Zi12cnJwLXVuaWZpZWQtc3BlYy0w Mi4NCj4gVGhlcmUgYXJlIHNvbWUNCj4gPiBpbXByb3ZlbWVudCwgd2Ugc2hhbGwgZGV2ZWxvcGUg aXQuDQo+ID4gICAgIFRoZXJlIGlzIGEgbmV3IGNvbmNlcHQgIkFjY2VwdF9Nb2RlIiBpbiA2LjEu IEluIG91ciBvcGluaW9uLCB0aGUNCj4gRGVmYXVsdCB3b3VsZCBiZSBUcnVlLg0KPiA+IFRob3Vn aCB0aGUgYWRkcmVzcyBpcyBub3QgaXRzIG93biwgYnV0IHRoZXJlIGlzIHJlcXVpcmVtZW50IHRo YXQgdGhlDQo+IG9wZXJhdG9yIGNhbiBtYW5hZ2UgdGhlDQo+ID4gcm91dGVyIGJ5IGNvbm5lY3Rp bmcgdG8gdGhpcyB2cnJwIGFkZHJlc3Mgd2hlbiBhIHZpcnR1YWwgcm91dGVyIGluDQo+IE1hc3Rl ciwgaS5lLiB0aGlzIGFkZHJlc3MNCj4gPiBjYW4gYmUgdGhvdWdodCBhcyB0aGUgdmlydHVhbCBy b3V0ZSdzIG93biBhZGRyZXNzLg0KPiA+ICAgICBGdXJ0aGVybW9yZSwgd2UgY291bGQgdGhpbmsg YWJvdXQgd2lwaW5nIHRoaXMgbW9kZSBhd2F5LCBhbmQgaXQNCj4gd2lsbCBicmluZyBiZW5pZml0 IGluDQo+ID4gaW1wbGVtZW50YXRpb24gYmVjYXVzZSBvZiBTaW1wbGUgZGVzaWduLg0KPiA+ICAg ICBTaW5jZXJlbHkgbG9vayBmb3J3YXJkIHRvIHlvdXIgcmVwbHkuDQo+ID4gDQo+ID4gICAgQWNj ZXB0X01vZGUgICAgICAgICAgICAgQ29udHJvbHMgd2hldGhlciBhIHZpcnR1YWwgDQo+IHJvdXRl ciBpbiBNYXN0ZXINCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdGF0ZSB3aWxsIGFj Y2VwdCBwYWNrZXRzIA0KPiBhZGRyZXNzZWQgdG8gdGhlDQo+ID4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgYWRkcmVzcyBvd25lcidzIElQdlggYWRkcmVzcyBhcyANCj4gaXRzIG93biBpZg0K PiBpdA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzIG5vdCB0aGUgSVB2WCBhZGRy ZXNzIG93bmVyLiAgDQo+IERlZmF1bHQgaXMNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGYWxzZS4NCj4gPiANCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgICBOb3RlOiBJUHY2 IE5laWdoYm9yIFNvbGljaXRhdGlvbnMgYW5kDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgTmVpZ2hib3IgQWR2ZXJ0aXNlbWVudHMgc2hvdWxkIG5vdCBiZQ0KPiBkcm9wcGVkDQo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hlbiBBY2NlcHRfTW9kZSBpcyBGYWxzZS4NCj4g PiANCj4gPiBGWUk6IFRoaXMgaXMgb3VyIGltcGxlbWVudGF0aW9uLg0KPiA+ID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPiBOYW1lIG9mIEltcGxlbWVudGF0aW9u OiAgVlJSUCBpbiBDb213YXJlDQo+ID4gUGxhdGZvcm06IENvbXdhcmUNCj4gPiBPcmdhbml6YXRp b246IEgzQyBUZWNobm9sb2dpZXMgQ28uDQo+ID4gT3JpZ2luIG9mIENvZGU6IEludGVybmFsIGRl dmVsb3BtZW50DQo+ID4gSW5mb3JtYXRpb24gc3VwcGxpZWQgYnk6IExpbiBUYW8gbGludEBoM2Mu Y29tDQo+ID4gVGVzdGVkIEludGVyb3BlcmFiaWxpdHk6IE5vbmUgeWV0Lg0KPiA+ID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPiANCj4gPiANCj4gPiANCj4gPiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogTXVrZXNoIEd1cHRhDQo+ID4g VG86IHZycnBAaWV0Zi5vcmcNCj4gPiBDYzogUm9zcyBDYWxsb24NCj4gPiBTZW50OiBTYXR1cmRh eSwgT2N0b2JlciAxMSwgMjAwOCA4OjQwIEFNDQo+ID4gU3ViamVjdDogW1ZSUlBdIFZSUlB2MyBJ bXBsZW1lbnRhdGlvbiBSZXBvcnQNCj4gPiANCj4gPiANCj4gPiBIaSBBbGwsDQo+ID4gDQo+ID4g VGhlIGNoYWlycyBhcmUgcHV0dGluZyB0b2dldGhlciBhbiBpbXBsZW1lbnRhdGlvbiByZXBvcnQg Zm9yIFZSUlB2Mw0KPiB1bmlmaWVkIGRyYWZ0IChkcmFmdC0NCj4gPiBpZXRmLXZycnAtdW5pZmll ZC1zcGVjLTAyLnR4dCkuICBJZiB5b3UgaGF2ZSBvbmUgb3IgaWYgeW91IGtub3cgb2YNCj4gYW55 LCBwbGVhc2UgbGV0IHVzIGtub3cNCj4gPiBiZWZvcmUgMTAvMzEvMDguDQo+ID4gDQo+ID4gSGVy ZSBpcyB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyByZXF1aXJlZC4NCj4gPiANCj4gPiA9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gTmFtZSBvZiBJbXBsZW1lbnRh dGlvbjoNCj4gPiBQbGF0Zm9ybToNCj4gPiBPcmdhbml6YXRpb246DQo+ID4gT3JpZ2luIG9mIENv ZGU6DQo+ID4gSW5mb3JtYXRpb24gc3VwcGxpZWQgYnk6DQo+ID4gVGVzdGVkIEludGVyb3BlcmFi aWxpdHk6DQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+ IA0KPiA+IFlvdSBjYW4gdGFrZSBhIGxvb2sgYXQNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9JRVNH L0ltcGxlbWVudGF0aW9ucy9yZmMtMjMzOC0NCj4gPiBpbXBsZW1lbnRhdGlvbi50eHQgZm9yIGV4 YW1wbGVzLg0KPiA+IA0KPiA+IFJlZ2FyZHMNCj4gPiBNdWtlc2gNCj4gPiANCj4gPiANCj4gPiAN Cj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+IHZycnAgbWFpbGluZyBsaXN0DQo+ID4gdnJycEBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdnJycA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2cnJwIG1haWxpbmcgbGlzdA0K PiB2cnJwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dnJycA0K ------=_NextPart_000_00C9_01C92EC0.C3D64D90 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgETAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANgHCgAPAAwAFwAAAAMAHgEB A5AGAMAPAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAkAAAAW1ZSUlBdIFZSUlB2MyBJbXBsZW1lbnRhdGlvbiBSZXBvcnQAAgFxAAEA AAAWAAAAAcku+2/NOArcGMAFTV+TO4qosD9ZawAAAgEdDAEAAAAXAAAAU01UUDpEUFJPVkFOQEJJ VklPLk5FVAAACwABDgAAAABAAAYOAMKNb/suyQECAQoOAQAAABgAAAAAAAAARC0ZLomniUKDAYXo Rnf4OsKAAAADABQOAQAAAAsAHw4BAAAAAgEJEAEAAACACwAAfAsAAI4ZAABMWkZ1cpbFdwMACgBy Y3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0 MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgVwBlbGwsIEkg dRpuBIFzAZAdgCB0aPBlIHBvC4AFQAGgCGAhBUBBY2NlBTBfTYsEcR0wYh7xbXkgFBC3AjAHcQIw cwqiCoByHXBmIA7AANB0bCBAHiJvDnAeYACQDrAgd2F5ei4c4GgDEB5AAhAFwHAuciHBDeAHQCAY IGFzTwIgELEfOCEEYmULgGe7IlABICAkQAOgJhAgE+GzBIEeEG8gB3ALUGUgst8iUAOgJLAHgCBQ eR3AKAB2cx0wF7BnJDIh9CEEZP0GkGYEkAnwH0AnsChxJ8LfDeAisCBABAAhkG4FsARgWHVzOiLg IrBoHxo9bk8BIB0wHiIqAiAh8CoPIQQnwSHBJmEgVlJShlAoUh4iSVB2NCag5wRxLCIeImFkKqAg kChh3S/RYStxJkAjcUEwISBx/nIjECEELVsDoCOhH0AEIH8wAyeRMdEesB3xGCAEYHZ/MbEDoDDA LFEeAB5jHTBh6yEEAJBnAwBmJDECMCHx7wRgGCAnECSQdiBAE+AdgTceACJgBJBhMhIjIChC/x7w N+EEICKwJxEicAnwKUH3KhcupB6wdgtwC2ACYDGx3yJwA2AA0C0wKG93I1A+cc8sMT+wOrAgIGFr B5EisHs4FQngbSt0EoErUSPlZbwuKSEEIQQ7MR1BZAIgvicFQEQwNjEgQDDBNiLgzQWwaz+bKuEg TCtRLDHtBaBtJjIDUiw4FSegOoHvO+ExciwxKqB2BAAyIgQA20RSO4FjI3AKwWMe8R4h9RggP0Ma QUTQIvEdMkjhJG5rQDRJJx4Ac3X8Z2cHkAVAMWInoECSSNT/SlMh8QBwLwcn9DqzRCAFkPtJYx0w czqAK+A4winSKcH+bwPwJkEkkD/iUDshBCeR/xPQIpAi0T/DBGJOM02gInH/ACA/khQgRlE24iJg MhMsMf8j4AeQIHE6QSeQVEUeMSzA/1cCHqEdEh3hHTAGkDuiBACHP5keIgEBYXVsdCMh/y0SHiJR siEEE+BJUCZBVbH/BQEmEB4EKtA6sAhwH8FEEv4gLHBK0kzSSmFd0x4gVPL/VNFCwQQgVjBURx4i UC0egf0DYGQa0AeRRMIx1iRROnf/JFE+MT3RKTAztSEEHVBdsf8J8ERhRVI6QgOgMAMxEyOi/zKQ P7EjcB/URkE3AUkhWlH/TRQhBAIQHXEi4TFyQGErUX8gMTbAM5ApYAdwIrEeAGTvOrAykRQgOxAz IlAFwDDw/VAsKUfFQkkuRFAsBCBnkv8m4WqBQJFgxEbiYXNHxUTBv0xDPjFJUCqgJkE/s2VtMb8+ CB4hIEAFoFwwHgBiJKD/aFQqF18FBCAv0TCEIFABkPZjTPB3A3dGYizAJjEjIP5TJ6BEFky0DsAr tCHwIQT/YIhb0lE0YdEngnFLVwIh0D51KcMT0SZAZERMsmc6/0/NHaEesDlxX+IHQCLxZFH/PdJV +F66X9FAgQJABJAhBN9AQ1zWIFCDsWarLUQxQxroPiAtibJPBRApkGUivk0HkIeATdCJs4k2RgNh wSzgdnJycC0e0SsRbHNACJAAMC4FsCZQW7cAwAMQJ5A6jD+NQl004XRCZRPgbCaQLhCJNk32dUCx LTBHVjABkIk2BmBrAjAs4FQKUHNuAExhT2ch0GZAEoExNB0wAdAwIjiTUDA6NG6gUE3NiTZUjfBG k1RhWLWJkGxDY4wUjPc7IuEmQGrAdUBoM2MuRxGRd5h1YmoFkJIhUmUs4KpbMAJdL/N2bqBJUDwv mUBWUok2m75bCFBwefF9xldHXZu+RqFHxZwYyEl0JwQgZ28EcCeC9zmhVxEe03kIYWLOHeKh8/9H ESCzIyAdUAPwHRCJNiNwfQVAUw6wNsAuRFwgYQFy/i8JgCKwBbF5ZR1wOLE6Qf0wA2Qj8AGAHTCJ NlgRHmD/HfInoKHyiTYOsBPQAwAkQv+jx59/Z/J3cx5AoMYYIB9A/0lAKzIjoYXhovMe0x4iiTZ/ UC15ZIk2p4aoUzsQqFMtWyewjREtjhOnhS1Rsi3IMDIuDNB0KSMiaoH/RJGJNqHxTKS2Oq0XJ8d9 xv5uB9GoU0tFnBilhXKDtrL8Z3WDwX94HgSyW7o/mUD+ZwsRIPWQlpu+iZ+Kr8Gi/4vUlTWNhyvA AjCXtp4nkd/Rku8yOjJuoEGUZ5TU35C6lzCzRLO/tMNAJ5AG8P9mkI0GwUiWIpdfxoaYz5nf95rv wYTBSERKcpC6gcXBov/WIk1gQaAykAEANsAXsDqB8StCSDNDIyEnAq5yvKj/iTbLLgUgRSC0xZPQ K1GqCf+WAQNwIvBfUh3icoMKsGrg/1mhDrAggTBSJ6DLL7RtlHf/RlODAiiSwUgnwXVBKAM/kf8o wY/BAyDW1juhq9fWFOE0vywxMpC5ogWgKxEFMSIfKeIiK0I2LjGkQduDIlG/C4BRY7Gp1HBcE60I VCFg/0LgyWlU4E2wXLQx0VgRO5HvBCBf4iKweUF3UYEf8krz4ywiGCBxdWk2gSgibIP/sak6dAWx JrIDgYrRsZqpIese4RKBYncybrmgJBFg0v9iciwxjhLs12pjMpBJUAAgf4Bh8vYLgZBGJKB/8Vph Lv9C4EjU7OXBSCa1YQHsYUoDvx4i9hugke4R7NbkzUYIcP9K8jlS42N3VEy0HsQD8OkB/3N1BGIe sExDHeJA9sHApIL/H+AFECZBJhA4omyy4htQWu8mECRAWWEvwlMnw14SOIG/5M0F0CsRGCAh8Rew b0zw/2lR3KGppyRxC1AzptOc1iH/HynWIwwGEjBj0s0gVqj2B/+ox/am95XVnBDfDAQdwSLC/wJS UyDm0y+BQLDt4Yk27OX/WHPyLBYPFrjs5u4RgsCgkf0wwVjs10ohsAft5FpxGcj/FX8cjxzB7WUw hRj4GEMjIP/BN+o2LDAbjyH//aKP0FlwdwnfIV8ljE6DUNDRRQNO/65Q7HCMgNSge3Arw3IVozHP JE8p7yZiJ1ZBZG0xuRD/WXCj8+Ohd2ODQgLw2ShXYP/kcCjfL28vsmpjC1oAgSNP+cOYWUnHMUjy AIGiDwaanj02TzdfN7PBSE5hPvF/eWHR7IwQaKRCQdx1wUhQ/z2w2iCu0YwQO3/CML+Q6SC+ejp1 16HEsKrCDSBvwmD/ZEGdQOTJwjR5Up1AVbAm0f9/4mUi1tXvosFI6ICuyFYi/22AXpHzcMRoxYrJ aU3hXpH7QfNlY2Jp0ANARTEmkPPQ/6Hg2hA1n0pfS28yb0z/wYn/QOXCmMHUw46Qv8m3lmvN3L5S YSBAAYBxiLbGuFNfItXHnDGThTiUEDDJO9A3z9EP0h/TL9OcSGkrsKSgv59nTkrhMYCy73CC5HCv kP/0BYEADZQaoVsMCYGEsmlS/1qEsd+y6uIZ3y+03KRQeXC/vAJyg0ji8VGnoLaja4NA/+aAQWAT 94FQdRF9gQVxpUJ/ewBqE8FIAvA8weOQk/Av+DMxL5PAMl9d4+XVcUP3rrnv8+8IZG4fSc9z/0vv /zk/Okc77zzwPZ93bkD9Qz//RE9Gr0e/cp+BP3S/cg8u8P5ZtsH50hJg1ODWoQgzNUADiTb6kHRw Oi8vd4OG4M1HL0lFU0eHoGFbC3MvcmbgYMkQM544Zco0zGgRY1NleHZg/wYB/NoueL99wE5cz4/f kO/8IF+Sr5O/lIouePTTxRK/nYJF4BJQlZxTr4ZUc4a+28US8cEvlwKuoi/00i52/5SPnX+Uzy6y lj+fapgvmV8Lmm+bfH2l0B4AQhABAAAARQAAADxGRjIyRDhEQTNDQzQ3ODQzODI4MEE0NUE3Q0ZB RDI3QTA2ODA5MkE5QGNhLWJheS1leGNoLTAxLnRyb3Bvcy5jb20+AAAAAAMACVkBAAAACwAAgAgg BgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAA AAMACoAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAA/cQEACwALgAggBgAAAAAAwAAAAAAAAEYAAAAA DoUAAAAAAAADAAyACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMADYAIIAYAAAAAAMAAAAAA AABGAAAAABiFAAAAAAAAHgAOgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsA D4AIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAQgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUA AAAAAAACAfgPAQAAABAAAABELRkuiaeJQoMBhehGd/g6AgH6DwEAAAAQAAAARC0ZLomniUKDAYXo Rnf4OgIB+w8BAAAAkQAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5 v7gBAKoAN9luAAAAQzpcRG9jdW1lbnRzIGFuZCBTZXR0aW5nc1xkcHJvdmFuXExvY2FsIFNldHRp bmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcZG9uLnBzdAAAAAADAP4PBQAA AAMADTT9NwAAAgF/AAEAAAAxAAAAMDAwMDAwMDA0NDJEMTkyRTg5QTc4OTQyODMwMTg1RTg0Njc3 RjgzQTI0NkI1OTA0AAAAAAMABhB07UBVAwAHEHIPAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABl AAAAV0VMTCxJVU5ERVJTVEFORFRIRVBPSU5UQUJPVVRBQ0NFUFRNT0RFLEJVVE1ZU0VOVElNRU5U U1JVTkVYQUNUTFlUSEVPUFBPU0lURVdBWVdISUxFRk9SUFJBQ1RJQ0FMUkVBUwAAAACJbw== ------=_NextPart_000_00C9_01C92EC0.C3D64D90-- ------------=_1224138899-3195-1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp ------------=_1224138899-3195-1-- From vrrp-bounces@ietf.org Thu Oct 16 04:32:42 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4EB3A6AFC; Thu, 16 Oct 2008 04:32:42 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B37F3A6B4A for ; Thu, 16 Oct 2008 04:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.327 X-Spam-Level: ** X-Spam-Status: No, score=2.327 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgMS3fWyX+SX for ; Thu, 16 Oct 2008 04:32:39 -0700 (PDT) Received: from huawei-3com.com (unknown [221.12.31.56]) by core3.amsl.com (Postfix) with ESMTP id 2C9B73A6AFC for ; Thu, 16 Oct 2008 04:32:37 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8T00HFZXHSX1@h3cml01-in.huawei-3com.com> for vrrp@ietf.org; Thu, 16 Oct 2008 19:34:40 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.124]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K8T00J4TXHSMF@h3cml01-in.huawei-3com.com> for vrrp@ietf.org; Thu, 16 Oct 2008 19:34:40 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.6]) by mailsecurity.h3c.com with ESMTP; Thu, 16 Oct 2008 19:38:37 +0800 Date: Thu, 16 Oct 2008 19:34:03 +0800 From: Lin Tao To: Don Provan , 'Mukesh Gupta' Message-id: <001a01c92f83$17ec1960$0611990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <00c801c92efb$70352590$a318a8c0@corp.networkrobots.com> Cc: wangju@h3c.com, vrrp@ietf.org Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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" To: "'Mukesh Gupta'" ; "'Lin Tao'" Cc: ; 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: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org]On Behalf Of >> Mukesh Gupta >> Sent: Tuesday, October 14, 2008 10:43 PM >> To: Lin Tao >> Cc: vrrp@ietf.org; wangju@h3c.com >> 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:lint@h3c.com] >> > Sent: Tuesday, October 14, 2008 2:23 AM >> > To: Mukesh Gupta; draft-ietf-vrrp-unified-spec@tools.ietf.org >> > Cc: wangju@h3c.com >> > 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 lint@h3c.com >> > Tested Interoperability: None yet. >> > ======================================== >> > >> > >> > >> > ----- Original Message ----- >> > From: Mukesh Gupta >> > To: vrrp@ietf.org >> > 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 >> > vrrp@ietf.org >> > https://www.ietf.org/mailman/listinfo/vrrp >> _______________________________________________ >> vrrp mailing list >> vrrp@ietf.org >> https://www.ietf.org/mailman/listinfo/vrrp > _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Oct 16 05:13:02 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F1C3A6B78; Thu, 16 Oct 2008 05:13:02 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33C963A6B78 for ; Thu, 16 Oct 2008 05:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SW28m7DLAJa2 for ; Thu, 16 Oct 2008 05:13:00 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 3DE443A6805 for ; Thu, 16 Oct 2008 05:13:00 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m9GCDVGE023925; Thu, 16 Oct 2008 07:13:33 -0500 Received: from eusrcmw720.eamcs.ericsson.se ([138.85.77.20]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 07:13:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 07:13:25 -0500 Message-ID: In-Reply-To: <001a01c92f83$17ec1960$0611990a@h3c.huawei3com.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VRRP] VRRPv3 Implementation Report Thread-Index: AckvgxSsH/RJa9dHSPCDg3RJCUDM2AABJeNw References: <00c801c92efb$70352590$a318a8c0@corp.networkrobots.com> <001a01c92f83$17ec1960$0611990a@h3c.huawei3com.com> From: "Stephen Nadas" To: "Lin Tao" , "Don Provan" , "Mukesh Gupta" X-OriginalArrivalTime: 16 Oct 2008 12:13:31.0295 (UTC) FILETIME=[9A9F2AF0:01C92F88] Cc: vrrp@ietf.org, wangju@h3c.com Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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. > > 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.) [snip] Thanks, Steve _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Oct 16 05:18:33 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524A03A6AD8; Thu, 16 Oct 2008 05:18:33 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6FF93A6AD8 for ; Thu, 16 Oct 2008 05:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuK6g+BNqdcV for ; Thu, 16 Oct 2008 05:18:31 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 2A2073A6999 for ; Thu, 16 Oct 2008 05:18:30 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m9GCKF8M018049; Thu, 16 Oct 2008 07:20:15 -0500 Received: from eusrcmw720.eamcs.ericsson.se ([138.85.77.20]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 07:19:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 07:19:10 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VRRP] VRRPv3 Implementation Report Thread-Index: Ackt3mnsG6fXqaAhSyqdW6/WXL5weQAqcanwAEAfbpA= References: <00d301c92dde$6d19d950$0611990a@h3c.huawei3com.com> From: "Stephen Nadas" To: "Mukesh Gupta" X-OriginalArrivalTime: 16 Oct 2008 12:19:11.0697 (UTC) FILETIME=[65846410:01C92F89] Cc: vrrp@ietf.org, wangju@h3c.com Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Oct 16 10:36:39 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 869903A682B; Thu, 16 Oct 2008 10:36:39 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B24E3A682B for ; Thu, 16 Oct 2008 10:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXvhnjslLsHO for ; Thu, 16 Oct 2008 10:36:36 -0700 (PDT) Received: from stimpy.bivio.net (stimpy.bivio.net [216.142.75.227]) by core3.amsl.com (Postfix) with ESMTP id C9D393A681A for ; Thu, 16 Oct 2008 10:36:36 -0700 (PDT) Received: from xp (nofear-ipsec-84.bivio.net [192.168.28.84]) by stimpy.bivio.net (8.12.8/8.12.8) with ESMTP id m9GHbWmS014294; Thu, 16 Oct 2008 10:37:32 -0700 Message-Id: <200810161737.m9GHbWmS014294@stimpy.bivio.net> From: "don provan" To: "'Lin Tao'" , "'Mukesh Gupta'" Date: Thu, 16 Oct 2008 10:37:32 -0700 Organization: Bivio Networks MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <001a01c92f83$17ec1960$0611990a@h3c.huawei3com.com> Thread-Index: AckvgwD0xEkvQMb8RHGWenyQh+yceQAK57eg Cc: wangju@h3c.com, vrrp@ietf.org Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org > 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" To: "'Mukesh Gupta'" ; "'Lin Tao'" Cc: ; 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: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org]On Behalf Of >> Mukesh Gupta >> Sent: Tuesday, October 14, 2008 10:43 PM >> To: Lin Tao >> Cc: vrrp@ietf.org; wangju@h3c.com >> 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:lint@h3c.com] >> > Sent: Tuesday, October 14, 2008 2:23 AM >> > To: Mukesh Gupta; draft-ietf-vrrp-unified-spec@tools.ietf.org >> > Cc: wangju@h3c.com >> > 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 lint@h3c.com >> > Tested Interoperability: None yet. >> > ======================================== >> > >> > >> > >> > ----- Original Message ----- >> > From: Mukesh Gupta >> > To: vrrp@ietf.org >> > 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 >> > vrrp@ietf.org >> > https://www.ietf.org/mailman/listinfo/vrrp >> _______________________________________________ >> vrrp mailing list >> vrrp@ietf.org >> https://www.ietf.org/mailman/listinfo/vrrp > _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Oct 16 11:59:33 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7AC73A6A46; Thu, 16 Oct 2008 11:59:33 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477D63A6AD6 for ; Thu, 16 Oct 2008 11:59:33 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 tagged_above=-999 required=5 tests=[AWL=-1.345, BAYES_40=-0.185, MIME_BASE64_TEXT=1.753] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWv+QHwefhMH for ; Thu, 16 Oct 2008 11:59:32 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1224183573-27507-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from stimpy.bivio.net (stimpy.bivio.net [216.142.75.227]) by core3.amsl.com (Postfix) with ESMTP id 9DF0D3A684C for ; Thu, 16 Oct 2008 11:59:32 -0700 (PDT) Received: from dprovan1 ([192.168.24.163]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id m9GJ0SmS015890; Thu, 16 Oct 2008 12:00:28 -0700 From: "Don Provan" To: "'Stephen Nadas'" , "'Lin Tao'" , "'Mukesh Gupta'" Date: Thu, 16 Oct 2008 12:00:06 -0700 Message-ID: <00cc01c92fc1$67f5ded0$a318a8c0@corp.networkrobots.com> X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Cc: vrrp@ietf.org, wangju@h3c.com Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format... ------------=_1224183573-27507-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1224183573-27507-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from stimpy.bivio.net (stimpy.bivio.net [216.142.75.227]) by core3.amsl.com (Postfix) with ESMTP id 9DF0D3A684C for ; Thu, 16 Oct 2008 11:59:32 -0700 (PDT) Received: from dprovan1 ([192.168.24.163]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id m9GJ0SmS015890; Thu, 16 Oct 2008 12:00:28 -0700 From: "Don Provan" To: "'Stephen Nadas'" , "'Lin Tao'" , "'Mukesh Gupta'" Cc: , Subject: RE: [VRRP] VRRPv3 Implementation Report Date: Thu, 16 Oct 2008 12:00:06 -0700 Message-ID: <00cc01c92fc1$67f5ded0$a318a8c0@corp.networkrobots.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CD_01C92F86.BBD28930" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 In-Reply-To: X-MS-TNEF-Correlator: 00000000442D192E89A78942830185E84677F83A64A55904 Importance: Normal This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C92F86.BBD28930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 PiBOb3RoaW5nIHByZXZlbnRzIHlvdXIgaW1wbGVtZW50YXRpb24gZnJvbSBkZWZhdWx0aW5nIHRv IA0KPiBBY2NlcHQgTW9kZSB5ZXMuIFRoZSBzcGVjIHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIGRv IHdoYXQNCj4geW91IHdhbnQuDQoNCldlbGwsIHRoZSBkcmFmdCBzcGVjaWZpY2FsbHkgc2F5cyAi RGVmYXVsdCBpcyBGYWxzZSIuDQpBbmQgYWx0aG91Z2ggaXQgZG9lc24ndCBzYXkgc28gZXhwbGlj aXRseSwgSSB0aGluayB0aGUNCnNwZWNzIGNvdWxkIGJlIGludGVycHJldGVkIGFzICpyZXF1aXJp bmcqIEFjY2VwdCBNb2RlDQphcyBhIGNvbmZpZ3VyYWJsZSBjb250cm9sLiAoSSBrbm93IEkgcmVh ZCBpdCB0aGF0IHdheQ0KaW4gdGhlIGVhcmxpZXIgUkZDcywgZXZlbiBhcyBJIHBvbmRlcmVkIGln bm9yaW5nIHRoZQ0KcmVxdWlyZW1lbnQuLi4uKQ0KDQpJZiBlaXRoZXIgb3IgYm90aCBvZiB0aGVz ZSBhcmUgaW50ZW5kZWQgdG8gYmUgb25seQ0KcmVjb21tZW5kYXRpb25zLCBhbnkgZnV0dXJlIHZl cnNpb24gb2YgdGhlIHNwZWMgc2hvdWxkDQpzYXkgdGhhdCBleHBsaWNpdGx5LiBJIHRoaW5rIEkn dmUgYWxyZWFkeSBtYWRlIGl0IGNsZWFyDQp0aGF0IEkgd291bGQgc3VwcG9ydCB0aGF0IHBvc2l0 aW9uLg0KDQotZG9uDQo= ------=_NextPart_000_00CD_01C92F86.BBD28930 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgcTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANgHCgAQAAwAAAAAAAQACQEB A5AGAOAGAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAkAAAAW1ZSUlBdIFZSUlB2MyBJbXBsZW1lbnRhdGlvbiBSZXBvcnQAAgFxAAEA AAAWAAAAAckvwWcwOghvJqBuSkaE5u2EDfWktQAAAgEdDAEAAAAXAAAAU01UUDpEUFJPVkFOQEJJ VklPLk5FVAAACwABDgAAAABAAAYOADhsY8EvyQECAQoOAQAAABgAAAAAAAAARC0ZLomniUKDAYXo Rnf4OsKAAAADABQOAQAAAAsAHw4BAAAAAgEJEAEAAACgAgAAnAIAAMYDAABMWkZ19XemgwMACgBy Y3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0 MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgPhEHsG90aAuA ZyBwVRggdgnwdAQgeQhhIBsHcAtQZQeAAjBhdGkVAiAgA1IgAQFhdWxzHxAdYXRvCuMKgBzwQehj Y2UFMU0EcR4QB5CQLiBUaCGwc3AFkPEdgW92aQEABCAdMCGwowGgAxBpdHkgUmQgcHp3E+B0IJYe ISRQAHB0Bi4glCCUV2VsbCzxIzNkcmEBgCJTBpAN4EUHQGwj4HNheQQgIm5EH8QeYAQgRgdAFBAi sSWlQW5kI3AgAGgIYDxnaB5gBUAkMAeQbif/J1EoUCJQIHAOwAtQDeAjwNsoECawSSMxC4BrIzIg lN8iYgQgBaAf8CpAYiGwC4C9DrByHZEOsCpBBCAqGCDYcXVpBRAdYCohCiCU1S+RYS4xbifAZwhw AaCrHqAx0nQDYGwiACgs0Lhrbm8H4CzQGCBhKkDvKvEdMB8AJVF5IJQLgCMzDTPwciOwEoFSRkNz 7yawHbIvgizQcAIgBIEvYb8yIDOAMCItSC/UHrMuOZHyKSW6SWYsACPAIjAFwP8FsQbgHTA7MDqw I0EUECNw/xggLsM3USpAIGEuoQIgKBDrOIYFoG0ewWQfAzZhAHDxI+BmdXQIcCGwHcAUAPcfIjvE IlRzKpEucC2FK7HPNGMsGCIALNZJJx3AKlHfM+Ij4ADAIaEq8WMeoArAFyCUNGMs0HcuU3N1cH83 MAAgNFQ3MACQHxIlqy0XJDALkCCjfUlQHgBCEAEAAABGAAAAPERGNzhCREY2OTU2RkRENDc4MEQ1 REFEODhBMDczQ0Y0MkQxQjMzQGV1c3JjbXc3MjAuZWFtY3MuZXJpY3Nzb24uc2U+AAAAAwAJWQEA AAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAA ABCFAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAD9xAQALAAuACCAGAAAAAADAAAAA AAAARgAAAAAOhQAAAAAAAAMADIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwANgAggBgAA AAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAA6ACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQA AAA5LjAACwAPgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADABCACCAGAAAAAADAAAAAAAAA RgAAAAABhQAAAAAAAAIB+A8BAAAAEAAAAEQtGS6Jp4lCgwGF6EZ3+DoCAfoPAQAAABAAAABELRku iaeJQoMBhehGd/g6AgH7DwEAAACRAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAA AAAATklUQfm/uAEAqgA32W4AAABDOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXGRwcm92YW5cTG9j YWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxNaWNyb3NvZnRcT3V0bG9va1xkb24ucHN0AAAA AAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDQ0MkQxOTJFODlBNzg5NDI4MzAx ODVFODQ2NzdGODNBNjRBNTU5MDQAAAAAAwAGELX21uMDAAcQ8gEAAAMAEBABAAAAAwAREAAAAAAe AAgQAQAAAGUAAABOT1RISU5HUFJFVkVOVFNZT1VSSU1QTEVNRU5UQVRJT05GUk9NREVGQVVMVElO R1RPQUNDRVBUTU9ERVlFU1RIRVNQRUNQUk9WSURFU1RIRUFCSUxJVFlUT0RPV0hBVFlPVVdBAAAA AL6c ------=_NextPart_000_00CD_01C92F86.BBD28930-- ------------=_1224183573-27507-1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp ------------=_1224183573-27507-1-- From vrrp-bounces@ietf.org Thu Oct 16 12:31:01 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD853A684C; Thu, 16 Oct 2008 12:31:01 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22953A684C for ; Thu, 16 Oct 2008 12:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYNY28BC6VXi for ; Thu, 16 Oct 2008 12:30:57 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id B58783A6452 for ; Thu, 16 Oct 2008 12:30:57 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m9GJV9pm007748; Thu, 16 Oct 2008 14:31:24 -0500 Received: from eusrcmw720.eamcs.ericsson.se ([138.85.77.20]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Oct 2008 14:31:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 14:31:17 -0500 Message-ID: In-Reply-To: <00cc01c92fc1$67f5ded0$a318a8c0@corp.networkrobots.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VRRP] VRRPv3 Implementation Report Thread-Index: AckvwWcwOghvJqBuSkaE5u2EDfWktQAAwqdA References: <00cc01c92fc1$67f5ded0$a318a8c0@corp.networkrobots.com> From: "Stephen Nadas" To: "Don Provan" , "Lin Tao" , "Mukesh Gupta" X-OriginalArrivalTime: 16 Oct 2008 19:31:18.0358 (UTC) FILETIME=[C302E760:01C92FC5] Cc: vrrp@ietf.org, wangju@h3c.com Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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 > -----Original Message----- > From: Don Provan [mailto:dprovan@bivio.net] > Sent: Thursday, October 16, 2008 15:00 > To: Stephen Nadas; 'Lin Tao'; 'Mukesh Gupta' > Cc: wangju@h3c.com; vrrp@ietf.org > Subject: RE: [VRRP] VRRPv3 Implementation Report > > > 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 > _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Mon Oct 20 00:23:54 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AD13A68F3; Mon, 20 Oct 2008 00:23:54 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985B83A6833 for ; Mon, 20 Oct 2008 00:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.834 X-Spam-Level: *** X-Spam-Status: No, score=3.834 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_63=0.6, RDNS_NONE=0.1, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZOIYUue7h5x for ; Mon, 20 Oct 2008 00:23:49 -0700 (PDT) Received: from huawei-3com.com (unknown [221.12.31.13]) by core3.amsl.com (Postfix) with ESMTP id EFB513A6A37 for ; Mon, 20 Oct 2008 00:23:47 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K91005L40LMKS@h3cml02-in.huawei-3com.com> for vrrp@ietf.org; Mon, 20 Oct 2008 15:24:58 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K91005570LMK1@h3cml02-in.huawei-3com.com> for vrrp@ietf.org; Mon, 20 Oct 2008 15:24:58 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.19]) by mailsecurity.h3c.com with ESMTP; Mon, 20 Oct 2008 15:22:10 +0800 Date: Mon, 20 Oct 2008 15:25:36 +0800 From: Lin Tao To: don provan , 'Mukesh Gupta' Message-id: <001701c93285$0c0ae6d0$1311990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <200810161737.m9GHbWmS014294@stimpy.bivio.net> Cc: wangju@h3c.com, vrrp@ietf.org Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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" To: "'Lin Tao'" ; "'Mukesh Gupta'" Cc: ; 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" > To: "'Mukesh Gupta'" ; "'Lin Tao'" > Cc: ; > 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: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org]On Behalf Of >>> Mukesh Gupta >>> Sent: Tuesday, October 14, 2008 10:43 PM >>> To: Lin Tao >>> Cc: vrrp@ietf.org; wangju@h3c.com >>> 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:lint@h3c.com] >>> > Sent: Tuesday, October 14, 2008 2:23 AM >>> > To: Mukesh Gupta; draft-ietf-vrrp-unified-spec@tools.ietf.org >>> > Cc: wangju@h3c.com >>> > 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 lint@h3c.com >>> > Tested Interoperability: None yet. >>> > ======================================== >>> > >>> > >>> > >>> > ----- Original Message ----- >>> > From: Mukesh Gupta >>> > To: vrrp@ietf.org >>> > 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 >>> > vrrp@ietf.org >>> > https://www.ietf.org/mailman/listinfo/vrrp >>> _______________________________________________ >>> vrrp mailing list >>> vrrp@ietf.org >>> https://www.ietf.org/mailman/listinfo/vrrp >> > _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Tue Oct 21 00:34:45 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F25C3A6869; Tue, 21 Oct 2008 00:34:45 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484873A6869 for ; Tue, 21 Oct 2008 00:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.764 X-Spam-Level: X-Spam-Status: No, score=0.764 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_50=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm14y05S30-Q for ; Tue, 21 Oct 2008 00:34:44 -0700 (PDT) Received: from stimpy.bivio.net (stimpy.bivio.net [216.142.75.227]) by core3.amsl.com (Postfix) with ESMTP id DE1EB3A67D9 for ; Tue, 21 Oct 2008 00:34:43 -0700 (PDT) Received: from dprovan1 ([192.168.24.163]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id m9KIkBmS012889; Mon, 20 Oct 2008 11:46:11 -0700 From: "don provan" To: "'Lin Tao'" , "'Mukesh Gupta'" Date: Mon, 20 Oct 2008 11:45:46 -0700 Message-ID: <01e801c932e4$11185770$a318a8c0@corp.networkrobots.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 In-Reply-To: <001701c93285$0c0ae6d0$1311990a@h3c.huawei3com.com> Importance: Normal Cc: vrrp@ietf.org, wangju@h3c.com Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org > 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 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Tue Oct 21 19:48:02 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5143A69B0; Tue, 21 Oct 2008 19:48:02 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A92B33A69B0 for ; Tue, 21 Oct 2008 19:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.78 X-Spam-Level: ** X-Spam-Status: No, score=2.78 tagged_above=-999 required=5 tests=[AWL=1.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEzbblrqCawT for ; Tue, 21 Oct 2008 19:48:01 -0700 (PDT) Received: from huawei-3com.com (unknown [221.12.31.56]) by core3.amsl.com (Postfix) with ESMTP id DAC2B3A694E for ; Tue, 21 Oct 2008 19:47:59 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K940026XD611N@h3cml01-in.huawei-3com.com> for vrrp@ietf.org; Wed, 22 Oct 2008 10:49:13 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K94002ZYD610Z@h3cml01-in.huawei-3com.com> for vrrp@ietf.org; Wed, 22 Oct 2008 10:49:13 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.19]) by mailsecurity.h3c.com with ESMTP; Wed, 22 Oct 2008 10:46:25 +0800 Date: Wed, 22 Oct 2008 10:49:41 +0800 From: Lin Tao To: don provan , 'Mukesh Gupta' Message-id: <000b01c933f0$d9d9d870$1311990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: <01e801c932e4$11185770$a318a8c0@corp.networkrobots.com> Cc: vrrp@ietf.org, wangju@h3c.com Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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. ----- Original Message ----- From: "don provan" To: "'Lin Tao'" ; "'Mukesh Gupta'" Cc: ; Sent: Tuesday, October 21, 2008 2:45 AM Subject: RE: [VRRP] VRRPv3 Implementation Report >> 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 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Oct 30 05:03:34 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1ED3A67E5; Thu, 30 Oct 2008 05:03:34 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A383A68E5 for ; Thu, 30 Oct 2008 05:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.19 X-Spam-Level: X-Spam-Status: No, score=-104.19 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqcv-4DhKMHX for ; Thu, 30 Oct 2008 05:00:35 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by core3.amsl.com (Postfix) with ESMTP id 7E9B03A6838 for ; Thu, 30 Oct 2008 05:00:35 -0700 (PDT) Received: from G5W0603.americas.hpqcorp.net (g5w0603.americas.hpqcorp.net [16.228.9.186]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id CFA081434D for ; Thu, 30 Oct 2008 12:00:09 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G5W0603.americas.hpqcorp.net (16.228.9.186) with Microsoft SMTP Server (TLS) id 8.1.263.0; Thu, 30 Oct 2008 11:59:29 +0000 Received: from GVW1116EXC.americas.hpqcorp.net ([16.228.24.173]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Thu, 30 Oct 2008 11:59:28 +0000 From: "Saraswat, Deepak" To: "vrrp@ietf.org" Date: Thu, 30 Oct 2008 11:59:27 +0000 Thread-Topic: VRRP deployment in MPLS network network Thread-Index: Ack6hvVGyo75gJKVQVCN3411ESl1eg== Message-ID: <4D50645E8AA05747BD35357AF9E321E51FED327094@GVW1116EXC.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [VRRP] VRRP deployment in MPLS network network X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org Hi All, I have been working on the provisioning solution for MPLS VPN. I would like to add support for VRRP provisioning in MPLS VPN. Most of the docs that I have read shows the usage of VRRP on the CE side. However, I am not to sure about the usage of VRRP in PE side routers in MPLS VPN network. Can somebody guide how to use VRRP on PE routers in MPLS network or some pointers about it. Thanks for the help in advance. Deepak Saraswat _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Oct 30 23:33:09 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2A643A6918; Thu, 30 Oct 2008 23:33:09 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DF903A6A69 for ; Thu, 30 Oct 2008 23:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxdfhWztXIkQ for ; Thu, 30 Oct 2008 23:33:07 -0700 (PDT) Received: from ca-bay-exch-01.tropos.com (ca-bay-exch-01.troposnetworks.com [12.108.168.189]) by core3.amsl.com (Postfix) with ESMTP id 0266A3A6859 for ; Thu, 30 Oct 2008 23:33:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 23:33:03 -0700 Message-ID: In-Reply-To: <00d201c93ac5$a9051260$a318a8c0@corp.networkrobots.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [VRRP] VRRPv3 Implementation Report thread-index: Ack6xcQJ0j+psJk3TH+2hOxuHNOZsQAW7XZw From: "Mukesh Gupta" To: "don provan" , "Lin Tao" Cc: wangju@h3c.com, vrrp@ietf.org Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org [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:dprovan@bivio.net] Sent: Thursday, October 30, 2008 12:28 PM To: 'Lin Tao'; Mukesh Gupta Cc: vrrp@ietf.org; wangju@h3c.com 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 > -----Original Message----- > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org]On Behalf Of > Lin Tao > Sent: Tuesday, October 21, 2008 7:50 PM > To: don provan; 'Mukesh Gupta' > Cc: vrrp@ietf.org; wangju@h3c.com > Subject: Re: [VRRP] VRRPv3 Implementation Report > > > 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. > > ----- Original Message ----- > From: "don provan" > To: "'Lin Tao'" ; "'Mukesh Gupta'" > > Cc: ; > Sent: Tuesday, October 21, 2008 2:45 AM > Subject: RE: [VRRP] VRRPv3 Implementation Report > > > >> 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 > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Fri Oct 31 01:22:29 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E65F3A680E; Fri, 31 Oct 2008 01:22:29 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42533A680E for ; Fri, 31 Oct 2008 01:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRHQ48AdFyRV for ; Fri, 31 Oct 2008 01:22:27 -0700 (PDT) Received: from huawei-3com.com (unknown [60.191.123.56]) by core3.amsl.com (Postfix) with ESMTP id DF9AE3A6804 for ; Fri, 31 Oct 2008 01:22:25 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K9L00HF1GLBDU@h3cml02-in.huawei-3com.com> for vrrp@ietf.org; Fri, 31 Oct 2008 16:22:23 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0K9L00EEGGLBQA@h3cml02-in.huawei-3com.com> for vrrp@ietf.org; Fri, 31 Oct 2008 16:22:23 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.63]) by mailsecurity.h3c.com with ESMTP; Fri, 31 Oct 2008 16:19:33 +0800 Date: Fri, 31 Oct 2008 16:22:21 +0800 From: Lin Tao To: Mukesh Gupta , don provan Message-id: <006d01c93b31$cc670670$3f11990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal References: Cc: wangju@h3c.com, vrrp@ietf.org Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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" To: "don provan" ; "Lin Tao" Cc: ; Sent: Friday, October 31, 2008 2:33 PM Subject: RE: [VRRP] VRRPv3 Implementation Report [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:dprovan@bivio.net] Sent: Thursday, October 30, 2008 12:28 PM To: 'Lin Tao'; Mukesh Gupta Cc: vrrp@ietf.org; wangju@h3c.com 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 > -----Original Message----- > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org]On Behalf Of > Lin Tao > Sent: Tuesday, October 21, 2008 7:50 PM > To: don provan; 'Mukesh Gupta' > Cc: vrrp@ietf.org; wangju@h3c.com > Subject: Re: [VRRP] VRRPv3 Implementation Report > > > 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. > > ----- Original Message ----- > From: "don provan" > To: "'Lin Tao'" ; "'Mukesh Gupta'" > > Cc: ; > Sent: Tuesday, October 21, 2008 2:45 AM > Subject: RE: [VRRP] VRRPv3 Implementation Report > > > >> 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 > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Fri Oct 31 05:36:44 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115393A6987; Fri, 31 Oct 2008 05:36:44 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97D63A6987 for ; Fri, 31 Oct 2008 05:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOl+gOTNsYAe for ; Fri, 31 Oct 2008 05:36:42 -0700 (PDT) Received: from stimpy.bivio.net (stimpy.bivio.net [216.142.75.227]) by core3.amsl.com (Postfix) with ESMTP id 8668A3A67F6 for ; Fri, 31 Oct 2008 05:36:41 -0700 (PDT) Received: from dprovan1 ([192.168.24.163]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id m9UJSImS016229; Thu, 30 Oct 2008 12:28:20 -0700 From: "don provan" To: "'Lin Tao'" , "'Mukesh Gupta'" Date: Thu, 30 Oct 2008 12:28:16 -0700 Message-ID: <00d201c93ac5$a9051260$a318a8c0@corp.networkrobots.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933 In-Reply-To: <000b01c933f0$d9d9d870$1311990a@h3c.huawei3com.com> Importance: Normal Cc: wangju@h3c.com, vrrp@ietf.org Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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 > -----Original Message----- > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org]On Behalf Of > Lin Tao > Sent: Tuesday, October 21, 2008 7:50 PM > To: don provan; 'Mukesh Gupta' > Cc: vrrp@ietf.org; wangju@h3c.com > Subject: Re: [VRRP] VRRPv3 Implementation Report > > > 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. > > ----- Original Message ----- > From: "don provan" > To: "'Lin Tao'" ; "'Mukesh Gupta'" > > Cc: ; > Sent: Tuesday, October 21, 2008 2:45 AM > Subject: RE: [VRRP] VRRPv3 Implementation Report > > > >> 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 > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Fri Oct 31 12:18:27 2008 Return-Path: X-Original-To: vrrp-archive@megatron.ietf.org Delivered-To: ietfarch-vrrp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F89528C182; Fri, 31 Oct 2008 12:18:27 -0700 (PDT) X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0837C28C13E for ; Fri, 31 Oct 2008 12:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWE7eVJhKcn8 for ; Fri, 31 Oct 2008 12:18:26 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 9E48A28C23F for ; Fri, 31 Oct 2008 12:18:24 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so569667eyd.31 for ; Fri, 31 Oct 2008 12:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=QgZzn/i7M1jLtOpOgR6BKthXfo/fvflYTqfoset2nV4=; b=pYPhm1CgtPr7j6WzUd2Jea+sU9OvP7MRxK044EIydetoJKq7n/GclRera/atjPDn3P IGHcL+hs4JsQiNkB45DNDAxZSkX2tgjHAUYRwNSZMsHt766wE0ieCppIKRD7Ac0fCPL5 oL1Yzy8vbxsm8NRPVDceZBARe4S7so/bGD95E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=C/iFeL7TsjoxhPHpPLPO0dS2Koe6llUYvUQQa4vhlPi4i3zhCn/v0vlizAHcRZvHfy Rf43oMQFEA2LxRxgatorYUR3zrW6YieoVfJ5hh2xDbVMqEkE3AuXuDLsbVliovvcKeNp jL6YlvpSNWk0KjEY/QhSZyf7gZRPoBa39QDjY= Received: by 10.86.93.17 with SMTP id q17mr8538403fgb.8.1225480696693; Fri, 31 Oct 2008 12:18:16 -0700 (PDT) Received: by 10.86.62.1 with HTTP; Fri, 31 Oct 2008 12:18:16 -0700 (PDT) Message-ID: Date: Fri, 31 Oct 2008 12:18:16 -0700 From: "Peter Hunt" To: "Lin Tao" In-Reply-To: <006d01c93b31$cc670670$3f11990a@h3c.huawei3com.com> MIME-Version: 1.0 Content-Disposition: inline References: <006d01c93b31$cc670670$3f11990a@h3c.huawei3com.com> Cc: vrrp@ietf.org, wangju@h3c.com, don provan Subject: Re: [VRRP] VRRPv3 Implementation Report X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org 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 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www.ietf.org/mailman/listinfo/vrrp