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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 26 Jan 2016 16:39:26 +0000

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

---

From: "Faraz Shamim (sshamim)" <[email-masked]>
Date: Wed, 27 Jan 2016 02:21:39 +0000

Support as a co-author.

Copying other co-authors of this draft.

Faraz

On 1/26/16, 10:39 AM, "OSPF on behalf of Acee Lindem (acee)"
<[email-masked] on behalf of [email-masked]> wrote:

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

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Wed, 27 Jan 2016 18:32:46 +0000

Support as co-author

Padma

-----Original Message-----
From: Faraz Shamim (sshamim) [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2016 6:22 PM
To: Acee Lindem (acee); OSPF WG List
Cc: Padmadevi Pillay Esnault; Khalid Raza; Kulawiak, Andrew; John Cavanaugh
Subject: Re: [OSPF] WG Adoption Call for "OSPF Stub Neighbors"

Support as a co-author.

Faraz

---

From: Anton Smirnov <[email-masked]>
Date: Sun, 31 Jan 2016 21:14:15 +0100

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