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

From: Acee Lindem <[email-masked]>
Date: Thu, 3 Oct 2013 09:29:56 +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>

---

From: Acee Lindem <[email-masked]>
Date: Thu, 3 Oct 2013 12:35:26 +0000

Hi Rajib,

On Oct 3, 2013, at 6:41 AM, Rajib Majila wrote:

> Hi Acee,
> 
> Thanks for the response. Please find my comments below on the last point.
> "
> "
> What I was getting at was not just hellos but any OSPFv3 packets which can loosely be termed as link-scope.
> Your primary intention here is to identify if the duplicate router-id detection mechanism is going to declare
> an id as duplicate because multiple router interfaces are wrongly connected to the same link. I was wondering
> if this can be achieved simply by comparing the source IP address against the link-local addresses of all the
> local interfaces. Since here we are talking about link-local addresses, I am not even considering the packets
> which are non-link scope (area or AS).

That would be the most straight forward way to implement duplicate detection on a link. I did not describe implementation in the draft. 

> 
> Also your draft sets the flooding scope of this new LSA to Area-scope. If you are actually trying to detect
> duplicate router-id across the the OSPF domain by flooding this LSA across the domain, should it not be set
> to AS-scope? Also detecting a duplicate router-id across the domain might be tricky as even AS-scope LSAs
> are not forwarded into stub/nssa.

I'd originally thought that area uniqueness would be good enough. I'm now thinking that it should be AS-External scope even though the initial auto-configuration use case is single area only. 

Thanks,
Acee