[VRRP] Please clear draft-ietf-vrrp-unified-spec

Stephen Nadas <stephen.nadas@ericsson.com> Fri, 02 October 2009 12:04 UTC

Return-Path: <stephen.nadas@ericsson.com>
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 <vrrp@core3.amsl.com>; 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 <vrrp@core3.amsl.com>; 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 <vrrp@ietf.org>; 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 <stephen.nadas@ericsson.com>
To: Jari Arkko <jari.arkko@piuha.net>
Date: Fri, 02 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" <Radia.Perlman@Sun.COM>, "vrrp@ietf.org" <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 <vrrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vrrp>
List-Post: <mailto:vrrp@ietf.org>
List-Help: <mailto:vrrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vrrp>, <mailto:vrrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2009 12:04:36 -0000

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 of
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 conditional
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 move (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]