From stephen.nadas@ericsson.com Fri Oct 2 05:04:36 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96E3028C0F9 for ; Fri, 2 Oct 2009 05:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4XL9FEf9WFa for ; Fri, 2 Oct 2009 05:04:35 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 2A66A28C0E3 for ; Fri, 2 Oct 2009 05:04:35 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n92C5vmo017946; Fri, 2 Oct 2009 07:05:58 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:05:40 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:05:40 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 2 Oct 2009 08:05:39 -0400 From: Stephen Nadas To: Jari Arkko Date: Fri, 2 Oct 2009 08:05:38 -0400 Thread-Topic: Please clear draft-ietf-vrrp-unified-spec Thread-Index: AcpDWKgEuXlEx+ApQoq1FJ4aLAAW9Q== Message-ID: <450AE4BEC513614F96969DDA34F3593497639A3A@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F3593497639A3AEUSAACMS0701eam_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2009 12:05:40.0415 (UTC) FILETIME=[A8F2D4F0:01CA4358] Cc: "Radia.Perlman@Sun.COM" , "vrrp@ietf.org" Subject: [VRRP] Please clear draft-ietf-vrrp-unified-spec X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 12:04:36 -0000 --_000_450AE4BEC513614F96969DDA34F3593497639A3AEUSAACMS0701eam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jari, Regarding your comment - will the below actions clear it? Thanks, Steve Requirement to send router advertisements is in 6.4.2 but not in 6.4.3, why= ? Oversight, added @ (630) In Section 6.4.3, the Accept_Mode flag is only checked in the IPv6 branch o= f the code, is this correct? (650) is outside of v4/v6 if condition, so is checked regardless In Section 6.4.3, I don't understand how there's first a MUST statement on responding to Neighbor Solicitations, and then two steps later a conditiona= l statement based on the value of Accept_Mode, again on the the same thing, responding to NSes. I think the need to accept some packets regardless of the setting of accept= _mode is what was trying to be expressed by (635). My proposed fix is to mo= ve (635) in between (615) and (620). I am also considering: (618) ++ (even) if Accept_mode is False: MUST NOT drop IPv6= Neighbor Solicitations and Neighbor Advertisements. 6.4.3. Master While in the {Master} state the router functions as the forwarding router for the IPvX address(es) associated with the virtual router. Note that in the Master state the Preempt_Mode Flag is not considered. (600) While in this state, a VRRP router MUST do the following: (605) - If the protected IPvX address is an IPv4 address: (610) + MUST respond to ARP requests for the IPv4 address(es) associated with the virtual router. (615) - else // ipv6 (620) + MUST be a member of the Solicited-Node multicast address for the IPv6 address(es) associated with the virtual router. (625) + MUST respond to ND Neighbor Solicitation message for the IPv6 address(es) associated with the virtual router. (630) ++ MUST send ND Router Advertisements for the virtual router. (635) ++ if Accept_mode is False: MUST NOT drop IPv6 Neighbor Solicitations and Neighbor Advertisements. (640) +-endif // ipv4? (645) +- MUST forward packets with a destination link layer MAC address equal to the virtual router MAC address. (650) - MUST accept packets addressed to the IPvX address(es) associated with the virtual router if it is the IPvX address owner or if Accept_Mode is True. Otherwise, MUST NOT accept these packets. [rest of 6.4.3] --_000_450AE4BEC513614F96969DDA34F3593497639A3AEUSAACMS0701eam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jari,
 
Regarding your comment - will the below actions clear it?
 
Thanks,
Steve
 
R= equirement to send router advertisements is in 6.4.2 but not in 6.4.3, why?=
&= nbsp;
Oversight, added @ (630)
&= nbsp;
I= n Section 6.4.3, the Accept_Mode flag is only checked in the IPv6 branch of=
t= he code, is this correct?
&= nbsp;
(650) is outside of v4/v6 if condition,  so is checke= d regardless
&= nbsp;
I= n Section 6.4.3, I don't understand how there's first a MUST statement on
r= esponding to Neighbor Solicitations, and then two steps later a conditional=
s= tatement based on the value of Accept_Mode, again on the the same thing,
r= esponding to NSes.
&= nbsp;
I think the need to accept some packets regardless of the = setting of accept_mode is what was trying to be expressed by (635). My prop= osed fix is to move (635) in between (615) and (620). I am also considering:
 
  &n= bsp;            = ; (618) ++ (even) if Accept_mode is False: MUST NOT drop IPv6 Neigh= bor
  &n= bsp;            = ;  Solicitations and Neighbor Advertisements.
 
6.4.3.  Master
 
   While in the {Maste= r} state the router functions as the forwarding
   router for the IPvX= address(es) associated with the virtual router.
 
   Note that in the Ma= ster state the Preempt_Mode Flag is not
   considered.<= /div>
 
   (600) While in this= state, a VRRP router MUST do the following:
 
      (= 605) - If the protected IPvX address is an IPv4 address:
 
     &n= bsp;   (610) + MUST respond to ARP requests for the IPv4 addr= ess(es)
     &n= bsp;   associated with the virtual router.
 
      (= 615) - else // ipv6
 
     &n= bsp;   (620) + MUST be a member of the Solicited-Node multica= st
     &n= bsp;   address for the IPv6 address(es) associated with the virtu= al
     &n= bsp;   router.
 
     &n= bsp;   (625) + MUST respond to ND Neighbor Solicitation messa= ge for
     &n= bsp;   the IPv6 address(es) associated with the virtual router.
 
     &n= bsp;   (630) ++ MUST send ND Router Advertisements for th= e virtual
     &n= bsp;   router.
 
     &n= bsp;   (635) ++ if Accept_mode is False: MUST NOT drop IP= v6 Neighbor
     &n= bsp;   Solicitations and Neighbor Advertisements.
 
      (= 640) +-endif // ipv4?
 
      (= 645) +- MUST forward packets with a destination link layer MAC
      a= ddress equal to the virtual router MAC address.
 
      (= 650) - MUST accept packets addressed to the IPvX address(es)
      a= ssociated with the virtual router if it is the IPvX address owner
      o= r if Accept_Mode is True.  Otherwise, MUST NOT accept these
      p= ackets.
 
[rest of 6.4.3]
 
--_000_450AE4BEC513614F96969DDA34F3593497639A3AEUSAACMS0701eam_-- From stephen.nadas@ericsson.com Fri Oct 2 05:17:31 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0F528C0E3 for ; Fri, 2 Oct 2009 05:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6ELfXm9AYTi for ; Fri, 2 Oct 2009 05:17:29 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id BB05428C0FE for ; Fri, 2 Oct 2009 05:17:29 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n92CIsQR008547; Fri, 2 Oct 2009 07:18:54 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:18:26 -0500 Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 07:18:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 2 Oct 2009 08:18:25 -0400 From: Stephen Nadas To: Jari Arkko Date: Fri, 2 Oct 2009 08:18:24 -0400 Thread-Topic: Please clear draft-ietf-vrrp-unified-spec number 2 Thread-Index: AcpDWnAmFv62voKXQlaEqk5m65iyCg== Message-ID: <450AE4BEC513614F96969DDA34F3593497639A45@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F3593497639A45EUSAACMS0701eam_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2009 12:18:25.0502 (UTC) FILETIME=[70F9D7E0:01CA435A] Cc: "Radia.Perlman@Sun.COM" , "vrrp@ietf.org" Subject: [VRRP] Please clear draft-ietf-vrrp-unified-spec number 2 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 12:17:31 -0000 --_000_450AE4BEC513614F96969DDA34F3593497639A45EUSAACMS0701eam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jari, Regarding this discuss, will the below clear it (I hope so as it's based on= your suggestion :-) Thanks, Steve Discuss: Thirdly, I do not understand why there is no issue, because the backup taking over, because then the backup has to authoratively sign the NAs and RAs it is sending, for the primary's address. If the "trust anchor and cga" mode from RFC 3971 is used, the private key would have to be shared, or this would not work at all. And private key sharing is not necessarily a good idea. I would recommend saying this: - VRRP is compatible with "trust anchor" and "trust anchor or cga" modes of SEND - The configuration needs to give the two routers the same prefix delegation in the certificates - But still, the routers should have their own key pairs Text added at end of section 9: In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND) is deployed, VRRP is s compatible with the "trust anchor" and "trust anchor or cga" modes of SEND [RFC3971]. The (SEND) configuration needs to give the master and backup routers the same prefix delegation in the certificates so that master and backup routers advertize the same set of subnet prefixes. However, the master and backup routers should have their own key pairs to avoid private key sharing. --_000_450AE4BEC513614F96969DDA34F3593497639A45EUSAACMS0701eam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jari,
 
Regarding this discuss, will the below clear it (I hope so as it's bas= ed on your suggestion :-)
 
Thanks,
Steve
 
Discuss:
 
T= hirdly, I do not understand why there is no issue, because the
b= ackup taking over, because then the backup has to authoratively
s= ign the NAs and RAs it is sending, for the primary's address.
I= f the "trust anchor and cga" mode from RFC 3971 is used, the
p= rivate key would have to be shared, or this would not work at
a= ll. And private key sharing is not necessarily a good idea.
&= nbsp;
I= would recommend saying this:
-= VRRP is compatible with "trust anchor" and "trust anchor or= cga" modes
&= nbsp; of SEND
-= The configuration needs to give the two routers the same
&= nbsp; prefix delegation in the certificates
-= But still, the routers should have their own key pairs
&= nbsp;
Text added at = end of section 9:
 
   In the context of I= Pv6 operation, if SEcure Neighbor Discovery (SEND)
   is deployed, VRRP i= s s compatible with the "trust anchor" and "trust
   anchor or cga"= modes of SEND [RFC3971].  The (SEND) configuration
   needs to give the m= aster and backup routers the same prefix
   delegation in the c= ertificates so that master and backup routers
   advertize the same = set of subnet prefixes.  However, the master and
   backup routers shou= ld have their own key pairs to avoid private key
   sharing.
 
--_000_450AE4BEC513614F96969DDA34F3593497639A45EUSAACMS0701eam_-- From stephen.nadas@ericsson.com Fri Oct 2 07:45:47 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9BB3A6A63 for ; Fri, 2 Oct 2009 07:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy0oU8v8ZzJX for ; Fri, 2 Oct 2009 07:45:46 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id DCE163A6A60 for ; Fri, 2 Oct 2009 07:45:45 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n92El1Ze014913; Fri, 2 Oct 2009 09:47:04 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 09:46:22 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 09:46:22 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 2 Oct 2009 10:46:21 -0400 From: Stephen Nadas To: Jari Arkko Date: Fri, 2 Oct 2009 10:46:19 -0400 Thread-Topic: Please clear draft-ietf-vrrp-unified-spec 3 Thread-Index: AcpDbxp1IlUKgCNvTE+lpFdbMeBxfw== Message-ID: <450AE4BEC513614F96969DDA34F3593497639B28@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F3593497639B28EUSAACMS0701eam_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2009 14:46:22.0567 (UTC) FILETIME=[1C1E7770:01CA436F] Cc: "vrrp@ietf.org" , "Radia.Perlman@Sun.COM" , Christian Vogt Subject: [VRRP] Please clear draft-ietf-vrrp-unified-spec 3 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 14:45:47 -0000 --_000_450AE4BEC513614F96969DDA34F3593497639B28EUSAACMS0701eam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jari, Will the below changes to the figures (analogous to the other not shown her= e) let you clear this comment? Thanks, Steve Comment text: In the figures illustrating sample configurations in section 4, it is not clear which IP address labels denote a host's own IP address vs. which denote the IP address of the router that a host is using. Both is currently denoted "IPvX A" in the figure. Suggest distinguishing the two types of labels more clearly. Blue is proposed new "text": +-----------+ +-----------+ | Rtr1 | | Rtr2 | |(MR VRID=3D1)| |(BR VRID=3D1)| | | | | VRID=3D1 +-----------+ +-----------+ IPvX A--------->* *<---------IPvX B | | | | ------------------+------------+-----+----------+----------+----------+-- ^ ^ ^ ^ | | | | default rtr IPvX addresses ---> (IPvX A) (IPvX A) (IPvX A) (IPvX A) | | | | | | | | IPvX H1->* IpvX H2->* IPxX H3->* IpvX H4->* +--+--+ +--+--+ +--+--+ +--+--+ | H1 | | H2 | | H3 | | H4 | +-----+ +-----+ +--+--+ +--+--+ Legend: --+---+---+-- =3D Ethernet, Token Ring, or FDDI H =3D Host computer MR =3D Master Router BR =3D Backup Router * =3D IPvX Address, X is 4 everywhere in IPv4 case X is 6 everywhere in IPv6 case (IPvX) =3D default router for hosts --_000_450AE4BEC513614F96969DDA34F3593497639B28EUSAACMS0701eam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jari,
 
Will the below changes to the figures (analogous to the other not show= n here)  let you clear this comment?
 
Thanks,
Steve
 
Comment text:<= /font>
 
In the figures illustrating sample configurations in section= 4, it is
  not clear which IP address labels denote a host's own IP address vs.=
  which denote the IP address of the router that a host is using.
  Both is currently denoted "IPvX A" in the figure.  Su= ggest
  distinguishing the two types of labels more clearly.
 
 
 
Blue is propos= ed new "text":
 
 
     &n= bsp;    +-----------+ +-----------+
     &n= bsp;    |   Rtr1    | |  = Rtr2    |
     &n= bsp;    |(MR VRID=3D1)| |(BR VRID=3D1)|
     &n= bsp;    |        &nb= sp;  | |           |=
  VRID=3D1  +-----= ------+ +-----------+
  IPvX A--------->* = ;           *<--------= -IPvX B
     &n= bsp;            |&nb= sp;           |
     &n= bsp;            |&nb= sp;           |
------------------+---------= ---+-----+----------+----------+----------+--
     &n= bsp;            = ;            &n= bsp;      ^      &nb= sp;   ^          ^&n= bsp;         ^
     &n= bsp;            = ;            &n= bsp;      |      &nb= sp;   |          |&n= bsp;         |
  d= efault rtr IPvX addresses ---> (IPvX A)   (IPvX A) = ;  (IPvX A)   (IPvX A)
     &n= bsp;            = ;            &n= bsp;      |      &nb= sp;   |          |&n= bsp;         |
     &n= bsp;            = ;            &n= bsp;      |      &nb= sp;   |          |&n= bsp;         |
  &n= bsp;            = ;             I= PvX H1->* IpvX H2->* IPxX H3->* IpvX H4->*
     &n= bsp;            = ;            &n= bsp;   +--+--+    +--+--+&= nbsp;   +--+--+    +--+--+=
     &n= bsp;            = ;            &n= bsp;   |  H1 |    |  H2 |  &nb= sp; |  H3 |    |  H4 |
     &n= bsp;            = ;            &n= bsp;   +-----+    +-----+ &nb= sp;  +--+--+    +--+--+<= /div>
   Legend:
     &n= bsp;   --+---+---+-- =3D Ethernet, Token Ring, or FDD= I
     &n= bsp;            = ;   H =3D Host computer
     &n= bsp;            = ;  MR =3D Master Router
     &n= bsp;            = ;  BR =3D Backup Router
     &n= bsp;            = ;  *  =3D  IPvX Address, X is 4 everywhere in IPv4 case
     &n= bsp;            = ;            &n= bsp;         X is 6 everywhere in I= Pv6 case
     &n= bsp;            = ;  (IPvX) =3D default router for hosts
 
--_000_450AE4BEC513614F96969DDA34F3593497639B28EUSAACMS0701eam_-- From stephen.nadas@ericsson.com Fri Oct 2 08:40:03 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3603A67D9 for ; Fri, 2 Oct 2009 08:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cgh8jFjh8xtm for ; Fri, 2 Oct 2009 08:40:02 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 4BBD73A6783 for ; Fri, 2 Oct 2009 08:40:02 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n92FfOsb011670; Fri, 2 Oct 2009 10:41:25 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:40:47 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 10:40:46 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 2 Oct 2009 11:40:46 -0400 From: Stephen Nadas To: "dromasca@avaya.com" Date: Fri, 2 Oct 2009 11:40:45 -0400 Thread-Topic: Clear draft-ietf-vrrp-unified-spec 4 Thread-Index: AcpDdrT5KtA8myKGSza8Uj43QXnO9A== Message-ID: <450AE4BEC513614F96969DDA34F3593497639B99@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F3593497639B99EUSAACMS0701eam_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2009 15:40:46.0932 (UTC) FILETIME=[B5D50940:01CA4376] Cc: "Radia.Perlman@Sun.COM" , "vrrp@ietf.org" Subject: [VRRP] Clear draft-ietf-vrrp-unified-spec 4 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 15:40:03 -0000 --_000_450AE4BEC513614F96969DDA34F3593497639B99EUSAACMS0701eam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, Will the approaches described below suffice to clear the draft for the comm= ent? (there's a separate email coming for the discuss) Thanks, Steve 1. Appendix B and part of Appendix C excepting the part refering to changes from RFC 3768 should be dropped at publication. Will do 2. Another feature that at least one vendor implements is so-called Backup = VRRP router passive ARP learning. This is very useful, because otherwise when y= ou switch from active to backup, the backup doesn't know ARP bindings for IP addresses and this increases the time needed to converge. (The same featur= e should apply to ND I think) This would seem to be something that could be w= orth adding or at least discussing in the spec. We (VRRP wg chairs & I) would like to ship this document soon and part of t= he thinking all along with this draft was to avoid feature creep. Thus we= are not thinking of adding this new feature- it is not required for intero= perability. It could, however, be covered in a new separate draft. --_000_450AE4BEC513614F96969DDA34F3593497639B99EUSAACMS0701eam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Dan,
 
Will the approaches described below suffice to clear the draft for the= comment? (there's a separate email coming for the discuss)
 
Thanks,
Steve
 
1. Appendix B and part of Append= ix C excepting the part refering to changes
from RFC 3768 should be dropped = at publication.
 
Will do
 
2. Another feature that at least= one vendor implements is so-called Backup VRRP
router passive ARP learning.&nbs= p; This is very useful, because otherwise when you
switch from active to backup, th= e backup doesn't know ARP bindings for IP
addresses and this increases the= time needed to converge.  (The same feature
should apply to ND I think) This= would seem to be something that could be worth
adding or at least discussing in= the spec.
 
We (VRRP= wg chairs & I) would like to ship this document soon and part of the t= hinking all along with this draft was to avoid feature creep.   T= hus we are not thinking of adding this new feature- it is not required for interoperability.  It could, however, be covere= d in a new separate draft.
 
 
--_000_450AE4BEC513614F96969DDA34F3593497639B99EUSAACMS0701eam_-- From stephen.nadas@ericsson.com Fri Oct 2 08:59:43 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB163A6963 for ; Fri, 2 Oct 2009 08:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLdaTEVinCq8 for ; Fri, 2 Oct 2009 08:59:42 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 6C1603A6853 for ; Fri, 2 Oct 2009 08:59:42 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n92G14Gc018210; Fri, 2 Oct 2009 11:01:06 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 11:00:57 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 11:00:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 2 Oct 2009 12:00:56 -0400 From: Stephen Nadas To: "dromasca@avaya.com" Date: Fri, 2 Oct 2009 12:00:55 -0400 Thread-Topic: Clear draft-ietf-vrrp-unified-spec 5 Thread-Index: AcpDeYX2uwXDCsT6SVu1uGMy43SgHw== Message-ID: <450AE4BEC513614F96969DDA34F3593497639BB0@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F3593497639BB0EUSAACMS0701eam_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2009 16:00:56.0683 (UTC) FILETIME=[86E663B0:01CA4379] Cc: "Radia.Perlman@Sun.COM" , "vrrp@ietf.org" Subject: [VRRP] Clear draft-ietf-vrrp-unified-spec 5 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 15:59:43 -0000 --_000_450AE4BEC513614F96969DDA34F3593497639BB0EUSAACMS0701eam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, Please see below for the various proposed resolutions. Are they sufficient= to clear the draft? Thanks, Steve Discuss remarks; 1. The version management and transition plan for VRRP is unlear to me. The Introduction section mentions that this is 'version three (3) of the protoc= ol and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 an= d on draft-ieft-vrrp-ipv6-spec-08.txt'. However RFC 3768 does not make the claim= to be VRRPv2, itlooks like this terminology was decided later and is defined h= ere for the first time. On the other hand draft-ieft-vrrp-ipv6-spec-08.txt whic= h VRRPv3 is based upon is just an informative reference and is actually an expired I-D? Should not this document update RFC 3768, and should not at le= ast part of the migration and coexistence issues in Appendix A be moved to the Operational Issues section? We are changing draft to obsoletes 3768. If we move the below from appendix A to operational issues, will t= hat work for this item? VRRPv3 support of VRRPv2 VRRPv2 and VRRPv3 interoperation is optional. Mixing VRRPv2 and VRRPv3 should only be done when transitioning from VRRPv2 to VRRPv3. Mixing the two versions should not be considered a permanent solution. An implementation MAY implement a configuration flag that tells it to listen for and send both VRRPv2 and VRRPv3 advertisements. When configured this way and the Master, it MUST send both types at the configured rate, even if sub-second. When configured this way and the Backup, it should time out based on the rate advertised by the master; in the case of a VRRPv2 master this means it must translate the timeout value it receives (in seconds) into centi-seconds. Also, a backup should ignore VRRPv2 advertisements from the current master if it is also receiving VRRPv3 packets from it. It MAY report when a v3 master is *not* sending v2 packets: that suggests they don't agree on whether they're supporting v2 routers. 2. I do not understand what is the logic of including a section 9 'Operatio= n over FDDI, Token Ring, and ATM LANE' in this document. Has anybody heard ab= out a deployment of any of these layer 2 networks lately, and with VRRP atop of them? This is moved to an appendix with the rationale that some future L2 may com= e someday and this thinking may be useful. It seems not to hurt anything t= o keep is as appendix. 3. Accept_Mode defaulting to false seems unrealistic at least in deployment= s I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual addr= ess no longer responds to ping; I've also seen an implementation to reject ping= s to the virtual IP when it's in Master mode, but this seems like an implementat= ion bug if so (I'd like a confirmation if this is the case). In any case, this restriction makes troubleshooting and deployment a pain; hosts and management systems often ping the gateway address to see if the network is working, and this kills that assumption. Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position. We are thinking that accept_mode needs a configuration control and that the= default vaule could be an implementation choice. This is TBD on the list. --_000_450AE4BEC513614F96969DDA34F3593497639BB0EUSAACMS0701eam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Dan,
 
Please see below for the various proposed resolutions.  Are they = sufficient to clear the draft?
 
Thanks,
Steve
 
Discuss remarks;
 
1= . The version management and transition plan for VRRP is unlear to me. The<= /font>
I= ntroduction section mentions that this is 'version three (3) of the protoco= l
a= nd it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and= on
d= raft-ieft-vrrp-ipv6-spec-08.txt'. However RFC 3768 does not make the claim = to
b= e VRRPv2, itlooks like this terminology was decided later and is defined he= re
f= or the first time. On the other hand draft-ieft-vrrp-ipv6-spec-08.txt which=
V= RRPv3 is based upon is just an informative reference and is actually an
e= xpired I-D? Should not this document update RFC 3768, and should not at lea= st
p= art of the migration and coexistence issues in Appendix A be moved to the
O= perational Issues section?
&= nbsp;
   W= e are changing draft to obsoletes 3768.
 
        I= f we move the below from appendix A to operational issues, will  that = work for this item?
 
   VRRPv3 support of VRRPv2
 
         &nbs= p;      VRRPv2 and VRRPv3 interoperation is optio= nal. Mixing
          &nb= sp; VRRPv2 and VRRPv3 should only be done when
          &nb= sp; transitioning from VRRPv2 to VRRPv3. Mixing the two
          &nb= sp; versions should not be considered a permanent
          &nb= sp; solution.
 
        An implementat= ion MAY implement a configuration flag that
        tells it to li= sten for and send both VRRPv2 and VRRPv3
        advertisements= .
 
        When configure= d this way and the Master, it MUST send both
        types at the c= onfigured rate, even if sub-second.
 
        When configure= d this way and the Backup, it should time out
        based on the r= ate advertised by the master; in the case of a
        VRRPv2 master = this means it must translate the timeout value
        it receives (i= n seconds) into centi-seconds.  Also, a backup
        should ignore = VRRPv2 advertisements from the current master if
        it is also rec= eiving VRRPv3 packets from it.  It MAY report
        when a v3 mast= er is *not* sending v2 packets: that suggests
        they don't agr= ee on whether they're supporting v2 routers.
&= nbsp;
2= . I do not understand what is the logic of including a section 9 'Operation=
o= ver FDDI, Token Ring, and ATM LANE' in this document. Has anybody heard abo= ut
a= deployment of any of these layer 2 networks lately, and with VRRP atop of<= /font>
t= hem?
&= nbsp;
This is moved to an appendix with the rationale th= at some future L2 may come someday and this thinking may be useful.  I= t seems not to hurt anything to keep is as appendix.
 
3= . Accept_Mode defaulting to false seems unrealistic at least in deployments=
I= 've seen.  Using accept-data config knob seems very common. Unless ena= ble
A= ccept_Mode, when the virtual address moves to the Backup, the virtual addre= ss
n= o longer responds to ping; I've also seen an implementation to reject pings= to
t= he virtual IP when it's in Master mode, but this seems like an implementati= on
b= ug if so (I'd like a confirmation if this is the case).
&= nbsp;
I= n any case, this restriction makes troubleshooting and deployment a pain;
h= osts and management systems often ping the gateway address to see if the
n= etwork is working, and this kills that assumption.
&= nbsp;
U= nless the WG has recently discussed and reached consensus that Accept_Mode<= /font>
s= hould still default to false, I'd consider revisiting this position.=
&= nbsp;
We are thinking that accept_mode needs a configura= tion control and that the default vaule could be an implementation choice.&= nbsp; This is TBD on the list. 
 =
--_000_450AE4BEC513614F96969DDA34F3593497639BB0EUSAACMS0701eam_-- From jari.arkko@piuha.net Fri Oct 2 10:17:54 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B15D53A69FE for ; Fri, 2 Oct 2009 10:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBbFZzI3U44c for ; Fri, 2 Oct 2009 10:17:54 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D5FD23A67B0 for ; Fri, 2 Oct 2009 10:17:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 92C84D4936; Fri, 2 Oct 2009 20:19:21 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AVCxzNvPAzJ; Fri, 2 Oct 2009 20:19:20 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B4D38D492B; Fri, 2 Oct 2009 20:19:20 +0300 (EEST) Message-ID: <4AC63617.5010300@piuha.net> Date: Fri, 02 Oct 2009 20:19:19 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Stephen Nadas References: <450AE4BEC513614F96969DDA34F3593497639A45@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <450AE4BEC513614F96969DDA34F3593497639A45@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Oct 2009 10:27:16 -0700 Cc: "Radia.Perlman@Sun.COM" , "vrrp@ietf.org" Subject: Re: [VRRP] Please clear draft-ietf-vrrp-unified-spec number 2 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:17:54 -0000 Ok for me (and same for your other mails). So this is just your text suggestion or do you actually have a new draft version out there? I don't find a new draft version yet... Jari Stephen Nadas wrote: > Hi Jari, > > Regarding this discuss, will the below clear it (I hope so as it's > based on your suggestion :-) > > Thanks, > Steve > > Discuss: > > Thirdly, I do not understand why there is no issue, because the > backup taking over, because then the backup has to authoratively > sign the NAs and RAs it is sending, for the primary's address. > If the "trust anchor and cga" mode from RFC 3971 is used, the > private key would have to be shared, or this would not work at > all. And private key sharing is not necessarily a good idea. > > I would recommend saying this: > - VRRP is compatible with "trust anchor" and "trust anchor or cga" modes > of SEND > - The configuration needs to give the two routers the same > prefix delegation in the certificates > - But still, the routers should have their own key pairs > > Text added at end of section 9: > > In the context of IPv6 operation, if SEcure Neighbor Discovery (SEND) > is deployed, VRRP is s compatible with the "trust anchor" and "trust > anchor or cga" modes of SEND [RFC3971]. The (SEND) configuration > needs to give the master and backup routers the same prefix > delegation in the certificates so that master and backup routers > advertize the same set of subnet prefixes. However, the master and > backup routers should have their own key pairs to avoid private key > sharing. > From stephen.nadas@ericsson.com Fri Oct 2 10:35:52 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9D1228C0DB for ; Fri, 2 Oct 2009 10:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG4A41t1a1uq for ; Fri, 2 Oct 2009 10:35:52 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id E604F3A67F5 for ; Fri, 2 Oct 2009 10:35:51 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n92HbGBS015887; Fri, 2 Oct 2009 12:37:17 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 12:36:05 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 12:36:05 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 2 Oct 2009 13:36:05 -0400 From: Stephen Nadas To: Jari Arkko Date: Fri, 2 Oct 2009 13:36:03 -0400 Thread-Topic: Please clear draft-ietf-vrrp-unified-spec number 2 Thread-Index: AcpDhQVWgqsnZ2A2SCSoF2RWWBw92AAAa4NQ Message-ID: <450AE4BEC513614F96969DDA34F3593497639C6F@EUSAACMS0701.eamcs.ericsson.se> References: <450AE4BEC513614F96969DDA34F3593497639A45@EUSAACMS0701.eamcs.ericsson.se> <4AC63617.5010300@piuha.net> In-Reply-To: <4AC63617.5010300@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2009 17:36:05.0693 (UTC) FILETIME=[D1BC2ED0:01CA4386] Cc: "Radia.Perlman@Sun.COM" , "vrrp@ietf.org" Subject: Re: [VRRP] Please clear draft-ietf-vrrp-unified-spec number 2 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 17:35:52 -0000 It is text suggestion until I get it all lined up=20 Thanks Steve =20 SJN> -----Original Message----- SJN> From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 SJN> Sent: Friday, October 02, 2009 1:19 PM SJN> To: Stephen Nadas SJN> Cc: Mukesh Gupta; Radia.Perlman@Sun.COM;=20 SJN> adrian.farrel@huawei.com; vrrp@ietf.org SJN> Subject: Re: Please clear draft-ietf-vrrp-unified-spec number 2 SJN>=20 SJN> Ok for me (and same for your other mails). So this is just=20 SJN> your text suggestion or do you actually have a new draft=20 SJN> version out there? I don't find a new draft version yet... SJN>=20 SJN> Jari SJN>=20 [snipped]= From stephen.nadas@ericsson.com Fri Oct 2 14:52:10 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6083A67EF for ; Fri, 2 Oct 2009 14:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwMtwwVSjLgP for ; Fri, 2 Oct 2009 14:52:09 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 75F6D3A67E7 for ; Fri, 2 Oct 2009 14:52:09 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n92LrWRU004165; Fri, 2 Oct 2009 16:53:35 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 16:53:32 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 16:53:32 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.112]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 2 Oct 2009 17:53:32 -0400 From: Stephen Nadas To: "Pasi.Eronen@nokia.com" Date: Fri, 2 Oct 2009 17:53:30 -0400 Thread-Topic: Clear draft-ietf-vrrp-unified-spec 6 Thread-Index: AcpDqsd1gdRQfOG4S5qtU4U8qxPiHg== Message-ID: <450AE4BEC513614F96969DDA34F3593497639DC0@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Oct 2009 21:53:32.0668 (UTC) FILETIME=[C8D983C0:01CA43AA] Cc: "Radia.Perlman@Sun.COM" , "vrrp@ietf.org" Subject: [VRRP] Clear draft-ietf-vrrp-unified-spec 6 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 21:52:10 -0000 Hi Pasi, With respect to your 1st part of discuss (2nd part still in process):=20 The security considerations text basically says security doesn't have to be considered here because an attacker can cause havoc with ARP anyway. I don't think this is fully accurate description. Many networks with untrusted hosts use switch security features that prevent hosts from bringing down the network with spoofed ARP packets (somewhat similar to what SAVI WG is working on). While compromising one of the switches or routers would still cause damage, compromised or malicious ordinary hosts (attached to switch ports where these features are enabled) can't do that much. The other reason for removing cryptographic authentication of VRRP messages is said to be misconfigured secrets (which obviously does cause problems -- but on the other hand, this situation should be detected very quickly). If it's indeed the case that cryptographic per-message authentication isn't a good solution to securing VRRP, at the very least the document should discuss other possible mechanisms. Perhaps e.g. filtering mechanisms in switches, configured on per-port basis, could provide some protection? Or could this somehow leverage the existing mechanisms for ARP? Does the below text capture your concerns? If not could you please suggest= changes that would?=20 VRRP for IPvX does not currently include any type of authentication. Earlier versions of the VRRP (for IPv4) specification included several types of authentication ranging from none to strong. Operational experience and further analysis determined that these did not provide sufficient security to overcome the vulnerability of misconfigured secrets causing multiple masters to be elected. Due to the nature of the VRRP protocol, even if VRRP messages are cryptographically protected, it does not prevent hostile nodes from behaving as if they are a VRRP master, creating multiple masters. Authentication of VRRP messages could have prevented a hostile node from causing all properly functioning routers from going into backup state. However, having multiple masters can cause as much disruption as no routers, which authentication cannot prevent. Also, even if a hostile nodes could not disrupt VRRP, it can disrupt ARP and create the same effect as having all routers go into backup. Some L2 switches provide the capability to filter out, e.g., ARP and/or ND messages from end hosts on a switch port basis. This mechanism could also filter VRRP messages from switch ports associated with end hosts and can be considered for deployments with untrusted hosts. Thanks, Steve=20 From mukesh@juniper.net Fri Oct 2 16:25:26 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D08D3A692E for ; Fri, 2 Oct 2009 16:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.635 X-Spam-Level: X-Spam-Status: No, score=-6.635 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwLTtu9K6OaN for ; Fri, 2 Oct 2009 16:25:22 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 865113A67EC for ; Fri, 2 Oct 2009 16:25:17 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSsaMNfe/5g6222iYew+jb5qRObyD6Z7S@postini.com; Fri, 02 Oct 2009 16:26:51 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 2 Oct 2009 16:26:08 -0700 From: Mukesh Gupta To: "vrrp@ietf.org" Date: Fri, 2 Oct 2009 16:26:05 -0700 Thread-Topic: Default Value of Accept_Mode Thread-Index: AcpDt7a0S0fo6R9bTVSNAA5SMibGxA== Message-ID: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_497B6D90E0023142AF34948DEFFAB38D3A66EEA26CEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "dromasca@avaya.com" , Adrian Farrel Subject: [VRRP] Default Value of Accept_Mode X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 23:25:26 -0000 --_000_497B6D90E0023142AF34948DEFFAB38D3A66EEA26CEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [WG Chair Hat Off] Folks, During the IESG review of the unified VRRP draft, Dan, Operations and Manag= ement AD, questioned the default value of the Accept_Mode in the draft. Th= e current default value is False and he would like us to reconsider that (h= is comments in the end of this email). We had discussions about this on the mailing list. However, I don't rememb= er having a clear WG consensus for either default value. Given the fact that the default value has absolutely no impact on the inter= operability and the fact that both the values have their pros and cons, we = are proposing that the draft should leave the default value to the implemen= tations. The draft would say that the implementations are free to choose a= ny default value. Please let us know if you agree/disagree. If we do not hear anything back,= we will assume that the WG agrees :) Regards Mukesh Dan's Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Accept_Mode defaulting to false seems unrealistic at least in deployment= s I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual addr= ess no longer responds to ping; I've also seen an implementation to reject ping= s to the virtual IP when it's in Master mode, but this seems like an implementat= ion bug if so (I'd like a confirmation if this is the case). In any case, this restriction makes troubleshooting and deployment a pain; = hosts and management systems often ping the gateway address to see if the network= is working, and this kills that assumption. Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position. --_000_497B6D90E0023142AF34948DEFFAB38D3A66EEA26CEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[WG Chair Hat Off]

 

Folks,

 

During the IESG review of the unified VRRP draft, Dan, Operations and Management A= D, questioned the default value of the Accept_Mode in the draft.  The current defaul= t value is False and he would like us to reconsider that (his comments in the= end of this email).

 

We had discussions about this on the mailing list.  However, I don’= t remember having a clear WG consensus for either default value.

 

Given the fact that the default value has absolutely no impact on the interoperab= ility and the fact that both the values have their pros and cons, we are proposin= g that the draft should leave the default value to the implementations. = The draft would say that the implementations are free to choose any default val= ue.

 

Please let us know if you agree/disagree.  If we do not hear anything back, w= e will assume that the WG agrees J

 

Regards

Mukesh

 

Dan’s  Comment:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

3. Accept_Mode defaulting to false seems unrealistic at least = in deployments

I've seen.  Using accept-data config knob seems very comm= on. Unless enable

Accept_Mode, when the virtual address moves to the Backup, the virtual address

no longer responds to ping; I've also seen an implementation t= o reject pings to

the virtual IP when it's in Master mode, but this seems like a= n implementation

bug if so (I'd like a confirmation if this is the case).<= /o:p>

 

In any case, this restriction makes troubleshooting and deploy= ment a pain; hosts

and management systems often ping the gateway address to see i= f the network is

working, and this kills that assumption.

 

Unless the WG has recently discussed and reached consensus tha= t Accept_Mode

should still default to false, I'd consider revisiting this position.

 

--_000_497B6D90E0023142AF34948DEFFAB38D3A66EEA26CEMBX01HQjnprn_-- From johcruz@cisco.com Mon Oct 5 11:47:26 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A903A6806 for ; Mon, 5 Oct 2009 11:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2BIIVUimu2v for ; Mon, 5 Oct 2009 11:47:21 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0DAB53A6A2D for ; Mon, 5 Oct 2009 11:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johcruz@cisco.com; l=12618; q=dns/txt; s=sjiport04001; t=1254768536; x=1255978136; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"John=20Cruz=20(johcruz)"=20 |Subject:=20RE:=20[VRRP]=20Default=20Value=20of=20Accept_ Mode|Date:=20Mon,=205=20Oct=202009=2011:48:44=20-0700 |Message-ID:=20<9D0602B62D632D499E0A26CBCDA74A7D0616C03D@ xmb-sjc-22a.amer.cisco.com>|To:=20"Mukesh=20Gupta"=20,=20|Cc:=20,=20"Adrian=20Farrel"=20 |MIME-Version:=201.0|In-Reply-To:=20<497B6D90E0023142AF34 948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net>|References:=20 <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnp r.net>; bh=zGqiTJNSwEw4wrVvyeLKkUZ1cih2m3yCq9KHwFtEKoU=; b=euwa4sMGG/oVG2pTRAFNcKvta6v3pmTILKWXyJUBtYPd65VaN+XctyCk kCMdSlgACJiotL7174RNrChd/El2h9A1Colbz7iaKOOho/GzYE9TvNF3v GA/O9T1hOT+FJoSOtKz+5ToaEgDfwnwRIsROxVEO8NI8EV6KEjN3XyvJr 8=; Authentication-Results: sj-iport-4.cisco.com; dkim=pass (partially verified [12551 bytes] [TEST]) header.i=johcruz@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsEAD/cyUqrR7O6/2dsb2JhbACCKSy4fohhAY4uBoQq X-IronPort-AV: E=Sophos;i="4.44,507,1249257600"; d="scan'208,217";a="44847220" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 05 Oct 2009 18:48:56 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n95ImuSF011562; Mon, 5 Oct 2009 11:48:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n95Imuj6000669; Mon, 5 Oct 2009 18:48:56 GMT Received: from xmb-sjc-22a.amer.cisco.com ([128.107.191.81]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Oct 2009 11:48:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA45EC.7DD973DC" Date: Mon, 5 Oct 2009 11:48:44 -0700 Message-ID: <9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sjc-22a.amer.cisco.com> In-Reply-To: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VRRP] Default Value of Accept_Mode Thread-Index: AcpDt7a0S0fo6R9bTVSNAA5SMibGxACNFBOA References: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net> From: "John Cruz (johcruz)" To: "Mukesh Gupta" , X-OriginalArrivalTime: 05 Oct 2009 18:48:56.0415 (UTC) FILETIME=[7E20AEF0:01CA45EC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12551; t=1254768536; x=1255632536; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=johcruz@cisco.com; z=From:=20=22John=20Cruz=20(johcruz)=22=20 |Subject:=20RE=3A=20[VRRP]=20Default=20Value=20of=20Accept_ Mode |Sender:=20; bh=NmFDxwSZu80J/xWdj2zDUkYdkPyzhWXSxtzfT1g0N58=; b=B3fuG+PkZ8M38GHvj5LmKMLvoBlK9AvDy1slks95dfzqvdDsSmQrfOohzF vlQ01Ilp9JaAIQ3B4Tf739lhpdSUdrrDbQfNxyglh3ikAFXwYBIAayvZOInI CyZ85JqFUK; Cc: dromasca@avaya.com, Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 18:47:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA45EC.7DD973DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mukesh, =20 Leaving the default value to be implementation dependent may not be a good idea as it will cause interoperability issues in environments where customers have a mix of devices from different vendors. =20 John =20 From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Mukesh Gupta Sent: Friday, October 02, 2009 4:26 PM To: vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: [VRRP] Default Value of Accept_Mode =20 [WG Chair Hat Off] =20 Folks, =20 During the IESG review of the unified VRRP draft, Dan, Operations and Management AD, questioned the default value of the Accept_Mode in the draft. The current default value is False and he would like us to reconsider that (his comments in the end of this email). =20 We had discussions about this on the mailing list. However, I don't remember having a clear WG consensus for either default value. =20 Given the fact that the default value has absolutely no impact on the interoperability and the fact that both the values have their pros and cons, we are proposing that the draft should leave the default value to the implementations. The draft would say that the implementations are free to choose any default value. =20 Please let us know if you agree/disagree. If we do not hear anything back, we will assume that the WG agrees J =20 Regards Mukesh =20 Dan's Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Accept_Mode defaulting to false seems unrealistic at least in deployments I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual address no longer responds to ping; I've also seen an implementation to reject pings to the virtual IP when it's in Master mode, but this seems like an implementation bug if so (I'd like a confirmation if this is the case). =20 In any case, this restriction makes troubleshooting and deployment a pain; hosts and management systems often ping the gateway address to see if the network is working, and this kills that assumption. =20 Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position. =20 ------_=_NextPart_001_01CA45EC.7DD973DC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Mukesh,

 

Leaving the default = value to be implementation

dependent may not be = a good idea as it will cause

interoperability = issues in environments where

customers  have = a mix of devices from different

vendors.

 

John

 

From:= vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of = Mukesh Gupta
Sent: Friday, October 02, 2009 4:26 PM
To: vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: [VRRP] Default Value of = Accept_Mode

 

[WG Chair Hat Off]

 

Folks,

 

During the IESG review of the unified VRRP draft, Dan, Operations and = Management AD, questioned the default value of the Accept_Mode in the draft.  The = current default value is False and he would like us to reconsider that (his = comments in the end of this email).

 

We had discussions about this on the mailing list.  However, I = don’t remember having a clear WG consensus for either default = value.

 

Given the fact that the default value has absolutely no impact on the interoperability and the fact that both the values have their pros and = cons, we are proposing that the draft should leave the default value to the implementations.  The draft would say that the implementations are = free to choose any default value.

 

Please let us know if you agree/disagree.  If we do not hear anything = back, we will assume that the WG agrees J

 

Regards

Mukesh

 

Dan’s  Comment:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

3. Accept_Mode defaulting to false seems unrealistic at = least in deployments

I've seen.  Using accept-data config knob seems very = common. Unless enable

Accept_Mode, when the virtual address moves to the Backup, = the virtual address

no longer responds to ping; I've also seen an = implementation to reject pings to

the virtual IP when it's in Master mode, but this seems = like an implementation

bug if so (I'd like a confirmation if this is the = case).

 

In any case, this restriction makes troubleshooting and = deployment a pain; hosts

and management systems often ping the gateway address to = see if the network is

working, and this kills that = assumption.

 

Unless the WG has recently discussed and reached consensus = that Accept_Mode

should still default to false, I'd consider revisiting this position.

 

------_=_NextPart_001_01CA45EC.7DD973DC-- From mukesh@juniper.net Tue Oct 6 09:56:02 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE92B3A67E9 for ; Tue, 6 Oct 2009 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.629 X-Spam-Level: X-Spam-Status: No, score=-6.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG55Zy0ru6s3 for ; Tue, 6 Oct 2009 09:55:57 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 0452B3A65A6 for ; Tue, 6 Oct 2009 09:55:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSst2+B3Bul/XmMw+QGPC7QaWaJZtvDHw@postini.com; Tue, 06 Oct 2009 09:57:35 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 6 Oct 2009 09:53:21 -0700 From: Mukesh Gupta To: "John Cruz (johcruz)" , "vrrp@ietf.org" Date: Tue, 6 Oct 2009 09:53:15 -0700 Thread-Topic: [VRRP] Default Value of Accept_Mode Thread-Index: AcpDt7a0S0fo6R9bTVSNAA5SMibGxACNFBOAAC42R3A= Message-ID: <497B6D90E0023142AF34948DEFFAB38D3A671590B7@EMBX01-HQ.jnpr.net> References: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net> <9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sjc-22a.amer.cisco.com> In-Reply-To: <9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sjc-22a.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_497B6D90E0023142AF34948DEFFAB38D3A671590B7EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "dromasca@avaya.com" , Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 16:56:03 -0000 --_000_497B6D90E0023142AF34948DEFFAB38D3A671590B7EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John, Could you please explain a little more about the interoperability issues th= at you are referring to? As far as I understand, an operator will see different behavior from the de= vices with different default values when he/she tries to connect to the vir= tual address. However, it should not cause any protocol interoperability i= ssues. Moreover, the operator would be able to change the default value us= ing the configurable knob to see consistent behavior from all the devices. Regards Mukesh From: John Cruz (johcruz) [mailto:johcruz@cisco.com] Sent: Monday, October 05, 2009 11:49 AM To: Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode Hi Mukesh, Leaving the default value to be implementation dependent may not be a good idea as it will cause interoperability issues in environments where customers have a mix of devices from different vendors. John From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Muk= esh Gupta Sent: Friday, October 02, 2009 4:26 PM To: vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: [VRRP] Default Value of Accept_Mode [WG Chair Hat Off] Folks, During the IESG review of the unified VRRP draft, Dan, Operations and Manag= ement AD, questioned the default value of the Accept_Mode in the draft. Th= e current default value is False and he would like us to reconsider that (h= is comments in the end of this email). We had discussions about this on the mailing list. However, I don't rememb= er having a clear WG consensus for either default value. Given the fact that the default value has absolutely no impact on the inter= operability and the fact that both the values have their pros and cons, we = are proposing that the draft should leave the default value to the implemen= tations. The draft would say that the implementations are free to choose a= ny default value. Please let us know if you agree/disagree. If we do not hear anything back,= we will assume that the WG agrees :) Regards Mukesh Dan's Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Accept_Mode defaulting to false seems unrealistic at least in deployment= s I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual addr= ess no longer responds to ping; I've also seen an implementation to reject ping= s to the virtual IP when it's in Master mode, but this seems like an implementat= ion bug if so (I'd like a confirmation if this is the case). In any case, this restriction makes troubleshooting and deployment a pain; = hosts and management systems often ping the gateway address to see if the network= is working, and this kills that assumption. Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position. --_000_497B6D90E0023142AF34948DEFFAB38D3A671590B7EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John,

 

Could you please explain a little more about the interoperability issues that you= are referring to?

 

As far as I understand, an operator will see different behavior from the devic= es with different default values when he/she tries to connect to the virtual addres= s.  However, it should not cause any protocol interoperability issues.  Mo= reover, the operator would be able to change the default value using the configurab= le knob to see consistent behavior from all the devices.

 

Regards

Mukesh

 

From: John Cruz (jo= hcruz) [mailto:johcruz@cisco.com]
Sent: Monday, October 05, 2009 11:49 AM
To: Mukesh Gupta; vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: RE: [VRRP] Default Value of Accept_Mode

 

Hi Mukesh,

 =

Leaving the default valu= e to be implementation

dependent may not be a g= ood idea as it will cause

interoperability issues = in environments where

customers  have a m= ix of devices from different

vendors.

 =

John

 =

From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Mu= kesh Gupta
Sent: Friday, October 02, 2009 4:26 PM
To: vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: [VRRP] Default Value of Accept_Mode

 

[WG Chair Hat Off]

 

Folks,

 

During the IESG review of the unified VRRP draft, Dan, Operations and Management A= D, questioned the default value of the Accept_Mode in the draft.  The cur= rent default value is False and he would like us to reconsider that (his comment= s in the end of this email).

 

We had discussions about this on the mailing list.  However, I don’= t remember having a clear WG consensus for either default value.

 

Given the fact that the default value has absolutely no impact on the interoperability and the fact that both the values have their pros and cons= , we are proposing that the draft should leave the default value to the implementations.  The draft would say that the implementations are fre= e to choose any default value.

 

Please let us know if you agree/disagree.  If we do not hear anything back, w= e will assume that the WG agrees J

 

Regards

Mukesh

 

Dan’s  Comment:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

3. Accept_Mode defaulting to false seems unrealistic at least = in deployments

I've seen.  Using accept-data config knob seems very comm= on. Unless enable

Accept_Mode, when the virtual address moves to the Backup, the virtual address

no longer responds to ping; I've also seen an implementation t= o reject pings to

the virtual IP when it's in Master mode, but this seems like a= n implementation

bug if so (I'd like a confirmation if this is the case).<= /o:p>

 

In any case, this restriction makes troubleshooting and deploy= ment a pain; hosts

and management systems often ping the gateway address to see i= f the network is

working, and this kills that assumption.

 

Unless the WG has recently discussed and reached consensus tha= t Accept_Mode

should still default to false, I'd consider revisiting this position.

 

--_000_497B6D90E0023142AF34948DEFFAB38D3A671590B7EMBX01HQjnprn_-- From johcruz@cisco.com Tue Oct 6 10:13:30 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE5A3A6A4D for ; Tue, 6 Oct 2009 10:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1uumka7YRJB for ; Tue, 6 Oct 2009 10:13:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5EF733A6973 for ; Tue, 6 Oct 2009 10:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johcruz@cisco.com; l=20375; q=dns/txt; s=sjiport06001; t=1254849297; x=1256058897; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"John=20Cruz=20(johcruz)"=20 |Subject:=20RE:=20[VRRP]=20Default=20Value=20of=20Accept_ Mode|Date:=20Tue,=206=20Oct=202009=2010:14:55=20-0700 |Message-ID:=20<9D0602B62D632D499E0A26CBCDA74A7D0616C4F1@ xmb-sjc-22a.amer.cisco.com>|To:=20"Mukesh=20Gupta"=20,=20|Cc:=20,=20"Adrian=20Farrel"=20 |MIME-Version:=201.0|In-Reply-To:=20<497B6D90E0023142AF34 948DEFFAB38D3A671590B7@EMBX01-HQ.jnpr.net>|References:=20 <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnp r.net>=20<9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sj c-22a.amer.cisco.com>=20<497B6D90E0023142AF34948DEFFAB38D 3A671590B7@EMBX01-HQ.jnpr.net>; bh=tiBPVqclzCoyYiASpUDEaH9v3WB36EuwbjKv98nGAqU=; b=eO46hKmjbD6q4z/h7rHBcOhbUCq3Pr0AXoYAIKBGFvnMfqyfZ9q01HuI 3d0uul222848SdwknXF7W4vfpozYYEgMxvcvCKAIgbXj+YgU4/ilyc6kz 31YiAVeG6ifldr83B2SVugRI0EYOyxpsfmX6rN8sDhzejKqJY+69ov1UW 8=; Authentication-Results: sj-iport-6.cisco.com; dkim=pass (partially verified [20308 bytes] [TEST]) header.i=johcruz@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQEAC8Yy0qrR7PD/2dsb2JhbACCKCy5GIhjAY8qBoQqgVc X-IronPort-AV: E=Sophos;i="4.44,513,1249257600"; d="scan'208,217";a="403125390" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Oct 2009 17:14:57 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n96HEvwk003360; Tue, 6 Oct 2009 10:14:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n96HEvh5010021; Tue, 6 Oct 2009 17:14:57 GMT Received: from xmb-sjc-22a.amer.cisco.com ([128.107.191.81]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Oct 2009 10:14:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA46A8.86E37CA0" Date: Tue, 6 Oct 2009 10:14:55 -0700 Message-ID: <9D0602B62D632D499E0A26CBCDA74A7D0616C4F1@xmb-sjc-22a.amer.cisco.com> In-Reply-To: <497B6D90E0023142AF34948DEFFAB38D3A671590B7@EMBX01-HQ.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [VRRP] Default Value of Accept_Mode Thread-Index: AcpDt7a0S0fo6R9bTVSNAA5SMibGxACNFBOAAC42R3AAAFesoA== References: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net> <9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sjc-22a.amer.cisco.com> <497B6D90E0023142AF34948DEFFAB38D3A671590B7@EMBX01-HQ.jnpr.net> From: "John Cruz (johcruz)" To: "Mukesh Gupta" , X-OriginalArrivalTime: 06 Oct 2009 17:14:56.0886 (UTC) FILETIME=[871E9960:01CA46A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20308; t=1254849297; x=1255713297; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=johcruz@cisco.com; z=From:=20=22John=20Cruz=20(johcruz)=22=20 |Subject:=20RE=3A=20[VRRP]=20Default=20Value=20of=20Accept_ Mode |Sender:=20; bh=/CRJlskRj1MDvjRnXH6PspQFdI7eAciXWkqBft1ZRS0=; b=klCmmv7Jz0Hy6i7uczAVZf5xqE32El/U6UkVTPgZi/YFV6JxRi6IQrzPSC mKcuFRXU9jEI/zxXtyxbBOC8TZhKuXm6ezWQsctSQ02nM6RT2UGfF5S8X4Wd gs4pStaJ9I; Cc: dromasca@avaya.com, Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 17:13:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA46A8.86E37CA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mukesh, =20 There are no interoperability issues w.r.t to the VRRP state machine. The interoperability issue that I mentioned refers to network deployments where customers have devices from different vendors on their network and each vendor has a different default value. In such situation, the onus is on the customers to know the default value for each implementation and set it accordingly, which I think is not a good idea. Let us choose a default value for all implementations. If the customer wants to change it, they can change it for all devices in the network. I believe, the concern is should it be TRUE or FALSE. With VRRP for IPv4, this option did not exists. Accept_mode is now being introduced for the unified spec. If there are no security/vulnerability issues w.r.t. accepting packets address to the virtual IP address, then let us default the value to TRUE. =20 Here is a crude analogy - can the VRRP hello timer value be a default value per implementation? =20 John =20 From: Mukesh Gupta [mailto:mukesh@juniper.net]=20 Sent: Tuesday, October 06, 2009 9:53 AM To: John Cruz (johcruz); vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode =20 John, =20 Could you please explain a little more about the interoperability issues that you are referring to? =20 As far as I understand, an operator will see different behavior from the devices with different default values when he/she tries to connect to the virtual address. However, it should not cause any protocol interoperability issues. Moreover, the operator would be able to change the default value using the configurable knob to see consistent behavior from all the devices. =20 Regards Mukesh =20 From: John Cruz (johcruz) [mailto:johcruz@cisco.com]=20 Sent: Monday, October 05, 2009 11:49 AM To: Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode =20 Hi Mukesh, =20 Leaving the default value to be implementation dependent may not be a good idea as it will cause interoperability issues in environments where customers have a mix of devices from different vendors. =20 John =20 From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Mukesh Gupta Sent: Friday, October 02, 2009 4:26 PM To: vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: [VRRP] Default Value of Accept_Mode =20 [WG Chair Hat Off] =20 Folks, =20 During the IESG review of the unified VRRP draft, Dan, Operations and Management AD, questioned the default value of the Accept_Mode in the draft. The current default value is False and he would like us to reconsider that (his comments in the end of this email). =20 We had discussions about this on the mailing list. However, I don't remember having a clear WG consensus for either default value. =20 Given the fact that the default value has absolutely no impact on the interoperability and the fact that both the values have their pros and cons, we are proposing that the draft should leave the default value to the implementations. The draft would say that the implementations are free to choose any default value. =20 Please let us know if you agree/disagree. If we do not hear anything back, we will assume that the WG agrees J =20 Regards Mukesh =20 Dan's Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Accept_Mode defaulting to false seems unrealistic at least in deployments I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual address no longer responds to ping; I've also seen an implementation to reject pings to the virtual IP when it's in Master mode, but this seems like an implementation bug if so (I'd like a confirmation if this is the case). =20 In any case, this restriction makes troubleshooting and deployment a pain; hosts and management systems often ping the gateway address to see if the network is working, and this kills that assumption. =20 Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position. =20 ------_=_NextPart_001_01CA46A8.86E37CA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Mukesh,

 

There are no = interoperability issues w.r.t to the VRRP state machine.  The = interoperability

issue that I = mentioned refers to network deployments where customers have devices

from different = vendors on their network and each vendor has a different  default value. = In

such situation, the = onus is on the customers to know the default value for each = implementation

and set it = accordingly, which I think is not a good idea. Let us choose a default value for = all

implementations. If = the customer wants to change it, they can change it for all devices in = the

network. I believe, = the concern is should it be TRUE or FALSE. With VRRP for IPv4, this = option

did not exists. =  Accept_mode is now being introduced for the unified spec. If there = are

no = security/vulnerability issues w.r.t. accepting packets address to the virtual IP address, = then

let us default the = value to TRUE.

 

Here is a crude = analogy – can the VRRP hello timer value be a default value per = implementation?

 

John

 

From:= Mukesh = Gupta [mailto:mukesh@juniper.net]
Sent: Tuesday, October 06, 2009 9:53 AM
To: John Cruz (johcruz); vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: RE: [VRRP] Default Value of = Accept_Mode

 

John,

 

Could you please explain a little more about the interoperability issues that = you are referring to?

 

As far as I understand, an operator will see different behavior from the = devices with different default values when he/she tries to connect to the = virtual address.  However, it should not cause any protocol = interoperability issues.  Moreover, the operator would be able to change the default = value using the configurable knob to see consistent behavior from all the = devices.

 

Regards

Mukesh

 

From:= John Cruz = (johcruz) [mailto:johcruz@cisco.com]
Sent: Monday, October 05, 2009 11:49 AM
To: Mukesh Gupta; vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: RE: [VRRP] Default Value of = Accept_Mode

 

Hi = Mukesh,

 

Leaving the default = value to be implementation

dependent may not be = a good idea as it will cause

interoperability = issues in environments where

customers  have = a mix of devices from different

vendors.

 

John

 

From:= vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of = Mukesh Gupta
Sent: Friday, October 02, 2009 4:26 PM
To: vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: [VRRP] Default Value of = Accept_Mode

 

[WG Chair Hat Off]

 

Folks,

 

During the IESG review of the unified VRRP draft, Dan, Operations and = Management AD, questioned the default value of the Accept_Mode in the draft.  The = current default value is False and he would like us to reconsider that (his = comments in the end of this email).

 

We had discussions about this on the mailing list.  However, I = don’t remember having a clear WG consensus for either default = value.

 

Given the fact that the default value has absolutely no impact on the interoperability and the fact that both the values have their pros and = cons, we are proposing that the draft should leave the default value to the implementations.  The draft would say that the implementations are = free to choose any default value.

 

Please let us know if you agree/disagree.  If we do not hear anything = back, we will assume that the WG agrees J

 

Regards

Mukesh

 

Dan’s  Comment:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

3. Accept_Mode defaulting to false seems unrealistic at = least in deployments

I've seen.  Using accept-data config knob seems very = common. Unless enable

Accept_Mode, when the virtual address moves to the Backup, = the virtual address

no longer responds to ping; I've also seen an = implementation to reject pings to

the virtual IP when it's in Master mode, but this seems = like an implementation

bug if so (I'd like a confirmation if this is the = case).

 

In any case, this restriction makes troubleshooting and = deployment a pain; hosts

and management systems often ping the gateway address to = see if the network is

working, and this kills that = assumption.

 

Unless the WG has recently discussed and reached consensus = that Accept_Mode

should still default to false, I'd consider revisiting this position.

 

------_=_NextPart_001_01CA46A8.86E37CA0-- From mukesh@juniper.net Wed Oct 7 10:56:21 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A56B28C0DD for ; Wed, 7 Oct 2009 10:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.625 X-Spam-Level: X-Spam-Status: No, score=-6.625 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+OW067nj+BD for ; Wed, 7 Oct 2009 10:56:13 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id E26D23A6872 for ; Wed, 7 Oct 2009 10:56:10 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSszWnPZX34lCjqdQW0Ps5wF37lt5Y/j7@postini.com; Wed, 07 Oct 2009 10:57:53 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 7 Oct 2009 10:46:24 -0700 From: Mukesh Gupta To: Don Provan , "John Cruz (johcruz)" , "vrrp@ietf.org" Date: Wed, 7 Oct 2009 10:46:21 -0700 Thread-Topic: [VRRP] Default Value of Accept_Mode Thread-Index: AcpDt7a0S0fo6R9bTVSNAA5SMibGxACNFBOAAC42R3AAAFesoAACHv7AADGoftA= Message-ID: <497B6D90E0023142AF34948DEFFAB38D3A67467986@EMBX01-HQ.jnpr.net> References: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net><9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sjc-22a.amer.cisco.com><497B6D90E0023142AF34948DEFFAB38D3A671590B7@EMBX01-HQ.jnpr.net> <9D0602B62D632D499E0A26CBCDA74A7D0616C4F1@xmb-sjc-22a.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_497B6D90E0023142AF34948DEFFAB38D3A67467986EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "dromasca@avaya.com" , Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 17:56:21 -0000 --_000_497B6D90E0023142AF34948DEFFAB38D3A67467986EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok. We hear 2 responses; one recommending TRUE and the other recommending F= ALSE :) It would be good to hear preferences of other WG members. Please speak up.= Here are the choices to make it easier. 1) Leave the default value to the implementers 2) Specify FALSE as the default value in the draft 3) Specify TRUE as the default value in the draft 4) I do not care Regards Mukesh From: Don Provan [mailto:dprovan@bivio.net] Sent: Tuesday, October 06, 2009 11:05 AM To: John Cruz (johcruz); Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode By this logic, the default should be FALSE since that's been the default un= til now. Previous versions of the protocol didn't allow accepting such pack= ets at all. -don ________________________________ From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Joh= n Cruz (johcruz) Sent: Tuesday, October 06, 2009 10:15 AM To: Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode Hi Mukesh, There are no interoperability issues w.r.t to the VRRP state machine. The = interoperability issue that I mentioned refers to network deployments where customers have d= evices from different vendors on their network and each vendor has a different de= fault value. In such situation, the onus is on the customers to know the default value for = each implementation and set it accordingly, which I think is not a good idea. Let us choose a d= efault value for all implementations. If the customer wants to change it, they can change it for= all devices in the network. I believe, the concern is should it be TRUE or FALSE. With VRRP fo= r IPv4, this option did not exists. Accept_mode is now being introduced for the unified spec. = If there are no security/vulnerability issues w.r.t. accepting packets address to the vi= rtual IP address, then let us default the value to TRUE. Here is a crude analogy - can the VRRP hello timer value be a default value= per implementation? John From: Mukesh Gupta [mailto:mukesh@juniper.net] Sent: Tuesday, October 06, 2009 9:53 AM To: John Cruz (johcruz); vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode John, Could you please explain a little more about the interoperability issues th= at you are referring to? As far as I understand, an operator will see different behavior from the de= vices with different default values when he/she tries to connect to the vir= tual address. However, it should not cause any protocol interoperability i= ssues. Moreover, the operator would be able to change the default value us= ing the configurable knob to see consistent behavior from all the devices. Regards Mukesh From: John Cruz (johcruz) [mailto:johcruz@cisco.com] Sent: Monday, October 05, 2009 11:49 AM To: Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode Hi Mukesh, Leaving the default value to be implementation dependent may not be a good idea as it will cause interoperability issues in environments where customers have a mix of devices from different vendors. John From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Muk= esh Gupta Sent: Friday, October 02, 2009 4:26 PM To: vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: [VRRP] Default Value of Accept_Mode [WG Chair Hat Off] Folks, During the IESG review of the unified VRRP draft, Dan, Operations and Manag= ement AD, questioned the default value of the Accept_Mode in the draft. Th= e current default value is False and he would like us to reconsider that (h= is comments in the end of this email). We had discussions about this on the mailing list. However, I don't rememb= er having a clear WG consensus for either default value. Given the fact that the default value has absolutely no impact on the inter= operability and the fact that both the values have their pros and cons, we = are proposing that the draft should leave the default value to the implemen= tations. The draft would say that the implementations are free to choose a= ny default value. Please let us know if you agree/disagree. If we do not hear anything back,= we will assume that the WG agrees :) Regards Mukesh Dan's Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Accept_Mode defaulting to false seems unrealistic at least in deployment= s I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual addr= ess no longer responds to ping; I've also seen an implementation to reject ping= s to the virtual IP when it's in Master mode, but this seems like an implementat= ion bug if so (I'd like a confirmation if this is the case). In any case, this restriction makes troubleshooting and deployment a pain; = hosts and management systems often ping the gateway address to see if the network= is working, and this kills that assumption. Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position. --_000_497B6D90E0023142AF34948DEFFAB38D3A67467986EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok. We hear 2 responses; one recommending TRUE and the other recommending FALSE= J

 

It would be good to hear preferences of other WG members.  Please speak u= p.  Here are the choices to make it easier.

 

1) Leave the default value to the implementers

2) Specify FALSE as the default value in the draft

3) Specify TRUE as the default value in the draft

4) I do not care

 

Regards

Mukesh

 

From: Don Provan [mailto:dprovan@bivio.net]
Sent: Tuesday, October 06, 2009 11:05 AM
To: John Cruz (johcruz); Mukesh Gupta; vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: RE: [VRRP] Default Value of Accept_Mode

 

By this logic, the default should be FALSE since that's been th= e default until now. Previous versions of the protocol didn't allow accepting such packets at all.

-don

 


From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of John Cruz (johcruz)
Sent: Tuesday, October 06, 2009 10:15 AM
To: Mukesh Gupta; vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: Re: [VRRP] Default Value of Accept_Mode

Hi Mukesh,

 =

There are no interoperab= ility issues w.r.t to the VRRP state machine.  The interoperability

issue that I mentioned r= efers to network deployments where customers have devices

from different vendors o= n their network and each vendor has a different  default value. In<= /span>

such situation, the onus= is on the customers to know the default value for each implementation<= /span>

and set it accordingly, = which I think is not a good idea. Let us choose a default value for all<= /span>

implementations. If the = customer wants to change it, they can change it for all devices in the

network. I believe, the = concern is should it be TRUE or FALSE. With VRRP for IPv4, this option

did not exists.  Accept_mode is now being introduced for the unified spec. If there ar= e

no security/vulnerabilit= y issues w.r.t. accepting packets address to the virtual IP address, then=

let us default the value= to TRUE.

 =

Here is a crude analogy = – can the VRRP hello timer value be a default value per implementation?

 =

John

 =

From: Mukesh Gupta [mailto:mukesh@juniper.net]
Sent: Tuesday, October 06, 2009 9:53 AM
To: John Cruz (johcruz); vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: RE: [VRRP] Default Value of Accept_Mode

 

John,

 

Could you please explain a little more about the interoperability issues that you= are referring to?

 

As far as I understand, an operator will see different behavior from the devic= es with different default values when he/she tries to connect to the virtual address.  However, it should not cause any protocol interoperability issues.  Moreover, the operator would be able to change the default va= lue using the configurable knob to see consistent behavior from all the devices= .

 

Regards

Mukesh

 

From: John Cruz (jo= hcruz) [mailto:johcruz@cisco.com]
Sent: Monday, October 05, 2009 11:49 AM
To: Mukesh Gupta; vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: RE: [VRRP] Default Value of Accept_Mode

 

Hi Mukesh,

 =

Leaving the default valu= e to be implementation

dependent may not be a g= ood idea as it will cause

interoperability issues = in environments where

customers  have a m= ix of devices from different

vendors.

 =

John

 =

From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Mu= kesh Gupta
Sent: Friday, October 02, 2009 4:26 PM
To: vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian Farrel
Subject: [VRRP] Default Value of Accept_Mode

 

[WG Chair Hat Off]

 

Folks,

 

During the IESG review of the unified VRRP draft, Dan, Operations and Management A= D, questioned the default value of the Accept_Mode in the draft.  The cur= rent default value is False and he would like us to reconsider that (his comment= s in the end of this email).

 

We had discussions about this on the mailing list.  However, I don’= t remember having a clear WG consensus for either default value.

 

Given the fact that the default value has absolutely no impact on the interoperability and the fact that both the values have their pros and cons= , we are proposing that the draft should leave the default value to the implemen= tations.  The draft would say that the implementations are free to choose any default value.

 

Please let us know if you agree/disagree.  If we do not hear anything back, w= e will assume that the WG agrees J

 

Regards

Mukesh

 

Dan’s  Comment:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

3. Accept_Mode defaulting to false seems unrealistic at least = in deployments

I've seen.  Using accept-data config knob seems very comm= on. Unless enable

Accept_Mode, when the virtual address moves to the Backup, the virtual address

no longer responds to ping; I've also seen an implementation t= o reject pings to

the virtual IP when it's in Master mode, but this seems like a= n implementation

bug if so (I'd like a confirmation if this is the case).<= /o:p>

 

In any case, this restriction makes troubleshooting and deploy= ment a pain; hosts

and management systems often ping the gateway address to see i= f the network is

working, and this kills that assumption.

 

Unless the WG has recently discussed and reached consensus tha= t Accept_Mode

should still default to false, I'd consider revisiting this position.

 

--_000_497B6D90E0023142AF34948DEFFAB38D3A67467986EMBX01HQjnprn_-- From bob.hinden@gmail.com Wed Oct 7 11:02:43 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7465A28C1B1 for ; Wed, 7 Oct 2009 11:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCUZwvHhaFdi for ; Wed, 7 Oct 2009 11:02:42 -0700 (PDT) Received: from mail-fx0-f228.google.com (mail-fx0-f228.google.com [209.85.220.228]) by core3.amsl.com (Postfix) with ESMTP id E696428C1AE for ; Wed, 7 Oct 2009 11:02:41 -0700 (PDT) Received: by fxm28 with SMTP id 28so4603607fxm.42 for ; Wed, 07 Oct 2009 11:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=dMSKPGuHwwAUvzN3i7ZdeOumwnLzaiUu/0AUv0UDbbg=; b=PpDX7fQ8Ei7930bNxwcJH/sHPlQ6U7XfN+wPO0sAi4MH/cHblbQD4B1kl1V0SAR/zC b8vyXRc0A7htFyZn+uI1lzNsl5d/mwXhd/wmg1TssVlVIQOMr9uaEEa9xl7R/dQM36zT /85Ys6JcjhBcZLmxMq+0h6jrVWMbPI06YcmtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=KizjB2okSZNu2SjeqKDR20q7dKX6fker2IXBmBE5a3kO04KEQ7Ro+5W8IhcGe+QYoP 7AOFDCezjDdQgNIr7HA6kIQcVtB5/JK75oNwILD/9cVFjuoUWl5WwfbMMpfWg35gwzoK Tm87TuCQYxf8UFKsoNqZphEz+oS3L9PPYTy9o= Received: by 10.87.66.2 with SMTP id t2mr240836fgk.62.1254938658142; Wed, 07 Oct 2009 11:04:18 -0700 (PDT) Received: from ?209.97.124.188? ([209.97.124.188]) by mx.google.com with ESMTPS id e20sm356329fga.15.2009.10.07.11.04.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 11:04:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Bob Hinden In-Reply-To: <497B6D90E0023142AF34948DEFFAB38D3A67467986@EMBX01-HQ.jnpr.net> Date: Wed, 7 Oct 2009 11:03:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net><9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sjc-22a.amer.cisco.com><497B6D90E0023142AF34948DEFFAB38D3A671590B7@EMBX01-HQ.jnpr.net> <9D0602B62D632D499E0A26CBCDA74A7D0616C4F1@xmb-sjc-22a.amer.cisco.com> <497B6D90E0023142AF34948DEFFAB38D3A67467986@EMBX01-HQ.jnpr.net> To: Mukesh Gupta X-Mailer: Apple Mail (2.1076) Cc: "dromasca@avaya.com" , Adrian Farrel , Don Provan , "vrrp@ietf.org" Subject: Re: [VRRP] Default Value of Accept_Mode X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 18:02:43 -0000 On Oct 7, 2009, at 10:46 AM, Mukesh Gupta wrote: > Ok. We hear 2 responses; one recommending TRUE and the other =20 > recommending FALSE J > > It would be good to hear preferences of other WG members. Please =20 > speak up. Here are the choices to make it easier. > > 1) Leave the default value to the implementers > 2) Specify FALSE as the default value in the draft > 3) Specify TRUE as the default value in the draft > 4) I do not care I think the main issue is that it should have a default value and not =20= be left to implementers. I would go with FALSE to be compatible with =20= earlier versions of the protocol (as Don Provan suggested). Bob > > Regards > Mukesh > > From: Don Provan [mailto:dprovan@bivio.net] > Sent: Tuesday, October 06, 2009 11:05 AM > To: John Cruz (johcruz); Mukesh Gupta; vrrp@ietf.org > Cc: dromasca@avaya.com; Adrian Farrel > Subject: RE: [VRRP] Default Value of Accept_Mode > > By this logic, the default should be FALSE since that's been the =20 > default until now. Previous versions of the protocol didn't allow =20 > accepting such packets at all. > -don > > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf =20= > Of John Cruz (johcruz) > Sent: Tuesday, October 06, 2009 10:15 AM > To: Mukesh Gupta; vrrp@ietf.org > Cc: dromasca@avaya.com; Adrian Farrel > Subject: Re: [VRRP] Default Value of Accept_Mode > > Hi Mukesh, > > There are no interoperability issues w.r.t to the VRRP state =20 > machine. The interoperability > issue that I mentioned refers to network deployments where customers =20= > have devices > from different vendors on their network and each vendor has a =20 > different default value. In > such situation, the onus is on the customers to know the default =20 > value for each implementation > and set it accordingly, which I think is not a good idea. Let us =20 > choose a default value for all > implementations. If the customer wants to change it, they can change =20= > it for all devices in the > network. I believe, the concern is should it be TRUE or FALSE. With =20= > VRRP for IPv4, this option > did not exists. Accept_mode is now being introduced for the unified =20= > spec. If there are > no security/vulnerability issues w.r.t. accepting packets address to =20= > the virtual IP address, then > let us default the value to TRUE. > > Here is a crude analogy =96 can the VRRP hello timer value be a =20 > default value per implementation? > > John > > From: Mukesh Gupta [mailto:mukesh@juniper.net] > Sent: Tuesday, October 06, 2009 9:53 AM > To: John Cruz (johcruz); vrrp@ietf.org > Cc: dromasca@avaya.com; Adrian Farrel > Subject: RE: [VRRP] Default Value of Accept_Mode > > John, > > Could you please explain a little more about the interoperability =20 > issues that you are referring to? > > As far as I understand, an operator will see different behavior from =20= > the devices with different default values when he/she tries to =20 > connect to the virtual address. However, it should not cause any =20 > protocol interoperability issues. Moreover, the operator would be =20 > able to change the default value using the configurable knob to see =20= > consistent behavior from all the devices. > > Regards > Mukesh > > From: John Cruz (johcruz) [mailto:johcruz@cisco.com] > Sent: Monday, October 05, 2009 11:49 AM > To: Mukesh Gupta; vrrp@ietf.org > Cc: dromasca@avaya.com; Adrian Farrel > Subject: RE: [VRRP] Default Value of Accept_Mode > > Hi Mukesh, > > Leaving the default value to be implementation > dependent may not be a good idea as it will cause > interoperability issues in environments where > customers have a mix of devices from different > vendors. > > John > > From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf =20= > Of Mukesh Gupta > Sent: Friday, October 02, 2009 4:26 PM > To: vrrp@ietf.org > Cc: dromasca@avaya.com; Adrian Farrel > Subject: [VRRP] Default Value of Accept_Mode > > [WG Chair Hat Off] > > Folks, > > During the IESG review of the unified VRRP draft, Dan, Operations =20 > and Management AD, questioned the default value of the Accept_Mode =20 > in the draft. The current default value is False and he would like =20= > us to reconsider that (his comments in the end of this email). > > We had discussions about this on the mailing list. However, I don=92t = =20 > remember having a clear WG consensus for either default value. > > Given the fact that the default value has absolutely no impact on =20 > the interoperability and the fact that both the values have their =20 > pros and cons, we are proposing that the draft should leave the =20 > default value to the implementations. The draft would say that the =20= > implementations are free to choose any default value. > > Please let us know if you agree/disagree. If we do not hear =20 > anything back, we will assume that the WG agrees J > > Regards > Mukesh > > Dan=92s Comment: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 3. Accept_Mode defaulting to false seems unrealistic at least in =20 > deployments > I've seen. Using accept-data config knob seems very common. Unless =20= > enable > Accept_Mode, when the virtual address moves to the Backup, the =20 > virtual address > no longer responds to ping; I've also seen an implementation to =20 > reject pings to > the virtual IP when it's in Master mode, but this seems like an =20 > implementation > bug if so (I'd like a confirmation if this is the case). > > In any case, this restriction makes troubleshooting and deployment a =20= > pain; hosts > and management systems often ping the gateway address to see if the =20= > network is > working, and this kills that assumption. > > Unless the WG has recently discussed and reached consensus that =20 > Accept_Mode > should still default to false, I'd consider revisiting this position. > > _______________________________________________ > vrrp mailing list > vrrp@ietf.org > https://www.ietf.org/mailman/listinfo/vrrp From stephen.nadas@ericsson.com Wed Oct 14 13:28:33 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13AA63A682B for ; Wed, 14 Oct 2009 13:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELRUpfEYOF5b for ; Wed, 14 Oct 2009 13:28:24 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 7D1FB3A68C0 for ; Wed, 14 Oct 2009 13:28:24 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9EKSJ9a011559; Wed, 14 Oct 2009 15:28:19 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 15:28:16 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 15:28:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.224]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 14 Oct 2009 16:28:15 -0400 From: Stephen Nadas To: Mukesh Gupta , Don Provan , "John Cruz (johcruz)" , "vrrp@ietf.org" Date: Wed, 14 Oct 2009 16:28:13 -0400 Thread-Topic: [VRRP] Default Value of Accept_Mode Thread-Index: AcpDt7a0S0fo6R9bTVSNAA5SMibGxACNFBOAAC42R3AAAFesoAACHv7AADGoftABZdlDIA== Message-ID: <450AE4BEC513614F96969DDA34F359349E0F610A@EUSAACMS0701.eamcs.ericsson.se> References: <497B6D90E0023142AF34948DEFFAB38D3A66EEA26C@EMBX01-HQ.jnpr.net><9D0602B62D632D499E0A26CBCDA74A7D0616C03D@xmb-sjc-22a.amer.cisco.com><497B6D90E0023142AF34948DEFFAB38D3A671590B7@EMBX01-HQ.jnpr.net> <9D0602B62D632D499E0A26CBCDA74A7D0616C4F1@xmb-sjc-22a.amer.cisco.com> <497B6D90E0023142AF34948DEFFAB38D3A67467986@EMBX01-HQ.jnpr.net> In-Reply-To: <497B6D90E0023142AF34948DEFFAB38D3A67467986@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F359349E0F610AEUSAACMS0701eam_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2009 20:28:16.0857 (UTC) FILETIME=[DC8BB490:01CA4D0C] Cc: "dromasca@avaya.com" , Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:28:33 -0000 --_000_450AE4BEC513614F96969DDA34F359349E0F610AEUSAACMS0701eam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2 Thanks, Steve ________________________________ From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Muk= esh Gupta Sent: Wednesday, October 07, 2009 1:46 PM To: Don Provan; John Cruz (johcruz); vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode Ok. We hear 2 responses; one recommending TRUE and the other recommending F= ALSE :) It would be good to hear preferences of other WG members. Please speak up.= Here are the choices to make it easier. 1) Leave the default value to the implementers 2) Specify FALSE as the default value in the draft 3) Specify TRUE as the default value in the draft 4) I do not care Regards Mukesh From: Don Provan [mailto:dprovan@bivio.net] Sent: Tuesday, October 06, 2009 11:05 AM To: John Cruz (johcruz); Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode By this logic, the default should be FALSE since that's been the default un= til now. Previous versions of the protocol didn't allow accepting such pack= ets at all. -don ________________________________ From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Joh= n Cruz (johcruz) Sent: Tuesday, October 06, 2009 10:15 AM To: Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: Re: [VRRP] Default Value of Accept_Mode Hi Mukesh, There are no interoperability issues w.r.t to the VRRP state machine. The = interoperability issue that I mentioned refers to network deployments where customers have d= evices from different vendors on their network and each vendor has a different de= fault value. In such situation, the onus is on the customers to know the default value for = each implementation and set it accordingly, which I think is not a good idea. Let us choose a d= efault value for all implementations. If the customer wants to change it, they can change it for= all devices in the network. I believe, the concern is should it be TRUE or FALSE. With VRRP fo= r IPv4, this option did not exists. Accept_mode is now being introduced for the unified spec. = If there are no security/vulnerability issues w.r.t. accepting packets address to the vi= rtual IP address, then let us default the value to TRUE. Here is a crude analogy - can the VRRP hello timer value be a default value= per implementation? John From: Mukesh Gupta [mailto:mukesh@juniper.net] Sent: Tuesday, October 06, 2009 9:53 AM To: John Cruz (johcruz); vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode John, Could you please explain a little more about the interoperability issues th= at you are referring to? As far as I understand, an operator will see different behavior from the de= vices with different default values when he/she tries to connect to the vir= tual address. However, it should not cause any protocol interoperability i= ssues. Moreover, the operator would be able to change the default value us= ing the configurable knob to see consistent behavior from all the devices. Regards Mukesh From: John Cruz (johcruz) [mailto:johcruz@cisco.com] Sent: Monday, October 05, 2009 11:49 AM To: Mukesh Gupta; vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: RE: [VRRP] Default Value of Accept_Mode Hi Mukesh, Leaving the default value to be implementation dependent may not be a good idea as it will cause interoperability issues in environments where customers have a mix of devices from different vendors. John From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Muk= esh Gupta Sent: Friday, October 02, 2009 4:26 PM To: vrrp@ietf.org Cc: dromasca@avaya.com; Adrian Farrel Subject: [VRRP] Default Value of Accept_Mode [WG Chair Hat Off] Folks, During the IESG review of the unified VRRP draft, Dan, Operations and Manag= ement AD, questioned the default value of the Accept_Mode in the draft. Th= e current default value is False and he would like us to reconsider that (h= is comments in the end of this email). We had discussions about this on the mailing list. However, I don't rememb= er having a clear WG consensus for either default value. Given the fact that the default value has absolutely no impact on the inter= operability and the fact that both the values have their pros and cons, we = are proposing that the draft should leave the default value to the implemen= tations. The draft would say that the implementations are free to choose a= ny default value. Please let us know if you agree/disagree. If we do not hear anything back,= we will assume that the WG agrees :) Regards Mukesh Dan's Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3. Accept_Mode defaulting to false seems unrealistic at least in deployment= s I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual addr= ess no longer responds to ping; I've also seen an implementation to reject ping= s to the virtual IP when it's in Master mode, but this seems like an implementat= ion bug if so (I'd like a confirmation if this is the case). In any case, this restriction makes troubleshooting and deployment a pain; = hosts and management systems often ping the gateway address to see if the network= is working, and this kills that assumption. Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position. --_000_450AE4BEC513614F96969DDA34F359349E0F610AEUSAACMS0701eam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
2
 
Thanks,
Steve

 

From: vrrp-bounces@ietf.org=20 [mailto:vrrp-bounces@ietf.org] On Behalf Of Mukesh=20 Gupta
Sent: Wednesday, October 07, 2009 1:46 PM
To: D= on=20 Provan; John Cruz (johcruz); vrrp@ietf.org
Cc: dromasca@avaya.c= om;=20 Adrian Farrel
Subject: Re: [VRRP] Default Value of=20 Accept_Mode

Ok. We = hear 2=20 responses; one recommending TRUE and the other recommending FALSE = J

&n= bsp;

It woul= d be=20 good to hear preferences of other WG members.  Please speak up. = ;=20 Here are the choices to make it easier.

&n= bsp;

1) Leav= e the=20 default value to the implementers

2) Spec= ify=20 FALSE as the default value in the draft

3) Spec= ify=20 TRUE as the default value in the draft

4) I do= not=20 care

&n= bsp;

Regards=

Mukesh<= o:p>

&n= bsp;

From: Don Provan= =20 [mailto:dprovan@bivio.net]
Sent: Tuesday, October 06, 2009 11:= 05=20 AM
To: John Cruz (johcruz); Mukesh Gupta;=20 vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian=20 Farrel
Subject: RE: [VRRP] Default Value of=20 Accept_Mode

 

By=20 this logic, the default should be FALSE since that's been the default unt= il=20 now. Previous versions of the protocol didn't allow accepting such packet= s at=20 all.

-don

&n= bsp;


From:=20 vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of = John=20 Cruz (johcruz)
Sent: Tuesday, October 06, 2009 10:15=20 AM
To: Mukesh Gupta; vrrp@ietf.org
Cc: dromasca@avaya= .com;=20 Adrian Farrel
Subject: Re: [VRRP] Default Value of=20 Accept_Mode

Hi=20 Mukesh,

 

There are no interope= rability=20 issues w.r.t to the VRRP state machine.  The=20 interoperability

issue that I mentione= d refers=20 to network deployments where customers have devices

from different vendor= s on=20 their network and each vendor has a different  default value.=20 In

such situation, the o= nus is on=20 the customers to know the default value for each=20 implementation

and set it accordingl= y, which=20 I think is not a good idea. Let us choose a default value for=20 all

implementations. If t= he=20 customer wants to change it, they can change it for all devices in=20 the

network. I believe, t= he=20 concern is should it be TRUE or FALSE. With VRRP for IPv4, this=20 option

did not exists.=20  Accept_mode is now being introduced for the unified spec. If there= =20 are

no security/vulnerabi= lity=20 issues w.r.t. accepting packets address to the virtual IP address,=20 then

let us default the va= lue to=20 TRUE.

 

Here is a crude analo= gy – can=20 the VRRP hello timer value be a default value per=20 implementation?

 

John

 

From: Mukesh Gup= ta=20 [mailto:mukesh@juniper.net]
Sent: Tuesday, October 06, 2009 9:= 53=20 AM
To: John Cruz (johcruz); vrrp@ietf.org
Cc:=20 dromasca@avaya.com; Adrian Farrel
Subject: RE: [VRRP] Default V= alue=20 of Accept_Mode

 

John,

&n= bsp;

Could y= ou=20 please explain a little more about the interoperability issues that you a= re=20 referring to?

&n= bsp;

As far = as I=20 understand, an operator will see different behavior from the devices with= =20 different default values when he/she tries to connect to the virtual=20 address.  However, it should not cause any protocol interoperability= =20 issues.  Moreover, the operator would be able to change the default = value=20 using the configurable knob to see consistent behavior from all the=20 devices.

&n= bsp;

Regards=

Mukesh<= o:p>

&n= bsp;

From: John Cruz= =20 (johcruz) [mailto:johcruz@cisco.com]
Sent: Monday, October 05,= 2009=20 11:49 AM
To: Mukesh Gupta; vrrp@ietf.org
Cc:=20 dromasca@avaya.com; Adrian Farrel
Subject: RE: [VRRP] Default V= alue=20 of Accept_Mode

 

Hi=20 Mukesh,

 

Leaving the default v= alue to=20 be implementation

dependent may not be = a good=20 idea as it will cause

interoperability issu= es in=20 environments where

customers  have = a mix of=20 devices from different

vendors.

 

John

 

From:=20 vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of=20 Mukesh Gupta
Sent: Friday, October 02, 2009 4:26=20 PM
To: vrrp@ietf.org
Cc: dromasca@avaya.com; Adrian=20 Farrel
Subject: [VRRP] Default Value of=20 Accept_Mode

 

[WG Cha= ir Hat=20 Off]

&n= bsp;

Folks,<= o:p>

&n= bsp;

During = the=20 IESG review of the unified VRRP draft, Dan, Operations and Management AD,= =20 questioned the default value of the Accept_Mode in the draft.  The=20 current default value is False and he would like us to reconsider that (h= is=20 comments in the end of this email).

&n= bsp;

We had= =20 discussions about this on the mailing list.  However, I don’t = remember=20 having a clear WG consensus for either default value.

&n= bsp;

Given t= he fact=20 that the default value has absolutely no impact on the interoperability a= nd=20 the fact that both the values have their pros and cons, we are proposing = that=20 the draft should leave the default value to the implementations.  Th= e=20 draft would say that the implementations are free to choose any default=20 value.

&n= bsp;

Please = let us=20 know if you agree/disagree.  If we do not hear anything back, we wil= l=20 assume that the WG agrees J

&n= bsp;

Regards=

Mukesh<= o:p>

&n= bsp;

DanR= 17;s=20  Comment:

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

3.=20 Accept_Mode defaulting to false seems unrealistic at least in=20 deployments

I've= =20 seen.  Using accept-data config knob seems very common. Unless=20 enable

Accep= t_Mode,=20 when the virtual address moves to the Backup, the virtual=20 address

no lo= nger=20 responds to ping; I've also seen an implementation to reject pings=20 to

the v= irtual=20 IP when it's in Master mode, but this seems like an=20 implementation

bug i= f so=20 (I'd like a confirmation if this is the case).

=  

In an= y case,=20 this restriction makes troubleshooting and deployment a pain;=20 hosts

and=20 management systems often ping the gateway address to see if the network=20 is

worki= ng, and=20 this kills that assumption.

=  

Unles= s the=20 WG has recently discussed and reached consensus that=20 Accept_Mode

shoul= d still=20 default to false, I'd consider revisiting this position.

&n= bsp;

--_000_450AE4BEC513614F96969DDA34F359349E0F610AEUSAACMS0701eam_-- From Pasi.Eronen@nokia.com Fri Oct 16 00:26:52 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2ABA3A6A40 for ; Fri, 16 Oct 2009 00:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EODQQxHRUd4 for ; Fri, 16 Oct 2009 00:26:52 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8F3C13A6A3D for ; Fri, 16 Oct 2009 00:26:51 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9G7QgK3023409; Fri, 16 Oct 2009 10:26:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 10:26:42 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Oct 2009 10:26:41 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 16 Oct 2009 09:26:40 +0200 From: To: Date: Fri, 16 Oct 2009 09:26:40 +0200 Thread-Topic: Clear draft-ietf-vrrp-unified-spec 6 Thread-Index: AcpDqsd1gdRQfOG4S5qtU4U8qxPiHgKhyJ/w Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09A444B7@NOK-EUMSG-01.mgdnok.nokia.com> References: <450AE4BEC513614F96969DDA34F3593497639DC0@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <450AE4BEC513614F96969DDA34F3593497639DC0@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Oct 2009 07:26:41.0727 (UTC) FILETIME=[01B23CF0:01CA4E32] X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 16 Oct 2009 00:46:21 -0700 Cc: Radia.Perlman@Sun.COM, vrrp@ietf.org Subject: Re: [VRRP] Clear draft-ietf-vrrp-unified-spec 6 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 07:26:52 -0000 Hi Stephen, Yes, the proposed text would address the 1st part of my discuss. Best regards, Pasi > -----Original Message----- > From: ext Stephen Nadas [mailto:stephen.nadas@ericsson.com] > Sent: 03 October, 2009 00:54 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: adrian.farrel@huawei.com; Radia.Perlman@Sun.COM; Mukesh Gupta; > vrrp@ietf.org > Subject: Clear draft-ietf-vrrp-unified-spec 6 >=20 > Hi Pasi, >=20 > With respect to your 1st part of discuss (2nd part still in process): >=20 > The security considerations text basically says security doesn't > have > to be considered here because an attacker can cause havoc with > ARP > anyway. I don't think this is fully accurate description. Many > networks with untrusted hosts use switch security features that > prevent hosts from bringing down the network with spoofed ARP > packets > (somewhat similar to what SAVI WG is working on). While > compromising > one of the switches or routers would still cause damage, > compromised > or malicious ordinary hosts (attached to switch ports where these > features are enabled) can't do that much. >=20 > The other reason for removing cryptographic authentication of > VRRP > messages is said to be misconfigured secrets (which obviously > does > cause problems -- but on the other hand, this situation should be > detected very quickly). If it's indeed the case that > cryptographic > per-message authentication isn't a good solution to securing > VRRP, at > the very least the document should discuss other possible > mechanisms. > Perhaps e.g. filtering mechanisms in switches, configured on per- > port > basis, could provide some protection? Or could this somehow > leverage > the existing mechanisms for ARP? >=20 > Does the below text capture your concerns? If not could you please > suggest changes that would? >=20 > VRRP for IPvX does not currently include any type of > authentication. Earlier versions of the VRRP (for IPv4) > specification included several types of authentication ranging > from none to strong. Operational experience and further > analysis determined that these did not provide sufficient > security to overcome the vulnerability of misconfigured secrets > causing multiple masters to be elected. Due to the nature of > the VRRP protocol, even if VRRP messages are cryptographically > protected, it does not prevent hostile nodes from behaving as > if they are a VRRP master, creating multiple masters. > Authentication of VRRP messages could have prevented a hostile > node from causing all properly functioning routers from going > into backup state. However, having multiple masters can cause > as much disruption as no routers, which authentication cannot > prevent. Also, even if a hostile nodes could not disrupt VRRP, > it can disrupt ARP and create the same effect as having all > routers go into backup. >=20 > Some L2 switches provide the capability to filter out, e.g., ARP > and/or ND messages from end hosts on a switch port basis. This > mechanism could also filter VRRP messages from switch ports > associated with end hosts and can be considered for deployments > with untrusted hosts. >=20 > Thanks, > Steve From stephen.nadas@ericsson.com Wed Oct 21 14:27:32 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA2228C104 for ; Wed, 21 Oct 2009 14:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3kJhWzS3E9Z for ; Wed, 21 Oct 2009 14:27:31 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id C6DDC28C100 for ; Wed, 21 Oct 2009 14:27:31 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9LLRah9005668; Wed, 21 Oct 2009 16:27:36 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:27:23 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 16:27:22 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.224]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 21 Oct 2009 17:27:22 -0400 From: Stephen Nadas To: "dromasca@avaya.com" Date: Wed, 21 Oct 2009 17:26:35 -0400 Thread-Topic: Clear draft-ietf-vrrp-unified-spec 5 Thread-Index: AcpDeYX2uwXDCsT6SVu1uGMy43SgHwPGgE9w Message-ID: <450AE4BEC513614F96969DDA34F359349E264C47@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_450AE4BEC513614F96969DDA34F359349E264C47EUSAACMS0701eam_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2009 21:27:22.0868 (UTC) FILETIME=[47064B40:01CA5295] Cc: "Radia.Perlman@Sun.COM" , "vrrp@ietf.org" Subject: Re: [VRRP] Clear draft-ietf-vrrp-unified-spec 5 X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 21:27:32 -0000 --_000_450AE4BEC513614F96969DDA34F359349E264C47EUSAACMS0701eam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, Wrt to Accept Mode default, Mukesh asked the list over two weeks ago and th= e (weak, I'm afraid) consensus is to keep this configurable parameter defau= lting to False. Thanks, Steve _____________________________________________ From: Stephen Nadas Sent: Friday, October 02, 2009 12:01 PM To: 'dromasca@avaya.com' Cc: 'adrian.farrel@huawei.com'; Radia.Perlman@Sun.COM; 'Mukesh Gupta'; = 'vrrp@ietf.org' Subject: Clear draft-ietf-vrrp-unified-spec 5 Hi Dan, Please see below for the various proposed resolutions. Are they sufficient= to clear the draft? Thanks, Steve Discuss remarks; [snipped] 3. Accept_Mode defaulting to false seems unrealistic at least in deployment= s I've seen. Using accept-data config knob seems very common. Unless enable Accept_Mode, when the virtual address moves to the Backup, the virtual addr= ess no longer responds to ping; I've also seen an implementation to reject ping= s to the virtual IP when it's in Master mode, but this seems like an implementat= ion bug if so (I'd like a confirmation if this is the case). In any case, this restriction makes troubleshooting and deployment a pain; hosts and management systems often ping the gateway address to see if the network is working, and this kills that assumption. Unless the WG has recently discussed and reached consensus that Accept_Mode should still default to false, I'd consider revisiting this position. We are thinking that accept_mode needs a configuration control and that the= default vaule could be an implementation choice. This is TBD on the list. --_000_450AE4BEC513614F96969DDA34F359349E264C47EUSAACMS0701eam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi Dan,
 
Wrt to Accept Mode default, Mukesh = asked the list over two weeks ago and the (weak, I'm afraid) consensus is t= o keep this configurable parameter defaulting to False.
 
Thanks,
Steve
 
_____________________________________________
From:    Stephen Nadas = ;
Sent:   Friday, October 02, 2009= 12:01 PM
To:     'dromasca@avay= a.com'
Cc:     'adrian.farrel= @huawei.com'; Radia.Perlman@Sun.COM; 'Mukesh Gupta'; 'vrrp@ietf.org'=
Subject:      &n= bsp; Clear draft-ietf-vrrp-unified-spec 5
 
Hi Dan,
 
Please see below for t= he various proposed resolutions.  Are they sufficient to clear the dra= ft?
 
Thanks,
Steve
 
Discuss remarks;
&nbs= p;
[sni= pped]
 
3. Accept_Mode defaulting to false seems unrealistic at least in = deployments
I've seen.  Using accept-data config knob seems very common.= Unless enable
Accept_Mode, when the virtual address moves to the Backup, the vi= rtual address
no longer responds to ping; I've also seen an implementation to r= eject pings to
the virtual IP when it's in Master mode, but this seems like an i= mplementation
bug if so (I'd like a confirmation if this is the case).
 
In any case, this restriction makes troubleshooting and deploymen= t a pain;
hosts and management systems often ping the gateway address to se= e if the
network is working, and this kills that assumption.
 
Unless the WG has recently discussed and reached consensus that A= ccept_Mode
should still default to false, I'd consider revisiting this posit= ion.
 
We are thinking that accept_mode needs a configura= tion control and that the default vaule could be an implementation choice.&= nbsp; This is TBD on the list. 
 
--_000_450AE4BEC513614F96969DDA34F359349E264C47EUSAACMS0701eam_-- From root@core3.amsl.com Fri Oct 23 13:30:02 2009 Return-Path: X-Original-To: vrrp@ietf.org Delivered-To: vrrp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EB60F3A679F; Fri, 23 Oct 2009 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091023203001.EB60F3A679F@core3.amsl.com> Date: Fri, 23 Oct 2009 13:30:01 -0700 (PDT) Cc: vrrp@ietf.org Subject: [VRRP] I-D Action:draft-ietf-vrrp-unified-spec-04.txt X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual Router Redundancy Protocol Working Group of the IETF. Title : Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6 Author(s) : S. Nadas Filename : draft-ietf-vrrp-unified-spec-04.txt Pages : 41 Date : 2009-10-23 This memo defines the Virtual Router Redundancy Protocol (VRRP) for IPv4 and IPv6. It is version three (3) of the protocol and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and on draft-ieft-vrrp-ipv6-spec-08.txt. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and forwards packets sent to these IPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. For IPv4, the advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host. For IPv6, the advantage gained from using VRRP for IPv6 is a quicker switch over to back up routers than can be obtained with standard IPv6 Neighbor Discover (RFC 4861) mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-spec-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-vrrp-unified-spec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23132124.I-D@ietf.org> --NextPart-- From zhangdacheng@huawei.com Sat Oct 24 08:29:17 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0D13A67AC for ; Sat, 24 Oct 2009 08:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DIogNVZu-tX for ; Sat, 24 Oct 2009 08:29:15 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 61E053A63EC for ; Sat, 24 Oct 2009 08:29:14 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS0009BLZ0R2X@szxga04-in.huawei.com> for vrrp@ietf.org; Sat, 24 Oct 2009 23:29:15 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS0006ERZ0RDD@szxga04-in.huawei.com> for vrrp@ietf.org; Sat, 24 Oct 2009 23:29:15 +0800 (CST) Received: from z00133208 ([10.111.12.108]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS0003KMZ0QEK@szxml06-in.huawei.com> for vrrp@ietf.org; Sat, 24 Oct 2009 23:29:15 +0800 (CST) Date: Sat, 24 Oct 2009 23:29:14 +0800 From: Dacheng Zhang To: vrrp@ietf.org Message-id: <003801ca54be$be890290$6c0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_m1RA2Y+iBE6ShhnsjWK0zw)" Thread-index: AcpUvr4RDVUviC2SS4q+8FTKFloztA== X-Mailman-Approved-At: Sun, 25 Oct 2009 10:52:38 -0700 Cc: Radia.Perlman@Sun.COM Subject: [VRRP] A newly proposed draft X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 15:29:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_m1RA2Y+iBE6ShhnsjWK0zw) Content-type: multipart/alternative; boundary="Boundary_(ID_ErWDambJbeCwPQfJVogL9w)" --Boundary_(ID_ErWDambJbeCwPQfJVogL9w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, all: We just proposed a new draft about a simplified vrrp protocol in IETF 76, which aims to reduce the overhead brought by vrrp signaling packets in certain cases. Could you please give us some comments and let us know whether you like the proposed idea. The draft is appended with the email. Thank you in advance. BR Dacheng --Boundary_(ID_ErWDambJbeCwPQfJVogL9w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi, all:
 
We just proposed a new draft about a simplified vrrp protocol in IETF 76, which aims to reduce the overhead brought by vrrp signaling packets in certain cases. Could you please give us some comments and let us know whether you like the proposed idea. The draft is appended with the email.
 
Thank you in advance.
 
BR
 
Dacheng
--Boundary_(ID_ErWDambJbeCwPQfJVogL9w)-- --Boundary_(ID_m1RA2Y+iBE6ShhnsjWK0zw) Content-type: text/plain; name=draft-zhang-vrrp-svrrp-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-zhang-vrrp-svrrp-00.txt Network working group Qiang Zhang Internet Draft Dacheng Zhang Category: Standards Track Created: October 19, 2009 Huawei Technologies Co.,Ltd Expires: April 2010 Slave Virtual Router Redundancy Protocol (SVRRP) draft-zhang-vrrp-svrrp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 19, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Zhang. Expires April 19, 2010 [Page 1] Internet-Draft Slave Virtual Router Redundancy Protocol October 2009 Abstract In this document, we propose a simplified VRRP protocol called the Slave Virtual Router Redundancy Protocol (SVRRP).The design objective of SVRRP is to specify an election protocol that dynamically assigns responsibility for a virtual router to one of the SVRRP routers on a LAN, which is exactly as same as that of VRRP. However, SVRRP executions do not exchange signaling packets and need the assistance of VRRP to perform their functionality appropriately. This approach can be used to improve the efficiency of VRRP routers in certain scenarios. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Motivating Scenario............................................3 4. SVRRP..........................................................4 5. IANA Considerations............................................7 6. Acknowledgments................................................7 7. References.....................................................7 Authors' Addresses................................................8 1. Introduction In many typical scenarios (e.g., a VRRP router supporting multiple VLANs), a VRRP router needs to backup multiple virtual routes (VRs) simultaneously. In order to maintain the state of a VRRP instance (execution) for the election of a VR, the router needs to exchange VRRP signaling packets with other routers involved in the same selection. The bandwidth consumed by the router in transporting VRRP signaling packets is proportional to the number of the VRs which it supports. In order to improve the efficiency of the VRRP routers in such scenarios, a simplified VRRP, called Slave VRRP (SVRRP) is proposed. SVRRP need not exchange signaling messages. Actually, the state of a SVRRP instance is determined by another VRRP instance (which is referred to as a MVRRP instance in this case). Therefore, a VRRP router executing SVRRP needs in addition to execute MVRRP. This solution is based on the fact that the states of a set of VRRP instances located on a VRRP router are always identical and Zhang. Expires April 19, 2010 [Page 2] Internet-Draft Slave Virtual Router Redundancy Protocol October 2009 transferred in a synchronized way, e.g., when they share a same physical interface. 2. Terminology MVRRP Router: a router running the Management Virtual Router Redundancy Protocol. SVRRP Router: a router running the Slave Virtual Router Redundancy Protocol. VRRP instance: a VRRP execution on a router for the backup of a virtual router. MVRRP instance: a MVRRP execution on a router for the backup of a virtual router. SVRRP instance: a SVRRP execution on a router for the backup of a virtual router. VRRP backup group (VRRP BG): a collection of VRRP instances for the backup of a same virtual router. MVRRP backup group (MVRRP BG): a collection of MVRRP instances for the backup of a same virtual router. SVRRP backup group (SVRRP BG): a collection of SVRRP instances for the backup of a same virtual router. Broadcast_Timer: a global timer that fire to trigger sending gratuitous ARP for SVRRP instances in Master. Broadcast_interval: the interval of a Broadcast_Timer, default is 300 seconds. 3. Motivating Scenario Figure 1 illustrates a motivating scenario where multiple hosts belonging to different VLANs connect to two VRRP routers (Router1 and Router2) through a switch. The packets from the hosts are routed to a same physical interface (e.g., Interface1) of the master VRRP router (e.g., Router1). Moreover, the physical interface is divided into multiple sub-interfaces; each is used to deal with the packets in a VLAN. Zhang. Expires April 19, 2010 [Page 3] Internet-Draft Slave Virtual Router Redundancy Protocol October 2009 Because in principle a VR acts as a default router for hosts on a shared LAN, each of the routers should generate a VRRP instance for every VLAN respectively. As mentioned previously, a VRRP instance needs to maintain a state machine and periodically exchange signaling packets with others in the same VRRP back group. When the number of VRRP instances supported by a VRRP router is large, the resource ( e.g, bandwidth, CPU, memory )occupied in transporting and processing signaling packets may influence the performance of the router negatively. +--------+ | host1 +------------\ +--------+ | VLAN1 | - - - - - - | Interface1 +----------+ +---------+ | | /---------+ Router1 +----/ +--------+ | | | +---------+ | | host2 +-----------| switch +-----| | +--------+ | | | |----- . | | | | . +----------+ | +---------+ | - - - - - - | \---------+ Router2 +----\ VLANn | +---------+ +--------+ | | hostn +------------/ +--------+ Figure 1. Motivating Scenario In this scenario, all the VRs share the same physical interface; the states of the VRRP instances located on a same VRRP router are always identical and change in a concurrent way. Therefore, it can be effective to select a VRRP BG as the MVRRP BG while the instances in other VRRP BGs are implemented with SVRRP. The state of a MVRRP instance is shared by the SVRRP instances on the same VRRP router, and any change in the state of the MVRRP instance can trigger identical changes in the states of the corresponding SVRRP instances. Therefore, Router1 and Router2 only need to exchange VRRP signaling packets for the MVRRP BG, irrespective of how may VRs they are supporting. 4. SVRRP 4.1. State Transition Diagram Zhang. Expires April 19, 2010 [Page 4] Internet-Draft Slave Virtual Router Redundancy Protocol October 2009 +---------------+ +--------->| |<-------------+ | | Initialize | | | +------| |----------+ | | | +---------------+ | | | | | | | V V | +---------------+ +---------------+ | |---------------------->| | | Master | | Backup | | |<----------------------| | +---------------+ +---------------+ 4.2. State Descriptions In the state descriptions below, the state names are identified by {state-name}, and the packets are identified by all upper case characters. There are two key events in the SVRRP state machine, the Startup event and the Shutdown event. A Startup event arises when the associated interface is available and the associate MVRRP instance is in the {Backup} or the {Master} state. A Shutdown event arises when the interface is unavailable or the associated MVRRP instance is in the {Initialize} state. 4.2.1. Initialize A SVRRP instance in this state just waits for a Startup event. If a Startup event is received, then: - If State of MVRRP is {Master} - If broadcast_timer is inactive, then: o set broadcast_timer to broadcast_interval. endif o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router. Zhang. Expires April 19, 2010 [Page 5] Internet-Draft Slave Virtual Router Redundancy Protocol October 2009 o Transition to the {Master} state. else o Transition to the {Backup} state endif 4.2.2. Backup While in this state, MUST discard ADVERTISEMENT received. - If receiving a Shutdown event: o Transition to the {Initialize} state endif - If the state of the associated MVRRP instance is transferred into Master. then: o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router. o Transition to the {Master} state endif 4.2.3. Master While in this state, a SVRRP instance must discard the received ADVERTISEMENT packets and periodically send gratuitous ARP packets according to Broadcast_timer in order to update a cache of MAC address of switch and/or hosts. - If a Shutdown event is received, then: o Transition to the {Initialize} state endif Zhang. Expires April 19, 2010 [Page 6] Internet-Draft Slave Virtual Router Redundancy Protocol October 2009 - If the state of the associated MVRRP instance is transferred into Backup, then: o Transition to the {Backup} state endif - If the Broadcast_timer fires, then: o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router. endif 5. IANA Considerations No such considerations. 6. Acknowledgments Thank Peter Smith for his kindly revision and precious comments. 7. References [RFC3768] R. Hinden, Ed., " Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004. [RFC2338] S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem, " Virtual Router Redundancy Protocol" RFC 2338, April 1998. Zhang. Expires April 19, 2010 [Page 7] Internet-Draft Slave Virtual Router Redundancy Protocol October 2009 Authors' Addresses Qiang Zhang Huawei Technologies Co.,Ltd Huihong Building, No.91 Baixia Rd., Baixia District Nanjing, 210001 P.R. China Email: njzq@huawei.com Dacheng Zhang Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: zhangdacheng@huawei.com Zhang. Expires April 19, 2010 [Page 8] --Boundary_(ID_m1RA2Y+iBE6ShhnsjWK0zw)-- From stephen.nadas@ericsson.com Mon Oct 26 06:53:51 2009 Return-Path: X-Original-To: vrrp@core3.amsl.com Delivered-To: vrrp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C743A698A for ; Mon, 26 Oct 2009 06:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSiR5TWYDByf for ; Mon, 26 Oct 2009 06:53:50 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 4B5A23A686A for ; Mon, 26 Oct 2009 06:53:50 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9QDruqA003800; Mon, 26 Oct 2009 08:53:59 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 08:53:07 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 08:53:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 26 Oct 2009 09:53:06 -0400 From: Stephen Nadas To: Dacheng Zhang , "vrrp@ietf.org" Date: Mon, 26 Oct 2009 09:53:05 -0400 Thread-Topic: [VRRP] A newly proposed draft Thread-Index: AcpUvr4RDVUviC2SS4q+8FTKFloztABfjeNA Message-ID: <450AE4BEC513614F96969DDA34F3593401160DDF99@EUSAACMS0701.eamcs.ericsson.se> References: <003801ca54be$be890290$6c0c6f0a@china.huawei.com> In-Reply-To: <003801ca54be$be890290$6c0c6f0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Oct 2009 13:53:07.0634 (UTC) FILETIME=[A5B46120:01CA5643] Cc: "Radia.Perlman@Sun.COM" Subject: Re: [VRRP] A newly proposed draft X-BeenThere: vrrp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual Router Redundancy Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:53:51 -0000 Hi Dacheng,=20 I read the draft. For me, the terminology was a little confusing as this d= raft uses the term "VR" to mean a router that is supporting one of several = "different L3 address spaces" (and is not the same as VRRPs use of the term= ...)=20 If I understand it correctly, this draft proposes to standardize a mechanis= m so that VRs (meaning different L3 address spaces) can reuse the VRRP sess= ion of some other VR (that is, an VRRP session running in yet another L3 ad= dress space) when it makes sense in the network design to do so. =20 I guess my thinking is that this is basically wanting to standardize behavi= our inside the node and so I don't see it as a protocol. =20 The draft says that this provides VRRP protocol simplification. I do not s= ee this as I think at least one VR (meaning one of different L3 address spa= ces) is running regular VRRP. So the protocol is not simpler. I think per= haps the draft means to say that the protocol is simpler for the "slaves". = But I guess I think this can be done in other ways (for example, by some e= ntity in the router registering interest in some VRRP session and getting n= otified when the VRRP master fails and taking actions at that time (in this= case issuing Grat ARPs.)) A similar mechanism is needed for routers to pr= opagate a BFD session failure to interested parties in the router - I don't= think this is standardized. =20 The draft also clams a reduction of VRRP traffic (and the benefits that bri= ngs) for a routers supporting a set of L3 address spaces when it happens th= at the different "VRs" are topologically arranged to take advantage of this= (one example is as given in the draft: when there are sessions on differen= t VLAN that are also in different "VRs" to the same router.) I agree that = this type of approach can save signalling bandwidth; however, I'm not sure = it needs to be standardized. Thanks, Steve ________________________________ From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org] On Behalf Of Da= cheng Zhang Sent: Saturday, October 24, 2009 11:29 AM To: vrrp@ietf.org Cc: Radia.Perlman@Sun.COM Subject: [VRRP] A newly proposed draft =09 =09 Hi, all: =20 We just proposed a new draft about a simplified vrrp protocol in IETF 76, = which aims to reduce the overhead brought by vrrp signaling packets in cert= ain cases. Could you please give us some comments and let us know whether y= ou like the proposed idea. The draft is appended with the email. =20 Thank you in advance. =20 BR =20 Dacheng