Subject: Re: [OSPF] WG Adoption Call for "OSPF Stub Neighbors"

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 1 Feb 2016 23:21:36 +0000

Thanks Anton - I agree with that this enhancement should support P2MP as
well. Note that the disclosed IPR abstracts the LSA scoping to a stub-site
specific database so P2MP and other use cases, e.g. parallel links to the
same site, can be accommodated.

http://www.google.com/patents/US20140010117

Acee 

On 1/31/16, 3:14 PM, "Anton Smirnov (asmirnov)" <[email-masked]> wrote:

>    Hello,
>    Hub-and-Spoke topology is a known topology where OSPF traditionally
>performed poorly and in my opinion work in this area is very important.
>    On the other hand, I have number of concerns regarding usability of
>approach chosen in this draft and I think in its current state the draft
>is not ready for WG adoption.
>    I have big concerns regarding implementation simplicity and solution
>applicability (i.e. hub-and-spoke networks where proposed solution
>doesn't work). But first of all I want to make a comment on the text as
>it is.
>    Some hub-and-spoke topologies are point-to-multipoint networks. 10
>years ago it was a fraction of all hub-and-spoke WAN, nowadays it is a
>majority. Draft doesn't consider multipoint operations (at least it
>doesn't have word 'multipoint' in it). But multipoint has very big
>implications on having multiple spoofed Router LSAs and their filtering
>- since all stub neighbors are on the same interface, one can't use
>per-interface filtering (which is tightly related to per-interface
>flooding). Spoofed Router LSA will have a new type of flooding behavior
>- per-neighbor. This is doable but it is not specified anywhere and is
>not coded by any implementation I am aware of (i.e. existing filtering
>mechanisms are between different interfaces, not between neighbors on
>the same multipoint interface).
>    So the draft needs to define new LSA flooding scope - per-neighbor
>flooding scope, much like interface-scope flooding had to be devised for
>Opaque LSAs.
>    This is not all for implementation complexity not covered in the
>draft but it will be a good start.
>
>Anton
>
>
>On 01/26/2016 05:39 PM, Acee Lindem (acee) wrote:
>> This draft was has gone through some refinements after being presented
>>in
>> Hawaii and in Yokohama there was some support of this protocol
>>extension.
>> Here is a URL for you convenience.
>>
>> https://datatracker.ietf.org/doc/draft-raza-ospf-stub-neighbor/
>>
>> Please indicate your support (or concerns) for adopting this as a WG
>> Document. The WG Adoption call will end in 2 weeks.
>>
>> Thanks,
>> Acee
>>
>>
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>>

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 5 Feb 2016 06:41:05 +0000

Hi,

I have a few concerns on the necessity of this draft.

1.  Necessity of protocol change
The draft proposes to add the default route as part of router LSA but it is not clear why this is required.
The draft in sec 5.2 vaguely talks about without clarifying the real issue

"We are introducing a new type of default route with a local behavior.
   The current use of default route as type 3 or as type 5 cannot solve
   some of the use cases and more specifically in the Data center
   topologies."

If the spoke nodes are connecting only to the HUB (which is what hub and spoke topology is)then there is no way spoke would be learning OSPF routes 
from other than the HUB. It doesn't look necessary to advertise default routes in route LSAs

2. The draft doesn't talk about the other possible hub and spoke topologies like hierarchical hub and spoke,
      Multiple interfaces connecting to one Hub, A group of spoke nodes connecting to hub etc.  There should be a section on topology
      Restrictions to identify what topologies this draft intends to support.

3.  The draft proposes to advertise router-capability for this feature but it is not clear how this information is used. 
       
4. The draft talks in-length about the normal LSA and modified LSA but it is not clear how to distinguish between the two.

5. The document uses first person language in many places which is not appropriate for an internet draft.

6. I am in agreement with Anton on the p2mp use case which is completely missed from the draft

IMHO, the draft needs more work before being adopted by WG.

Rgds
Shraddha

-----Original Message-----
From: OSPF [mailto:[email-masked]] On Behalf Of Acee Lindem (acee)
Sent: Tuesday, January 26, 2016 10:09 PM
To: OSPF WG List <[email-masked]>
Subject: [OSPF] WG Adoption Call for "OSPF Stub Neighbors"

This draft was has gone through some refinements after being presented in Hawaii and in Yokohama there was some support of this protocol extension.
Here is a URL for you convenience.

Please indicate your support (or concerns) for adopting this as a WG Document. The WG Adoption call will end in 2 weeks.

Thanks,
Acee