Message

From vrrp-bounces@ietf.org Mon Jan 09 01:40:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evqhu-00037t-QB; Mon, 09 Jan 2006 01:40:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evqhs-00037o-Pv for vrrp@megatron.ietf.org; Mon, 09 Jan 2006 01:40:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20184 for ; Mon, 9 Jan 2006 01:39:21 -0500 (EST) Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EvqoJ-0002Ch-6k for vrrp@ietf.org; Mon, 09 Jan 2006 01:47:20 -0500 Received: (qmail 21834 invoked by uid 510); 9 Jan 2006 06:40:19 -0000 Date: 9 Jan 2006 06:40:19 -0000 Message-ID: <20060109064019.21833.qmail@webmail31.rediffmail.com> Received: from unknown (203.145.155.11) by rediffmail.com via HTTP; 09 jan 2006 06:40:19 -0000 MIME-Version: 1.0 From: "venki" To: vrrp@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [VRRP] VRRP Operation across subnets X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: venki List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1634856163==" Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org This is a multipart mime message --===============1634856163== Content-type: multipart/alternative; boundary="Next_1136788819---0-202.54.124.130-21817" This is a multipart mime message --Next_1136788819---0-202.54.124.130-21817 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =A0=0AHi,=0A=0A Is VRRP operation across subnets valid?=0A=0A RFC3768 do= es not discuss anything related to this. Kindly respond with any known refe= rences in this regard.=0A=0AThanks=0AVenki.. --Next_1136788819---0-202.54.124.130-21817 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A
=0AHi,
=0A
=0A Is VRRP operation across subnet= s valid?
=0A
=0A RFC3768 does not discuss anything related to t= his. Kindly respond with any known references in this regard.
=0A
=0A= Thanks
=0AVenki..=0A

=0A

=0A

=0A --Next_1136788819---0-202.54.124.130-21817-- --===============1634856163== 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://www1.ietf.org/mailman/listinfo/vrrp --===============1634856163==-- From vrrp-bounces@ietf.org Mon Jan 09 22:47:35 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwATv-0007Tc-Qm; Mon, 09 Jan 2006 22:47:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwATt-0007TU-1x for vrrp@megatron.ietf.org; Mon, 09 Jan 2006 22:47:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27899 for ; Mon, 9 Jan 2006 22:46:14 -0500 (EST) Received: from fed1rmmtao12.cox.net ([68.230.241.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwAaS-0001ma-GK for vrrp@ietf.org; Mon, 09 Jan 2006 22:54:24 -0500 Received: from ASDF ([68.7.100.32]) by fed1rmmtao12.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060110034444.FTKI17437.fed1rmmtao12.cox.net@ASDF>; Mon, 9 Jan 2006 22:44:44 -0500 From: "Davis, Jesse M" To: "'venki'" , Subject: RE: [VRRP] VRRP Operation across subnets Date: Mon, 9 Jan 2006 19:57:55 -0800 Message-ID: <008701c6159a$0d258f30$0e01a8c0@ASDF> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <20060109064019.21833.qmail@webmail31.rediffmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal X-Spam-Score: 0.7 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1383887750==" Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. --===============1383887750== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C61556.FF024F30" This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C61556.FF024F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Venki, =20 Since VRRP is designed as a Unicast first-hop gateway mechanism, I = don't see how it could function successfully across subnets. VRRP allows a = client to store a shared MAC address handled by one or more virtual routers. = Since a MAC address is only available locally on the same data-link network, receiving and storing a DMAC for a VRRP router on a different subnet = would not make communication using said DMAC possible. In practice I have = never seen any situation where a VRRP advertisement is learned across subnets. = =20 =20 Hope this helps, JD -----Original Message----- From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of venki Sent: Sunday, January 08, 2006 10:40 PM To: vrrp@ietf.org Subject: [VRRP] VRRP Operation across subnets Hi, Is VRRP operation across subnets valid? RFC3768 does not discuss anything related to this. Kindly respond with = any known references in this regard. Thanks Venki..=20 =20 =20 ------=_NextPart_000_0088_01C61556.FF024F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi=20 Venki,

Since VRRP is designed as a Unicast first-hop = gateway=20 mechanism, I don't see how it could function successfully across = subnets. VRRP=20 allows a client to store a shared MAC address handled by one or more = virtual=20 routers. Since a MAC address is only available locally on the same = data-link=20 network, receiving and storing a DMAC for a VRRP router on a different = subnet=20 would not make communication using said DMAC possible. In practice I = have never=20 seen any situation where a VRRP advertisement is learned across subnets. =

Hope=20 this helps,

-----Original Message-----
From:=20 vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of=20 venki
Sent: Sunday, January 08, 2006 10:40 = PM
To:=20 vrrp@ietf.org
Subject: [VRRP] VRRP Operation across=20 subnets

Hi,

Is VRRP operation across subnets=20 valid?

RFC3768 does not discuss anything related to = this. Kindly=20 respond with any known references in this = regard.

Thanks
Venki..=20

------=_NextPart_000_0088_01C61556.FF024F30-- --===============1383887750== 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://www1.ietf.org/mailman/listinfo/vrrp --===============1383887750==-- From vrrp-bounces@ietf.org Tue Jan 10 06:37:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHof-0001w7-Go; Tue, 10 Jan 2006 06:37:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwHod-0001w0-KG for vrrp@megatron.ietf.org; Tue, 10 Jan 2006 06:37:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23609 for ; Tue, 10 Jan 2006 06:36:08 -0500 (EST) Received: from [202.54.124.145] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwHvJ-0005oB-W3 for vrrp@ietf.org; Tue, 10 Jan 2006 06:44:23 -0500 Received: (qmail 13310 invoked by uid 510); 10 Jan 2006 11:36:58 -0000 Date: 10 Jan 2006 11:36:58 -0000 Message-ID: <20060110113658.13309.qmail@webmail30.rediffmail.com> Received: from unknown (203.145.155.11) by rediffmail.com via HTTP; 10 jan 2006 11:36:58 -0000 MIME-Version: 1.0 From: "venki" To: "Davis,Jesse M" Subject: Re: RE: [VRRP] VRRP Operation across subnets X-Spam-Score: 1.2 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: vrrp@ietf.org X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: venki List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1151738790==" Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org This is a multipart mime message --===============1151738790== Content-type: multipart/alternative; boundary="Next_1136893018---0-202.54.124.145-13267" This is a multipart mime message --Next_1136893018---0-202.54.124.145-13267 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Extactly this is what I expected.. It clarifies my query..=0A=0AThanks JD.= .=0A=0A - Venki.=0A=0A=0AOn Tue, 10 Jan 2006 Davis,Jesse M wrote :=0A>Hi Ve= nki,=0A>=0A> Since VRRP is designed as a Unicast first-hop gateway mech= anism, I don't=0A>see how it could function successfully across subnets. VR= RP allows a client=0A>to store a shared MAC address handled by one or more = virtual routers. Since=0A>a MAC address is only available locally on the sa= me data-link network,=0A>receiving and storing a DMAC for a VRRP router on = a different subnet would=0A>not make communication using said DMAC possible= . In practice I have never=0A>seen any situation where a VRRP advertisement= is learned across subnets.=0A>=0A>=0A>Hope this helps,=0A>JD=0A>=0A>-----O= riginal Message-----=0A> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@i= etf.org] On Behalf Of=0A>venki=0A>Sent: Sunday, January 08, 2006 10:40 PM= =0A>To: vrrp@ietf.org=0A>Subject: [VRRP] VRRP Operation across subnets=0A>= =0A>=0A>=0A>=0A>Hi,=0A>=0A> Is VRRP operation across subnets valid?=0A>= =0A> RFC3768 does not discuss anything related to this. Kindly respond wi= th any=0A>known references in this regard.=0A>=0A>Thanks=0A>Venki..=0A>=0A>= =0A>=0A>=0A>ture-home.htm/1507191490@Middle5?PARTNER=3D3>=0A>=0A --Next_1136893018---0-202.54.124.145-13267 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AExtactly this is what I expected.. It clarifies my query..
= =0A
=0AThanks JD..
=0A
=0A - Venki.
=0A
=0A
=0AOn Tue, 10= Jan 2006 Davis,Jesse M wrote :
=0A>Hi Venki,
=0A>
=0A>&n= bsp; Since VRRP is designed as a Unicast first-hop gateway mechanis= m, I don't
=0A>see how it could function successfully across subnets.= VRRP allows a client
=0A>to store a shared MAC address handled by on= e or more virtual routers. Since
=0A>a MAC address is only available = locally on the same data-link network,
=0A>receiving and storing a DM= AC for a VRRP router on a different subnet would
=0A>not make communi= cation using said DMAC possible. In practice I have never
=0A>seen an= y situation where a VRRP advertisement is learned across subnets.
=0A>= ;
=0A>
=0A>Hope this helps,
=0A>JD
=0A>
=0A>-= ----Original Message-----
=0A> From: vrrp-bounces@ietf.org [mailto:vr= rp-bounces@ietf.org] On Behalf Of
=0A>venki
=0A>Sent: Sunday, J= anuary 08, 2006 10:40 PM
=0A>To: vrrp@ietf.org
=0A>Subject: [VR= RP] VRRP Operation across subnets
=0A>
=0A>
=0A>
=0A&g= t;
=0A>Hi,
=0A>
=0A> Is VRRP operation across subn= ets valid?
=0A>
=0A> RFC3768 does not discuss anything r= elated to this. Kindly respond with any
=0A>known references in this = regard.
=0A>
=0A>Thanks
=0A>Venki..
=0A>
=0A>=
=0A>
=0A>
=0A><http://adworks.rediff.com/cgi-bin/AdWo= rks/sigclick.cgi/www.rediff.com/signa
=0A>ture-home.htm/1507191490@Mi= ddle5?PARTNER=3D3>
=0A>
=0A=0A

=0A

=0A

=0A --Next_1136893018---0-202.54.124.145-13267-- --===============1151738790== 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://www1.ietf.org/mailman/listinfo/vrrp --===============1151738790==-- From vrrp-bounces@ietf.org Thu Jan 19 09:56:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbCk-0000d5-1g; Thu, 19 Jan 2006 09:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbCi-0000bU-1Y for vrrp@megatron.ietf.org; Thu, 19 Jan 2006 09:56:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28689 for ; Thu, 19 Jan 2006 09:54:33 -0500 (EST) Received: from gate15-norfolk.nmci.navy.mil ([138.162.5.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbLD-0001x6-8Z for vrrp@ietf.org; Thu, 19 Jan 2006 10:04:50 -0500 Received: from naeanrfkms04.nmci.navy.mil by gate15-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 19 Jan 2006 14:55:51 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Thu, 19 Jan 2006 14:55:40 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 19 Jan 2006 08:55:36 -0600 Message-ID: <1929B8C5B318524495727D8A241DAFB20147FD8E@NAEAMILLEX03VA.nadsusea.nads.navy.mil> Thread-Topic: Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt Thread-Index: AcYdCGcuQDCMmqSqQgSVmxBF060F2A== From: "Hott, Robert W CIV B35-Branch" To: X-OriginalArrivalTime: 19 Jan 2006 14:55:36.0859 (UTC) FILETIME=[6802B6B0:01C61D08] X-Spam-Score: 0.8 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1951187115==" Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. --===============1951187115== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61D08.6781AA1E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C61D08.6781AA1E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, This is just a reminder that the draft for providing sub-second timers = for VRRP for IPv4 was posted. I would appreciate any comments that you = might have on this draft. Abstract: The router survivability capability provided by the Virtual = Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the requirements = for many LAN environments. There are, however, LAN environments that = have sub-second failover requirements and thus a need for finer = granularity of the VRRP timers. This draft proposes extensions to VRRPv4 = [RFC 3768] for specifying sub-second Advertisement Intervals. A new = message type is introduced which permits the timer granularity for the = Advertisement Interval to be specified. In addition, a new field is = introduced permitting the specification of the number of missed = ADVERTISEMENTs before a Virtual Router Master is declared down.=20 Bob Hott=20 Robert (Bob) W. Hott NSWC-DD Code B35, Bldg. 1500A/122A 17320 Dahlgren Road Dahlgren, VA 22448-5100 540-653-1497 (W) 540-653-8673 (FAX) robert.hott@navy.mil (E-mail) ------_=_NextPart_001_01C61D08.6781AA1E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt

All,
This is just a reminder that the draft for providing = sub-second timers for VRRP for IPv4 was posted. I would appreciate any = comments that you might have on this draft.

Abstract: The router survivability = capability provided by the Virtual Router Redundancy Protocol for IPv4 = (VRRPv4) satisfies the requirements for many LAN environments. There = are, however, LAN environments that have sub-second failover = requirements and thus a need for finer granularity of the VRRP timers. = This draft proposes extensions to VRRPv4 [RFC 3768] for specifying = sub-second Advertisement Intervals. A new message type is introduced = which permits the timer granularity for the Advertisement Interval to be = specified. In addition, a new field is introduced permitting the = specification of the number of missed ADVERTISEMENTs before a Virtual = Router Master is declared down.

Bob Hott

Robert (Bob) W. = Hott
NSWC-DD
Code B35, Bldg. = 1500A/122A
17320 Dahlgren = Road
Dahlgren, VA = 22448-5100
540-653-1497 = (W)
540-653-8673 = (FAX)
robert.hott@navy.mil (E-mail)

------_=_NextPart_001_01C61D08.6781AA1E-- --===============1951187115== 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://www1.ietf.org/mailman/listinfo/vrrp --===============1951187115==-- From vrrp-bounces@ietf.org Tue Jan 24 19:43:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1YlK-0005WL-Fl; Tue, 24 Jan 2006 19:43:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1YlJ-0005WB-78 for vrrp@megatron.ietf.org; Tue, 24 Jan 2006 19:43:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21531 for ; Tue, 24 Jan 2006 19:42:18 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1Yuv-0000Tj-Sl for vrrp@ietf.org; Tue, 24 Jan 2006 19:53:47 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k0P0stjU023181 for ; Tue, 24 Jan 2006 17:54:55 -0700 (MST) Received: from de01exm60.ds.mot.com (de01exm60.am.mot.com [10.176.8.105]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k0P10wHE006254 for ; Tue, 24 Jan 2006 19:00:59 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt Date: Tue, 24 Jan 2006 19:43:35 -0500 Message-ID: Thread-Topic: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt Thread-Index: AcYdCGcuQDCMmqSqQgSVmxBF060F2AEP07/A From: "Mathur Sonum-CSM109" To: "Hott, Robert W CIV B35-Branch" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org Few comments on the draft If the VR_Mode =3D 1, then: o Send an ADVERTISEMENT o Set the Adver_Timer to Advertisement_Interval else: o Send a FAST ADVERTISEMENT o Set the Adver_2_Timer to Advertisement_Interval =20 For initialization, when VR_Mode =3D 1, then why are Fast Advts. not = sent. VR_Mode =3D 1 indicates that both types of VRRP implementations are present. Then, to satisfy the backup routers with newer implementation, Fast Advts. are needed. If not, they will declare Master Down and will try to become Master causing more than one Masters to be active. =20 - If the Adver_2_Timer fires, then: If the VR_Mode is 1 or if the VR_Type is 2, then: o Send a FAST ADVERTISEMENT o Reset the Adver_2_Timer to VR_Adver_Interval =20 When Adver_2_Timer fires, and VR_Type configured on the local router is 2, then local router should send a Fast Advt. Why do we need a check for VR_Mode =3D=3D 1 at all ? In my opinion, the only check for sending Fast Advt should be VR_Type =3D=3D 2. Please clarify. =20 I would like to suggest removal of parameter 'VR_Mode'. If there is a situation of new implementation inter operating with older one, we can live with ignore and log. Although 'VR_Mode' takes care of this issue, but implementation would be relatively simpler if we don't consider the heterogeneous environment. This is just my opinion, if this topic is still open for discussion. -- Sonum=20 ________________________________ From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Hott, Robert W CIV B35-Branch Sent: Thursday, January 19, 2006 6:56 AM To: vrrp@ietf.org Subject: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt =09 =09 All,=20 This is just a reminder that the draft for providing sub-second timers for VRRP for IPv4 was posted. I would appreciate any comments that you might have on this draft. Abstract: The router survivability capability provided by the Virtual Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the requirements for many LAN environments. There are, however, LAN environments that have sub-second failover requirements and thus a need for finer granularity of the VRRP timers. This draft proposes extensions to VRRPv4 [RFC 3768] for specifying sub-second Advertisement Intervals. A new message type is introduced which permits the timer granularity for the Advertisement Interval to be specified. In addition, a new field is introduced permitting the specification of the number of missed ADVERTISEMENTs before a Virtual Router Master is declared down.=20 Bob Hott=20 Robert (Bob) W. Hott=20 NSWC-DD=20 Code B35, Bldg. 1500A/122A=20 17320 Dahlgren Road=20 Dahlgren, VA 22448-5100=20 540-653-1497 (W)=20 540-653-8673 (FAX)=20 robert.hott@navy.mil (E-mail)=20 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Jan 26 08:29:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27C8-00025n-Sj; Thu, 26 Jan 2006 08:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F27C8-00025Y-1X for vrrp@megatron.ietf.org; Thu, 26 Jan 2006 08:29:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13779 for ; Thu, 26 Jan 2006 08:28:16 -0500 (EST) Received: from gate14-norfolk.nmci.navy.mil ([138.162.5.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F27M5-0003jY-JB for vrrp@ietf.org; Thu, 26 Jan 2006 08:40:05 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate14-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with ESMTP; Thu, 26 Jan 2006 13:29:46 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw14c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Thu, 26 Jan 2006 13:29:45 +0000 Received: (private information removed) Received: (private information removed) Received: (private information removed) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt Date: Thu, 26 Jan 2006 07:29:34 -0600 Message-ID: <1929B8C5B318524495727D8A241DAFB20147FD94@NAEAMILLEX03VA.nadsusea.nads.navy.mil> Thread-Topic: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt Thread-Index: AcYdCGcuQDCMmqSqQgSVmxBF060F2AEP07/AAEyOUkA= From: "Hott, Robert W CIV B35-Branch" To: "Mathur Sonum-CSM109" , X-OriginalArrivalTime: 26 Jan 2006 13:29:34.0404 (UTC) FILETIME=[8BD6D840:01C6227C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org Sonum, Thank you for your comments on the draft. I have included my response = to your comments in-line. Bob Hott -----Original Message----- From: Mathur Sonum-CSM109 [mailto:sonum@motorola.com] Sent: Tuesday, January 24, 2006 19:44 To: Hott, Robert W CIV B35-Branch; vrrp@ietf.org Subject: RE: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt Few comments on the draft If the VR_Mode =3D 1, then: o Send an ADVERTISEMENT o Set the Adver_Timer to Advertisement_Interval else: o Send a FAST ADVERTISEMENT o Set the Adver_2_Timer to Advertisement_Interval =20 For initialization, when VR_Mode =3D 1, then why are Fast Advts. not = sent. VR_Mode =3D 1 indicates that both types of VRRP implementations are present. Then, to satisfy the backup routers with newer implementation, Fast Advts. are needed. If not, they will declare Master Down and will try to become Master causing more than one Masters to be active. =20 This is a good observation. You caught an error in the draft. = The "VR_Mode" in the IF statement, above and on page 8 in the draft, = should have been "VR_Type"! During initialization, the VRRP router, when = it is the Master, should send out the type of advertisement that it is = configured to send. Thank you for catching this error. - If the Adver_2_Timer fires, then: If the VR_Mode is 1 or if the VR_Type is 2, then: o Send a FAST ADVERTISEMENT o Reset the Adver_2_Timer to VR_Adver_Interval =20 When Adver_2_Timer fires, and VR_Type configured on the local router is 2, then local router should send a Fast Advt. Why do we need a check for VR_Mode =3D=3D 1 at all ? In my opinion, the only check for sending Fast Advt should be VR_Type =3D=3D 2. Please clarify. =20 For the above comment, this test is on pages 12 and 13 of the = draft. I believe that we should have both tests following the firing of = the Adver_2_Timer. It is possible that the VRRP router, although running = this new implementation, would be configured to run as an older version = (possibly to use authentication). Thus it should check to see if the = VR_Mode is 1 (heterogeneous). I would like to suggest removal of parameter 'VR_Mode'. If there is a situation of new implementation inter operating with older one, we can live with ignore and log. Although 'VR_Mode' takes care of this issue, but implementation would be relatively simpler if we don't consider the heterogeneous environment. This is just my opinion, if this topic is still open for discussion. If you are in an environment in which a new implementation is = interoperating with an older implementation, if the new implementation = only logs and ignores the older implementation, then you run the risk of = having two masters. If the new implementation is supposed to be the = Master, it must force the older implementation to transition to a backup = state. The older implementation will ignore the new FAST ADVERTISEMENTS, = thus it will want to transition to Master, unless it sees an = ADVERTISEMENT from the new implementation Master. For this reason, I = don't think you want to ONLY ignore and log. -- Sonum=20 ________________________________ From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Hott, Robert W CIV B35-Branch Sent: Thursday, January 19, 2006 6:56 AM To: vrrp@ietf.org Subject: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt =09 =09 All,=20 This is just a reminder that the draft for providing sub-second timers for VRRP for IPv4 was posted. I would appreciate any comments that you might have on this draft. Abstract: The router survivability capability provided by the Virtual Router Redundancy Protocol for IPv4 (VRRPv4) satisfies the requirements for many LAN environments. There are, however, LAN environments that have sub-second failover requirements and thus a need for finer granularity of the VRRP timers. This draft proposes extensions to VRRPv4 [RFC 3768] for specifying sub-second Advertisement Intervals. A new message type is introduced which permits the timer granularity for the Advertisement Interval to be specified. In addition, a new field is introduced permitting the specification of the number of missed ADVERTISEMENTs before a Virtual Router Master is declared down.=20 Bob Hott=20 Robert (Bob) W. Hott=20 NSWC-DD=20 Code B35, Bldg. 1500A/122A=20 17320 Dahlgren Road=20 Dahlgren, VA 22448-5100=20 540-653-1497 (W)=20 540-653-8673 (FAX)=20 robert.hott@navy.mil (E-mail)=20 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Jan 26 20:14:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ICU-0007E3-48; Thu, 26 Jan 2006 20:14:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2ICR-0007Bm-MN for vrrp@megatron.ietf.org; Thu, 26 Jan 2006 20:14:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23342 for ; Thu, 26 Jan 2006 20:13:19 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F2IMT-0001BJ-1H for vrrp@ietf.org; Thu, 26 Jan 2006 20:25:15 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k0R1OmsU025405 for ; Thu, 26 Jan 2006 18:24:48 -0700 (MST) Received: from de01exm60.ds.mot.com (de01exm60.am.mot.com [10.176.8.105]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k0R1O2LE029554 for ; Thu, 26 Jan 2006 19:24:03 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt Date: Thu, 26 Jan 2006 20:14:40 -0500 Message-ID: Thread-Topic: [VRRP] Reminder of posting of draft-ietf-vrrp-ipv4-timers-01.txt Thread-Index: AcYdCGcuQDCMmqSqQgSVmxBF060F2AEP07/AAEyOUkAAGKgr8A== From: "Mathur Sonum-CSM109" To: "Hott, Robert W CIV B35-Branch" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: vrrp-bounces@ietf.org Errors-To: vrrp-bounces@ietf.org Comments inline > - If the Adver_2_Timer fires, then: > If the VR_Mode is 1 > or > if the VR_Type is 2, then: > o Send a FAST ADVERTISEMENT > o Reset the Adver_2_Timer to VR_Adver_Interval > =20 > When Adver_2_Timer fires, and VR_Type configured on the local=20 > router is 2, then local router should send a Fast Advt. Why=20 > do we need a check for VR_Mode =3D=3D 1 at all ? In my opinion,=20 > the only check for sending Fast Advt should be VR_Type =3D=3D 2.=20 > Please clarify. > =20 > For the above comment, this test is on pages 12=20 > and 13 of the draft. I believe that we should have both tests=20 > following the firing of the Adver_2_Timer. It is possible=20 > that the VRRP router, although running this new=20 > implementation, would be configured to run as an older=20 > version (possibly to use authentication). Thus it should=20 > check to see if the VR_Mode is 1 (heterogeneous).=20 The 'or' condition is ok for Adver_Timer and is not needed for Adver_2_Timer. We need to send regular Advt. when we are configured as old version (VR_Type =3D 1) or when environment is heterogeneous = (VR_Mode =3D 1). For Fast Advt., we need to send it only when we are configured = as new version (VR_Type =3D 2). The truth table can look something like = this Type Mode =09 1 0 Advt only 1 1 Advt only 2 0 Fast Advt only 2 1 Advt & Fast Advt If a router (with new implementation) is configured to run as older version (VR_Type =3D 1), then why do we want to send Fast Advt. at all from this router ? We should never have the case of 'Adver_2_Timer' firing at all when VR_Type =3D 1. Once you make the correction of changing VR_Mode to VR_Type on Page 8 for initialization, if VR_Type =3D 1, then we will set only Adver_Timer and won't touch Adver_2_Timer. Correct me if I am not understanding this right and correct the table accordingly. Also, in initialization, if VR_Mode =3D=3D 1 and VR_Type =3D=3D 2, then = we want to send and trigger timers for both - Advt. and Fast Advt. So we will need a check for VR_Mode in initialization also. To avoid confusion, it might be a good idea to rename 'VR_Mode' or 'VR_Type' (or both). They can be renamed to something like VR_Conf (for type) and VR_Envt (for mode) - just a suggestion. > If you are in an environment in which a new=20 > implementation is interoperating with an older=20 > implementation, if the new implementation only logs and=20 > ignores the older implementation, then you run the risk of=20 > having two masters. If the new implementation is supposed to=20 > be the Master, it must force the older implementation to=20 > transition to a backup state. The older implementation will=20 > ignore the new FAST ADVERTISEMENTS, thus it will want to=20 > transition to Master, unless it sees an ADVERTISEMENT from=20 > the new implementation Master. For this reason, I don't think=20 > you want to ONLY ignore and log. Agreed. We will need this if we want to make it backward compatible. -- Sonum > -----Original Message----- > From: Hott, Robert W CIV B35-Branch [mailto:robert.hott@navy.mil]=20 > Sent: Thursday, January 26, 2006 5:30 AM > To: Mathur Sonum-CSM109; vrrp@ietf.org > Subject: RE: [VRRP] Reminder of posting of=20 > draft-ietf-vrrp-ipv4-timers-01.txt >=20 > Sonum, > Thank you for your comments on the draft. I have=20 > included my response to your comments in-line. >=20 > Bob Hott >=20 > -----Original Message----- > From: Mathur Sonum-CSM109 [mailto:sonum@motorola.com] > Sent: Tuesday, January 24, 2006 19:44 > To: Hott, Robert W CIV B35-Branch; vrrp@ietf.org > Subject: RE: [VRRP] Reminder of posting of=20 > draft-ietf-vrrp-ipv4-timers-01.txt >=20 >=20 >=20 > Few comments on the draft >=20 > If the VR_Mode =3D 1, then: > o Send an ADVERTISEMENT > o Set the Adver_Timer to Advertisement_Interval > else: > o Send a FAST ADVERTISEMENT > o Set the Adver_2_Timer to Advertisement_Interval > =20 > For initialization, when VR_Mode =3D 1, then why are Fast=20 > Advts. not sent. > VR_Mode =3D 1 indicates that both types of VRRP implementations=20 > are present. Then, to satisfy the backup routers with newer=20 > implementation, Fast Advts. are needed. If not, they will=20 > declare Master Down and will try to become Master causing=20 > more than one Masters to be active. > =20 > This is a good observation. You caught an error in=20 > the draft. The "VR_Mode" in the IF statement, above and on=20 > page 8 in the draft, should have been "VR_Type"! During=20 > initialization, the VRRP router, when it is the Master,=20 > should send out the type of advertisement that it is=20 > configured to send. Thank you for catching this error. >=20 >=20 >=20 > - If the Adver_2_Timer fires, then: > If the VR_Mode is 1 > or > if the VR_Type is 2, then: > o Send a FAST ADVERTISEMENT > o Reset the Adver_2_Timer to VR_Adver_Interval > =20 > When Adver_2_Timer fires, and VR_Type configured on the local=20 > router is 2, then local router should send a Fast Advt. Why=20 > do we need a check for VR_Mode =3D=3D 1 at all ? In my opinion,=20 > the only check for sending Fast Advt should be VR_Type =3D=3D 2.=20 > Please clarify. > =20 > For the above comment, this test is on pages 12=20 > and 13 of the draft. I believe that we should have both tests=20 > following the firing of the Adver_2_Timer. It is possible=20 > that the VRRP router, although running this new=20 > implementation, would be configured to run as an older=20 > version (possibly to use authentication). Thus it should=20 > check to see if the VR_Mode is 1 (heterogeneous). >=20 >=20 > I would like to suggest removal of parameter 'VR_Mode'. If=20 > there is a situation of new implementation inter operating=20 > with older one, we can live with ignore and log. Although=20 > 'VR_Mode' takes care of this issue, but implementation would=20 > be relatively simpler if we don't consider the heterogeneous=20 > environment. This is just my opinion, if this topic is still=20 > open for discussion. >=20 > If you are in an environment in which a new=20 > implementation is interoperating with an older=20 > implementation, if the new implementation only logs and=20 > ignores the older implementation, then you run the risk of=20 > having two masters. If the new implementation is supposed to=20 > be the Master, it must force the older implementation to=20 > transition to a backup state. The older implementation will=20 > ignore the new FAST ADVERTISEMENTS, thus it will want to=20 > transition to Master, unless it sees an ADVERTISEMENT from=20 > the new implementation Master. For this reason, I don't think=20 > you want to ONLY ignore and log. >=20 > -- > Sonum=20 >=20 >=20 > ________________________________ >=20 > From: vrrp-bounces@ietf.org=20 > [mailto:vrrp-bounces@ietf.org] On Behalf Of Hott, Robert W=20 > CIV B35-Branch > Sent: Thursday, January 19, 2006 6:56 AM > To: vrrp@ietf.org > Subject: [VRRP] Reminder of posting of > draft-ietf-vrrp-ipv4-timers-01.txt > =09 > =09 >=20 > All,=20 > This is just a reminder that the draft for=20 > providing sub-second timers for VRRP for IPv4 was posted. I=20 > would appreciate any comments that you might have on this draft. >=20 > Abstract: The router survivability capability provided=20 > by the Virtual Router Redundancy Protocol for IPv4 (VRRPv4)=20 > satisfies the requirements for many LAN environments. There=20 > are, however, LAN environments that have sub-second failover=20 > requirements and thus a need for finer granularity of the=20 > VRRP timers. This draft proposes extensions to VRRPv4 [RFC=20 > 3768] for specifying sub-second Advertisement Intervals. > A new message type is introduced which permits the timer=20 > granularity for the Advertisement Interval to be specified.=20 > In addition, a new field is introduced permitting the=20 > specification of the number of missed ADVERTISEMENTs before a=20 > Virtual Router Master is declared down.=20 >=20 > Bob Hott=20 >=20 > Robert (Bob) W. Hott=20 > NSWC-DD=20 > Code B35, Bldg. 1500A/122A=20 > 17320 Dahlgren Road=20 > Dahlgren, VA 22448-5100=20 > 540-653-1497 (W)=20 > 540-653-8673 (FAX)=20 > robert.hott@navy.mil (E-mail)=20 >=20 _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp