Subject: Comments on draft-ietf-ospf-ospfv3-update-02

From: Alan Davey <[email-masked]>
Date: Thu, 3 Mar 2005 15:25:03 -0000

Hi Acee

I have had a look at the draft-ietf-ospf-ospfv3-update-02 document.  Overall it looks good.  However, I have a few doubts, which I have listed below.  I also noticed a number of minor editorial points with the document.

_Doubts_

-	I have a doubt about the handling of multiple interfaces to a single link.  Consider the following case.
	o	Neighbors A and B both have a single active interface to a single broadcast link.  
	o	An adjacency is formed between A and B.
	o	A new interface to the same link is activated on A.
	o	B receives a Hello from A sent through the new interface containing no mention of B.
	o	A also receives the Hello from A sent through the new interface and decides that it should continue to use the original interface.
	o	The new link goes into Standby state and takes no further part in the OSPF protocol exchanges.
	o	However, the neighbor state machine on B has moved to Init state as a result of receiving the Hello from A containing no mention of B.

	Should the protocol attempt to handle B receiving the Hello from the new interface on A without losing the adjacency between A and B?

-	Section 3.4.3, bullet 4.  I have a doubt about the reorigination of intra-area-prefix-LSA described in this bullet.
	o	The first part of the bullet is discussing reorigination of Router-LSAs.  
	o	The reasons given for reoriginating the intra-area-prefix-LSA relate to reorigination of Network-LSAs
	o	Reorigination of Network-LSAs, and related reorigination of intra-area-prefix-LSAs, is covered in other bullets.
	o	Why is it necessary to discuss reorigination of intra-area-prefix-LSAs in bullet 4?

-	Section 3.9, bullet 2.  Suggest deleting the first sentence: "Each of the multiple interfaces must be configured with the same interface ID."  This is not true and not, I suspect, what is meant.  I think that the bullet makes sense without this first sentence.

_Minor Editorial Points_

-	Section 2.1, paragraph 2.  s/relaced/replaced/

-	Section 2.7, bullet 4.  s/Netowrk-LSA/Network-LSA/

-	Section 3.2.2, second paragraph on page 19.  s/Router ID appearing the the/Router ID appearing in the/

-	Section 3.2.2, third paragraph on page 19.  s/identical to to the/identical to the/

-	Section 3.4.3, bullet 4.  I have a doubt about the reorigination of intra-area-prefix-LSA described in this bullet.
	o	The first part of the bullet is discussing reorigination of Router-LSAs.  
	o	The reasons given for reoriginating the intra-area-prefix-LSA relate to reorigination of Network-LSAs
	o	reorigination of Network-LSAs, and related reorigination of intra-area-prefix-LSAs, is covered in other bullets.
	o	Why is it necessary to discuss reorigination of intra-area-prefix-LSAs in bullet 4?

-	Section 3.4.3, bullet 4.  If the last sentence is retained, there is a typo: s/ot/to/

-	Section 3.4.3.5, 1st paragraph of page 30.  s/assume the the IPv6/assume that the IPv6/

-	Section 3.5.1, step (2).  s/interface area has been been configued/interface area has been configured/

-	Section 3.9.1.  s/Interface states machine addtions include/Interface state machine additions include/

-	Section 5, last bullet.  s/suggested improvments/suggested improvements/

-	Section A.4.5, 1st paragraph.  s/These LSAs are are the/These LSAs are the/

Please let me know if you have any questions or comments on any of the above.

Regards

Alan

------------------------------------
Alan Davey
Data Connection Ltd
Tel:   +44 20 8366 1177       
Fax:   +44 20 8363 1039
Email: [email-masked]  
Web:   http://www.dataconnection.com

---

From: Acee Lindem <[email-masked]>
Date: Fri, 4 Mar 2005 17:26:59 -0500

Hi Alan,
Thanks much for reviewing and taking the time to compile the list of
comments. See inline.

>	Should the protocol attempt to handle B receiving the Hello from the new interface on A without losing the adjacency between A and B?
I'm going to defer this one to Michael.

>	o	Why is it necessary to discuss reorigination of intra-area-prefix-LSAs in bullet 4?
Agreed. I don't think intra-area-prefix LSAs will change when a neighbor's
interface ID changes. I will remove this and add interface ID changes to the
first bullet.

>-	Section 3.9, bullet 2.  Suggest deleting the first sentence: "Each of the multiple interfaces must be configured with the same interface ID."  This is not true and not, I suspect, what is meant.…
This is the "Instance ID"  as opposed to the "Interface ID". It allows 
one to use the same link in
more than one OSPF instance or OSPF area (as described in section 2.4).

>-	Section A.4.5, 1st paragraph.  s/These LSAs are are the/These LSAs are the/

Got all these.

Thanks Again,
Acee

---

From: Michael J Barnes <[email-masked]>
Date: Sat, 5 Mar 2005 23:53:33 -0800

Hi Alan,

> 	Should the protocol attempt to handle B receiving the Hello from the new interface on A without losing the adjacency between A and B?

To my thinking, B should notice the different interface ID in the packet
from the second interface on A, and keep state separately for the second
interface, so the state between B and the first interface of A should not
be affected.

<snip>
> -	Section 3.9, bullet 2.  Suggest deleting the first sentence: "Each of the multiple interfaces must be configured with the same interface ID."  This is not true and not, I suspect, what is meant.…

I agree.

Regards,
Michael