Re: [OSPF] Mail regarding draft-ietf-ospf-ospfv3-autoconfig

Acee Lindem <acee.lindem@ericsson.com> Thu, 03 October 2013 09:30 UTC

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 992BE21F9D4C for <ospf@ietfa.amsl.com>; Thu, 3 Oct 2013 02:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 vGz84dccLz29 for <ospf@ietfa.amsl.com>; Thu, 3 Oct 2013 02:30:35 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6083221F9EE1 for <ospf@ietf.org>; Thu, 3 Oct 2013 02:30:00 -0700 (PDT)
X-AuditID: c6180641-b7fe28e000000d82-01-524d39157f24
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 10.E7.03458.5193D425; Thu, 3 Oct 2013 11:29:58 +0200 (CEST)
Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 05:29:57 -0400
From: Acee Lindem <acee.lindem@ericsson.com>
To: Rajib Majila <rajib.majila@ericsson.com>
Thread-Topic: Mail regarding draft-ietf-ospf-ospfv3-autoconfig
Thread-Index: AQHOwASlI9PLx/zgAkW2E2LSvWff95ni+UKA
Date: Thu, 03 Oct 2013 09:29:56 +0000
Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030744EA@eusaamb101.ericsson.se>
References: <524D1358.3020509@ericsson.com>
In-Reply-To: <524D1358.3020509@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.134]
Content-Type: multipart/alternative; boundary="_000_94A203EA12AECE4BA92D42DBFFE0AE47030744EAeusaamb101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPuK6YpW+QwYWHvBYLNv9jt2i5d4/d gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MrYuXc+a0GPZsWmbzeZGhg3KHUxcnJICJhI NB+ZwQxhi0lcuLeerYuRi0NI4CijRMOOyywQzjJGiQk/JrKDVLEJ6Eg8f/QPrEMEyG7ePJMV pIhZoI1R4u2502AJYQFbiY1LJ7JAFNlJXJ+9mAnCNpI4fH4b2CAWARWJxoWb2UBsXgFfiTNL OsF6hQS0JXZMmwpWwwm0YPKPvWBzGIHO+35qDdgcZgFxiVtP5jNBnC0gsWTPeagXRCVePv7H CmErSyx5sp8Foj5fYvmNbiaIXYISJ2c+YZnAKDoLyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1 M4x95sBjqF5riRVT76OoWcDIsYqRo7Q4tSw33chwEyMw4o5JsDnuYFzwyfIQozQHi5I475e3 zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGIN4OdbLvyh7vmFqg0/9+4e7WbXEFrI41Dg0 TvJp+/dmw0KrNb9/NT8omazgeZxJYNXqLscbHH8qPj/5cvVm14s7n/RZg4ryTfnK+YTYfz1l PxFj5HP2nFpkmsCpBRLR754r59ze0sa70EGX/c+amRPOH8ky2varIsg+6OSxS4YW8nYv3QOt JJRYijMSDbWYi4oTAQ+hHyGGAgAA
Cc: OSPF List <ospf@ietf.org>, "draft-ietf-ospf-ospfv3-autoconfig@tools.ietf.org" <draft-ietf-ospf-ospfv3-autoconfig@tools.ietf.org>
Subject: Re: [OSPF] Mail regarding draft-ietf-ospf-ospfv3-autoconfig
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, 03 Oct 2013 09:30:47 -0000

Adding OSPF list.

On Oct 3, 2013, at 2:48 AM, Rajib Majila wrote:

Hi Acee/Arkko,

I had a few questions/comments on your draft. Please find them below and clarify.

1.    On using asynchronous hello/dead interval: Are you suggesting implementing the LLS for supporting
 async hello/dead interval as mentioned in in your reference [ASYNC-HELLO].

No

As I understand it may not
be necessary as you are simply suggesting allowing a per neighbor hold timer timer based on the
 hello/dead interval advertised by the neighbor in its hello packet.

Yes


2.    Router-id selection: It would probably be better to use a mechanism that would most likely provide
a unique id instead of a pseudo-random number. It can be a 32 bits hash of the router-hardware-
fingerprint as suggested in your draft. A regeneration of router-id can possibly use a different hash
function in case a collision was detected. Given that this fingerprint is used even for detection of
duplicates, I believe it can be expected to generate unique router-ids quite reliably.

The pseudo-random number generation is seeded with an ID such as the router-hardware-fingerprint.



3.    Duplicate router-id detection: Can a self originated hello packet be identified by looking at the source
IPv6 address and comparing the same against the IP addresses of the local interfaces. If you do not see
any issue with this approach, it can eliminate the need to have a new LSA and thereby simplifying the
implementation.

Hello are only exchanged between adjacent neighbors.  The router-id must be unique within the entire OSPF routing domain.

Acee


Rajib


<http://www.ericsson.com/email_disclaimer>