Return-Path: <acee.lindem@ericsson.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
 with ESMTP id 4C82311E811C for <ospf@ietfa.amsl.com>;
 Thu, 31 May 2012 08:43:57 -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=[AWL=0.001,
 BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rydYcrEVbdbU for
 <ospf@ietfa.amsl.com>; Thu, 31 May 2012 08:43:56 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com
 (Postfix) with ESMTP id 3525A11E8119 for <ospf@ietf.org>;
 Thu, 31 May 2012 08:43:54 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by
 imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4VFhomh004102;
 Thu, 31 May 2012 10:43:53 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.181]) by
 eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi;
 Thu, 31 May 2012 11:43:47 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: "Retana, Alvaro" <alvaro.retana@hp.com>
Date: Thu, 31 May 2012 11:43:44 -0400
Thread-Topic: New Version Notification for
 draft-acee-ospf-ospfv3-autoconfig-02.txt
Thread-Index: Ac0/RCqU61zFhtkwRZmaLSNweOaP3A==
Message-ID: <4E55EFFC-AC9F-4CAD-A959-658A37D9DD23@ericsson.com>
References: <20120528194115.31565.2145.idtracker@ietfa.amsl.com>
 <4086D39E-4BC9-47CC-809D-271CEC738B57@ericsson.com>
 <C03AAF38AD209F4BB02BC0A34B774CE701D7A3@G2W2446.americas.hpqcorp.net>
In-Reply-To: <C03AAF38AD209F4BB02BC0A34B774CE701D7A3@G2W2446.americas.hpqcorp.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="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OSPF List <ospf@ietf.org>, Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [OSPF] New Version Notification for
 draft-acee-ospf-ospfv3-autoconfig-02.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>,
 <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>,
 <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 May 2012 15:43:57 -0000

On May 31, 2012, at 11:34 AM, Retana, Alvaro wrote:

Hi!

My reason for the suggestion was that requiring a special instance ID (even=
 if well known) takes away from the auto-* properties by requiring other ro=
uters to behave in a special way.  IOW, the use case of adding an auto-conf=
iguration-capable router to an existing network would not be possible w/out=
 additional configuration and/or hacks.

I obviously like option #2. :)

IMHO, option #3 is not good because it still requires the auto-configuratio=
n-capable router to be configured beforehand=85which is an oxymoron!

This was not the intent of #3 - it was meant to allow an implementation to =
decide dependent on the targeted deployments. Even without the reserved ins=
tance ID, other parameters (area, hello, dead, etc) in the existing network=
 would need to use the auto-configured values.

Thanks,
Acee



Thanks!

Alvaro.

From: Acee Lindem [mailto:acee.lindem@ericsson.com]
Sent: Monday, May 28, 2012 4:19 PM
To: OSPF List
Cc: Jari Arkko; Retana, Alvaro
Subject: Fwd: New Version Notification for draft-acee-ospf-ospfv3-autoconfi=
g-02.txt

Speaking as a Draft Author:

This version includes additions based on comments received at IETF 83. Sect=
ion 5.1 clarifies the detection of a neighbor with a duplicate Router-ID to=
 exclude the case where multiple router interfaces are connected to the sam=
e link. Section 5.4 was added to mitigate the effects of a duplicate OSPFv3=
 Router-ID in the OSPFv3 routing domain prior to duplicate Router-ID resolu=
tion.

Additionally, we received a suggestion from Alvaro Retana to not use an res=
erved OSPFv3 instance ID for auto-configured routers. Rather, allow OSPFv3 =
auto-configured routers to use the default OSPFv3 instance ID and automatic=
ally join an existing non-autoconfigured OSPFv3 routing domain. I see three=
 possible alternatives:

    1. Reject the suggestion. The alternate OSPFv3 instance ID was added sp=
ecifically to prevent this.
    2. Adopt the suggestion and remove the reserved instance ID. The securi=
ty considerations now recommend that implementation provide the capability =
to configure a single key.
    3. Add an applicability statement indicating that an implementation MAY=
 use the default OSPFv3 instance if the network where the implementation is=
 deployed requires incorporation into an existing OSPFv3 network.

Please provide your thoughts on this issue.

Thanks,
Acee




Begin forwarded message:


From: "internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>" <internet=
-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: May 28, 2012 3:41:15 PM EDT
To: Acee Lindem <acee.lindem@ericsson.com<mailto:acee.lindem@ericsson.com>>
Cc: "jari.arkko@piuha.net<mailto:jari.arkko@piuha.net>" <jari.arkko@piuha.n=
et<mailto:jari.arkko@piuha.net>>
Subject: New Version Notification for draft-acee-ospf-ospfv3-autoconfig-02.=
txt

A new version of I-D, draft-acee-ospf-ospfv3-autoconfig-02.txt has been suc=
cessfully submitted by Acee Lindem and posted to the IETF repository.

Filename:       draft-acee-ospf-ospfv3-autoconfig
Revision:       02
Title:              OSPFv3 Auto-Configuration
Creation date:            2012-05-28
WG ID:                     Individual Submission
Number of pages: 14

Abstract:
  OSPFv3 is a candidate for deployments in environments where auto-
  configuration is a requirement.  One such environment is the IPv6
  home network where users expect to simply plug in a router and have
  it automatically use OSPFv3 for intra-domain routing.  This document
  describes the necessary mechanisms for OSPFv3 to be self-configuring.




The IETF Secretariat


