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.
> "
> 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.
> "
> 
> 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

> 
> Rajib
> 
> 

_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf

Reply via email to