From vrrp-bounces@ietf.org Thu Mar 09 13:31:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPvF-0000jC-9h; Thu, 09 Mar 2006 13:31:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHPvE-0000iY-Fr for vrrp@ietf.org; Thu, 09 Mar 2006 13:31:36 -0500 Received: from gate12-norfolk.nmci.navy.mil ([138.162.5.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHPvC-000340-VW for vrrp@ietf.org; Thu, 09 Mar 2006 13:31:36 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate12-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with ESMTP; Thu, 9 Mar 2006 18:31:33 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Wed, 8 Mar 2006 10:13:55 +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, 9 Mar 2006 12:31:03 -0600 Message-ID: <1929B8C5B318524495727D8A241DAFB20362951F@NAEAMILLEX03VA.nadsusea.nads.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Latest update to draft-ietf-vrrp-ipv4-timers Thread-Index: AcZDp56ISYBSosBDR8G0n8qlugK0XQ== From: "Hott, Robert W CIV B35-Branch" To: X-OriginalArrivalTime: 09 Mar 2006 18:31:03.0710 (UTC) FILETIME=[9F4163E0:01C643A7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: "Odonoghue, Karen F CIV B35-Branch" Subject: [VRRP] Latest update to draft-ietf-vrrp-ipv4-timers 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="===============1454894826==" Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. --===============1454894826== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C643A7.9EFEE98C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C643A7.9EFEE98C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, I have made some minor editorial changes and one logic error change in = the Initialize state (thank you Sonum) in = draft-ietf-vrrp-ipv4-timers-01.txt I was late in posting the updated draft so it will not be posted in the = drafts location until after the upcoming IETF meeting. For this reason, = the draft was placed on the link, below, by Brian Haberman. Please take = a look at the draft and provide any and all comments you might have. = Karen O'Donoghue was hoping to discuss this draft and the way forward at = the upcoming IETF. Thank you! Bob Hott http://www.innovationslab.net/~brian/drafts/draft-ietf-vrrp-ipv4-timers-0= 2.txt 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_01C643A7.9EFEE98C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Latest update to draft-ietf-vrrp-ipv4-timers

All,
        I have made some minor editorial changes and one logic error = change in the Initialize state (thank you Sonum) in = draft-ietf-vrrp-ipv4-timers-01.txt

        I was late in posting the updated draft so it will not be posted = in the drafts location until after the upcoming IETF meeting. For this = reason, the draft was placed on the link, below, by Brian Haberman. = Please take a look at the draft and provide any and all comments you = might have. Karen O'Donoghue was hoping to discuss this draft and the = way forward at the upcoming IETF. Thank you!

Bob Hott

http://www.innovationslab.net/~brian/drafts/draft-ietf-vrr= p-ipv4-timers-02.txt


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_01C643A7.9EFEE98C-- --===============1454894826== 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 --===============1454894826==-- From vrrp-bounces@ietf.org Fri Mar 17 16:50:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMpt-0007qs-0l; Fri, 17 Mar 2006 16:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKMpr-0007qn-Vk for vrrp@ietf.org; Fri, 17 Mar 2006 16:50:15 -0500 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKMpq-0006dB-I4 for vrrp@ietf.org; Fri, 17 Mar 2006 16:50:15 -0500 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IWA0092PKNPPF10@dps.sfvic.sunlabs.com> for vrrp@ietf.org; Fri, 17 Mar 2006 13:50:13 -0800 (PST) Received: from sun.com ([129.150.26.73]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IWA00EKPKNM2400@mail.sunlabs.com> for vrrp@ietf.org; Fri, 17 Mar 2006 13:50:11 -0800 (PST) Date: Fri, 17 Mar 2006 13:50:10 -0800 From: Radia Perlman To: vrrp@ietf.org Message-id: <441B2F12.3080809@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [VRRP] Security considerations...SEND interaction....IESG "discuss" item 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: , Errors-To: vrrp-bounces@ietf.org I guess I'll put on my security advisor hat and take off my cochair hat for this thread. Sam Hartman brought up a good point, which is how might VRRP interact with SEND. (secure neighbor discovery). The basic idea of SEND (from my memory) is that with IPv6 addresses, a node can select the bottom 8 bytes of its address to be a hash of a public key, and then sign ND advertisements using the private key. So, one way I could imagine SEND impacting VRRP is that the routers would all have to know the private key associated with the shared IP address, so that they could then do the ND advertisements if they took over as master. Sam specifically asked though whether there might actually be some use for authentication of VRRP messages in the SEND case. And that's a good point. Otherwise, someone could prevent one of the real guys from getting elected, impersonating a VRRP router in the election, whereas SEND would have prevented them from answering ND queries. So it is possible in that case that if neighbor discovery is being armored, that VRRP should be similarly armored. I haven't thought about this a lot, but my inclination would be to have, in that case, the VRRP message signed with the same mechanism, and with the same private key, as the IPv6 address key. Is there anyone else who wants to think about this? Radia _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Wed Mar 22 18:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCKn-0005N1-Lg; Wed, 22 Mar 2006 18:01:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCKm-0005Mw-IB for vrrp@ietf.org; Wed, 22 Mar 2006 18:01:44 -0500 Received: from postal1.ind.alcatel.com ([208.8.0.237] helo=ind.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMCKm-0007Br-3x for vrrp@ietf.org; Wed, 22 Mar 2006 18:01:44 -0500 Received: from mailhub1.ind.alcatel.com (mailhub1.ind.alcatel.com [198.206.181.170]) by ind.alcatel.com (8.12.9/8.12.9/(postal1 2.1 [OUT])) with ESMTP id k2MN1gAP012165; Wed, 22 Mar 2006 15:01:42 -0800 (PST) X-InterScan: Passed Received: from mailhub1.ind.alcatel.com (localhost [127.0.0.1]) by mailhub1.ind.alcatel.com (8.12.10/8.12.10/(mailhub1 4.1.4 [HUB1])) with ESMTP id k2MN1fBx013615; Wed, 22 Mar 2006 15:01:42 -0800 (PST) Received: from sbates ([128.251.40.224]) by mailhub1.ind.alcatel.com (MailFrontier 4.1.1.5579) with ESMTP; Wed, 22 Mar 2006 15:01:42 -0800 From: "Steve Bates" To: "'Hott, Robert W CIV B35-Branch'" , Subject: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Date: Wed, 22 Mar 2006 16:04:18 -0700 Message-ID: <002c01c64e04$f3751490$e028fb80@sbates> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mlf-Threat: nothreat X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: , Errors-To: vrrp-bounces@ietf.org Hi Bob, I've posted these comments before but I'll rephrase them based on the 02 draft. 1) Back in early December there was a flurry of comments about = mismatched advertisement intervals causing multiple masters. The consensus seemed = to be that virtual routers of a lower priority would ignore a mismatch if = the higher priority interval was less than their configured interval and = make the higher priority interval their own operational value when it was = greater than their configured interval. I was under the impression, based on Radia's response to your original December 2nd post, that this would be reflected in the draft. Other than the omission of the phrase "the = receiver MUST discard the packet" in the final paragraph of section 4.1 I don't = see anything about this. =20 2) This may become a greater issue with the addition of advertising = interval granularity. It's conceivable that one implementation might not be able = to support as fine(?) a granularity as another, while both are type 2 = virtual routers. For example, suppose a higher priority virtual router A is configured with adver_cnt =3D 3, aig =3D 1, and adver_int =3D 1, while a = lower priority virtual router B is configured with adver_cnt =3D 3, aig =3D 2, = and adver_int =3D 1. Virtual router B MUST accept virtual router A's values = to avoid flapping - unless it discards the FAST ADVERTISEMENT and creates a = two master situation. Conversely, if the priorities are reversed B's values = are useless to A if A is incapable of supporting the finer granularity but = at least A will maintain it's backup state. Am I mistaken? 3) The two bit granularity field seems a bit shortsighted. A) There are some RTOSes where a "tick" is defined as 1/60th of a second. This makes achieving centisecond granularity difficult. A decisecond value would = be nice. B) But if we do that we've used up all the values in the field. = Ten years from now we'll be on terabit networks and someone may want = microsecond granularity. Another bit might be a good idea. 4) I don't dispute the desirability of a configurable advertisement = count but I'm not sure we gain much passing it in the advertisement. 5) For the VRRPv3 packet there are only 4 bits available since the advertisement interval uses 12. Do you have an idea how to migrate this draft to the IPv6 case? Steve Bates _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Mar 23 04:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMMGl-0000xh-DU; Thu, 23 Mar 2006 04:38:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMMGj-0000xc-G4 for vrrp@ietf.org; Thu, 23 Mar 2006 04:38:14 -0500 Received: from 33.106-14-84.ripe.coltfrance.com ([84.14.106.33] helo=proxy.6wind.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMMGi-0000qB-20 for vrrp@ietf.org; Thu, 23 Mar 2006 04:38:13 -0500 Received: from [10.16.0.239] (unknown [10.16.0.239]) by proxy.6wind.com (Postfix) with ESMTP id 54709525F8A; Thu, 23 Mar 2006 10:38:10 +0100 (CET) Message-ID: <44226C84.80101@6wind.com> Date: Thu, 23 Mar 2006 10:38:12 +0100 From: Vincent Jardin Organization: http://www.6WIND.com/ User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vrrp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [VRRP] Two MAC addresses for a same IP Primary address 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: , Errors-To: vrrp-bounces@ietf.org Hi all, According to the RFC3768, when a multicast VRRP packet is sent, the source IP address must be the *Primary IP Address* (section 5.2.1) and the source MAC address must be the *Virtual Router MAC Address*. Moreover, the source MAC address of the the ICMP, TCP, ARP packets related to the *IP Address Owner*, must (of course) be the *Virtual Router MAC Address*. Two routers running VRRP should have 2 differents *Primary IP Address*, and (of course) the same *IP Address Owner*. So, if from a host, which is on the same Ethernet network, I send an ICMP echo request to: - the *Primary IP Address*, which source MAC address should the ICMP echo reply use ? According to me, it must NOT be the *Virtual Router MAC Address*. - the *IP Address Owner*, which source MAC address should the ICMP echo reply use ? According to me, it must be the *Virtual Router MAC Address*. So it means that for any packets, when the source IP address is the *Primary IP Address*, the source MAC address could be any MAC address of the NIC; but when it is a VRRP Multicast packet to 224.0.0.18, the source MAC address must be the *Virtual Router MAC Address*. Conclusion: a *Primary IP Address* can have two MAC addresses !!!, the *Virtual Router MAC Address* and the MAC address of the NIC ! It is not logical, so what are we missing ? According to me: -Option1: the section 5.2.1 should specify that the source address should be an *IP Address Owner*, instead of the *Primary IP address*. -Option2: remove the constraint of the source MAC address of the VRRP packet = the *Virtual Router MAC Address*. I prefer option 2 because it avoids the Ethernet switch from oscillating during a transition state. Regards, Vincent _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Thu Mar 23 12:37:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTkW-00069j-BF; Thu, 23 Mar 2006 12:37:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTkV-00069Y-Jb for vrrp@ietf.org; Thu, 23 Mar 2006 12:37:27 -0500 Received: from stimpy.bivio.net ([216.142.75.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTkU-0005Jb-28 for vrrp@ietf.org; Thu, 23 Mar 2006 12:37:27 -0500 Received: from xp (beavis.bivio.net [192.168.2.10]) by stimpy.bivio.net (8.12.8/8.12.8) with ESMTP id k2NHbLXI021866; Thu, 23 Mar 2006 09:37:22 -0800 Message-Id: <200603231737.k2NHbLXI021866@stimpy.bivio.net> From: "don provan" To: "'Vincent Jardin'" Subject: RE: [VRRP] Two MAC addresses for a same IP Primary address Date: Thu, 23 Mar 2006 09:37:24 -0800 Organization: Bivio Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZOXYZf3FTfIEElTSeM7L638LOOzAAP75vw In-Reply-To: <44226C84.80101@6wind.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: vrrp@ietf.org 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: , Errors-To: vrrp-bounces@ietf.org Vincent, What you are missing is that there is no relation between the source IP address in an IP packet and the source MAC address in the ethernet packet carrying it. There is no requirement whatsoever for them to match in any way, and thank goodness because it would make routed packets somewhat difficult to handle since they have source IP addresses completely unrelated to any MAC address sending on the local network. In other words, there is no such requirement as: >Moreover, the source MAC address of the the ICMP, TCP, ARP >packets related to the *IP Address Owner*, must (of course) >be the *Virtual Router MAC Address*. >Conclusion: a *Primary IP Address* can have two MAC >addresses !!!, the *Virtual Router MAC Address* and >the MAC address of the NIC ! The VR IP address "has" one MAC address: the VR MAC. ARP should always advertise that mapping and no other. But this has no relevance to the selection of source MAC address when transmitting a packet. I understand how startling this observation can be, but it's just basic IP logic, nothing VRRP specific about it. Once you get your thoughts around it, VRRP falls out nicely. In particular, you realize that there is only one reason, ever, to use the VR's MAC address as the source of an ethernet packet, and that is to teach the ethernet switching infrastructure where to send packets with that MAC address as the destination. That is accomplished by sending the advertisement packets with the VR MAC address as source since those packets are known to be sent at the appropriate times. For all other packets, the source MAC address retains its original purpose: to identify the hardware that transmitted the packet. If anything, this becomes *more* important in a VRRP environment, since problems can be much harder to diagnose if it's impossible to tell which system sent which packets. -don -----Original Message----- From: Vincent Jardin [mailto:Vincent.Jardin@6wind.com] Sent: Thursday, March 23, 2006 1:38 AM To: vrrp@ietf.org Subject: [VRRP] Two MAC addresses for a same IP Primary address Hi all, According to the RFC3768, when a multicast VRRP packet is sent, the source IP address must be the *Primary IP Address* (section 5.2.1) and the source MAC address must be the *Virtual Router MAC Address*. Moreover, the source MAC address of the the ICMP, TCP, ARP packets related to the *IP Address Owner*, must (of course) be the *Virtual Router MAC Address*. Two routers running VRRP should have 2 differents *Primary IP Address*, and (of course) the same *IP Address Owner*. So, if from a host, which is on the same Ethernet network, I send an ICMP echo request to: - the *Primary IP Address*, which source MAC address should the ICMP echo reply use ? According to me, it must NOT be the *Virtual Router MAC Address*. - the *IP Address Owner*, which source MAC address should the ICMP echo reply use ? According to me, it must be the *Virtual Router MAC Address*. So it means that for any packets, when the source IP address is the *Primary IP Address*, the source MAC address could be any MAC address of the NIC; but when it is a VRRP Multicast packet to 224.0.0.18, the source MAC address must be the *Virtual Router MAC Address*. Conclusion: a *Primary IP Address* can have two MAC addresses !!!, the *Virtual Router MAC Address* and the MAC address of the NIC ! It is not logical, so what are we missing ? According to me: -Option1: the section 5.2.1 should specify that the source address should be an *IP Address Owner*, instead of the *Primary IP address*. -Option2: remove the constraint of the source MAC address of the VRRP packet = the *Virtual Router MAC Address*. I prefer option 2 because it avoids the Ethernet switch from oscillating during a transition state. Regards, Vincent _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Fri Mar 24 03:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhaw-0004k1-Ez; Fri, 24 Mar 2006 03:24:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMhau-0004jw-C8 for vrrp@ietf.org; Fri, 24 Mar 2006 03:24:28 -0500 Received: from 33.106-14-84.ripe.coltfrance.com ([84.14.106.33] helo=proxy.6wind.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMhar-0003Wf-9I for vrrp@ietf.org; Fri, 24 Mar 2006 03:24:28 -0500 Received: from [10.16.0.239] (unknown [10.16.0.239]) by proxy.6wind.com (Postfix) with ESMTP id A6FF3525F86; Fri, 24 Mar 2006 09:24:23 +0100 (CET) Message-ID: <4423ACB9.4080405@6wind.com> Date: Fri, 24 Mar 2006 09:24:25 +0100 From: Vincent Jardin Organization: http://www.6WIND.com/ User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vrrp@ietf.org Subject: Re: [VRRP] Two MAC addresses for a same IP Primary address References: <200603231737.k2NHbLXI021866@stimpy.bivio.net> In-Reply-To: <200603231737.k2NHbLXI021866@stimpy.bivio.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: don provan 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: , Errors-To: vrrp-bounces@ietf.org Don, > What you are missing is that there is no relation between the > source IP address in an IP packet and the source MAC address > in the ethernet packet carrying it. I definitively agree, that's why I was suspicious with our understanding of the RFC ! > >>Moreover, the source MAC address of the the ICMP, TCP, ARP >>packets related to the *IP Address Owner*, must (of course) >>be the *Virtual Router MAC Address*. > > >>Conclusion: a *Primary IP Address* can have two MAC >>addresses !!!, the *Virtual Router MAC Address* and >>the MAC address of the NIC ! > > > The VR IP address "has" one MAC address: the VR MAC. Here, what you call VR IP address is defined by *IP Address Owner* into the RFC, isn't it ? > ARP should always advertise that mapping and no other. > But this has no relevance to the selection of source > MAC address when transmitting a packet. I agree that Address Resolution (ARP) of *IP Address Owner* must only adverise the *Virtual Router MAC Address*. > In particular, you realize that there is only one reason, ever, > to use the VR's MAC address as the source of an ethernet packet, > and that is to teach the ethernet switching infrastructure > where to send packets with that MAC address as the destination. Of course, it is the basic goal of VRRP. > That is accomplished by sending the advertisement packets with > the VR MAC address as source since those packets are known to > be sent at the appropriate times. Please, here, when you write "by sending the advertisement packets with VR MAC address", please, what is the IPv4 source address ? 1-> the *IP Address Owner* 2-> xor the *Primary IP Address* Our issue is related to the fact that 2 IP addresses are defined into the RFC *IP Address Owner* and *Primary IP Address*. It is clear how the *IP Address Owner* must be used with the VR MAC address on many gateways running VRRP on a same link, but it is unclear for the *Primary IP Address*. I would be interested in better understanding how is supposed to be used the *Primary IP Address* on 3 gateways running VRRP on a same link: -> There are 3 *Primary IP addresses* at least, aren't there ? -> Are these 3 *Primary IP addresses* reachable at anytime even if the gateway is in the backup state ? Thanks, Vincent _______________________________________________ vrrp mailing list vrrp@ietf.org https://www1.ietf.org/mailman/listinfo/vrrp From vrrp-bounces@ietf.org Fri Mar 24 14:23:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMrsp-00052q-Gi; Fri, 24 Mar 2006 14:23:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMrsn-00052i-Km for vrrp@ietf.org; Fri, 24 Mar 2006 14:23:37 -0500 Received: from stimpy.bivio.net ([216.142.75.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMrsm-0007Fv-6o for vrrp@ietf.org; Fri, 24 Mar 2006 14:23:37 -0500 Received: from dprovan1 ([192.168.24.150]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id k2OJNCXI032276; Fri, 24 Mar 2006 11:23:15 -0800 From: "Don Provan" To: "'Vincent Jardin'" Subject: RE: [VRRP] Two MAC addresses for a same IP Primary address Date: Fri, 24 Mar 2006 11:23:35 -0800 Message-ID: <000201c64f78$72e9e9c0$9618a8c0@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.1506 Importance: Normal In-Reply-To: <4423ACB9.4080405@6wind.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: vrrp@ietf.org 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="===============2076568266==" Errors-To: vrrp-bounces@ietf.org --===============2076568266== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 PiBIZXJlLCB3aGF0IHlvdSBjYWxsIFZSIElQIGFkZHJlc3MgaXMgZGVmaW5lZCBieSAqSVAgQWRk cmVzcyANCj4gT3duZXIqIGludG8gdGhlIFJGQywgaXNuJ3QgaXQgPw0KDQpUaGVyZSBpcyBhIFZS IElQIGFkZHJlc3MuIFRoZSBWUiBJUCBhZGRyZXNzIGhhcyBhbiBvd25lciwgYnV0DQppdCBpcyB0 aGUgVlIgbWFzdGVyLCB3aGV0aGVyIGN1cnJlbnRseSB0aGUgb3duZXIgb3Igbm90LCB0aGF0DQp1 c2VzIHRoZSBWUiBNQUMgYWRkcmVzcy4NCg0KPiA+IEFSUCBzaG91bGQgYWx3YXlzIGFkdmVydGlz ZSB0aGF0IG1hcHBpbmcgYW5kIG5vIG90aGVyLg0KPiA+IEJ1dCB0aGlzIGhhcyBubyByZWxldmFu Y2UgdG8gdGhlIHNlbGVjdGlvbiBvZiBzb3VyY2UNCj4gPiBNQUMgYWRkcmVzcyB3aGVuIHRyYW5z bWl0dGluZyBhIHBhY2tldC4NCj4gDQo+IEkgYWdyZWUgdGhhdCBBZGRyZXNzIFJlc29sdXRpb24g KEFSUCkgb2YgKklQIEFkZHJlc3MgT3duZXIqIG11c3Qgb25seSANCj4gYWR2ZXJpc2UgdGhlICpW aXJ0dWFsIFJvdXRlciBNQUMgQWRkcmVzcyouDQoNClRoZSAqbWFzdGVyKiBpcyB0aGUgb25lIHRo YXQgQVJQcyB0aGUgVlIgSVAgYWRkcmVzcywgcmVnYXJkbGVzcw0Kb2Ygd2hldGhlciBpdCBpcyB0 aGUgVlIgSVAgYWRkcmVzcyBvd25lci4gSW4gYW55IGNhc2UsIHdlIGFncmVlDQp3aXRoIHRoZSBp bXBvcnRhbnQgcG9pbnQ6IEFSUCBhbHdheXMgbWFwcyBWUiBJUCBhZGRyZXNzIHRvIFZSIE1BQw0K YWRkcmVzcy4NCg0KPiBQbGVhc2UsIGhlcmUsIHdoZW4geW91IHdyaXRlICJieSBzZW5kaW5nIHRo ZSBhZHZlcnRpc2VtZW50IA0KPiBwYWNrZXRzIHdpdGggDQo+IFZSIE1BQyBhZGRyZXNzIiwgcGxl YXNlLCB3aGF0IGlzIHRoZSBJUHY0IHNvdXJjZSBhZGRyZXNzID8NCj4gICAgMS0+IHRoZSAqSVAg QWRkcmVzcyBPd25lcioNCj4gICAgMi0+IHhvciB0aGUgKlByaW1hcnkgSVAgQWRkcmVzcyoNCg0K VGhlIHNvdXJjZSBpcyB0aGUgcHJpbWFyeSBJUCBhZGRyZXNzIG9mIHRoZSBpbnRlcmZhY2UgdGhy b3VnaA0Kd2hpY2ggdGhlIGFkdmVydGlzZW1lbnQgaXMgc2VudC4gRm9yIHRoZSBWUiBJUCBhZGRy ZXNzIG93bmVyLA0KdGhpcyBjb3VsZCBiZSB0aGUgVlIgSVAgYWRkcmVzcyBpdHNlbGYsIGJ1dCBm b3IgYW55IG90aGVyIHJvdXRlcg0Kc3VwcG9ydGluZyB0aGlzIFZSLCBpdCBoYXMgdG8gYmUgYW4g SVAgYWRkcmVzcyB1bnJlbGF0ZWQgdG8gdGhlDQpWUi4gKEluIG15IGltcGxlbWVudGF0aW9uLCBl dmVuIHRoZSBWUiBJUCBhZGRyZXNzIG93bmVyIHVzZXMNCmFuIHVucmVsYXRlZCBJUCBhZGRyZXNz IGFzIGl0J3MgcHJpbWFyeSBJUCBhZGRyZXNzLikNCg0KPiBPdXIgaXNzdWUgaXMgcmVsYXRlZCB0 byB0aGUgZmFjdCB0aGF0IDIgSVAgYWRkcmVzc2VzIGFyZSBkZWZpbmVkIGludG8gDQo+IHRoZSBS RkMgKklQIEFkZHJlc3MgT3duZXIqIGFuZCAqUHJpbWFyeSBJUCBBZGRyZXNzKi4gSXQgaXMgDQo+ IGNsZWFyIGhvdyB0aGUgKklQIEFkZHJlc3MgT3duZXIqIG11c3QgYmUgdXNlZCB3aXRoIHRoZSBW UiBNQUMgYWRkcmVzcyBvbiANCj4gbWFueSBnYXRld2F5cyBydW5uaW5nIFZSUlAgb24gYSBzYW1l IGxpbmssIGJ1dCBpdCBpcyB1bmNsZWFyIGZvciB0aGUgDQo+ICpQcmltYXJ5IElQIEFkZHJlc3Mq Lg0KDQpUaGUgcHJpbWFyeSBJUCBhZGRyZXNzIHVuaXF1ZWx5IGlkZW50aWZpZXMgZWFjaCByb3V0 ZXIgcGFydGljaXBhdGluZw0KaW4gdGhlIFZSLiBJdCBpcyB0aGUgSVAgYWRkcmVzcyBhc3NpZ25l ZCB0byB0aGUgcm91dGVyIGJlY2F1c2UgaXQgaXMNCmFuIElQIG5vZGUgb24gdGhhdCBuZXR3b3Jr OyBpdCB3YXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBmYWN0IHRoYXQNCnRoZSByb3V0ZXIgaXMg bm93IGFzc2lnbmVkIHRvIHN1cHBvcnQgVlJSUC4NCg0KPiBJIHdvdWxkIGJlIGludGVyZXN0ZWQg aW4gYmV0dGVyIHVuZGVyc3RhbmRpbmcgaG93IGlzIHN1cHBvc2VkIA0KPiB0byBiZSB1c2VkIA0K PiB0aGUgKlByaW1hcnkgSVAgQWRkcmVzcyogb24gMyBnYXRld2F5cyBydW5uaW5nIFZSUlAgb24g YSBzYW1lIGxpbms6DQo+ICAgIC0+IFRoZXJlIGFyZSAzICpQcmltYXJ5IElQIGFkZHJlc3Nlcyog YXQgbGVhc3QsIGFyZW4ndCB0aGVyZSA/DQoNClllcy4gRWFjaCByb3V0ZXIgaGFzIGl0cyBvd24s IHVuaXF1ZSBwcmltYXJ5IElQIGFkZHJlc3Mgb24gdGhlDQpuZXR3b3JrIFZSUlAgaXMgcnVubmlu ZyBvbi4gKFRoZSBWUiBJUCBhZGRyZXNzIG93bmVyIGlzIGFsbG93ZWQgYnV0DQpub3QgcmVxdWly ZWQgdG8gdXNlIHRoZSBWUiBJUCBhZGRyZXNzIGFzIGl0cyBwcmltYXJ5IElQIGFkZHJlc3MuKQ0K DQo+ICAgIC0+IEFyZSB0aGVzZSAzICpQcmltYXJ5IElQIGFkZHJlc3NlcyogcmVhY2hhYmxlIGF0 IGFueXRpbWUgZXZlbiBpZiANCj4gdGhlIGdhdGV3YXkgaXMgaW4gdGhlIGJhY2t1cCBzdGF0ZSA/ DQoNClRoZSBwcmltYXJ5IElQIGFkZHJlc3MgYXJlIGFzc2lnbmVkIHRvIHRoZSBwaHlzaWNhbCBy b3V0ZXIuIEl0cw0KcmVhY2hhYmlsaXR5IGlzIHVucmVsYXRlZCB0byB0aGUgVlJSUCBwcm90b2Nv bCBpbiBhbnkgd2F5LiBPbmUgd291bGQNCmV4cGVjdCB0aGUgYWRkcmVzcyB0byBiZSByZWFjaGFi bGUgd2hlbmV2ZXIgdGhhdCBpbnRlcmZhY2UgaXMgdXAganVzdA0KYXMgb25lIHdvdWxkIGV4cGVj dCBhbnkgb3RoZXIgbm9kZSdzIElQIGFkZHJlc3NlcyB0byBiZSByZWFjaGFibGUgd2hlbg0KdGhl IG5vZGUgaXMgYWN0aXZlLiBBcyBpdCB0dXJucyBvdXQsIFZSUlAgZG9lc24ndCBldmVuIHJlcXVp cmUgdGhhdCBtdWNoOg0KVlJSUCBuZXZlciBzZW5kcyBhIHBhY2tldCAqdG8qIHRoZSBQcmltYXJ5 IElQIGFkZHJlc3MgKHVubGVzcyBJJ20NCmZvcmdldHRpbmcgc29tZXRoaW5nLi4uLiksIHNvIGZv ciBWUlJQIHRvIHdvcmssIHRoZSBQcmltYXJ5IElQIGFkZHJlc3MNCm5lZWQgbm90IGJlIGFjdHVh bGx5IHJlYWNoYWJsZSwgYWx0aG91Z2ggSSBkb24ndCB0aGluayB0aGUgcHJvdG9jb2wgc3BlYw0K aXRzZWxmIG1lbnRpb25zIHRoaXMgdW5pbXBvcnRhbnQgZGV0YWlsLg0KDQotZG9uDQo= --===============2076568266== 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 --===============2076568266==-- From faxnow@stedu.net Sat Mar 25 18:32:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNIEx-0008Pd-MB for vrrp-archive@lists.ietf.org; Sat, 25 Mar 2006 18:32:15 -0500 Received: from mail.stinfo.net ([202.96.144.151] helo=smtp.stinfo.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNIEu-0005Ir-O9 for vrrp-archive@lists.ietf.org; Sat, 25 Mar 2006 18:32:15 -0500 Received: from honyasrv (honyasrv [127.0.0.1]) by smtp.stinfo.net (Postfix) with ESMTP id 6A8CC4540CF; Sun, 26 Mar 2006 06:52:32 +0800 (CST) Message-ID: <1160052531.1143327152419.JavaMail.root@honyasrv> Date: Sun, 26 Mar 2006 06:52:32 +0800 (CST) From: faxnow@stedu.net To: solder@popfeel.com Subject: =?gb2312?B?ztLSqreisrzI7bz+?= Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_111_2015035187.1143327152418" X-Mailer: Honya Webmail 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c ------=_Part_111_2015035187.1143327152418 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 1b6zpKOsxPq6w6OhsO+w78OmytXCvM/Cw+a1xNfu0MKw5rG+yO28/lvN6sir19TW97+qt6Jdo6zQ u9C7o6EgDQoNCqG60MK6/LXnxNS0q9XmobuhqqG+zai5/TU2S8bVzahNT0RFTcGqtee7sM/ft6LL zbrNvdPK1bSr1eajrM7e0Oi0q9Xm1r26zbTy06G7+qOsy9m2yL/so6zKoceuob8NCqG60MK6/LSr 1ebIureiobuhqqG+19S2r7W8yOu6xcLrz/Kzycenyc/N8rXEv827p8i6t6K0q9Xmo6zO3tDoyMu5 pNa1ytijrMTayN24/MflzvqjrMqhx67KocGmob8NCqG60MK6/LSr1ebL0cv3obuhqqG+tbzI67nY vPy0ysirzOzX1Lavy9HL97j3s8fK0KGi0NDStbmry77G89K1tKvV5rv6usXC69DOs8nB0LHto6zT qs/6vNvWtbjfob8gDQqhusvR0te0q9Xmt/7O8cb3obuhqqG+vtbT8s34yc+w2cyotefE1Lmyz+3S u8z1tee7sM/fytW3orSr1eajrL3ayqG24LK/w8Ww7LmryeixuLm61sO30dPDo6yzrNa1ob8gDQqh utDCuvy157uwueOypaG7oaqhvs2ouf01NkvT79L0TW9kZW3X1Lavsqa08rPJx6fJz83ytcS157uw usXC67Klt8XT79L0zajWqqOstee7sLTfvcm30dPDzNjQp6G/DQqhurDZtsi159PKy9HL96G7oaqh vrW8yOu52Lz8tMrB0LHt19S2r9TasNm2yMvRy/fS/cfmtqjP8svRy/e497PHytChotDQ0rW5q8u+ xvPStbXn19PTyrz+tdjWt6G/DQqhurm3ube159PKy9HL98b3obuhqqG+tbzI67nYvPy0ysHQse3X 1Lav1NpHT09HTEUuQ09Nyc+2qM/yy9HL97j3s8fK0KGi0NDStbmry77G89K1tefX09PKvP612Na3 ob8gDQqhusvR0tfTyrz+y9HL9831obuhqqG+yc/N+MqxsrvWqrK7vvXU2rrzzKjX1Lavy9HL9834 0rPJz7XE08q8/rXY1rejrM34yc/RsNXSxL+x6r/Nu6eyu9TZysfE0crCob8NCqG6z8i609PKvP7X t7K2IKG7oaqhvsrkyOvSu7j2zfjWt7Hjv8m9q7jDzfjVvs/Cy/nT0NKzw+bJz7XE08q8/rXY1rfS u834tPK+oaOsv8nX1MnotqjL0cv3suPK/aG/DQqhusLbzLO159PKy9HL96G7oaqhvteo0rXL0cv3 uPfA4NDo0qrXorLhtcfCvbXEwtvMs6GiuanH89DFz6KhorvG0rOhorvh1LHVvrXjyc+5q7K8tcTT yrz+tdjWt6G/IA0KobrN+LzKtefTyrK2173G96G7oaqhvtPDyvOx6ri01sa3vcq9uKjW+sjLuaS0 08341b7Jz7/sy9nM4cihxL+x6r/Nu6e1xLXn19PQxc/ko6zTyta3sNm31rDZvqvIt6G/DQqhurXn 19PTyrz+yajD6Mb3obuhqqG+y9HL98jO0uLOxLz+oaLEv8K8oaJPVVRMT09LL0ZPWE1BSUwg08q8 /rzQoaLTssXMoaK54rX61tDTyta3sqK/ycils/3W2Li0ob8gDQqhutLX0MLM9cLrtPLToaG7oaqh vrn6vMqx6te8zPXQzsLryei8xqGiyfqzybrNtPLTocjtvP6jrLOsytDF5MzXyfqy+sbz0rXKytPD o6y/ycz1wuu54se5yajD6KG/DQqhusvR0tfM9cLr16i80qG7oaqhvrn6vMqx6te8MznKvbfAzrHM 9dDOwuvX1Lavy+a7+sn6s8mhorfW0rO08tOhoaKy6dGvo6zWxtTs0rWy+sa3t8DOsde3y93Tw6G/ IA0KobrN+NW+06rP+sbvsfihu6Gqob65+sTazqjSu9ans9bTw7un19S8ur2owaLK/b7dv+K1xM34 1b7Qxc+ixKPE4sjLuaTX1Lavt6KyvLXEzajTw9DN06rP+sjtvP6hvw0KobrQwrr8wtvMs7/xzPmh u6Gqob7X1Lav1NrC28yztcS497j21vfM4sf40/LVxcz5ueO45tDFz6KjrNXm1f21xMLbzLO3osz7 u/rG98jLo6zTqs/60Ke5+9fuvNGhvw0KobrL0dLXsOy5q7zgudzN9aG7oaqhvrbUvtbT8s34tefE 1MbBxLvKtcqxxcTV1bzgv9ijrLbFvvjJz7DgzebTzs+3oaLBxMzsoaK/tLXn07CjrMzhuN+w7Lmr vKjQp6G/DQqhusvR0tdJRbzgudy088qmobuhqqG+z97WxklF5K/AwMb31rvE3LTyv6rWuLaotcS6 z7eozfjVvsHQse2jrL371rm/tLvGyauhorfHt6ihorKhtr66zcS+wu3VvrXjob8gDQqhurart73X 1NPJ1ve7+qG7oaqhvtPDxtXNqMGqzfhQQ7/sy9m9qMGiuqPBv7/VvOS49sjL1vfSs7f+zvHG97mk vt+jrM/C1NjK/b7dyN3Bv73PtPOzobrPysrTw6G/IA0KobrQwrr8UVHIureixvehu6Gqob7P8rPJ sNnJz8entcRRUbrD09HX1LavyLq3ornjuObQxc+io6zWp7PWUVHX7tDCsOaxvqOst6LLzcvZtsi/ 7KOs0Ke5+7yrvNGhvw0Kobq/qtS01qS/qLTy06Ghu6Gqob6+q8i3x7bM17Ty06HQxbfioaLWp8ax oaK3osaxoaK5pNf31qShor3h0rXWpLXIuPfA4Nakv6ijrMbVzai08tOhu/q/ycqkyM6hvw0KobrQ wrr8tPrA7bf+zvHG96G7oaqhvsjDvtbT8s34yc+w2cyotefE1EhUVFC0+sDtt73Kvbmyz+3Jz7ul warN+KOsytW3otPKvP6horKlt8W159Ow0tS8sFFRwcTM7KG/IA0KDQrTptPDxr3MqKO6V2luOXgv TWUvTlQvMjAwMC9YUA0KvLzK9dans9ajujA1MTktODUzNzE4OS84NjcwMzIzIA0KUVG6xdfJ0a+j ujcwMDk0NjM3IE1TTqO6d3d3Ljg3MTUuY29tQGhvdG1haWwuY29tDQrI7bz+0+/R1KO6vPLM5dbQ zsQNClvI7bz+MTAwo6W/yc/C1NijrMjnxLPBtL3TtPKyu7+qx+uzosrUxuTT4MG0vdO78lFRwO/L 98ihzfjWt10NCsPit9HPwtTYo7ogaHR0cDovL3hoc29mdDM2NS41ODg4LmNvbQ0Kw+K30c/C1Nij uiBodHRwOi8veGhzb2Z0MzY1LmNubmIubmV0DQrD4rfRz8LU2KO6IGh0dHA6Ly94aHNvZnQzNjUu eWVhaC5uZXQNCsPit9HPwtTYo7ogaHR0cDovL3hoc29mdDM2NS45MTI2LmNvbQ== ------=_Part_111_2015035187.1143327152418-- From vrrp-bounces@ietf.org Mon Mar 27 23:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO69Z-0005U1-Vu; Mon, 27 Mar 2006 23:50:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO69Y-0005Tr-P5 for vrrp@ietf.org; Mon, 27 Mar 2006 23:50:00 -0500 Received: from gate12-norfolk.nmci.navy.mil ([138.162.5.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO69Y-0006Wh-2U for vrrp@ietf.org; Mon, 27 Mar 2006 23:50:00 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate12-norfolk.nmci.navy.mil via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with ESMTP; Tue, 28 Mar 2006 04:50:00 +0000 Received: (private information removed) Received: from no.name.available by naeanrfkfw10c.nmci.navy.mil via smtpd (for insidesmtp2.nmci.navy.mil [10.16.0.170]) with ESMTP; Sun, 26 Mar 2006 17:42:38 +0100 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 Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Date: Mon, 27 Mar 2006 22:49:57 -0600 Message-ID: <1929B8C5B318524495727D8A241DAFB20147FDB8@NAEAMILLEX03VA.nadsusea.nads.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Thread-Index: AcZOBLeY1Gtf0XYHTUGyOEpdGzzkAgEG6E+g From: "Hott, Robert W CIV B35-Branch" To: "Steve Bates" , X-OriginalArrivalTime: 28 Mar 2006 04:49:57.0489 (UTC) FILETIME=[1025E610:01C65223] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1fb4c76a9d88e8fb8b791f63f8d1b07f Cc: "Odonoghue, Karen F CIV B35-Branch" 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="===============0979376229==" Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. --===============0979376229== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65223.0FFF9DF8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65223.0FFF9DF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, Sorry I missed your comments the first go around. I did get them and missed responding. Thank you for hitting me with them again. You have some good questions. I think the draft needs to have wording added to clarify what needs to happen. I also think some discussion on the reflector is in order with regard to timers, granularity, and counts. Thank you for the comments. See my response and observations below. Hopefully this will get some discussion going!! Bob Hott -----Original Message----- From: Steve Bates [mailto:Steve.Bates@alcatel.com] Sent: Wednesday, March 22, 2006 18:04 To: Hott, Robert W CIV B35-Branch; vrrp@ietf.org Subject: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Hi Bob, I've posted these comments before but I'll rephrase them based on the 02 draft. 1) Back in early December there was a flurry of comments about = mismatched advertisement intervals causing multiple masters. The consensus seemed = to be that virtual routers of a lower priority would ignore a mismatch if = the higher priority interval was less than their configured interval and = make the higher priority interval their own operational value when it was = greater than their configured interval. I was under the impression, based on Radia's response to your original December 2nd post, that this would be reflected in the draft. Other than the omission of the phrase "the = receiver MUST discard the packet" in the final paragraph of section 4.1 I don't = see anything about this. =20 Steve, removing the phrase from Section 4.1 about discarding the packet was needed so that mismatches would get handled in the STATE MACHINE. If the Advertisements were discarded, multiple Masters could occur. Now, with regard to which timer to use, I think that the consensus was to use the MASTER values when there was a mis-match. Clock granularity = could impact what is actually used, see my response to your question #2, = below. When I look at your questions and the draft, I think the draft needs to better identify and discuss the values used; whether it is the configured value, the value received from the MASTER, etc... 2) This may become a greater issue with the addition of advertising = interval granularity. It's conceivable that one implementation might not be able = to support as fine(?) a granularity as another, while both are type 2 = virtual routers. For example, suppose a higher priority virtual router A is configured with adver_cnt =3D 3, aig =3D 1, and adver_int =3D 1, while a = lower priority virtual router B is configured with adver_cnt =3D 3, aig =3D 2, = and adver_int =3D 1. Virtual router B MUST accept virtual router A's values = to avoid flapping - unless it discards the FAST ADVERTISEMENT and creates a = two master situation. Conversely, if the priorities are reversed B's values = are useless to A if A is incapable of supporting the finer granularity but = at least A will maintain it's backup state. Am I mistaken? Okay, so here is how it should work, not saying that the wording is in place: If Router A is Master (or any router with a granularity less than its Backups), then the Master will propagate its values to the Backups. The Backups, in this case Router B, should be able to set its timer (Master_Down_Timer) based on the received adver_cnt and adver_int in the advertised clock granularity (centiseconds) units, since its own clock granularity was milliseconds. This should work fine. Now for the opposite situation, where the Master has a clock granularity greater that its Backups. So, Router B is now the Master and Router A is the Backup. Here, Router B sends the advertisement once every millisecond. Since Router A cannot set its timer to 1 millisecond, it should set its timer based upon its own lowest setting. In this case, 1 centisecond should be used. Router A won't failover to become Master as fast as Router B would like (3 microseconds) but it will eventually become Master, as soon as it can. Once Router B becomes the Master, if it does, it would use its configured settings. I think the draft needs to better describe which settings should be used, based upon clock granularity. Thus, the Master_Down_Interval needs to reflect the Master settings and the internal settings. 3) The two bit granularity field seems a bit shortsighted. A) There are some RTOSes where a "tick" is defined as 1/60th of a second. This makes achieving centisecond granularity difficult. A decisecond value would = be nice. B) But if we do that we've used up all the values in the field. = Ten years from now we'll be on terabit networks and someone may want = microsecond granularity. Another bit might be a good idea. I tend to agree with you about the need for more bits for granularity. This kind of relates to your last question, below. I figured that the last bit would be used for microseconds, but wondered about the decisecond need. I thought that the 10 bits for centiseconds would=20 cover the decisecond requirement. 4) I don't dispute the desirability of a configurable advertisement = count but I'm not sure we gain much passing it in the advertisement. The issue that I have with the current Master_Down_Interval is that it is based upon a fixed Advertisement Count of 3. As you move into lower time intervals between Advertisements, missing 3 Advertisements is very likely and flapping occurs. I think that missing 3 Advertisements was reasonable when the failovers were in the order of seconds. I guess one option would be to change to way that the advertisement_interval is calculated and only pass the acceptable outage period ( = failover_time). What do you / everyone think about that? So, in the Advertisement, you would pass the desired failover time. On the Master, it is configured to send Advertisements every (Failover_Time / Configured_number_per_interval). The Backups would only care about Failover_Time and clock granularity. 5) For the VRRPv3 packet there are only 4 bits available since the advertisement interval uses 12. Do you have an idea how to migrate this draft to the IPv6 case? I think the right way to handle this for IPv6 is to do the same thing for both V4 and V6. If the discussion on your 4th question moves the standard to specify a failover time, then I think there will be enough room to specify a clock granularity. My original proposal was not to introduce a new version of VRRP, but add a new message type. If IPv4 and IPv6 were aligned, maybe it would be better to use a single type advertisement and introduce a new version. What do folks think? Steve Bates Bob Hott ------_=_NextPart_001_01C65223.0FFF9DF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [VRRP] Questions on = draft-ietf-vrrp-ipv4-timers-02.txt

Steve,

  Sorry I missed your comments the first go around. = I did get them
and missed responding. Thank you for hitting me with them = again. You
have some good questions. I think the draft needs to have = wording
added to clarify what needs to happen. I also think some = discussion
on the reflector is in order with regard to timers, = granularity, and
counts. Thank you for the comments. See my response and = observations
below. Hopefully this will get some discussion = going!!

Bob Hott

-----Original = Message-----
From: Steve Bates = [mailto:Steve.Bates@alcatel.com]
Sent: Wednesday, = March 22, 2006 18:04
To: Hott, Robert = W CIV B35-Branch; vrrp@ietf.org
Subject: [VRRP] = Questions on draft-ietf-vrrp-ipv4-timers-02.txt


Hi = Bob,

I've posted these = comments before but I'll rephrase them based on the 02
draft.

1) Back in early = December there was a flurry of comments about mismatched
advertisement = intervals causing multiple masters.  The consensus seemed = to
be that virtual = routers of a lower priority would ignore a mismatch if the
higher priority = interval was less than their configured interval and make
the higher = priority interval their own operational value when it was = greater
than their = configured interval.  I was under the impression, based = on
Radia's response = to your original December 2nd post, that this would be
reflected in the = draft.  Other than the omission of the phrase "the = receiver
MUST discard the = packet" in the final paragraph of section 4.1 I don't = see
anything about = this. 

Steve, removing the phrase from Section 4.1 about = discarding the packet
was needed so that mismatches would get handled in the = STATE MACHINE.
If the Advertisements were discarded, multiple Masters = could occur.
Now, with regard to which timer to use, I think that the = consensus was
to use the MASTER values when there was a mis-match. Clock granularity = could
impact what is actually used, see my response to your = question #2, below.
When I look at your questions and the draft, I think the = draft needs
to better identify and discuss the values used; whether = it is the
configured value, the value received from the MASTER, = etc...


2) This may become = a greater issue with the addition of advertising interval
granularity.  It's conceivable that one = implementation might not be able to
support as = fine(?) a granularity as another, while both are type 2 = virtual
routers.  = For example, suppose a higher priority virtual router A is
configured with = adver_cnt =3D 3, aig =3D 1, and adver_int =3D 1, while a = lower
priority virtual = router B is configured with adver_cnt =3D 3, aig =3D 2, = and
adver_int =3D = 1.  Virtual router B MUST accept virtual router A's values = to
avoid flapping - = unless it discards the FAST ADVERTISEMENT and creates a = two
master = situation.  Conversely, if the priorities are reversed B's values = are
useless to A if A = is incapable of supporting the finer granularity but at
least A will = maintain it's backup state.  Am I mistaken?


Okay, so here is how it should work, not saying that the = wording is in
place:

If Router A is Master (or any router with a granularity = less than its
Backups), then the Master will propagate its values to = the Backups.
The Backups, in this case Router B, should be able to set = its
timer (Master_Down_Timer) based on the received adver_cnt = and adver_int
in the advertised clock granularity = (centiseconds) = units, since = its
own clock granularity was milliseconds. This should work = fine.

Now for the opposite situation, where the Master has a = clock
granularity greater that its Backups. So, Router B is now = the Master
and Router A is the Backup. Here, Router B sends the = advertisement
once every millisecond. Since Router A cannot set its = timer to 1
millisecond, it should set its timer based upon its own = lowest setting.
In this case, 1 centisecond should be used. Router A = won't failover to
become Master as fast as Router B would like (3 = microseconds) but it
will eventually become Master, as soon as it = can. Once Router = B
becomes the Master, if it does, it would use its = configured settings.

I think the draft needs to better describe which settings = should be
used, based upon clock granularity. Thus, the = Master_Down_Interval
needs to reflect the Master settings and the internal = settings.

3) The two bit = granularity field seems a bit shortsighted.  A) There = are
some RTOSes where = a "tick" is defined as 1/60th of a second.  This = makes
achieving = centisecond granularity difficult.  A decisecond value would = be
nice.  B) = But if we do that we've used up all the values in the field.  = Ten
years from now = we'll be on terabit networks and someone may want = microsecond
granularity.  Another bit might be a good = idea.

I tend to agree with you about the need for more bits for = granularity.
This kind of relates to your last question, below. I = figured that
the last bit would be used for microseconds, but wondered = about the
decisecond need. I thought that the 10 bits for = centiseconds would
cover the decisecond requirement.

4) I don't dispute = the desirability of  a configurable advertisement = count
but I'm not sure = we gain much passing it in the advertisement.

The issue that I have with the current = Master_Down_Interval is that it
is based upon a fixed Advertisement Count of 3. As you = move into lower
time intervals between Advertisements, missing 3 = Advertisements is very
likely and flapping occurs. I think that missing 3 = Advertisements was
reasonable when the failovers were in the order of = seconds. I guess
one option would be to change to way that the = advertisement_interval
is calculated and only pass the acceptable outage = period ( = failover_time).
What do you / everyone think about that? So, in the Advertisement, = you
would pass the desired failover time. On the Master, it is configured = to
send Advertisements every
(Failover_Time / Configured_number_per_interval). The = Backups = would
only care about Failover_Time and clock = granularity.


5) For the VRRPv3 = packet there are only 4 bits available since the
advertisement = interval uses 12.  Do you have an idea how to migrate = this
draft to the IPv6 = case?

I think the right way to handle this for IPv6 is to do the same = thing
for both V4 and V6. If the discussion on your 4th = question moves the
standard to specify a failover time, then I think there = will be
enough room to specify a clock granularity. My original = proposal
was not to introduce a new version of VRRP, but add a = new
message type. If IPv4 and IPv6 were aligned, maybe it = would be
better to use a single type advertisement and introduce a = new
version. What do folks think?


Steve = Bates

Bob Hott

------_=_NextPart_001_01C65223.0FFF9DF8-- --===============0979376229== 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 --===============0979376229==-- From vrrp-bounces@ietf.org Tue Mar 28 18:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONgc-0005fx-CB; Tue, 28 Mar 2006 18:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FONgb-0005fs-9g for vrrp@ietf.org; Tue, 28 Mar 2006 18:33:17 -0500 Received: from stimpy.bivio.net ([216.142.75.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FONgY-0005ID-4Q for vrrp@ietf.org; Tue, 28 Mar 2006 18:33:17 -0500 Received: from dprovan1 ([192.168.24.150]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id k2SNWrXI016431; Tue, 28 Mar 2006 15:32:54 -0800 From: "Don Provan" To: "'Hott, Robert W CIV B35-Branch'" , "'Steve Bates'" , Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Date: Tue, 28 Mar 2006 15:33:20 -0800 Message-ID: <004501c652c0$000ba740$9618a8c0@corp.networkrobots.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0046_01C6527C.F1E86740" 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.1506 X-MS-TNEF-Correlator: 00000000442D192E89A78942830185E84677F83AC4166603 Importance: Normal In-Reply-To: <1929B8C5B318524495727D8A241DAFB20147FDB8@NAEAMILLEX03VA.nadsusea.nads.navy.mil> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: "'Odonoghue, Karen F CIV B35-Branch'" 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: , Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C6527C.F1E86740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Rmlyc3QsIEkganVzdCB3YW50IHRvIG1lbnRpb24gdGhhdCBJIHRoaW5rIEJvYiBoYXMgdGhlDQph bnN3ZXIgdG8gdGhlICJ3aGljaCB0aW1lIHRvIHVzZSIgcXVlc3Rpb24gc3BvdCBvbi4gSQ0KcmVj YWxsIHRoYXQgdGhlIHdvcmRpbmcgaW4gdGhlIHNwZWMgd2Fzbid0IHF1aXRlIHJpZ2h0DQpsYXN0 IHRpbWUgSSByZWFkIGl0IChhbmQgaXQgc291bmRzIGxpa2UgQm9iIGFncmVlcyBpdA0KbmVlZHMg YSBsaXR0bGUgd29yayksIGJ1dCB0aGUgZGVzY3JpcHRpb24gQm9iIGhhcyBoZXJlDQppbiB0aGlz IGUtbWFpbCBhZ3JlZXMgZXhhY3RseSB3aXRoIGJvdGggbXkgcG9uZGVyaW5ncw0KYW5kIG15IGV4 cGVyaWVuY2Ugb24gd2hhdCBjYW4gZ28gd3JvbmcgYW5kIHdoYXQgdGhlDQpydWxlcyBzaG91bGQg YmUgdG8gbWFrZSBzdXJlIHRoZXkgZG9uJ3QuDQogDQpCdXQgbXkgcHVycG9zZSBmb3Igd3JpdGlu ZyB0aGlzIGlzIHRvIGV4cGxvcmUgYW5vdGhlcg0KcXVlc3Rpb24sIG9uZSB0aGF0IGNvbWVzIHVw IG92ZXIgYW5kIG92ZXIgYW5kIEkndmUNCm5ldmVyIGZlbHQgc2F0aXNmaWVkIGFib3V0LiBCb2Ig c2F5cywgIkFzIHlvdSBtb3ZlIGludG8gbG93ZXIgDQp0aW1lIGludGVydmFscyBiZXR3ZWVuIEFk dmVydGlzZW1lbnRzLCBtaXNzaW5nIDMgQWR2ZXJ0aXNlbWVudHMgaXMgdmVyeSANCmxpa2VseSBh bmQgZmxhcHBpbmcgb2NjdXJzLiIgDQogDQpOb3cgSSAqZG9uJ3QqIGhhdmUgZXhwZXJpZW5jZSBp biBhY3R1YWwgbmV0d29ya3Mgd2hlcmUNCnRoZXNlIGxvd2VyIHRvbGVyYW5jZXMgYXJlIHJlcXVp cmVkLCBzbyBJIGFzayB0aGlzDQp3aXRob3V0IGhhdmluZyBhbiBvcGluaW9uLCBidXQgaXMgaXQg aW4gZmFjdCB0cnVlIHRoYXQNCnRoYXQgcGVyIHBhY2tldCBmYWlsdXJlIHJhdGUgaW5jcmVhc2Vz IGluIGNhc2VzIHdoZXJlDQphIHNob3J0ZXIgZmFpbG92ZXIgdGltZSBpcyBkZXNpcmVkPyBXaGF0 IGlzIHRoZQ0KY2hhcmFjdGVyaXN0aWMgb2YgdGhlc2UgZW52aXJvbm1lbnRzIHRoYXQgbWFrZXMN CnRoZSBzdGFuZGFyZCBvZiAzIHBhY2tldHMgbGVzcyByZWxpYWJsZSB0aGF0IGluIGFuDQplbnZp cm9ubWVudCB3aGVyZSBhIDMgc2Vjb25kIGZhaWxvdmVyIGlzIGFjY2VwdGFibGU/DQpJdCBzZWVt cyBjb3VudGVyIGludHVpdGl2ZSB0byBtZSAtLSB3aGVuIHlvdSByZXRyYW5zbWl0DQpmYXN0ZXIs IGl0IGNhdXNlcyBhIHByb2JsZW0sIGFuZCB0aGUgc29sdXRpb24gdG8gdGhhdA0KcHJvYmxlbSBp cyB0byByZXRyYW5zbWl0ICpldmVuIGZhc3Rlcio/IC0tIGJ1dCwgYXMgSQ0Kc2F5LCBpdCdzIHBy b2JhYmx5IGp1c3Qgc29tZXRoaW5nIGFib3V0IHRoZSB0YXJnZXQNCmFwcGxpY2F0aW9uIHRoYXQg SSBkb24ndCB5ZXQgdW5kZXJzdGFuZC4NCiANCk9yIGlzIHRoaXMganVzdCBiZWNhdXNlIHBlb3Bs ZSBoYXZlIGFsd2F5cyB3YW50ZWQgdG8NCmJlIGFibGUgdG8gY29uZmlndXJlIHRoZSBudW1iZXIg b2YgcmV0cmFuc21pc3Npb25zLCBzbw0Kbm93J3MgdGhlIGNoYW5jZT8gSSBhZG1pdCB0byBiZWlu ZyBhIGxpdHRsZSBjb25jZXJuZWQNCndpdGggZGVwZW5kaW5nIG9uIG9ubHkgMyByZXRyYW5zbWlz c2lvbnMgcmVnYXJkbGVzcyBvZg0KdGhlIHJhdGUsIGJ1dCBJJ3ZlIG5ldmVyIGFjdHVhbGx5IGJl ZW4gYWJsZSB0byBqdXN0aWZ5DQphbnkgcmVhc29uIHdoeSB0aHJlZSBwYWNrZXRzIHdvdWxkbid0 IGJlIGVub3VnaC4NCiANCi1kb24NCiANCg== ------=_NextPart_000_0046_01C6527C.F1E86740 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhUXAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANYHAwAcAA8AIQAAAAIALgEB A5AGAEQdAAAnAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA3AAAAW1ZSUlBdIFF1ZXN0aW9ucyBvbiBkcmFmdC1pZXRmLXZycnAtaXB2NC10 aW1lcnMtMDIudHh0AAACAXEAAQAAABYAAAABxlK//2xyX3KBKKNPAIt2XPvowcl5AAACAR0MAQAA ABcAAABTTVRQOkRQUk9WQU5AQklWSU8uTkVUAAALAAEOAAAAAEAABg4AHkHzv1LGAQIBCg4BAAAA GAAAAAAAAABELRkuiaeJQoMBhehGd/g6woAAAAMAFA4BAAAACwAfDgEAAAACAQkQAQAAAKIYAACe GAAA7YkAAExaRnXGOaqlAwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3CoACpAPjAgBjaMEKwHNl dDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR1TMERhDZ+RLvZjQDxhGFEeMI7wn39jsa Hw4wNRs/HEMR4QxgzmMAUAsJAWQzNhFgC6VkNCAQAipcDrIBkGcBIBAzIDwhRE9DAFRZUEUgSFRN AEwgUFVCTElDACAiLS8vVzNDkSLQRFREIeQ0LhFg5FRyAHJ0aQIgB0Ai0PBFTiI+EeMghyEwCqP5 JTwxOSFAIfIlLiAgJ5CIRUFEJS0xNzchQOBUSVRMRSUtIBAO8ABSRTogW1ZSUtBQXSBRClBzJHIE INkCICBkJCABgC0IkAAwIC12cnJwLeBwdhw0LSRwB4ARIC0wMkouDNB0Jo04NSFAL18qnycyJi8y Dyb2Ng7wPOBNRVRBIAWgAjAJ8Fh0PSIF4CHzNiPgMCguMjg2kTEOQDgiJiAkoAeAPUck8EVS8EFU T1IlLSvhMNApHxcg8TOfIOE1EWA8Qk8cRFklLR+ROv9nOTZxIUBESVYlICCTACEgzwAAP3URYCBp NjQ/X0BiCSacNDghQEZPTlTsIGYA0DegIhcpN1AZk1w9IzaQNpABICAAkHrdN6AyP0sV0AMwYxPw A7IvAdADMEI/IMM4KOFTUDRBTj2UYwtgBBA9OAE20DEwNTQyMi1lNsEzAdAwNj9PQFNGAmkRIHQs IEkgajJ1LPAgdwBwBUB0b/4gB4ACMCSBTqARAAVATfADT2ALgGsgQm9iIN8RAAQgOHw9lU9gZT4M FPBfMNBKAkwpTDdCrjU+4S//Q+JTn0BeAcBMNwqiVEgKgP0mnDAo4SMwPytUTz0fPi//Pz9Xb0Ff XI9Df0SPRZ9Gr39Hv0jPSd9K70v/YFYAcXfvEzFOsVIBIqB3T+AQ8E6g1wdxTqJOIGU3UHEs1WZg bHBvBUACIC5Qr13jSf9SP1NPaI9Vb3PPV49Yn1mv/1q/ds9c313vXv9gD2EfYi//Yz9kT2VfZm9n f4J/aZ9qr/drv4ANGiBjB0ADIE9jblLKdwWwZAuAZyALgG5Dx3BgBZBOUXNuJwVAb9DfJGBucHD/ fhIFEGcOsHJf/3NviK91j5P/d694v3nPet//lv98/34Pfx+AL4E/gk+DX/+Eb4V/ho+Hn6Kvib+K z4vfP6A9qzFOkW8STfAaIGFk/49ABUCSj5OfqN+Vv7C/sc//pBgKo6S/pc+m36fvtF+qC3erL6w/ oGooAHCu/1F3c8cIYL+wBCBsaWtucFAy/yDwCdEEICRgr0+wX7q/sn//xG+X35jvmf+bD8dvnS+e P/+fT6BfoW+if7UfpJ+3j7ifv7mv0x+p76r/vZ/QrW4J4C3BoWHBwQJAbI6zayn/TdDC/8QP2U/G L+FP4l+1r//VT9Zf12/Yf+UPvA/b/90P+dE0YnW//86f4I/kb+Kv/+O/89/UL+c/6E/pX+pv9t// 2o/tT+5f0NpuUg8gBPRPIv9QNlIQGiDxv/LP/N/07wU//8hPyV/Kb8t/CD/Nn/Fvz7//0M/R39Lv 94/4n/mv+r/7z78T7/3v/v8ADxF9j1Np3rBgZS1tYWmOIMJlZfZ4FgDfIHlOUMLQbuADz/8E3xof Bv8i7yP/5j8WHxcv/xg/GU8mr+yfHM8d3+/FcID/IV3xPyIPJe8kLyU/NW8nX/8ovynPKt8r7zhv Gz8cTy/ffRGMbSEAcHC/sG3wjxFz/zNvNH8+jzafRf8JHwovCz//DE9I/w5vMx8QjxGfEq8Tv/85 PzpPO188bz1/VK8/n0Cvf0G/bM+/wEOxIKCP0FdBbr9W0HChkACOUo3wcEBnbjD/RI9Fn1rfR79j j2SfJ99W3/9X71j/Wg9nTy4/XY9en1LE/HdyAtCPMDIfUE9i72bP/2UPZh92X1XfaZ9qr2u/bM// eV9cP2+vcL9fbGFTjpF0H/91L38/d0+Gn0nfSu9L/00P/4mfTy9zz1FPUl9Tb1R/ee//ev98D30f fi+VT4BPgV+Cb5mS3XJ13zDesHNol8DqbL/AYsIAdGHwH+DB8f5zl9ChgYUAIQCFL4Y/m3//iF+k P6VPaH+Xf5iPmZ+ar1+n/5zPnd+e75U5ZALQJ/x0LqLPo9+uP6X/tT+Kf/+Lj4yfja+4P4/PkN+R 75L//5QPlR+on5c/qw+sH60vw+//r0+wX7Fvw5+z77T/zs+3HwPQ38qfICZuYnNwwjvIeFwnYTDB z7nP/7rfu++8/9Rvvx/AL84fwk//35/Eb8V/xo/Hn8ivyb/Kz+/L38zv4Z/ggkLwMUOy5ND1Q+Bz AiBm5bByUSEwREH/H2QfkaGhYHHloQIgcs/d4v9gADHR5QDPT9Bf6H/Sf/O//9d/2I/Zn9qv9r/c z93f3u//3//hD+If4y/kP+VP5l/nb58Cb+mP6p/rr//9cXUgcDvvAGEgLGERolJhcm9t6SBxdXBh EHYFIWACD4fz8I/+AkknD5DyT/NfCJ//9X8Tr/ef+K/5v/rPFq/87//9//8PAB8BLwI/A08EXwVv /wZ/B48iXwmvCr8Lzx/tDnB5D5JmZXNQJmBhcO9wZltgwBCAYTHA7bAu7ZBvcmIuUXlzDkAQrx3y Iv8SPxNPKI8VbzLvM/8p9yrgxURQPWDQLXVzLF82v30p40Im2y+QOc8jbyRyQdnu4GFsJY8mn2Zz kSfvdSChQe+AeSTQMA8d423bD4HvkG6hoT9Qd/ItNQ//Nh8xnjt6R58x30mPIJI9DZIxRmFCUibZ XGzvEP8SIUo/N384jzmfOq87v1O//z3fPuMqhD9PQF9BbyCD7wB3DxBEwiUQdj8A74ChcHS3RUBg 0EKwZA+RLoFlDxD7ROAv4W3vcFoAcpEnsEM/7x3yXizvkg+ReUV/Ro9KL/9Ir2QvZT9L30zvTf9P D2dP/1EvUj9TT1cPqbk+01pvcH//Vz1ZKybbW3N0f1c9Wg8ngdMoT23dVFIkIEdVLyBWW2ygofBs 7fAP0mYq4HCOcO8SX88d8m9jYyTgfnOzv2jRfa5nL3lfJG8i/ybfIEcxbCn/Kw8sH4Tf1V//1m+N /2ivhI9ir2O/k1+Ub/+Vf5aPl5+Yr5m/ms+b35G//54PF88Y3xnvGv+ePx0fHi//Hz+hTyFfpm9u L28/rE+Fv/9yv3PPsD9173b/eA+0P3ov/3s/t89x34b/iA+7H4o/i0//jF+vn59foG/ET5z/xl/H b//If8mPyp/Lr8y/zc/O38S//8XP0h+Ov4/PoZ+ir6O/pM//1E+m76f/qQ+qH6svw9/AX/+uX+J/ u6+xj7Kf5m+0v7XP/7bf6m+4/7oP7f+8L70/vk9fv1/jz8HPwt/gmk5FMCAQSSAqZA4gJ3QqxiAO sEShZXhwJRAlAD5uJICAv95jXQAQUGN0XnU/AQ5wXcBZUGth4Hf+aCUQEi/Tr9y/0D8A3wHv/wL/ BA8FHwYvBz8ITwlfCm//AE+g/9h/2Y/an9uvDM/dz//e39/vD9/iDxT/5C/lPxrf/+df6G/pfx7P 65/sr+2/Is//79/w7yZf8w/0H/UvKa/3T//4Xx1vXGT/MGGARRRcoFkw/yxgHNAr0GHgwZD8jxZE /1CocXVp/1BkXwBzRQD7+wAv8GsyoWIADX8Ojy3f/wsfOJ85rzq/O8883z3vPv//QA9BHw1POA8P bxB/EY8Sn/8Tr0SPFc8W3zFfGP8aD0y//xwvHT9Snx9fIG8hf1aPI5//JK9Zf1qPJ98o714fKw8s Hz8tL2FvL08wX1UvULJ3aTsysGPQdPuSgIJUgCBv7YBxaftANjBiarE0b/2zP/8AanBtwP4AY2Fq wHRy5nUy8DKwYXRFL0Y/ZY//Qs9wj3Gfcq9zv3TPdd927/93/3kPRP9v/0cfSC9JP0pP/0tffH9N f06PaQ9Qr1G/hK//U99U74qPVw9YH1kvjn9bT/9cX5Fvkn9fj2Cflg9iv2PPf2TfmV9m/2gPjR8y dG7wIDf8EaKQm2Br/qCbQWlst5vQMvAzsHQ0T/2WY/9Q95+QM/H98WOlw/8vfd+ED/96b3t/qS+q P6tPrF+tb65//6+PsJ+xr6ePs99/z4Dfge//gv+0D4Ufhi+HP7cfiV+8P/+Lf4yPwh+Z34+/kM/G D5Lv/5P/lQ/KD5cvmD/Nn5pfm2+/nH/Q756fn6+gv8A3Yc9Ab2qQuODT4aNSb/vAM1Fp3m0y8G2h pC+94mQz8DXy/j+077X/vC+yj98v4D/hT//iX+Nv5H/lj+af56/ov96f/+rv1i/EL9kv0X/SjsgP yR//8h/LP8xP9V/Ob89/0I/5///Hd9OP1J/9H9a40uPXX9hv/cAKV6Ji27+9tTKx68/s3/8A/+lv CZ8Krwu/DM8N3w7v/w//EQ8SH+ufCQ+277f/uQ//uh+7LxWPvU++XwTPwH/Bj/8dv+9P8F8jn/3/ 89/07yeP//cP+B8qfyuP+0/8Xy8f0o9//z8ATzJv1s8DzyYvIbJjv2rgo9BuUDUQbaDbYGNrcH8h IAfxpdAGnx8DJcBrAHIza9DbgG50poCiU21h/aMQcxYvFz82jxPPQR9CL/9DP0RPRV9Gb0d/SI9J nxX//0CPGB8ZLxo/G08cX00PHn//H486DyGvIr9VPyTfJe9bH/8oDykfKi9fDyxPLV9h/2MP/zCP MZ9mnzO/NM8132nvN/+/OQ9dr6IUo7A8AF0AZGuw3mQ8Qm3gouSmgGyl4AaP61Z0ptBsYNBidICi RKYR/10ATa9Ov24PS094z3nfeu//e/99D34ffy+AP4FPTX94P/9Pn1CvUb9Sz1PfhL9V/1cP/3GP WS9aP4zvXF9db5LPX4//YJ9hr5a/Y89k35mvmr9oD/9pH55Paz9sT21foZ9vf3CP55VfkOI+OSB3 CADdcNoh/6WQPLCbwHNQdM+OM9rXBnHbo6CjsHCN0HZxP4Vfhm//pb+C/7Cfsa+yv7PPtN+17/+2 /7gPuR+FL7APh0+IX4lv/4p/i4+8j42vjr+pP5Dfke//xL+UD5Ufyp+XP5hPmV/Oj/+bf5yP0X/S j5+/oM/WH6Lvf6P/pQ/Zb6cvqD/NL8iySfMGUDywZW10v8X/vd/ED/+6b7t/5m/nf+iP6Z/qr+u/ /+zP7d/u7+TP8R/eD8wP4Q//9L/ab8//0Q/4X9Mv1D/VT//8r9dv2H8AP89r27/czwOf/97o2xPf j+CfOqsFwD7ArhK5PsB1aTwQrgBy0G8/QNk8wC0tq0J3EHkFwOLvxXXVdDuQbnNtDWDyT//zXwd/ 7+8STxNfFG8VfxaP/xefGK8ZvxrP8h8Rv78fwC//wT/CT8NfHj/Ff8aPC0/Ir//JvyZv9c/23yxP BH/6X/tv/zA//Y/+nzMvND8BzwLfN8//2r8FvwbPOx/e/wpPLt8qYjc9EHMgPcAsrjDicGNhty6g dJCroXCq0HZxbURw3w7vJ8JzQXLUNVB1DXCq4P8NsnayHt8f7z8/HH9KL0s//0xPTV9Ob09/UI9R n1KvHq//SZ8gzyHfIu8j/yUPVh8nL/8oP0K/Kl8rb15PLY8un2Qv/zC/Mc8y32gfNP82D2sPbB// OT86T2+vPG89fz6Pcv9Ar39Bv2a/YkJFVa4yDcEQOCB8KmWuAEggRe+tdEQyKvo/DhJiR+BEcHkw 4lBWv/9Xz3cfVF+B/4MPhB+FL4Y//4dPiF+Jb4p/Vo+Bb1ivWb//Ws9b31zvje9fD2Afep9iP/9j T5YfZW9mf5v/aJ9pr2q//5/vbN9t76Lfo+9xH3Ivp3//dE91X3Zvqs94j3mfno+aEmhzYXlEcifi 0EVSYf18IHl935dvj0+Vf4vfjO//uH+5j7qfu6+8v73Pvt+/7//A/7bfwy+vf51/sn/Gz6vf/6Fv on/Kb6Sfpa+mv86/qN//qe/STwTvrW+uf8cPCS+xX9vJD5oDasjg4nFvDfBHcPUNIGdFIGLXwOJw R3K0//O2ApcAcmcQQMRPxV/Zf//B7+Nf5G/lf+aP55/or+m//+rP69/EH+LPkH+Rj5Kfk6//lL/v T5bfl+/dT5oPmx/3f//Hz8jf/V/Wf8xfzW8BT8+P/9CfBD8FT9PP1N8I36wf178/2M8ML7Bf3E// 7/tyYXB4cGxpRMBH9EiBgGAg+mRIECfe0OA/+N/wv/bv/+1P7l8aTxtfHG8dfx6PH5//IK8hvyLP GK8k/xDv/u8T7/8jDw1PAt8D7yw/Bg8HHy9//zCPCk8LXzQf1v8O3w/vKN/v2z8Szyrf+3J5fOAW rxez3nVHQDnARDBHMS4mDycf/zs/I69EH0UvRj9HT0hfSW//Sn9Lj0yfJd9Dj/Hf8u/z///1D/Yf UA/4P/lPPw/7b/x//1g/KY8qn14fOD8uHy8vYg//MU8yX2T/Zg81jzafaZ8Nf/85fzqPbO88rz2/ Ps9xH1Ev/1dfTb9Oz3gveT96T3tffG//fX9+j3+fgK92j4Lfg+8RokAmbmJzcDtwGFz4J2EwW99T 31TvVf9XD/+Gj1kvWj91D1xfkb+G31+P/5GPlL9iv2PPZN+Yr2b/aA//m59qL2s/bE+gP25vb39w j0+U/xHvdA+XTyBPphBpz7RA3zG0QN6jYmUVcJbg8eAQcGVvFUDgH4/kFfB2dq4gmlB3s9C0QLAA buh0ZWQV0G+EP4VPp3//gd+yX7NvtH+1j7aft6+4v/+5z7rfhA+xz1Kfih+LL4w//41Pvk+Pb5B/ qv+Sn5Ovxn//lc+W38xfmP+aD5sf0E+dP/+eT9M/1E+hf6KP19+kr6W//6bP2y+o76n/zu/Kcq1Q r9AOYq4RsMDVQW5maWcb3aDkgWiuL8e0bnVtm61Q3eBvyeDlQHRyzkCcc22sgNlAFmBzLNkw/7Df v+/GH7x/6j/rT+xf7W//7n/vj/Cf8a/yv/PP6a/Az//B38Lvw//FD/Yvxy/IP8lP//k/y2/+X82P zp8EP9C/0c//0t8IL9T/1g/XHwwv2T/aT/8Pv9xv3X/ejxMP4K/hvwbPYQJTbm93J6yS5ZBjRa+Q bhUwPyBJr9Bkv+gQQIDkoeW//8KtUGkGQHev0AYQHYB0rhHk0RUwcv5usJD23/fvFz/0fyIvIz// JE8lXyZvJ38ojymfKq/2r/8hn/jP+d/67/v//Q8uH/8v/wA/Gr8CXwNvNk8FjwafPC//CL8Jzwrf QB8M/w4PQw9EH/8RPxJPR68UbxV/Fo9K/xivFxm/Pr86QncdgGggZHJlrdBuZB9S5OBU0Wx8eSBO 8B3vN6LnreeRZ/1MwGSuEFFA52Euvy/PTx//LF9aH1svXD9dT15fX29gf/9hj2KfLo9ZjzCvMb8y zzPf/zTvZg83DzgfUp86PztPbj//PW8+f3QfQJ9Br0K/eA9E3/9F73r/fA9JH0ovf59MT01f/05v gu9Qj1Gfdq9yMuVy59CTsIDokGJ1rTBJJ6+xPyCAr7CFoFWPb5KE8HR1P3ngVTGtUHZA5EetAmlm /nlmr2e/hw9kT5IPkx+UL/+VP5ZPl1+Yb5l/mo9mf5F//2ifaa9qv2vPbN+d/27/cA//io9yL3M/ pi91X3ZvrA94j/95n3qvr/98z33fsu+z/4EP/4Ift4+EP4VPhl+634h/iY9/rp+qIq3wVUDlQMEQ VOF3PmhVQOVw5UDlkLyQY2sv57AcUI1/p4J3vUBsZDxuJx2Q5CGuML1AZ2j/np+fr77/nD/Jj8qf y6/Mv//Nz87fz+/Q/9IPnm/I/9VP/7/fp1St767/uz+xH7Iv3C//tE+1X7Zv4C+4j7mf47+7v/+8 z73f5w/ZP+kywP/CD6mq/i7WH9cv65/Tv/JP81/0b//1f/aP95/4r/m/+s/V7/G//6CPoZ+ir6O/ pM/+P6bvp///72+qH6svBm+tT9r/DE/dH//eL98/ED/hX+JvEy8UP+Wf/+avF8/oz+nf6u8bH+0P 7h//7y8fT/9fBY/77/z/Jl8nb/8ofymPKp8rryy/Lc8u3yS/BzEPMh/AUiZuYnNwwjseSFwnYTAK DwIP/wMfBC8FPzS/B18IbyM/Co//P+81Dw2/P79C7xDvEf8TD/9G3xUvFj9JzxhfGW8af05v/xyf Ha8ev0MvIN8h7yL/QLT8LWTEUDJvM39VrzAPXI//XZ9er1+/YM9h32LvY/9lD/8yP1v/AM84Tzlf Om87f2h//z2fPq9Zf0DPQd9wr0P/RQ//do9HL0g/SU96f0tvTH99b/9+f0+vUL+CD1LfU+9U/4Vf /1cfWC9ZP4mPaZ9vz2YvZz//kJ+Rr5K/k8+U35Xvlv+YD/+ZH47/m0+cXzXvNv9r32zvL23/bw+e j8XYNXtRL0KYT0RZiHBw+zI3paFwSFRNTKjNiVFx830Bq8AAAB4AQhABAAAAUQAAADwxOTI5QjhD NUIzMTg1MjQ0OTU3MjdEOEEyNDFEQUZCMjAxNDdGREI4QE5BRUFNSUxMRVgwM1ZBLm5hZHN1c2Vh Lm5hZHMubmF2eS5taWw+AAAAAAMAAlkAABYAAwAJWQIAAAALAACACCAGAAAAAADAAAAAAAAARgAA AAADhQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAKgAggBgAAAAAAwAAA AAAAAEYAAAAAUoUAAD9xAQALAAuACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMADIAIIAYA AAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwANgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAe AA6ACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAACwAPgAggBgAAAAAAwAAAAAAA AEYAAAAABoUAAAAAAAADABCACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAB4ANoAIIAYAAAAA AMAAAAAAAABGAAAAAIOFAAABAAAAEwAAADg4MDEwNTQyMi0yODAzMjAwNgAAAgH4DwEAAAAQAAAA RC0ZLomniUKDAYXoRnf4OgIB+g8BAAAAEAAAAEQtGS6Jp4lCgwGF6EZ3+DoCAfsPAQAAAJEAAAAA AAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERv Y3VtZW50cyBhbmQgU2V0dGluZ3NcZHByb3ZhblxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBE YXRhXE1pY3Jvc29mdFxPdXRsb29rXGRvbi5wc3QAAAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAA MQAAADAwMDAwMDAwNDQyRDE5MkU4OUE3ODk0MjgzMDE4NUU4NDY3N0Y4M0FDNDE2NjYwMwAAAAAD AAYQPBsRtgMABxBbBQAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEZJUlNULElKVVNUV0FO VFRPTUVOVElPTlRIQVRJVEhJTktCT0JIQVNUSEVBTlNXRVJUT1RIRSJXSElDSFRJTUVUT1VTRSJR VUVTVElPTlNQT1RPTklSRUNBTExUSEFUVEhFV08AAAAARu0= ------=_NextPart_000_0046_01C6527C.F1E86740 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 ------=_NextPart_000_0046_01C6527C.F1E86740-- From vrrp-bounces@ietf.org Wed Mar 29 06:49:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZAi-0000Ew-8M; Wed, 29 Mar 2006 06:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOZAg-0000Cn-8H for vrrp@ietf.org; Wed, 29 Mar 2006 06:49:06 -0500 Received: from gate12-norfolk.nmci.navy.mil ([138.162.5.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOZAf-0000HX-M3 for vrrp@ietf.org; Wed, 29 Mar 2006 06:49:06 -0500 Received: from naeanrfkms03.nmci.navy.mil by gate12-norfolk.nmci.navy.mil via smtpd (for stiedprmail1.ietf.org [156.154.16.150]) with ESMTP; Wed, 29 Mar 2006 11:49:05 +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; Wed, 29 Mar 2006 11:49:05 +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 Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Date: Wed, 29 Mar 2006 05:49:00 -0600 Message-ID: <1929B8C5B318524495727D8A241DAFB20147FDBA@NAEAMILLEX03VA.nadsusea.nads.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Thread-Index: AcZSv/9scl9ygSijTwCLdlz76MHJeQAY054A From: "Hott, Robert W CIV B35-Branch" To: "Don Provan" , "Steve Bates" , X-OriginalArrivalTime: 29 Mar 2006 11:49:01.0255 (UTC) FILETIME=[C569DD70:01C65326] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 Cc: "Odonoghue, Karen F CIV B35-Branch" 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="===============0806291926==" Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. --===============0806291926== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65326.C51F1FB8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65326.C51F1FB8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Don, What I have seen in doing some testing with faster advertisement intervals and more/fewer advertisements leads me to a conclusion with may or may not be correct. I will offer my observation though. =20 I have done testing of various techniques for providing survivable network environments. I have looked at standards-based solutions as well as proprietary enhancements. I have looked for solutions that can detect failures and recover in less than 1 second. =20 When I have tested VRRP using timer settings which adhere to the standard, I have seen very little problems. I can certainly introduce a load on the network with can cause packets to be dropped, but for the most part, devices are capable of transmitting and receiving an advertisement within the 3 second window. =20 When I have tested VRRP, and other protocols, using timer settings which permit sub-second failovers, there have been instances where flapping has occurred and I did not need to introduce a load on the network. This observation leads me to believe that the issue is in the implementation of the particular survivability technology. With some technologies, it appeared that the protocol was activated based upon a timer and that the protocol would not perform faster than a certain rate, regardless of the settings. In these cases, if the rate and number of messages missed were configured in such a way, flapping would occur! I have also seen cases where the load on the network APPEARS to slow down the handling of the advertisements (i.e., not high enough priority process), and flapping has occurred. In some cases, enabling logging has been enough to cause flapping to occur, when using sub-second intervals. Please note that I have not always been able to test with a particular vendor's top-of-the-line device. That is one reason why I think it is important to test these technologies with devices, and images, that are planned for a particular computing environment. =20 I hope this has cast a little light on my interest in sub-second capability and a little on what I have seen when looking at various technologies and implementations. =20 Bob Hott =20 -----Original Message----- From: Don Provan [mailto:dprovan@bivio.net] Sent: Tuesday, March 28, 2006 18:33 To: Hott, Robert W CIV B35-Branch; 'Steve Bates'; vrrp@ietf.org Cc: Odonoghue, Karen F CIV B35-Branch Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt First, I just want to mention that I think Bob has the answer to the "which time to use" question spot on. I recall that the wording in the spec wasn't quite right last time I read it (and it sounds like Bob agrees it needs a little work), but the description Bob has here in this e-mail agrees exactly with both my ponderings and my experience on what can go wrong and what the rules should be to make sure they don't. =20 But my purpose for writing this is to explore another question, one that comes up over and over and I've never felt satisfied about. Bob says, "As you move into lower=20 time intervals between Advertisements, missing 3 Advertisements is very=20 likely and flapping occurs."=20 =20 Now I *don't* have experience in actual networks where these lower tolerances are required, so I ask this without having an opinion, but is it in fact true that that per packet failure rate increases in cases where a shorter failover time is desired? What is the characteristic of these environments that makes the standard of 3 packets less reliable that in an environment where a 3 second failover is acceptable? It seems counter intuitive to me -- when you retransmit faster, it causes a problem, and the solution to that problem is to retransmit *even faster*? -- but, as I say, it's probably just something about the target application that I don't yet understand. =20 Or is this just because people have always wanted to be able to configure the number of retransmissions, so now's the chance? I admit to being a little concerned with depending on only 3 retransmissions regardless of the rate, but I've never actually been able to justify any reason why three packets wouldn't be enough. =20 -don =20 ------_=_NextPart_001_01C65326.C51F1FB8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [VRRP] Questions on = draft-ietf-vrrp-ipv4-timers-02.txt
Don,
    What=20 I have seen in doing some testing with faster = advertisement
intervals = and more/fewer=20 advertisements leads me to a conclusion
with may or = may not be=20 correct. I will offer my observation though.
 
    I=20 have done testing of various techniques for = providing
survivable = network=20 environments. I have looked at standards-based
solutions as = well as=20 proprietary enhancements. I have looked for
solutions = that can=20 detect failures and recover in less than 1 second.
 
    When=20 I have tested VRRP using timer settings which adhere
to the = standard, I have=20 seen very little problems. I can certainly
introduce a = load on the=20 network with can cause packets to be
dropped, but = for the=20 most part, devices are capable of transmitting
and = receiving an=20 advertisement within the 3 second window.
 
    When=20 I have tested VRRP, and other protocols, using timer
settings = which permit=20 sub-second failovers, there have been
instances = where flapping=20 has occurred and I did not need to
introduce a = load on the=20 network. This observation leads me to
believe that = the issue=20 is in the implementation of the particular
survivability=20 technology. With some technologies, it appeared
that the = protocol was=20 activated based upon a timer and that
the protocol = would not=20 perform faster than a certain rate,
regardless = of the=20 settings. In these cases, if the rate and
number of = messages=20 missed were configured in such a way,
flapping = would occur! I=20 have also seen cases where the
load on the=20 network APPEARS to slow down the handling of
the = advertisements=20 (i.e., not high enough priority process),
and flapping = has=20 occurred. In some cases, enabling logging
has been = enough to cause=20 flapping to occur, when using
sub-second = intervals.=20 Please note that I have not always been
able to test = with a=20 particular vendor's top-of-the-line
device. That = is one=20 reason why I think it is important to test these
technologies = with=20 devices, and images, that are planned for
a particular = computing=20 environment.
 
    I=20 hope this has cast a little light on my interest in=20 sub-second
capability = and a little=20 on what I have seen when looking at
various = technologies and=20 implementations.
 
Bob=20 Hott
 
-----Original Message-----
From: Don Provan=20 [mailto:dprovan@bivio.net]
Sent: Tuesday, March 28, 2006=20 18:33
To: Hott, Robert W CIV B35-Branch; 'Steve Bates';=20 vrrp@ietf.org
Cc: Odonoghue, Karen F CIV=20 B35-Branch
Subject: RE: [VRRP] Questions on=20 draft-ietf-vrrp-ipv4-timers-02.txt

First, I just want to mention that I think = Bob has=20 the
answer to the "which time to use" question = spot on.=20 I
recall that the wording in the spec wasn't = quite=20 right
last time I read it (and it=20 sounds like Bob agrees it
needs a little work), but=20 the description Bob has = here
in this e-mail agrees exactly with=20 both my=20 ponderings
and my experience on what can go = wrong=20 and what the
rules should be to make sure they = don't.
 
But my purpose for writing this is to = explore=20 another
question, one that comes up over and over = and=20 I've
never felt satisfied about. Bob says,=20 "As=20 you move into lower
time intervals between Advertisements, = missing 3=20 Advertisements is very
likely and = flapping=20 occurs." 
&nbs= p;
Now I *don't* = have=20 experience in actual networks=20 where
these lower = tolerances are=20 required, so I ask = this
without having = an opinion,=20 but is it in fact true = that
that per packet = failure rate=20 increases in cases = where
a shorter = failover time is=20 desired? What is=20 the
characteristic = of these=20 environments that = makes
the standard of = 3 packets=20 less reliable that in = an
environment = where a 3 second=20 failover is = acceptable?
It seems=20 counter intuitive to me -- when you=20 retransmit
faster, it = causes a problem,=20 and the solution to = that
problem is to = retransmit=20 *even faster*? -- but, as = I
say, it's = probably=20 just something about the=20 target
application that = I don't=20 yet=20 understand.
&nbs= p;
Or is this just = because=20 people have always wanted = to
be able to = configure the=20 number of retransmissions, = so
now's the = chance? I admit to=20 being a little = concerned
with depending = on only 3=20 retransmissions regardless = of
the rate, but = I've never=20 actually been able to = justify
any reason why = three packets=20 wouldn't be enough.
&nbs= p;
-don=
&nbs= p;
------_=_NextPart_001_01C65326.C51F1FB8-- --===============0806291926== 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 --===============0806291926==-- From vrrp-bounces@ietf.org Wed Mar 29 12:07:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOe8d-0000kD-W3; Wed, 29 Mar 2006 12:07:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOe8c-0000k3-If for vrrp@ietf.org; Wed, 29 Mar 2006 12:07:18 -0500 Received: from postal1.ind.alcatel.com ([208.8.0.237] helo=ind.alcatel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOe8b-0006jV-Dy for vrrp@ietf.org; Wed, 29 Mar 2006 12:07:18 -0500 Received: from mailhub1.ind.alcatel.com (mailhub1.ind.alcatel.com [198.206.181.170]) by ind.alcatel.com (8.12.9/8.12.9/(postal1 2.1 [OUT])) with ESMTP id k2TH7GAP003991; Wed, 29 Mar 2006 09:07:16 -0800 (PST) X-InterScan: Passed Received: from mailhub1.ind.alcatel.com (localhost [127.0.0.1]) by mailhub1.ind.alcatel.com (8.12.10/8.12.10/(mailhub1 4.1.4 [HUB1])) with ESMTP id k2TH7EBx005410; Wed, 29 Mar 2006 09:07:14 -0800 (PST) Received: from sbates ([128.251.40.224]) by mailhub1.ind.alcatel.com (MailFrontier 4.1.1.5579) with ESMTP; Wed, 29 Mar 2006 09:07:14 -0800 From: "Steve Bates" To: "'Hott, Robert W CIV B35-Branch'" , Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Date: Wed, 29 Mar 2006 10:10:09 -0700 Message-ID: <000a01c65353$a2a437e0$e028fb80@sbates> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-reply-to: <1929B8C5B318524495727D8A241DAFB20147FDB8@NAEAMILLEX03VA.nadsusea.nads.navy.mil> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal X-Mlf-Threat: nothreat X-Mlf-Threat-Detailed: nothreat;none;list_addrbk_domain X-Spam-Score: 0.1 (/) X-Scan-Signature: fd911903d9eb33179d1ec28b0417afe8 Cc: "'Odonoghue, Karen F CIV B35-Branch'" 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="===============0675241201==" Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. --===============0675241201== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C65318.F646E680" This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C65318.F646E680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bob, =20 In regard to the responses for both 1 & 2, that's what I'm driving at. We've changed the rules to allow a mismatched packet to reach the state machine but haven't addressed in the draft how the state machine should react. =20 For 3, another thought, if aig were some logarithmic function: 1/(10 ** = x) where x is the value of the field, we could support values for as long = as there are bits without modifying a RFC. On the other hand, fixed values = do conserve bits. I have no strong feelings one way or the other. =20 For 4, the reason I say we don't gain much is because the value being = passed is the Master's value. Since we've already shown in 2 that this value = can be meaningless to a less capable backup virtual router the question is = how much autonomy should a backup have? One advantage to a configured advertisement count is that a backup on an unreliable link can adjust = its value independently to avoid flapping. =20 And finally, for 5, not passing the advertisement count would also free = up space. IPv4 and IPv6 should be as silmilar as possible.=20 =20 Steve -----Original Message----- From: Hott, Robert W CIV B35-Branch [mailto:robert.hott@navy.mil]=20 Sent: Monday, March 27, 2006 9:50 PM To: Steve Bates; vrrp@ietf.org Cc: Odonoghue, Karen F CIV B35-Branch Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Steve,=20 Sorry I missed your comments the first go around. I did get them=20 and missed responding. Thank you for hitting me with them again. You=20 have some good questions. I think the draft needs to have wording=20 added to clarify what needs to happen. I also think some discussion=20 on the reflector is in order with regard to timers, granularity, and=20 counts. Thank you for the comments. See my response and observations=20 below. Hopefully this will get some discussion going!!=20 Bob Hott=20 -----Original Message-----=20 From: Steve Bates [mailto:Steve.Bates@alcatel.com]=20 Sent: Wednesday, March 22, 2006 18:04=20 To: Hott, Robert W CIV B35-Branch; vrrp@ietf.org=20 Subject: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt=20 Hi Bob,=20 I've posted these comments before but I'll rephrase them based on the 02 = draft.=20 1) Back in early December there was a flurry of comments about = mismatched=20 advertisement intervals causing multiple masters. The consensus seemed = to=20 be that virtual routers of a lower priority would ignore a mismatch if = the=20 higher priority interval was less than their configured interval and = make=20 the higher priority interval their own operational value when it was = greater than their configured interval. I was under the impression, based on=20 Radia's response to your original December 2nd post, that this would be=20 reflected in the draft. Other than the omission of the phrase "the = receiver MUST discard the packet" in the final paragraph of section 4.1 I don't = see=20 anything about this. =20 Steve, removing the phrase from Section 4.1 about discarding the packet=20 was needed so that mismatches would get handled in the STATE MACHINE.=20 If the Advertisements were discarded, multiple Masters could occur.=20 Now, with regard to which timer to use, I think that the consensus was=20 to use the MASTER values when there was a mis-match. Clock granularity = could impact what is actually used, see my response to your question #2, = below.=20 When I look at your questions and the draft, I think the draft needs=20 to better identify and discuss the values used; whether it is the=20 configured value, the value received from the MASTER, etc...=20 2) This may become a greater issue with the addition of advertising = interval granularity. It's conceivable that one implementation might not be able = to=20 support as fine(?) a granularity as another, while both are type 2 = virtual=20 routers. For example, suppose a higher priority virtual router A is=20 configured with adver_cnt =3D 3, aig =3D 1, and adver_int =3D 1, while a = lower=20 priority virtual router B is configured with adver_cnt =3D 3, aig =3D 2, = and=20 adver_int =3D 1. Virtual router B MUST accept virtual router A's values = to=20 avoid flapping - unless it discards the FAST ADVERTISEMENT and creates a = two master situation. Conversely, if the priorities are reversed B's values = are useless to A if A is incapable of supporting the finer granularity but = at=20 least A will maintain it's backup state. Am I mistaken?=20 Okay, so here is how it should work, not saying that the wording is in=20 place:=20 If Router A is Master (or any router with a granularity less than its=20 Backups), then the Master will propagate its values to the Backups.=20 The Backups, in this case Router B, should be able to set its=20 timer (Master_Down_Timer) based on the received adver_cnt and adver_int=20 in the advertised clock granularity (centiseconds) units, since its=20 own clock granularity was milliseconds. This should work fine.=20 Now for the opposite situation, where the Master has a clock=20 granularity greater that its Backups. So, Router B is now the Master=20 and Router A is the Backup. Here, Router B sends the advertisement=20 once every millisecond. Since Router A cannot set its timer to 1=20 millisecond, it should set its timer based upon its own lowest setting.=20 In this case, 1 centisecond should be used. Router A won't failover to=20 become Master as fast as Router B would like (3 microseconds) but it=20 will eventually become Master, as soon as it can. Once Router B=20 becomes the Master, if it does, it would use its configured settings.=20 I think the draft needs to better describe which settings should be=20 used, based upon clock granularity. Thus, the Master_Down_Interval=20 needs to reflect the Master settings and the internal settings. =20 3) The two bit granularity field seems a bit shortsighted. A) There are = some RTOSes where a "tick" is defined as 1/60th of a second. This makes = achieving centisecond granularity difficult. A decisecond value would = be=20 nice. B) But if we do that we've used up all the values in the field. = Ten=20 years from now we'll be on terabit networks and someone may want = microsecond granularity. Another bit might be a good idea.=20 I tend to agree with you about the need for more bits for granularity.=20 This kind of relates to your last question, below. I figured that=20 the last bit would be used for microseconds, but wondered about the=20 decisecond need. I thought that the 10 bits for centiseconds would=20 cover the decisecond requirement.=20 4) I don't dispute the desirability of a configurable advertisement = count=20 but I'm not sure we gain much passing it in the advertisement.=20 The issue that I have with the current Master_Down_Interval is that it=20 is based upon a fixed Advertisement Count of 3. As you move into lower=20 time intervals between Advertisements, missing 3 Advertisements is very=20 likely and flapping occurs. I think that missing 3 Advertisements was=20 reasonable when the failovers were in the order of seconds. I guess=20 one option would be to change to way that the advertisement_interval=20 is calculated and only pass the acceptable outage period ( = failover_time).=20 What do you / everyone think about that? So, in the Advertisement, you=20 would pass the desired failover time. On the Master, it is configured to = send Advertisements every=20 (Failover_Time / Configured_number_per_interval). The Backups would=20 only care about Failover_Time and clock granularity.=20 5) For the VRRPv3 packet there are only 4 bits available since the=20 advertisement interval uses 12. Do you have an idea how to migrate this = draft to the IPv6 case?=20 I think the right way to handle this for IPv6 is to do the same thing=20 for both V4 and V6. If the discussion on your 4th question moves the=20 standard to specify a failover time, then I think there will be=20 enough room to specify a clock granularity. My original proposal=20 was not to introduce a new version of VRRP, but add a new=20 message type. If IPv4 and IPv6 were aligned, maybe it would be=20 better to use a single type advertisement and introduce a new=20 version. What do folks think?=20 Steve Bates=20 Bob Hott=20 ------=_NextPart_000_000B_01C65318.F646E680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Bob,
 
In regard to the responses for both 1 & = 2, that's=20 what I'm driving at.  We've changed the rules to allow a mismatched = packet=20 to reach the state machine but haven't addressed in the draft how the = state=20 machine should react.
 
For 3, another thought, if aig were some = logarithmic=20 function:  1/(10 ** x) where x is the value of the field, we could = support=20 values for as long as there are bits without modifying a RFC. On the = other hand,=20 fixed values do conserve bits.  I have no strong feelings = one way=20 or the other.
 
For 4, the reason I say we don't gain much is = because the=20 value being passed is the Master's value.  Since we've already = shown in 2=20 that this value can be meaningless to a less capable backup virtual = router the=20 question is how much autonomy should a backup have?  One advantage = to a=20 configured advertisement count is that a backup on an unreliable = link can=20 adjust its value independently to avoid = flapping.
 
And = finally, for=20 5,  not passing the advertisement count would also free up=20 space.  IPv4 and IPv6 should be as silmilar as possible.=20
 
Steve
-----Original Message-----
From: = Hott, Robert W=20 CIV B35-Branch [mailto:robert.hott@navy.mil]
Sent: Monday, = March=20 27, 2006 9:50 PM
To: Steve Bates; = vrrp@ietf.org
Cc:=20 Odonoghue, Karen F CIV B35-Branch
Subject: RE: [VRRP] = Questions on=20 draft-ietf-vrrp-ipv4-timers-02.txt

Steve,

  Sorry I=20 missed your comments the first go around. I did get = them=20
and missed=20 responding. Thank you for hitting me with them again. = You=20
have some good=20 questions. I think the draft needs to have wording =
added to = clarify what=20 needs to happen. I also think some discussion =
on the = reflector is in=20 order with regard to timers, granularity, and =
counts. = Thank you for the=20 comments. See my response and observations
below. = Hopefully this will=20 get some discussion going!!

Bob=20 Hott

-----Original=20 Message-----
From:=20 Steve Bates [mailto:Steve.Bates@alcatel.com]=20
Sent: Wednesday, = March 22, 2006=20 18:04
To: Hott,=20 Robert W CIV B35-Branch; vrrp@ietf.org
Subject: [VRRP] Questions on=20 draft-ietf-vrrp-ipv4-timers-02.txt


Hi = Bob,

I've posted these = comments before=20 but I'll rephrase them based on the 02
draft.

1) Back in early = December there=20 was a flurry of comments about mismatched
advertisement intervals = causing multiple=20 masters.  The consensus seemed to
be that virtual routers of a = lower priority=20 would ignore a mismatch if the
higher priority interval was less than their = configured=20 interval and make
the higher priority interval their own operational value when = it was=20 greater
than their=20 configured interval.  I was under the impression, based = on=20
Radia's response to = your original=20 December 2nd post, that this would be
reflected in the draft.  Other than the = omission of the=20 phrase "the receiver
MUST discard the packet" in the final paragraph of section = 4.1 I don't=20 see
anything about=20 this. 

Steve, removing=20 the phrase from Section 4.1 about discarding the = packet=20
was needed so=20 that mismatches would get handled in the STATE = MACHINE.=20
If the=20 Advertisements were discarded, multiple Masters could = occur.=20
Now, with regard=20 to which timer to use, I think that the consensus = was=20
to use the=20 MASTER = values when there was a mis-match. = Clock granularity=20 could
impact what is actually used, see my response to your = question #2,=20 below.
When I look at your questions and the draft, = I think the=20 draft needs
to better identify and discuss the values = used; whether=20 it is the
configured value, the value received from the = MASTER,=20 etc...


2) This may become a = greater issue=20 with the addition of advertising interval
granularity.  It's = conceivable that=20 one implementation might not be able to
support as fine(?) a = granularity as=20 another, while both are type 2 virtual
routers.  For example, = suppose a=20 higher priority virtual router A is
configured with adver_cnt =3D 3, aig =3D 1, and = adver_int =3D 1,=20 while a lower
priority virtual router B is configured with adver_cnt =3D 3, = aig =3D 2,=20 and
adver_int =3D=20 1.  Virtual router B MUST accept virtual router A's values=20 to
avoid flapping -=20 unless it discards the FAST ADVERTISEMENT and creates a = two=20
master = situation. =20 Conversely, if the priorities are reversed B's values = are=20
useless to A if A = is incapable of=20 supporting the finer granularity but at
least A will maintain it's = backup=20 state.  Am I mistaken?


Okay, so here is=20 how it should work, not saying that the wording is = in=20
place:

If Router A is=20 Master (or any router with a granularity less than = its=20
Backups), then=20 the Master will propagate its values to the Backups.
The Backups, = in this case=20 Router B, should be able to set its
timer = (Master_Down_Timer)=20 based on the received adver_cnt and adver_int =
in = the advertised clock granularity=20 (centiseconds) = units, since its =
own clock = granularity was=20 milliseconds. This should work fine.

Now for the=20 opposite situation, where the Master has a clock =
granularity greater that=20 its Backups. So, Router B is now the Master =
and Router = A is the=20 Backup. Here, Router B sends the advertisement =
once every = millisecond.=20 Since Router A cannot set its timer to 1
millisecond, it should set=20 its timer based upon its own lowest setting. =
In this = case, 1=20 centisecond should be used. Router A won't failover = to=20
become Master as=20 fast as Router B would like (3 microseconds) but it=20
will eventually=20 become Master, as soon as it can.=20 Once Router B
becomes the Master, if it does, it would use = its=20 configured settings.

I = think the draft=20 needs to better describe which settings should be =
used, = based upon clock=20 granularity. Thus, the Master_Down_Interval =
needs to = reflect the=20 Master settings and the internal = settings.  

3) The two bit = granularity field=20 seems a bit shortsighted.  A) There are
some RTOSes where a "tick" is = defined as=20 1/60th of a second.  This makes
achieving centisecond granularity = difficult.  A=20 decisecond value would be
nice.  B) But if we do that we've used up all the values = in the=20 field.  Ten
years from now we'll be on terabit networks and someone may = want=20 microsecond
granularity.  Another bit might be a good = idea.

I = tend to agree=20 with you about the need for more bits for = granularity.=20
This kind of=20 relates to your last question, below. I figured that =
the last bit=20 would be used for microseconds, but wondered about = the=20
decisecond need.=20 I thought that the 10 bits for centiseconds would =
cover the = decisecond=20 requirement.

4) I don't dispute = the=20 desirability of  a configurable advertisement count =
but I'm not sure we = gain much=20 passing it in the advertisement.

The issue that I=20 have with the current Master_Down_Interval is that = it=20
is based upon a=20 fixed Advertisement Count of 3. As you move into = lower=20
time intervals=20 between Advertisements, missing 3 Advertisements is = very=20
likely and=20 flapping occurs. I think that missing 3 Advertisements = was=20
reasonable when=20 the failovers were in the order of seconds. I guess=20
one option would=20 be to change to way that the advertisement_interval=20
is calculated=20 and only pass the acceptable outage period ( failover_time).
What do you=20 / everyone think = about that? So,=20 in the Advertisement, you
would pass the desired=20 failover time. On the = Master, it is=20 configured to
send Advertisements every=20
(Failover_Time /=20 Configured_number_per_interval). The Backups would
only care about Failover_Time = and clock=20 granularity.


5) For the VRRPv3 = packet there are=20 only 4 bits available since the
advertisement interval uses 12.  Do you = have an idea=20 how to migrate this
draft to the IPv6 case?

I = think the right=20 way to handle this for IPv6 is to do the same=20 thing
for both V4 and V6. If the discussion on your 4th question = moves=20 the
standard to specify a failover time, then I think there will=20 be
enough room to specify a clock granularity. My original proposal =
was not to = introduce a new=20 version of VRRP, but add a new
message type. If IPv4 and IPv6 = were aligned,=20 maybe it would be
better to use a single type advertisement and = introduce a=20 new
version. What do folks think?


Steve = Bates

Bob=20 Hott

------=_NextPart_000_000B_01C65318.F646E680-- --===============0675241201== 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 --===============0675241201==-- From vrrp-bounces@ietf.org Wed Mar 29 13:47:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfhh-0003xX-SH; Wed, 29 Mar 2006 13:47:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOfhf-0003vl-W4 for vrrp@ietf.org; Wed, 29 Mar 2006 13:47:35 -0500 Received: from stimpy.bivio.net ([216.142.75.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOfhf-0003R4-7z for vrrp@ietf.org; Wed, 29 Mar 2006 13:47:35 -0500 Received: from dprovan1 ([192.168.24.150]) by stimpy.bivio.net (8.12.8/8.12.8) with SMTP id k2TIlOXI023315; Wed, 29 Mar 2006 10:47:24 -0800 From: "Don Provan" To: "'Hott, Robert W CIV B35-Branch'" , "'Steve Bates'" , Subject: RE: [VRRP] Questions on draft-ietf-vrrp-ipv4-timers-02.txt Date: Wed, 29 Mar 2006 10:47:52 -0800 Message-ID: <002101c65361$4927dc40$9618a8c0@corp.networkrobots.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0022_01C6531E.3B27B4A0" 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.1506 X-MS-TNEF-Correlator: 00000000442D192E89A78942830185E84677F83AE4B96603 In-reply-to: <1929B8C5B318524495727D8A241DAFB20147FDBA@NAEAMILLEX03VA.nadsusea.nads.navy.mil> Importance: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b Cc: "'Odonoghue, Karen F CIV B35-Branch'" 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: , Errors-To: vrrp-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C6531E.3B27B4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 T0ssIHBsZWFzZSBleGN1c2UgbWUgZm9yIGRvdWJ0aW5nIHlvdSwgYnV0IEknbQ0KYWZyYWlkIHRo aXMgcmVzcG9uc2UgaGFzIGtpbmRhIHN1cHBvcnRlZCBteSBmZWFycy4NClRoZSBpc3N1ZXMgeW91 J3JlIHRhbGtpbmcgYWJvdXQgLS0gYW5kIEkgbm90ZQ0KdHVybmluZyBvbiBsb2dnaW5nIGFzIGEg c3BlY2lmaWMgY2FzZSAtLSBzaG91bGQNCmhhdmUgdGhlIGVmZmVjdCBvZiBkZWxheWluZyB0aGUg cHJvY2Vzc2luZyBvZiBlYWNoDQppbmRpdmlkdWFsIHBhY2tldCBpbmNsdWRpbmcgdGhlIG9uZSB0 aGF0IHNob3VsZA0KaGF2ZSBwcmV2ZW50ZWQgdGhlIGZsYXAuIFRoYXQgc3VnZ2VzdHMgdGhhdCB0 aGUNCm92ZXIgYWxsIHRpbWVvdXQgaXMgdG9vIHNtYWxsLCAqbm90KiB0aGF0IHRvbyBmZXcNCnBh Y2tldHMgd2VyZSB0cmFuc21pdHRlZC4NCiANCkJ1dCBzaW5jZSB5b3UndmUgb2J2aW91c2x5IGlu dmVzdGlnYXRlZCB0aGlzIHdheQ0KYmV5b25kIGFueXRoaW5nIEkndmUgZG9uZSwgcGVyaGFwcyB5 b3UgYWxyZWFkeSBoYXZlDQp0aGUgbW9yZSBkZXRhaWxlZCBkYXRhIHRoYXQgd291bGQgY29udmlu Y2UgbWUuDQpGaXJzdCwgYXJlIHlvdSBzdXJlIHlvdXIgdGVzdHMgd2VyZSBjaGVja2luZyB0aGUN Cm51bWJlciBvZiBwYWNrZXRzIHRyYW5zbWl0dGVkIHdpdGhvdXQgY2hhbmdpbmcgdGhlDQpsZW5n dGggb2YgdGhlIHRpbWVvdXQuIEFuZCwgc2Vjb25kLCB3ZXJlIHlvdSBhYmxlDQp0byBjb25maXJt IHRoYXQgZmxhcHBpbmcgd2FzIGNhdXNlZCBieSBwYWNrZXRzIHRoYXQNCndlcmUgbG9zdCBhbmQg bm90IGJ5IHBhY2tldHMgdGhhdCB3ZXJlIGRlbGF5ZWQuDQogDQpJJ20gbm90IGFyZ3VpbmcgYWdh aW5zdCBiZWluZyBhYmxlIHRvIGNvbmZpZ3VyZQ0KdGhlIG51bWJlciBvZiByZXRyYW5zbWlzc2lv bnMsIGFzIGxvbmcgYXMgZXZlcnlvbmUNCmFncmVlcyBWUlJQIG5lZWRzIGl0LiBJIGp1c3Qgd2Fu dCB0byBtYWtlIHN1cmUgd2UNCnVuZGVyc3RhbmQgKGFuZCB0aGUgc3BlYyBleHByZXNzZXMpIHdo YXQgdGhpcyByZWFsbHkNCmFjY29tcGxpc2hlcy4gSW4gbXkgZXhwZXJpZW5jZSAod2hpY2ggd2Fz LCBhZG1pdHRlZGx5LA0KbGltaXRlZCB0byBteSBpbXBsZW1lbnRhdGlvbiksIEkgZm91bmQgdGhh dCBsaW1pdHMNCnRvIHRoZSB0aW1lb3V0IHdlcmUgKmFsd2F5cyogY2F1c2VkIGJ5IHBhY2tldCBs YXRlbmN5LA0KbmV2ZXIsIGV2ZXIgYnkgcGFja2V0IGxvc3MuIEkgaGF2ZSBzZWVuIHByb2JsZW1z DQpjYXVzZWQgYnkgcGFja2V0IGxvc3MsIGJ1dCB3aXRoIG5vcm1hbCBpbnRlcnZhbHMNCmFzIG11 Y2ggYXMgd2l0aCBzbWFsbCBvbmVzLg0KIA0KT24gYW5vdGhlciBub3RlLCBJIHRoaW5rIHdlIGFn cmVlIHRoYXQgdGhlIGxvd2VzdCwNCnJlbGlhYmxlIHRpbWVvdXQgcGVyaW9kIGRlcGVuZHMgb24g bWFueSBmYWN0b3JzDQppbiB0aGUgaW1wbGVtZW50YXRpb24gYW5kIGluIHRoZSBlbnZpcm9ubWVu dDsgaXQNCmlzbid0IHNvbWV0aGluZyB0aGF0IGNhbiBiZSBkZWZpbmVkIGJ5IHRoZQ0KcHJvdG9j b2wuIEkgd29uZGVyIGlmLCBhdCB0aGVzZSByYXRlcywgd2UgY2FuIG9yDQpzaG91bGQgYWRkIHNv bWUgcnVsZXMgZm9yICJmbGFwcGluZyByZWNvdmVyeS4iDQpXaGVuIGEgYmFja3VwIGluYXBwcm9w cmlhdGUgdGFrZXMgb3ZlciB0aGUgVlIsDQp0aGUgY29ycmVjdCBtYXN0ZXIga25vd3MgaXQuIEkg d29uZGVyIGlmIHdlIHNob3VsZA0KYWRkIHNvbWV0aGluZyBmb3IgYSBtYXN0ZXIgdG8gYW5ub3Vu Y2UgdGhhdCBpdCB3YXMNCmluYXBwcm9wcmlhdGVseSByZXBsYWNlZCBhbmQgc2V0IGEgaGlnaGVy IHRpbWVvdXQNCnRvIGF2b2lkIGZ1dHVyZSBtaXN0YWtlcz8gSnVzdCBhIHRob3VnaHQgb2ZmIHRo ZQ0KdG9wIG9mIG15IGhlYWQuLi4uDQogDQotZG9uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBIb3R0LCBSb2JlcnQgVyBDSVYgQjM1LUJyYW5jaCBbbWFpbHRvOnJvYmVydC5o b3R0QG5hdnkubWlsXQ0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyOSwgMjAwNiAzOjQ5IEFNDQpU bzogRG9uIFByb3ZhbjsgU3RldmUgQmF0ZXM7IHZycnBAaWV0Zi5vcmcNCkNjOiBPZG9ub2dodWUs IEthcmVuIEYgQ0lWIEIzNS1CcmFuY2gNClN1YmplY3Q6IFJFOiBbVlJSUF0gUXVlc3Rpb25zIG9u IGRyYWZ0LWlldGYtdnJycC1pcHY0LXRpbWVycy0wMi50eHQNCg0KDQpEb24sDQogICAgV2hhdCBJ IGhhdmUgc2VlbiBpbiBkb2luZyBzb21lIHRlc3Rpbmcgd2l0aCBmYXN0ZXIgYWR2ZXJ0aXNlbWVu dA0KaW50ZXJ2YWxzIGFuZCBtb3JlL2Zld2VyIGFkdmVydGlzZW1lbnRzIGxlYWRzIG1lIHRvIGEg Y29uY2x1c2lvbg0Kd2l0aCBtYXkgb3IgbWF5IG5vdCBiZSBjb3JyZWN0LiBJIHdpbGwgb2ZmZXIg bXkgb2JzZXJ2YXRpb24gdGhvdWdoLg0KIA0KICAgIEkgaGF2ZSBkb25lIHRlc3Rpbmcgb2YgdmFy aW91cyB0ZWNobmlxdWVzIGZvciBwcm92aWRpbmcNCnN1cnZpdmFibGUgbmV0d29yayBlbnZpcm9u bWVudHMuIEkgaGF2ZSBsb29rZWQgYXQgc3RhbmRhcmRzLWJhc2VkDQpzb2x1dGlvbnMgYXMgd2Vs bCBhcyBwcm9wcmlldGFyeSBlbmhhbmNlbWVudHMuIEkgaGF2ZSBsb29rZWQgZm9yDQpzb2x1dGlv bnMgdGhhdCBjYW4gZGV0ZWN0IGZhaWx1cmVzIGFuZCByZWNvdmVyIGluIGxlc3MgdGhhbiAxIHNl Y29uZC4NCiANCiAgICBXaGVuIEkgaGF2ZSB0ZXN0ZWQgVlJSUCB1c2luZyB0aW1lciBzZXR0aW5n cyB3aGljaCBhZGhlcmUNCnRvIHRoZSBzdGFuZGFyZCwgSSBoYXZlIHNlZW4gdmVyeSBsaXR0bGUg cHJvYmxlbXMuIEkgY2FuIGNlcnRhaW5seQ0KaW50cm9kdWNlIGEgbG9hZCBvbiB0aGUgbmV0d29y ayB3aXRoIGNhbiBjYXVzZSBwYWNrZXRzIHRvIGJlDQpkcm9wcGVkLCBidXQgZm9yIHRoZSBtb3N0 IHBhcnQsIGRldmljZXMgYXJlIGNhcGFibGUgb2YgdHJhbnNtaXR0aW5nDQphbmQgcmVjZWl2aW5n IGFuIGFkdmVydGlzZW1lbnQgd2l0aGluIHRoZSAzIHNlY29uZCB3aW5kb3cuDQogDQogICAgV2hl biBJIGhhdmUgdGVzdGVkIFZSUlAsIGFuZCBvdGhlciBwcm90b2NvbHMsIHVzaW5nIHRpbWVyDQpz ZXR0aW5ncyB3aGljaCBwZXJtaXQgc3ViLXNlY29uZCBmYWlsb3ZlcnMsIHRoZXJlIGhhdmUgYmVl bg0KaW5zdGFuY2VzIHdoZXJlIGZsYXBwaW5nIGhhcyBvY2N1cnJlZCBhbmQgSSBkaWQgbm90IG5l ZWQgdG8NCmludHJvZHVjZSBhIGxvYWQgb24gdGhlIG5ldHdvcmsuIFRoaXMgb2JzZXJ2YXRpb24g bGVhZHMgbWUgdG8NCmJlbGlldmUgdGhhdCB0aGUgaXNzdWUgaXMgaW4gdGhlIGltcGxlbWVudGF0 aW9uIG9mIHRoZSBwYXJ0aWN1bGFyDQpzdXJ2aXZhYmlsaXR5IHRlY2hub2xvZ3kuIFdpdGggc29t ZSB0ZWNobm9sb2dpZXMsIGl0IGFwcGVhcmVkDQp0aGF0IHRoZSBwcm90b2NvbCB3YXMgYWN0aXZh dGVkIGJhc2VkIHVwb24gYSB0aW1lciBhbmQgdGhhdA0KdGhlIHByb3RvY29sIHdvdWxkIG5vdCBw ZXJmb3JtIGZhc3RlciB0aGFuIGEgY2VydGFpbiByYXRlLA0KcmVnYXJkbGVzcyBvZiB0aGUgc2V0 dGluZ3MuIEluIHRoZXNlIGNhc2VzLCBpZiB0aGUgcmF0ZSBhbmQNCm51bWJlciBvZiBtZXNzYWdl cyBtaXNzZWQgd2VyZSBjb25maWd1cmVkIGluIHN1Y2ggYSB3YXksDQpmbGFwcGluZyB3b3VsZCBv Y2N1ciEgSSBoYXZlIGFsc28gc2VlbiBjYXNlcyB3aGVyZSB0aGUNCmxvYWQgb24gdGhlIG5ldHdv cmsgQVBQRUFSUyB0byBzbG93IGRvd24gdGhlIGhhbmRsaW5nIG9mDQp0aGUgYWR2ZXJ0aXNlbWVu dHMgKGkuZS4sIG5vdCBoaWdoIGVub3VnaCBwcmlvcml0eSBwcm9jZXNzKSwNCmFuZCBmbGFwcGlu ZyBoYXMgb2NjdXJyZWQuIEluIHNvbWUgY2FzZXMsIGVuYWJsaW5nIGxvZ2dpbmcNCmhhcyBiZWVu IGVub3VnaCB0byBjYXVzZSBmbGFwcGluZyB0byBvY2N1ciwgd2hlbiB1c2luZw0Kc3ViLXNlY29u ZCBpbnRlcnZhbHMuIFBsZWFzZSBub3RlIHRoYXQgSSBoYXZlIG5vdCBhbHdheXMgYmVlbg0KYWJs ZSB0byB0ZXN0IHdpdGggYSBwYXJ0aWN1bGFyIHZlbmRvcidzIHRvcC1vZi10aGUtbGluZQ0KZGV2 aWNlLiBUaGF0IGlzIG9uZSByZWFzb24gd2h5IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIHRl c3QgdGhlc2UNCnRlY2hub2xvZ2llcyB3aXRoIGRldmljZXMsIGFuZCBpbWFnZXMsIHRoYXQgYXJl IHBsYW5uZWQgZm9yDQphIHBhcnRpY3VsYXIgY29tcHV0aW5nIGVudmlyb25tZW50Lg0KIA0KICAg IEkgaG9wZSB0aGlzIGhhcyBjYXN0IGEgbGl0dGxlIGxpZ2h0IG9uIG15IGludGVyZXN0IGluIHN1 Yi1zZWNvbmQNCmNhcGFiaWxpdHkgYW5kIGEgbGl0dGxlIG9uIHdoYXQgSSBoYXZlIHNlZW4gd2hl biBsb29raW5nIGF0DQp2YXJpb3VzIHRlY2hub2xvZ2llcyBhbmQgaW1wbGVtZW50YXRpb25zLg0K IA0KQm9iIEhvdHQNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERvbiBQ cm92YW4gW21haWx0bzpkcHJvdmFuQGJpdmlvLm5ldF0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI4 LCAyMDA2IDE4OjMzDQpUbzogSG90dCwgUm9iZXJ0IFcgQ0lWIEIzNS1CcmFuY2g7ICdTdGV2ZSBC YXRlcyc7IHZycnBAaWV0Zi5vcmcNCkNjOiBPZG9ub2dodWUsIEthcmVuIEYgQ0lWIEIzNS1CcmFu Y2gNClN1YmplY3Q6IFJFOiBbVlJSUF0gUXVlc3Rpb25zIG9uIGRyYWZ0LWlldGYtdnJycC1pcHY0 LXRpbWVycy0wMi50eHQNCg0KDQpGaXJzdCwgSSBqdXN0IHdhbnQgdG8gbWVudGlvbiB0aGF0IEkg dGhpbmsgQm9iIGhhcyB0aGUNCmFuc3dlciB0byB0aGUgIndoaWNoIHRpbWUgdG8gdXNlIiBxdWVz dGlvbiBzcG90IG9uLiBJDQpyZWNhbGwgdGhhdCB0aGUgd29yZGluZyBpbiB0aGUgc3BlYyB3YXNu J3QgcXVpdGUgcmlnaHQNCmxhc3QgdGltZSBJIHJlYWQgaXQgKGFuZCBpdCBzb3VuZHMgbGlrZSBC b2IgYWdyZWVzIGl0DQpuZWVkcyBhIGxpdHRsZSB3b3JrKSwgYnV0IHRoZSBkZXNjcmlwdGlvbiBC b2IgaGFzIGhlcmUNCmluIHRoaXMgZS1tYWlsIGFncmVlcyBleGFjdGx5IHdpdGggYm90aCBteSBw b25kZXJpbmdzDQphbmQgbXkgZXhwZXJpZW5jZSBvbiB3aGF0IGNhbiBnbyB3cm9uZyBhbmQgd2hh dCB0aGUNCnJ1bGVzIHNob3VsZCBiZSB0byBtYWtlIHN1cmUgdGhleSBkb24ndC4NCiANCkJ1dCBt eSBwdXJwb3NlIGZvciB3cml0aW5nIHRoaXMgaXMgdG8gZXhwbG9yZSBhbm90aGVyDQpxdWVzdGlv biwgb25lIHRoYXQgY29tZXMgdXAgb3ZlciBhbmQgb3ZlciBhbmQgSSd2ZQ0KbmV2ZXIgZmVsdCBz YXRpc2ZpZWQgYWJvdXQuIEJvYiBzYXlzLCAiQXMgeW91IG1vdmUgaW50byBsb3dlciANCnRpbWUg aW50ZXJ2YWxzIGJldHdlZW4gQWR2ZXJ0aXNlbWVudHMsIG1pc3NpbmcgMyBBZHZlcnRpc2VtZW50 cyBpcyB2ZXJ5IA0KbGlrZWx5IGFuZCBmbGFwcGluZyBvY2N1cnMuIiANCiANCk5vdyBJICpkb24n dCogaGF2ZSBleHBlcmllbmNlIGluIGFjdHVhbCBuZXR3b3JrcyB3aGVyZQ0KdGhlc2UgbG93ZXIg dG9sZXJhbmNlcyBhcmUgcmVxdWlyZWQsIHNvIEkgYXNrIHRoaXMNCndpdGhvdXQgaGF2aW5nIGFu IG9waW5pb24sIGJ1dCBpcyBpdCBpbiBmYWN0IHRydWUgdGhhdA0KdGhhdCBwZXIgcGFja2V0IGZh aWx1cmUgcmF0ZSBpbmNyZWFzZXMgaW4gY2FzZXMgd2hlcmUNCmEgc2hvcnRlciBmYWlsb3ZlciB0 aW1lIGlzIGRlc2lyZWQ/IFdoYXQgaXMgdGhlDQpjaGFyYWN0ZXJpc3RpYyBvZiB0aGVzZSBlbnZp cm9ubWVudHMgdGhhdCBtYWtlcw0KdGhlIHN0YW5kYXJkIG9mIDMgcGFja2V0cyBsZXNzIHJlbGlh YmxlIHRoYXQgaW4gYW4NCmVudmlyb25tZW50IHdoZXJlIGEgMyBzZWNvbmQgZmFpbG92ZXIgaXMg YWNjZXB0YWJsZT8NCkl0IHNlZW1zIGNvdW50ZXIgaW50dWl0aXZlIHRvIG1lIC0tIHdoZW4geW91 IHJldHJhbnNtaXQNCmZhc3RlciwgaXQgY2F1c2VzIGEgcHJvYmxlbSwgYW5kIHRoZSBzb2x1dGlv biB0byB0aGF0DQpwcm9ibGVtIGlzIHRvIHJldHJhbnNtaXQgKmV2ZW4gZmFzdGVyKj8gLS0gYnV0 LCBhcyBJDQpzYXksIGl0J3MgcHJvYmFibHkganVzdCBzb21ldGhpbmcgYWJvdXQgdGhlIHRhcmdl dA0KYXBwbGljYXRpb24gdGhhdCBJIGRvbid0IHlldCB1bmRlcnN0YW5kLg0KIA0KT3IgaXMgdGhp cyBqdXN0IGJlY2F1c2UgcGVvcGxlIGhhdmUgYWx3YXlzIHdhbnRlZCB0bw0KYmUgYWJsZSB0byBj b25maWd1cmUgdGhlIG51bWJlciBvZiByZXRyYW5zbWlzc2lvbnMsIHNvDQpub3cncyB0aGUgY2hh bmNlPyBJIGFkbWl0IHRvIGJlaW5nIGEgbGl0dGxlIGNvbmNlcm5lZA0Kd2l0aCBkZXBlbmRpbmcg b24gb25seSAzIHJldHJhbnNtaXNzaW9ucyByZWdhcmRsZXNzIG9mDQp0aGUgcmF0ZSwgYnV0IEkn dmUgbmV2ZXIgYWN0dWFsbHkgYmVlbiBhYmxlIHRvIGp1c3RpZnkNCmFueSByZWFzb24gd2h5IHRo cmVlIHBhY2tldHMgd291bGRuJ3QgYmUgZW5vdWdoLg0KIA0KLWRvbg0KIA0KDQo= ------=_NextPart_000_0022_01C6531E.3B27B4A0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjUSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANYHAwAdAAoALwAAAAMAOQEB A5AGAHxFAAAoAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAA3AAAAW1ZSUlBdIFF1ZXN0aW9ucyBvbiBkcmFmdC1pZXRmLXZycnAtaXB2NC10 aW1lcnMtMDIudHh0AAACAXEAAQAAACAAAAABxlK//2xyX3KBKKNPAIt2XPvowcl5ABjTngAADcuX YAIBHQwBAAAAFwAAAFNNVFA6RFBST1ZBTkBCSVZJTy5ORVQAAAsAAQ4AAAAAQAAGDgCqgilhU8YB AgEKDgEAAAAYAAAAAAAAAEQtGS6Jp4lCgwGF6EZ3+DrCgAAAAwAUDgEAAAALAB8OAQAAAAIBCRAB AAAAs0AAAK9AAACgWwEATFpGdew9pvwDAAoAcmNwZzEyNYIyA0NodG1sMQMwPwEDAfcKgAKkA+MC AGNowQrAc2V0MCAHEwKA/xADAFAEVghVB7IR1Q5RAwHdENcyBgAGwxHVMwRGENmJEu9mNAPGVGFo A3F9EdU1A8YRhRHjCO8J9zt7G38OMDUcnx2jEeEMYGNnAFALCQFkMzYRYAulNLIgEAIqXA6yAZBn IXAAMyA8IURPQ1QAWVBFIEhUTUwAIFBVQkxJQyCAIi0vL1czQyQwSERURCNENC4RYFRycgBydGkC IAdAJDBF+E4iPhHjIecikAqjJpx8MTkioCNSJo4hgCjwRURBRCaNMTc3IqBUcElUTEUmjSFwDvBS AEU6IFtWUlJQ6F0gUQpQcyXSBCACIGwgZCWAAYAtCJAAMC0QdnJycC9AcHY0Di0l0AeAESAtMDIu pQzQdCftODUioC8r/y8okiePM28oVjYO8DxNcEVUQSAFoAIwCfB0LD0iBeAjUzYlQDAuFDI4N/Ex DkA4IiATJgAHgD1HJlBFUkH4VE9SJo0tQTIwKn8iUQs0/yJBNRFgPEJPRI5ZJo0g8TxfZzk2IqC4 RElWJoAh8wAhIAAA50DVEWAhyTY0QL9BwiGrwjgqQVNQQU42wAtgoQQQPTM3OA4hOSugIC0yOTAz AdAwNidAr0PfDhA0OCKgRk+wTlQgZgDQOQAiFynzOLAa8z0jN/A38AEgPvR1AJB6OQAyRwsV0AMw Yx8T8AOyAdADMEF3T0ssCiALUGVFoGUgZXi8Y3VPYQeAScAFsWQIYMJiJdBuZyB5CGBPAERidQVA SSdtJ/w1vUBBL0mCRwlHF0QNORTw/zIwRTJTP0G+AcBHFwqiU+j7CoAn/DAqQSSQQItT7z5//z+P QJ9W/0K/XB9E30XvRv//Yi9JH0ovSz9MT01fX+YvEEElgGlkIHRoBAAgeRuAc3AugU9wEQAEIGvJ C4BkYWqAdXBuMAAguwmAT/B5aCBPQBEgLlHP/1LfW89U/3HvVx9YL1k/Wk//dN9cb11/Xo9fn2Cv Zf9iz/9j32TvgF9nD2gfaS9qP2tPeU39VGhPcAQBLjFQ8if/G4BtoAdAbtFQ4AGgCGAFQLwtLW0w bvBRgDjAbzcA/3BvcX96b3OfkD91v3bPd9//eO+TL3sPfB99L34/f0+En/+Bb4J/g4+er4Wvhr+H z4jf+4nvTf10CHADAFDRLsEbENxnZ41DBCBvEXAFkAaQLw3gNsBPUo3hcxjwdWz+ZI6/j8+Yv5Hv rq+UD5Uf/5Yvlz+xn5lfmm+bf5yPnZ//ou+fv6DPod+9H6P/pQ+mH++nL6g/Tf0RAHaM4YvxARG7 BZAFQG+68AEAC2B5UML9yPJwA2DDsAQQqnO68E9A/xDwrS+uP7cvsF/NT7J/s4//tJ+1r9A/t8+4 37nvuv+8D//BX74vvz/AT9u/wm/Df8SPT8Wfxq9N/W7haXZtgHXjB0DcjiZuYm4gAoDfhzhcJ2EB QNnXCrBja/cRQOcx3eB152DKNQIgjqz36L/pzm2wYQVAOdzXVazP/8x/1W/On8+v2c/Rz9Lf0+// 1P/zj9cf2C/fn9pP/p/cb//df96PAL/gr+G/4s/j3+Tv9+X/yGfKoGXIwDbxbZJPcP/xL/I/+y/0 Xw9fEG8CvwPP/wTfEy8G+AmjB58Irgn/Cw/l/zdmICBwLg3PDt8Sr/8Q/x//IQ8UKAmjFM8V3xbv /xf/GV8abxt/HI+LWe9P8Fb2dasAjGB0q3DvI8jxHo//H58jbyG/Mw/2f/eP+J/5r/81//vP/N/9 7/7/AA8n3yRf/yW/Js9BfyjvKf8rDwmfLN9dTf1vDMBIsI0QbG2gaf9QAI2ibdExjzKfO480v0/P /1DfQx9EL0U/U58Yf0gfK0/nSo9Ln6nVb29OP09PUx//UW9gT2FfJN9VX1ZvY89G/59Z71r/XA9d Hz+1c21NUdYsLx89MyqOcSow9V6h/clQd17fX+9jv2IPc4823/837zj/Og92fzwvPT8+Tz9f/0Bv aC9kr2YPZx+B/2k/ak+/a19J/20vLe3qxKtwd4kg/w2/cv9773Ufdi+Qz4N/hI//hZ+Tj1jPiH9r f4rvi/+pt0hyYW5vIGl0DVEu/45fj2+TP5GPoO93X3hveX//eo+j33yvfb9+z3/fgO+XX/+UL5U/ lk+vX5hviF+a34p//5yvLe2fb6B/qW+in7xvvX//7R/pzqT/pg+nH6gvv5+qT/+rX6xvws+uj8fv sK+xv7LPf83/tO+1/7cPuB+5Lx15Qq9N4daQ60Dr8HlN0CcMwYxvYueATdBzbHnnMXMMwDDAaWcu 8A1jThF3/GF5uu+7/8fPvh/dz8Mf/8QvxT/GT+C/yG/Jf8qPy5//zK/R/87Pz9/Q7+w/0w/UH0/V L9Y/108t7WJl2eBuCw1wnsB528FuZyBJ1doSZPfwZW9wcPNgLuCecDDg2eFNQQ0AYWTa0P8MotxP 3V/mT99//H/hn+Kv/+O/5M//b+bv5//pD+of6y//8H/tT+5f728K7/GP8p/zr8/0v/XPXa4xYCBt EsD48VGNwGFpbNuRZC7wYfUw9HdN0GzboBKQ2wDZk/9NsJ9f+/8E7/4fGs8APwFP/wJfA28dvwWP Bp8Hrwi/Cc//Dx8L7wz/Dg8pPxAvET8ST8cTXxRv9s5GaXLbMG9w/zHw2cMyEDBA2cMwgNuA2zD9 jeVjFoCNoPiCFnEZXxpv/yNfHI85Xx6vH78gzyHfPE//I/8lDyYfJy8oPy2PKl8rb/8sf0fPLp8v rzC/Mc8y37n92G51bffATwBvRaCNhveeqY3wnwBoTrDZYDcQnsD+ZzdvOH9BbzqfO688vz3P/z7f P+9A/1jPQx9EL0ufRk//Y99Ib0l/So9l/0yvTb9Oz/9P31DvUf9kwxdQ+JDbwFOyjxZy20AZIFVx LiBB+ADtNSBzNzD38SzAf8GPwpqfjgP58mErdQBiFGFiF1D/Vn9Xj2B/Wa96r1vPXN9d7/9e/32f YR9iL2M/ZE9lX2qv/2d/aI9pn4kfa79sz23fbu+rb/+dvm8YgmY04G263/96L4MffE+Wz5ffiq+L v4zP/5qfjumRo4+fkK6R/5MPFenlGAFmnFBwcPiC3BDb8OxjYdqg25Fi2tBT9nef/4TiF+KVX5Zv mj+Yj6r/fn//f4+An4Gvre+Dz4Tfhe+G//+ID55fmy+cP51PuW+fb49//6HfkZ+jr9hdNsPBMNsw lU//qn+zb6yfxw/IH7r/vA+9H//K35/vv/+iD8Jvw3+3pfgw+dugbm/ZYKc5F+Q20qfv97UyFwDM kHnbkBlPxp/Kb//Iv9r/rr+vz7Dfse/d77QP/7Ufti+3P7hPzo/LX8xvzX//6W/Pn7+/0g/B39Pf 9s7Zj//an+OP3L/2j/efdP92Dt8f/+Av4T/iT/m/5G/lf+aP/O//6K8CD+rP69/s7wgf7w/wH8/x L/I/808VyUknlTDWIvnQ8Gd1VgIHEBcwVKCpbP/7b3YOU4AUI3jxlJcUADbg//UP9h8B7/g/Gq/9 P/5P/1//AG8dnwKPA58ErwW/Bs8MH/8I7wn/Cw8pHw0vDj8PTxBffxFvpL818FNYNuBUdStwaf1z 4HNzkKaRMOAUMqfNGf//Iu8cHx0vOZ8qezGjK08sX38tby5/L48wnzGvMr/0LGX2dkOAd1BuGR84 TzwfOm//Sd8ebx9/II8hn0zPI78kz/8l3ybvJ/9Ajz0PKy8/f1hPv0GfQq9Dv0TPRd/U72fFEMJl pqBWUlJQE5BkEIpkpqBpczFJIGqm4M/XQdXg10CUoW1hp5BzoP8Y8cThSG9Jf1JvS59of02//07P T99Q72tvUw9UH1UvVj//V09cn1lvWn9bj3bvXa9ev+9fz2DfYe8SfXXV8H4QxWCd1eIo1eI0ohYA ZWNH0Nx4cMUQeUBkICmmcKWyhzSgNgA1cWFsbHlm//9oD3D/ai+HP2xPbV9ub29//4ovcZ9yr3O/ dM9133svd///eQ96H5WvfD99T35ff2+Af8XU/mOdUG1wbIUgNLD6c2UhbmYgp0CEAZzQnMCObpxA gxCEsGljaKZyJzZw17+RcmFkNfB0dPvZUIWQLIW/hs+Pv4jvp2//iw+MH40vjj+qX5BfkW+Sf/+T j5Sfme+Wv5fPmN+135r//5wPnR+eL58/En2hkKVR2VDPZfPWcMFwoYBlbaLQsTDadDYxKTZwZUBm vMCDQ/uE0cFjc6Xvpv+v76kfxg//qz+sT61frm/I/7CPsZ+yr/+zv7TPuh+277f/uQ/Uf7sv/7w/ vU++X79vM75mEDSiwuDfwpDbYGWR26AYQCqFcKOQaHlzKtaQYWVwwbFi+6JQ3RBjZlCE4KPv0ELW sP+lgKLgpc/Ff85vx5/Ir9LP/8rPy9/M7+kPzw/QH9Ev0j//00/Yn9Vv1n/Xj/SP2a/av//bz9zf 3e/e/0hAR/E2cEfi/+I5/HD3AGUihMBH8P1wZBDroiCEIG8YIW3Ef+W/7q//598Er+n/6w/sH+0v B5/vT//wX/Fv8n/zj/jf9a/2v/fP/xMf+e/6//wP/R/+L98O4d8bAZI2cGLgwBP+Jm5ihYOwOxbo XCdhMBE43ndlAKNw4u8O8m4bAGYwbmwgXyFvInppZdAaUHb/hXADLwQ/DS8GXyofCH8Jj/8Knwuv LQ8Nzw7fD+8Q/xIP/xdfFC8VPxZPOI8Ybxl/Go8/G58cr6A/KJwmDyI+bXWXo2E64CMkcyUBbCDD AP+h0SivKb8yryvfSi8t/y8P/zAfMS9NHzNPNF81bzZ/N4//PN85rzq/O89Ynz3vPv9AD/9BH0Iv oE1Ir0m/Uq9L32Wv/2a/RR8iPk4/T09QX1FvaN//U49Un1WvbA9Xz3EvWe9a//9cD3c/Xi9fP2BP YV9ib99Zek+iIGEk0OAxfjCCwWWzwzKFAW5r4OGhIGfhEJ/gUcPi4DJ+wODwc3Tkr/9lL3D/Z0+H H2xPbV9ub29//4oPcZ9yr3O/dM9133svd///eQ96H5WPfD99T35ff2+Af7ffDuEQwWBhAuHgZ3Cc wPPC8MOwZGWiMMOgR4DDAN9HEIKwwiCcEcHgciifhq//j5+Iz6WPiu+L/40Pjh+of/+QP5FPkl+T b5R/mc+Wn5ev/5i/s/+a35vvnP+eD58f3w5/KBDgI8JMgqHDsL+V5GB26mkCwG7AUjvBICBMpO// rd+nD6gfsj+qP6tPrF/Gz//FH6+PsJ+4D7K/0C+037Xv/7b/0k+5H7ovuz+8T71fvm+RJ/Fzbifi wHNvodDdg7JnhJQesAKQYuEgoqD+ZsEw4hSC4cKfw6/Mn8XP/+I/x+/I/8oPyx/lL80/zk//z1/Q b9F/1s/Tn9Sv1b/wr//X39jv2f/bD9wfQz0CsaPQO/hRAdJ3SFCioPfgaWb/IACExAJgoRDAkEhw IACEEf/fYviA4L/hz+q/4+8Av+YP/+cf6C/pPwOv61/sb+1/7o//75/07/G/8s/z3w8v9f/3D0/4 H/kv+j9DPXNoFhBs/x8A/z8ATwk/Am8crx2/EM//Ed8S7yB/FQgXsxWvFr4YD/sZH0OYZOAw3nKh EBrg/mAjJqAXACAiZiIgcHC/3tIJ6wgQCtSEYBbQdidg+HkuIhsvHD8gDx5fML//BI8FnwavB78z rwnfCu8L//8NDw4fJC8g/yIPIx8/LyU/3xWPJ68Xryl/vq1XgvDA0ePgQEWwa3VwwSEs0cHgz/ww oVD+UIOgYWssMS7C+YTjVlKFnzA/OS8yX08P/zR/NY82nzevUf85zzrfO+//PP8+D0NfQC9BP0JP XX9Eb39Ff0aPR59Iryp+hPJlMHJfLpHfQKNQhXBksWuDMHf/owDCcPy7hAIatE2fTq9Xn/9Qz22/ Uu9T/1UPVh9wr1g//1lPWl9bb1x/Yc9en1+vYL//fC9i32PvZP9mD2cfKo8rlH/etCxiSwBp1aPQ wOFqUHX+boLA3wTCcP6QfnBsP21P/3Y/b2+MX3GPcp9zr3S/j0//dt9373j/eg97H4BvfT9+T/9/ X5rPgX+Cj4OfhK+Fv76v/Uu5bOBgLpDAIKFR4DDA8u/+AN9ASwDewGf94E0BwAD+ZaGwwo+L35TP jf+q35Af/5Evkj+TT63PlW+Wf5ePmJ//ma+e/5vPnN+d77lPoA+hHx+iL6M/pE9oH4lxdm9p3eAw ZqlAwFD+sG3eEExz8D8gSnVp8Erx/dDAQPuooN9Ab8Gx4I+qT7M/rG//rX+3n6+fsK+xv8wvyn+0 7/+1/7cPuB+9b7o/u0+8X9ev/75/v4/An8Gvwr/Dz4lRS3Dfx3BpwKcw/eArcC7kQcfv/8j/0e/L H+YPzT/OT89f0G//6P/Sj9Of1K/Vv9bP3B/Y7//Z/9sP9H/dL94/30/gX+Fv/6Vt5I/ln+6P578B jwKf9hFAJm5ic3A7+Dhc+CdhMPKP6o/rn+yv7b//BS/v3/Dv+F/zDxBfBX/2P//3TxJ/+W/6f/uP /J/9r/6/+RFCLWRrEAAPAR8M7wM//yAvCD8JTwpfC28jHw2PDp8BD6NCTE9DS1FVwE9URSBkaRrA EfBjGhAbZHR5bBmBFMBEAQ/wTkctTEVGVAA6IDVweDsgTRhBUkct4C4aQk9S2ERFUi4VGuYyLpCH 4YZsxUAut1JJR0guUfowLpAiHBkbYilSLKEbcchccWw0MmNo/18pv/kRiTI0NcA4MCqfD+IU9UZP qUAaoG9rTcZAc7kSEGVI5BEaASxmYTGgxGduLJBlZnQcGzRPHzSwaGkRjxbfPVBpMzbzF88Y21Rh a+Bp0DbEODBfG78cwSeAHW9G0k8Z4GdfS5E+gDqVRtNB3DErglK7MxoxoG7H0TVPFBhCHBtKYmhp RqagbTohfy8DTIooqSBIb3R0LDAgUm9iGgCKUFcgfkM5kTXrRbE27xRiOEFCYDM1LUJyp+A1EVtl adBpP7BvOqagUZIui2vgUTBApmB2eS7F4PxsXUh/SY9Kn0uvTL8+5HBTZW50Tm9Pf1CHV0OnsFlg c2RheVFQTf8bgDURFgBRUFJPU19UZBZCACAzOjQ5IEFNv1dPWF9Zb1p/W48+5FRV0JddT15fUJZE HoAgUKagVnan4C6wU4kgdsXAQj2m8XMusGE/Yk9UZHZyrTRgQBnwJXAuGrBnZH+fZY9mn2evaL8+ 5ENjak8ra19Qh08ecW+ooHVl/VFQSxuAXQBOEFH/b09UH39VInHfcu9z/3UPdh9clXVwYmplY10v eK9QeFICRS5gW1ZSUlBdrCBResAtMGkegHPHYG9tEHvPfN9UZGRVEDxwLQ1xUi1xAowAcHY0LQGo 8nJzLTAyLnT+eKldf8+A343fju+P/x7f/x/vPs8kzyXfJu+VT5OPNq//N78PP0AvPx+fv0E/FB8V I/+RsBWQneCRoBX/Fw9CDxkhv0QFGoscGx0joGds8SyT3/+U75sfId+t75Zvl3+Yj5mf/7Dfm7+c z53fnu+f/6EPoh//oy+kP6VPpl+2vwZPB1/DD//EH8Uvxj/HT1CHp8+o36nvk6r/tvBXaG4gIEnj 8HNWwG3wc2V7MZLgLFBvfZLgZzFxjSDjUIiC0ZF3/Gl0NSAZUC0wGgGJP7gv71RkOyBt4LMgadDg jSBdEP+sb61/tm+vn9gvsb+yz7Pf/7Tv2x+3D9RfuS+6P7tPvF//vW++f7+PwJ/Br+D/QorNr9/O v+YkkuDTEW1gbIjgVSAuZNNP4l991W0asGUv/mYaQBoB1duI4C1gOyCI4J3R4m874BpxfrBsdURw /x6P15/gj9m/2s/mL9zv3f//3w/8H+Ev8w/jT+Rf7D/mf/8Gj+if6a/qv+vPAf/t7+7/7/APB3HS k0PQeYjwGhASsv96gFHAUZDyHwN/fdUagHEQrYTRLtBh0pBsR5BvGzD9GgFtEtHJ8PFyiKLSAEOw +nV6oC73z/jfAc/6/xqf//0f/i//PwBPHY8CbxTfBI//BZ8Grwe/CM8J3wrvC/8ND/8jb8x/zY8Q 3y9PGa8inxvP/xzfNj/JL8o/KI8fTyBfIW//OG85fySfJa8mvy6fKN9Fv/8q/ywPLR8uL0EvOj87 T01//06PT59Qr1G/yw8wHzGfMq//RnXQcBPfQs9jVNCTemHR+PUXUCBtYHKIsPdw0gFgwLhuaXGI cdLQEvFwbUH8aWTRgTQvNT9BDzdfYc//PF89bz5/P49kv0GvW39Dz/9E30XvRv9ID0kfSi9LP0xP X2qfVx9YL1k/0bB18YBpXV5AYvZAE1CMIHd4kGu/Wm9r/4tF0QBf4F/AbvXjxxbC0JN4gG9rZfIA 0EHP0wDx4X0g9nAtYtLwgCD/YE9hX2pPY3+C/2WfZq9nv/9oz4Xvau99H20Pbh9vL3A//3FPcl9z b3R/dY+Lz3eveL//ec/RsfdgGFLxwV6g9RAXIb+csXwfjT/VdF+xX7Bpe6D/nnATQNEA0DD3QPXU f15fcf+Bf4KPi3+Er6Qfhs+H34jv/4n/pw+MH55vjj+PT5BfkW//kn+Tj5Sfla+Wv6zvmN+Z7++a /5wJ0rDQQWPx4J1frk/9fiVke6AWkdLRFxB68F9B//HiFoFf0PUh0TH2QLaQvcLt0UAx0NH3IWQZ D6OfrI//pb/Ff6ffqO+p/6sPyG+tL/+/X69PsF+4P7J/0t+0n7Wv/7a/t8/OTzBvMX+7n9ovxI// zX/Gr8e/4R9Tv1TP02/KL//LP8xP40/kX89/0I/Rn9l//9O/8J/V39bv1//ZD+wP5R//5i/4X/lv +n/7j/yfVZ/a/+fcD90fWW1XaKCgf2ZdksGAIVZSUlAgXpBd0m9dwKEQwoAYAHRdwpzBaJ5pXuC+ X+2vfiVhZAXA/8Ig3x/gL+v/4k8NT+dP6F//6W/qfxA/7J8J7+6/78/w3//x7/L/9A/1H/Yv9z8W H7n/dwOPBJ/DEG/DEV0ggIYs/1pPF19cbAfwBdHCYaCAHdDvCBB7YV+xe1FtoVO+IqDw4xKAwWBu bHkLzwzfFc//Dv8ujxEfEi8TPxRPMX8Wb/8onxiPGZ8arxu/HM8d3x7vfx//IQ83XyMvJD8lT8KR dPlfwGR1oPDB0H/RC2BeAN++TzivfhYmknuWdysQCMDNLDNhXpArUWFjgBChQP0mUmILvy4PNv8w L09fMk//M180bzV/Uk83n0nfOb86z/9CrzzvXL8/D0AfQS9CP1gvr0RfRW9Gf1hwZJ/xcIFQ/SdQ YpxAolImg0jvWa/AhPxtb4CATQFUoCdQwOB+sL+g8MHBwiC+EWrQe1Jv/WDzR8C+MHNtKxEHUU3v Tv//V+9RH3C/Uz9UT1VfVm9zr/9Yj2rfWq9bv1zPXd9e71///2EPYh9jL3mPZU9mX2dvwdb8ZWlt IAdhvj96zwrZwmG/CCAH8KESTBPCoSaSM8OF80wRwfBvd8P/cD95L3Jf/5FvdH91j3afd6+UX3nP i9//e+98/4Tffx+ez4E/gk+DX/+Eb5o/Af8DD4g/ph+Qf5lv/5Kfk6+tD/6v/7+fX5Yfly//mD+v P7BPm2+cf52PpW+fr/+8j6HPot+j76T/t/+xD7If/8RPxV/Gb8d/yI8Aj6bvp/+/qQ8EzwXfBuIn UInSb2mR7wfQK3EmYM8hcydQBzSK7/+5r0sFB6KrD6wft++uP9k//7M/tE+1X7Zv3C+4j9Xvuq// u7+8z73fvu+//8EPwh/DL7/iD4afz3/QjwfuaMBybsGH1N/jbymlc3ViLY8V/mYssO/wjYHUUdOC S4AqE/9NwI4A17/Yz+G/2u/6D90P/94f3y/gP/z/4l/0v+R/5Y//5p/nr+i/6c/q3+vv7P8C3//v H/Av8T9HkSbSbULy4Pey9/O/BE8ptGYMYGiwinIqEONNcNQQY3VybZDSsInS6SdwZGnSsG7TcEuR 0qH/JmD4j/mfAo/7vxrf/d/+7////wEPHc8DLxUvBU8GXwdv/wh/CY8KnwuvDL8NzyOvD+9/EP8S D0efSK8U/0rPS9IuPCBU8vAXUctw97B2Yf/ygDUBbhCNYE1wjfAZLxo//yMvHF8dbyjPH48gnyGv Po//PN8k3yXvJv8u3ykfSP8rP/8sTy1fLm9EbzCPMZ8yr0ni//hATFBtENJB0hBpMGmSjcB/9jAU D0Xva9Y4oY6F13Bwf24QjfI5NG5CN8FsovMAdf9OINevO09EPz1vXO8/j0Cf/0GvQr9f30TfV09G /0gPT+//Si9qT0xPTV9Ob09/Zb9Rn79Sr1O/8jEXoIpgOSBi9wC9jlB5Vk9nLzdGiiBoGKBpc7Bn eThgV45RjwBv/znyeYZVENRR84EWwTmgF8H/W39cj2V/Xq9972DPYd9i7/9j/4DfZh93/2g/aU9q X2tv/2x/bY9un2+vcL+Gv3Lfc+//dP9VWNPWE7AXQXb/iC/11NxhY/KAOSHSoWKQUNKh/HVwNQE0 kNdj0yNVYnxv/31/hm9/n56/gb+Cz4PfhO//oa+HD5lviS+KP4tPjF+Nb/+Of4+PkJ+Rr6ePk8+U 35Xv/ZdNb1swGISYb6j/9dTzQfpmtYBt9tHSgakAVWGcEq8TgKPw9vA1EHKbMSydP/+eT6c/oG+/ f6KPo5+kr6W//8Jvp9+6T6n/qw+sH60vrj//r0+wX7Fvsn/IT7Sfta+2v+m9kGVnybBkOZDR8FpW 37lPyb/11fJlOGBJWRPyUP/WAJuRe4JadL2inKK9/78P/8f/wS/gT8NPxF/Fb8Z/4z//yJ/av8q/ y8/M383vzv/QD//RH9Iv0z/pH9Vf1m/Xfzfg/HVtVODqkFphWcDywOogbxOR2b/qj3kUbVXxF9F3 wxPi9uBuZmlnF6AX0d9ZAVYQevA0gZggeb3v38//6L/h7wDf5A/lH+Yv5z8Dz//pX/uP63/sj/Rv 7q8OP/DP//Hf8u/z/wmv9h/3L/g/CfB+ZhNAe/DccbiVl9BbIHLOIfqPCx95BUkgnQBVMexhbHqA enBlWdDdVLiQ/1lA/aFZMf9vAH8JbwKfIW//BL8FzwbfB+8kXwoPHG8ML/8NPw5PD18QbxF/Eo8T nxSvryo/Fs8X3xjvIDggYRrRb1kUG28rr3kUbtxAuKByAmsyXiZuYnNwOyE1SFwnYTAvKEFQ4FBF QVJTvKAegTgg+HcgZEHgWRS8wdjgGlL/+dAf7yD/Ke8jH0TfJT8mT/8nXyhvR88qjzxPLK8tvy7P /y/fMO8x/zMPNB81L02vN09/OF85b5dDOqAeIEoQ/SBlOZxwbnT6f07/ePYoadguZS57kLkCaP4Q emDvHsC4sGJxl5BpW6B2speR+70gV1Ap/19EX01PRn9lr/9In0mvSr9Lz2ifTe9gH1AP/1EfWP9T P3MPVV9Wb1d/WI//bn9ar1u/XM9uwJyyGge8wP9fD2/f/JYa8/5B3LMecJxwM91WHsBhYkLjfHBn Z/9C8WQ/ZU9uP2dvhn9pj2qf/2uvbL+Jb27fgO9w/3IPcx//dC91P3ZPd194b3l/j097n/98r32/ f5P5kB7BYqVBkX/v95C//LQe8HXdMRoHQZEa8/9h8B9RvOCjYITPhd+Oz4f//4kPlG+LL4w/jU+p v6gPkH//kY+Sn5p/lL+0L5bfl++Y/3+aD6+fnC+dP55PtRL+sGKeLdww/dH+Yt5gcnYeUe/csKDP sT/8tFDY8B8BYgL/H5LeUNzAHfRiEh5Q/yGftP+lf6aPr3+or8fvqs+r36zv/63/yt+wH8J/sj+z T7RftW//tn+3j7ifua+6v9C/vN+977++//7whCDEkR6AwOBzYjD+d2Ng/uLBf9Iv/LTjQV6AvxsQ fyDSMB4gfuDesCcfMKlBkHAtQzAtH7EtQuH/H9/Hb9BfyY/ob8uvzL/Nz//O3+tf0P/jP9Mf1C/c D9ZP//XP2G/Zf9qP25/xP92/3s9j39/xgGRlduUAYdAg/lTEwl6QOsE7L/KfPUaCsH/64DrRpNBj gB3gH7BC8GvjwLACQ2ltcP9A8kBe4P/hRx+xHxDm/+gP8P/qLwnf/+xP7V/ub+9/DM/xnwPf87// 9M/13/bv9//5D/of+y/8P58Sr/5f/28Af+FxY2jFcP2EgWlj4OHEAt8UHz1kAZT/g8F+0gbgE7CD ssSzJSDEkPpwfyBuPcB+8SCgCF8Jb/8SXwuPKq8Nrw6/D88Q3y2f/xL/JR8VHxYvFz8YTxlfGm// G38cjx2fM38fvyDPId/iEffkyUFABvB1XoCkASQfNO+vggSf8AGwY7BuXsIuKS//Kj8zLyxfSf8u fy+PMJ8xr/9M7zPPRj817zb/OA85Hzov/zs/PE89Xz5vUs9AilQTVXD/QU9CX17PSS9SH0tPTF9l v4FbVyZuYnNwO13Y8FwnYTBXv05/T49Qn/9Rr2ivU89U31XvXc9YD1kf/1ovWz9cT11fXm9pb2p/ fK//fb9+z3/fgO9rHF8fQN9hr9+ey8UART9yL+RkaOYQxJI/AmGfkqNA4aHiIHhwdHTf4SF4cKBg xOAFkW0F4MDD/wfCo/CJz4rf5FXAGGOPZJ//cG9mv5Q/a79sz23fbu+XL/9xD5Cfcy90P3VPdl93 b3h//3mPep97r50Phn+Hj4ifjSH5nmBiaY2hBeAnIuIvnl//5EaNpQWTxNjEMOWABbGyYfmq8G9r RPLE0JK/k8+cv/+V77UPmA+ZH5ovmz+3/51f/69vn3+gj6Gfoq+jv6TPpd//pu+n/73fqh+rL6w/ 5WC/QPhpb3Xl4SMKrm+/T+RkOyckKHBlSCKxoM5QbnP/SG+0j71/tq/Ur7jPud+67/+7/9efvh/Q b8A/wU/JL8Nv/+IPxY/Gn8evyL/df1/PYN//zI/pX9O/3K/V39bv8E+DH/+EL+Kf2V/ab9t/8n/z j96v/9+/4M/or+Lv/8/lD+Yf5y8/6D/7P8qv69/s7wCzQm/OYs9v/N+RpUhvjcDuT//vX/sv8X8Q T/Z/94/4n/mv/xM/+88ND/3v/v8ADwEfAi//Az8ETwVfBm8ZHxJPGH/z7//0//YPFL8VzxbfF+8n vxoPAxsfHC1CTE9DS1FAVU9URSBkR+A9Lx8QMVDrVY1QedJgPSIFJqBEHRBORy1MRQBGVDogNXB4 O2AgTUFSRzYgNlpCYE9SREVSNlUJpSBOMjbQsjAJUGlkNvdSqElHSDaRMDbQIiQZjzEiMDI0wTEx XHFsPHJ/zsDtnzCfMa8ynxzkIoVPK0TQsuJNjyBzPtBlSFhlYWSPADR3YY4RbvE0sGVmdCQbPI88 8M15Px6vJG8gwSvAB78IxmZh0mM1sFRhjFBtrkDrVak1UWl6NbAyJBtmDNGsZnNKAUcILU9ST85A /c8gbkRQNwBDBE9TSjwjAM0zsVI7WiDQbmU+ID2PnSGoQiQbC+BHCEZyTCCaOiV/L1UKL4kgRI5x flBWsM4gj38/H5GVQKFbg0wwraB0bzpkcFnjKkCtkHbOUC5TEHRdv1D/Ug9TH1QvVT9HRFPSkSdW 71f/hTdUdY8gZGGceSw3AFtQPVEyOGeQDyPSWj9bT1xXMTg6M34zXo9fn2CvYb9iz0dEVL9dQGSP ZZ+FRg6CZ5BSC9AjQ6CxsFcgQ0HxQjNwNS1CctHwzsA28Ce2U47wshFCsaCPICc28Kdor2m/XGZ2 cjygQM8w9SxQLglwZ2ufbK9tv27Pc2/fR0RDY3Fvcn+FN0+2ZJKAzxBoZzBnkEt4AP2yYUZ083b/ eA9cZnVIem+/e398j32ffq9j1ZIgapJgJ2RvgT9Y+FJFNqBbVsBSUlBdIFFnMdLTb7FChF+Fb1xm ZHWQRNAtDXniLXmSlNBwdjQtA9LQ0oBycy0wMi78dHgOvYh/iY+Wr5e/mM//Dv8QD0cvK68svy3P nh+cX/8+7z//QQ8kH0dfSG9Jf0qPOUuUIkPOYM5AQ6FOZdx3Igk8TO9N8jPNcM1DH05tip8iQ0xn IpQ4ODD5oqA1NCMwI4C1ACPPVgnHNJA1cGeQSSBqznB0wO530fB0wF0wINKC0uHOkN5odoC30blQ T+BrC7O5YP/PX6WPXEi5UJvRJZ8mr7Iv/50/vw+fX6BvoX+ij78/pK//pb+mz6ffqO+p/6sPrB+t L/+uP69PsF+xb7J/s4+0n7Wvc8y6uGBzd0OhuKG9QSB8Ine50D1RldK4krgQZW3SgHGRJdNwcA6Q kaEu97qfyS9cV0m9f76P1Z/Ar//ib8LPw9/E78X/5W/IH99P/8o/y0/Z781v79/Pj9Cf0a//0r/T z9Tf61/W/9gP2R8knL2DsGNEUFAQuVPboncJcPE0gG5nIE/g25MpYI2AsbhBc24ndMDdIGl2kP/e P+yvXFdPsQpA4P/iD/kf/+QvBf/mT+df6G/pfwj/65//Ap/tv+7P/W/w7xNv8w/0H//1L/Y/90/4 Xw7v+n/7j/yf/yScH0G4gdxit+CDsEOA//D/dMAEjwWfHK8HvyTPJd8X6P9MZxiPGZ8arxu/KG8d 2x8/+yBPE8oouGAjAAGfEE9cZrsjITnAdTQAuoAWsGt2Uf+6MQ/gg7B2oCMRI18kby8P/yaPOg8J 3wrvC/8NDz0PDy//NT8RTxJfMs8Uf0d/Fp8Xr/8rHywvLT8uT0L/Hg8fHzH/a7acm8BlN0FhN2F0 MGz5/2NrKWeQOJ85r1C/O8//WP9aDym/Ks9Nj06fT69cf88wH1NvVH9H+GJ1Iz01D/+TylePWJ9j P1q/bG9tf0v//1+PYJ9hr2K/Y89SX2VfZm+rR/jbomTdQGNygHC5A/+6Jr1Qg7Bq/2wPdh9uL36/ /z3vPv9AD0Efgb9DP2lfRV//Rm96b0iPjC9Kr3Efci9zP/90T3Vfh693f3iPeZ+2nAADgmm6gGUt bWFp/tDZOAVleJFQVtB5uEABUP/cMGhfiQ9qf33fht9//4EP/6GvkC+RP5JPk1+Ub6Svlo//l5+Y r5m/aADd0JztoH+kX/+in6Ovss+lz6berMin76j/v6oPtc9kn63Prt+M822ckH+dD54fNlbdwDQA p1D/wXP/sI+xn7w/s7/F/4Kfg6+Ev/+Fz8j/h+/CT4oPix+//40//9Nvj1+2r6bfuV+6b7t/zu// rC+tP78v1cwz8sERnDAAgNXZEW7YoCB8UXf/Av6g+QAQZ2/BP9A/nx/FD84P/8cvyD/ov9df2G/Z f9qP258/67/dv97P39/g788Qd3L/fFD/4ObP59/x7+n/+S/6P//tL7f/uQ/vz/Df/K+9T/Sf//Wv 4XzjY+Qv5T82VnuB97//+M8Db/rvDR/J38rvy//ND/8QH88vCd/RT9JfBy/UfxqP/9af/d/t/wCP AZ8CrxYP809n9F8GXxzscnVW4DdQc6poNxBsNBBiN6B05AD7m3A3kXMgICoRe5DBLxdP/+YvDB8V Hw4/D08v3x5vH3//II8hnyKvI78kzyXfJu8n/8UbcWR8UCd0Li3/Lw//OR8xL0BfEP8SDxMfFC9D X/8WTyxfGG8Zfz1vG59Nzx2//zQfNS82PzdPOF9JTzp/O4//PJ9QLD7vP/9b30IfXe9e/4FYcSZu YnNwO1so8FwnYTBOT0TvRf9HD/9IH2GfSj9LT0xfTW9kf0+P/1CfUa9Sv1PPVN9V71b/WA/PWR9a L3A/byFCdQiwwRHWcCrAw+Bz4xBmdLD3Qf+cwMRBmvSbISox4oF0oeMQ/ytfax/DZuPAsEF0AFx/ XY//d39fr4RPZK9lv2bPZ9+HT/9p/4DPbB9tL3vPb0+Rv3Fv/3J/c490n3Wvdr+NP3jfee9zev+U HHF1KWB+QOMwLCfjISri44JvbSlhdXD94yB2l4HiEqInf8+On8Nm/EknojCC34Pvmv+GD6ef/4gv iT+KT4tfqp+Nf6RPj5//kK+fT5LPtQ+U75X/lw+YH/+ZL5o/sI+cX51vnn+3bKEQeaIyZmW2kLwg 44B+sGZzusAp4GFi/yA+wHzQb/JixFF5c6Dgo0+x7wr2/iKmL6c/vk+pX8o/y0+/t4vA4PeAPeLg LXVzwl/7zg+/o0LQW8WQ0R+5L7oyMkG6sGFsu0+8X2Y1e72PtdNBKXDGH8cvCvZ5b/8gKlCiIX7Q biox1qB3/4K9zF/Nb8ju0srgP8kv4i/LteLUXTHfAUJS0Fm4Qf+hELDQ4t/Oz8/f0O/R/9MP/+xf uXnAR9Xf1u/X/9kPfkB3obDdYrrQdvHQKXAqAHS33eDq8NoAZKIxxIFlobDv3YDF79svCsltfrDy 4H5h771w9wx+0qIxed4f3y/iz//hT/5f/2/kf+WP5p/nrwF//79vwHTqr+u/73/VnPNPCz//DE3y Cwpr9FMO7wxN8u+9QdO+DwgNVFK54Eftz7Wme7hQKoBsKz/4/4HKKeBmicDgcHB+Um9jYyrAfnM+ 3wMBGB4BXxPPui8i/7yftZfIvAivwM/B3wr/Yk//Y18pvwKfIA/Lf/2vLx8wL/8xPzJPM180bzV/ No83ny1//znPq3+sj62frq88v7DPG2//su+z/ykfth9HL7g/6d8KD/8pjyGPDT8OT04fEG8RfxKP /1If8JoU3xXvVd8iPyNPJF7/St8mfyePKJ9dnzufQc84L/85P2TvZf9nD2gfaS9qP2tP/2xfbW9j T2+fcK8q/ywPPd//Pu8//0EPct9DL0Q/RU9GX/9Hb0h/SY9Kn0uvTL97T1qf/0/vUP+HH1MfVC+K D1ZPV1//WG+OH4ePW59cr5JPXspgHwthL4BKTt3QIEkgKuJkoMAndCoaX3y/3FdjoVDdQWV4cLrQ usBux7pA3WGiYGN0dfHRw7A79qDyMGvaL5z/3Eh3aP+60KYfcf97D26PpS+mP6dP/6hfqW+qf6uP rJ+tr66/pJ//PP92z3ffeO95/7EffB99L/9+P39PgF+Bb4J/lt+En7/P/7lvh8+I34nvxT+MD40f yC//jz+QT5FfzD+Tf5SPlZ/Qb/+Xv5jPw5/1U6OA+7DdtKDP97qv+hfdkGzSwB0A0jD8QEfa4PXA o6BxdWmjoGTZ9+Bzb5tR1lBr2c/a3/3b6Gj8MLHPst/UP69v4u//4//lD+Yf5y/oP+lP6l/rb/+x n+Jfs7+0z7Xftu+3/+7f/7ofuy+8P71P8Z+/b8B/1N//wp/9j+x/xc/G39QvAv/KD//LHwXvzT/O T89fCf/Rf9KPP9Of1K/Vv9bPAV/8cXdp+9kQEDB03o/4X54aHZIdANsdwB2BaZug3eBiFxHhUB+f kBsxn7APwRcgdHJ1z9lQF08YX+C4YXTvf/CP/xHv7R8g3yHvIv8kDyUfJi//Jz8oTylf708gT/Fv 8n/zj//0n/WvLM/3z/jf+e/6/y+P//0f/i8SjwBPO38qbwN/BI//Ed9A7we/CM9D3wrvC/8ND/9H 7w8vED8RTxJfE28Ufz9P+9jjH0AgnxEcfzZP4KdWQMxja6BQTaFpbE4w3UF7H0CfgmOjoFHw3PGf oWP/WXNVT1Zfov8try6/UB8rT/9e/2APYR9iL2M/ZE9lX2Zv/2d/XV9ebzoPMK8xvzLPM9//au81 /zcPOB85L22vO088X/9Qvz5/P49MX0GvQr99/0Tf/0XvRv+B/0kfSi9LP4YPTV+/Tm9Pf3sfUZ9S r3meYYfwvxbwbzBVH3QP4IlYUm+ewLF0QHRpbZ+BWjBk3PD93aI/az9sT3J/aN+Y35nv/5r/nA+d H54vnz+gT6Ffom//mE+kn46PfECHd3xvfX+KT/9/n4Cvq8+Cz4PfhO+vz4sl/4gPiR+zz4cdi5+M r7a/js/3j9+Q73fYV1TCG1GTP5RP/+C4XT+mf6ePow/FD8Yfxy//yD/JT8pfy2/Mf82Pzp/Ef/9t L24/b09wX3Fv0P9zj3Sf/3Wvdr93z3jfee+8D3wP36//2U+s/64Prx/lH7E/sk/oD/+3/4e/tf/s H4rvub+6z/BP76kPvW++f94LYxngWNAcAPfyoBtQlmBjGnDzoMNxWYA2IOMQGgByGtCWgG50n8Cw VLPA39qfXHZtYVgQ/nPRr9K/9B/PTwCPAZ8Cr/8DvwTPBd8G7wf/CQ/Rf////9Of1K/Vv9bP198M f9n/2w//3B/dLw8/30/gX/S/4n8bL/8KH+Wv5r/0DyCf6e/q/yOP/+0f7i/vPyef8V/yb/N/9I9/ vP/3Px7/VINYsPogHkBk/RYAZPwfFf9cZ/pxL2BX5D3AsGxZkMCwXSAccGFi/zigVKRZwTU/Nk9c dh5ADR//Di8vjwq/Pj8/T0BfQW9Cf/9Dj0SfRa9GvwzvPa8PDxAf/xEvEj8TT0ovFW8WfxePGJ// TO8avxvPMC8d71jfR88hH/8iLy9/Xk8lXyZvYT8ojymf/yqvZU8szy3fLu8v/zEPMh+/XK9XwfsJ Of9Tr/43d8OA/5cgkoFtEPrQYwA00GsBlfXXwK9zvzv6Y2swcFNAOUH+P0rPS99tP0hvfA99H34v /38/gE+BX4Jvg3+Ej0qfe3//TL9Nz07fT+9Q/4f/Ux9UL/9VP1ZPir9Yb1l/bd9bn5av/4WfXs9f 320vnB9jD2Qfnw//Zj9nT2hfox9qf2uPbJ9tr29uv2/Pmn+VkUlysPrQZf5tdy+Rb/4oiJ+Jr6sP hj//tI+1n7avt7+4z7nfuu+7//+9D4hvs//AT6vvma+av6eP/6R8nS+eP8cfoF+hb6J/y6//qLGl X6Zvz2+oj6mfqq/D7//1361Prl/5B9TQ+5B24vuQnHVp+jB20DRQbyBygLAgLS0gdXE54HnU0C+w b7F//jc48HT5sG5z/m3csMEfwi/Wj76/4u/j///lD+Yf5y/oP+lP6l/rb8Dv/+Jfio+Ln4yvjb+O z+7fkO//kf+TD5Qf8Z+WP5dP1y/E7//9j+x/nJ/Jv9Z/Av/M783//wXvx++lH9GvCf/Tz9Tf1e// 1v+sj9mvAV/8cQ/ANKAQcJ4sdwByv/hPNzhjYQEQ2ziwdcFwclA5QW0XIDTB+zRUB8B13MByYN0C F38Yj/83VjmC73/wjxHv7R8gzyHf/yLvI/8lDyYfJy8oPylP70//ID/xb/J/84/0n/WvLL/3z//4 3/nv+v8vf/0f/i8SjwBP/ztvKl8DfwSPEd9A3we/CM//Q88K7wv/DQ9H3w8vED8RT/8SXxNvFH8/ PzpRGqV3AhxPxzYf4C/hMiAqZXbQHCDpFsQqP91iYhvgGxGwX/tWf1eISS1fLm9Pzyr/Xp//X69g v2HPYt9j72T/Zg9nH/8tL14PL08wXzFvMn8zj2qP/zWvNr83zzjfbU86/zwPUG//Pi95P2gvQV9C b0+/fq9Fn/9Gr4GfSM9J30rvha9ND04fP08vUD9RT1JffQ94IXNhenkXIidaX3P/V4gaomH9VNB5 ax9sL3JfaL+Xr5i//5nPmt+b75z/ng+fH6AvoT//lx+jb45vfC+Rb4oPyE9/3/+A76pvgw+EH4Uv rv+H34jv/7KPiw+MH40vpw/YP4/PkN/9d8dqqOAXUBuw3UAbcNxw+mcacGK4ABdQG3KTH5Qv+x6X wcBn4OCkT6Vfub+h7//FL8Y/x0/IX8lvyn/Lj8yf/82vpB/En20fbi9vP3BPcV//0R9zf3SPdZ92 r9PfeM953/+6X6gf38/Ov38vrO+5r+U//7AfsS/oL6sfh6+03+w/tv9/uA+5H7ovjx+83+Of3rFh /HBw4RAaEBvzwL/arx6a0CBJIGQcECcXXdKP/9i/zx/QL/9/AI8BnwKvA7//BM8F3wbvB//93wov 9M+7bP/i3+Pv8L/mD+cfEY/pP+pP/+tfFY+zn+8fGR/tH6wY8l+/828cz/WP9p8Qj96TeVgwx/m/ +s9Xl3VuZB/AWVD5D/BkLgs/DE8hPwjfKx//LC8tPy5PL18wbzF/Mo8zn/8LDyqP06/Uv9XP1t/X 7zcP/9oP2x/cL90/Oc/fX+BvId//4o9FvzSvEs8T3yEvSy8XD/8YH04fHc/uPxvPUi/xbx+P/yCf Ia8O3yM/JE9KDzf/Pi//Xz81n2FPYl9jb2R/ZY9mn39nr2i/ac9fr2C/bQ8iZSYgbmJzcDteOFwn /GEwRD863zvvPP8+D2/f/0AvQT9CT0Nfcr9Ff0aPWu//SK9+r1aPS99M74MPTw9QH/9RL4cPU09U X1Vvix9Xj1ifX1mvgC8i711vgn9PeWBpfnPAYZfhJl95X8LWvyNijmX5UIIAwJBwZW/5IBvAkPxw dsCQhXB3YXnDl/CcsG50ZWSYX5lv/cLIb22Pbp+S32svoa+iv/+jz6Tfpe+m/6gPqR+qL21f/6Ef OZ9zb3R/dY92n62feL//ec9633vvsF9+D38fk3+BP/+8T6s/hG+Ff5LPwb+Ir4m//8Svi9+M743/ yL+QH5Evkj9/k0+UX5VvwB+7MZtQ+PBiP5wRoBCdb7cf+9fGcG5mLGlnzwDV4WiccG51Nm2bULcw b9Aw2UB0cjm/YHNtl+DK8Pzgcyz31i/XP/vXc6Avrz+1b6vP/9+P4J/hr+K/48/k3+Xv5v//6A/p H97/sB+xL7I/s0+0X//rf7Z/t4+4n7mvur+7z7zf/9E/vv/6L/PPwi/DP8RP/5//xm/HfwKPyZ/K r8u/Bp/N33/O78//Cs/SH9Mv/f/5Em74b3cnl/KccNtv9R/YV0WcQG4MkD8gSZyAZO/awJsw1gGb UGn9YJyA/TB9F4B0nBEUHxUv2FkMkHL+bp1A7C/tPw6f6c8dfx6P/x+fIK8hvyLPI98k7yX/6/// HO/uH+8v8D/xT/JfKW/0f//1j/af968sL/nP+t8PP/z//zgfJw8ALwE/Do89jwRvBX//QH8Hnwiv Cb9EjwvfDO8N/18PDxAfES877zcBdxeAaCcYzzLvn4dkZZvQbmTHGALY4FTRbHkgTFDaXfXaQWdS sGScEE6gUZ9Sr/+fh9ogKg8rH0x/J69bb1x//12PXp9fr2C/Yc9i32PvKd//Wt8r/y0PLh8vLzA/ Z18yX/8zbzR/NY9qHzevOL9NHzrf/3YPZP8+Dz8fTG97f0JPQ1//fm9Ff0aPR5+Cf0m/Ss9L3/9M 703/Tw9533Tx2XLagJ0wedtAYnWbMFc/cO+flkk+J5xhG9CcYHDwiFB0df99AFUxm1B5YNWvkK+R v5sC+GlmeWf/aQ+Kb2WfmV//mm+bf5yPnZ+er5+/oM+h3/9nz5jPae9q/2wPbR9uL6VP/3BPcV9y b3N/qA91n3aviw//eM+z/6Lve/99D4pfuW+AP/+BT7xfg2+Ef4WPwG+Hr4i//4nPit+L74z/t8+y 4bcQVUA/2UDKcFThlN+u35b2d2ifVUDZcNlAkvDO4GNr2mCFVxB3xqBsZG4nF5A/1YHN787/lva3 UMagZ2j/pe+m/8hfo4/W39fv2P/aD//bH9wv3T/eT99fpb/WT+Kf/8k/tv+4D8Tfwcy6f7uP6W// va++v7/P7f/GAcKvw7/xv//F38bvx//mP+dCwhfKX8tv/bJaLuNv5H/43+EP/88A3/8B7wL/BA8F HwYvBz8IT+M///8/p9+o76n/qw+sHwu/rj//r0+wX7FvDn+zj7Sf+X/nP/8abwlfue/sD/jPH9/v P/BP/yLP6j/Cb/P/Jt/2H/cv+D//+U/6X/tv/H8evwyvEt8z7/8KTzX/Nw84HzkvOj87TzxfPz1v Pn80XzVvQb/JhSZuEGJzcDsy6FwnYf4wGO8PjxCfEa8Sv0SPFN//Fe8W/xgPR28aLxs/L58dX/9T Xys/II8hn1e/I78kzyXf/1u/J/8pDyofX88sPy1PLl+fVN8wfzGPMp9Rty1kzbD/Qj9DT2ePP99u r2+/cM9x3/9y73P/dQ92H3cvQg9uHw5P/0gfSS9KP0tPep9Nb05/T4//UJ99X1K/U89oL1XviU94 P/9ZH1ovZ3+Ov11fXm+Rr2CP/2GfYq+Vv2TPZd9m72f/aQ//ah9rL42fe4+Bv6LPeS+k3/+l76b/ qA+pH6ovqz+sT61f/6M/pE+wn0WPRp99z37ff+8PgP+yz7kfuiBCTE9DwEtRVU9URbp7hBG/gxC7 P7xPvV++z4i0NZsBscCAT0RZobCEbDe6EXBIVE1Mw/2dgYQTfQHG8AAeAEIQAQAAAFEAAAA8MTky OUI4QzVCMzE4NTI0NDk1NzI3RDhBMjQxREFGQjIwMTQ3RkRCQUBOQUVBTUlMTEVYMDNWQS5uYWRz dXNlYS5uYWRzLm5hdnkubWlsPgAAAAADAAJZAAAWAAMACVkCAAAACwAAgAggBgAAAAAAwAAAAAAA AEYAAAAAA4UAAAAAAAADAAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMACoAIIAYAAAAA AMAAAAAAAABGAAAAAFKFAAA/cQEACwALgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAyA CCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMADYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAA AAAAHgAOgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAD4AIIAYAAAAAAMAA AAAAAABGAAAAAAaFAAAAAAAAAwAQgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALABGACCAG AAAAAADAAAAAAAAARgAAAACChQAAAQAAAB4ANoAIIAYAAAAAAMAAAAAAAABGAAAAAIOFAAABAAAA EwAAADM3ODEyNTkxNy0yOTAzMjAwNgAAAgH4DwEAAAAQAAAARC0ZLomniUKDAYXoRnf4OgIB+g8B AAAAEAAAAEQtGS6Jp4lCgwGF6EZ3+DoCAfsPAQAAAJEAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAA bXNwc3QuZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3Nc ZHByb3ZhblxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29r XGRvbi5wc3QAAAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwNDQyRDE5MkU4 OUE3ODk0MjgzMDE4NUU4NDY3N0Y4M0FFNEI5NjYwMwAAAAADAAYQnbFwMwMABxD+EwAAAwAQEAAA AAADABEQAAAAAB4ACBABAAAAZQAAAE9LLFBMRUFTRUVYQ1VTRU1FRk9SRE9VQlRJTkdZT1UsQlVU SU1BRlJBSURUSElTUkVTUE9OU0VIQVNLSU5EQVNVUFBPUlRFRE1ZRkVBUlNUSEVJU1NVRVNZT1VS RVRBTEtJTkcAAAAA5HE= ------=_NextPart_000_0022_01C6531E.3B27B4A0 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 ------=_NextPart_000_0022_01C6531E.3B27B4A0--