Subject: Re: [Lsr] FW: New Version Notification for draft-white-distoptflood-00.txt

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 1 Apr 2019 07:32:23 +0000

Russ -

Having reviewed the draft, I have the following high level comments:

1)Section 3 defines an algorithm which is used to "calculate" the flooding topology. As such, this draft is not an alternative to draft-ietf-lsr-dynamic-flooding.  It is simply one of potentially many drafts which may be written which will define such an algorithm,
Note that definition of algorithms is outside the scope of draft-ietf-lsr-dynamic-flooding.

The algorithm defined in your draft is by its nature a distributed algorithm i.e., your algorithm cannot be supported in centralized mode as defined by draft-ietf-lsr-dynamic-flooding.
However, nodes could advertise/agree on using this algorithm as a distributed algorithm using the signaling mechanisms defined in draft-ietf-lsr-dynamic-flooding.
I think this should be made clear in your draft.

2)The use of Circuit Scoped LSPs (RFC 7356) to flood standard L1/L2 LSPs to "DNR" nodes as defined in Section 3.1 of the draft is an invalid usage of CS-LSPs. The content of CS-LSPs is NOT identical to standard LSPs and the 1:1 equivalence you seem to require is inconsistent with RFC 7356.

3)The adjacency formation logic discussed in Section 2 isn’t directly relevant to calculating a flooding topology. There are existing implementations which use the techniques you define as a means of reducing redundant flooding associated with adjacency bringup when there are parallel links between two nodes. Note this can be (and is) done without  requiring protocol extensions/specification i.e., a node can do this today without introducing any interoperability issues. So while this is definitely a good idea, it isn’t directly related to the work on flooding topologies and I think is better removed from the draft.

   Les

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of [email-masked]
> Sent: Sunday, March 31, 2019 6:18 PM
> To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
> Subject: Re: [Lsr] FW: New Version Notification for draft-white-distoptflood-
> 00.txt
> 
> 
> > The WG just went through a lengthy consideration of multiple flooding
> > optimization drafts and selected https://datatracker.ietf.org/doc/draft-
> ietf-
> > lsr-dynamic-flooding/ as the vehicle for the WG to use to move forward in
> > this area.
> 
> Yep.
> 
> > It would be good if, in the context of the above, you articulated why it
> makes
> > sense for the WG to do yet another round of such discussion.
> 
> ==
> In this idea, the flooding topology is computed within an IGP area
>    with the dense topology either centrally on an elected node, termed
>    the Area Leader, or in a distributed manner on all nodes that are
>    supporting Dynamic Flooding.
> ==
> 
> Because this is only one way to solve the problem... The process outlined in
> the draft I just published is a different and simpler way that applies to a wider
> range of topologies than the dynamic flooding draft does, afaict.
> 
> 😊 /r
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: <[email-masked]>
Date: Mon, 1 Apr 2019 05:44:25 -0400

> 1)Section 3 defines an algorithm which is used to "calculate" the flooding
> topology. As such, this draft is not an alternative to draft-ietf-lsr-dynamic-
> flooding.  It is simply one of potentially many drafts which may be written
> which will define such an algorithm, Note that definition of algorithms is
> outside the scope of draft-ietf-lsr-dynamic-flooding.

Correct. This was my initial impression when I read draft-ietf-lsr-dynamic-flooding.

> I think this should be made clear in your draft.

Sure -- I can add this bit.

> 2)The use of Circuit Scoped LSPs (RFC 7356) to flood standard L1/L2 LSPs to
> "DNR" nodes as defined in Section 3.1 of the draft is an invalid usage of CS-
> LSPs. The content of CS-LSPs is NOT identical to standard LSPs and the 1:1
> equivalence you seem to require is inconsistent with RFC 7356.

Hm... I will need to look at this -- it might be worth chatting about this off line to see how to bring this in line. 

> 3)The adjacency formation logic discussed in Section 2 isn’t directly relevant
> to calculating a flooding topology. There are existing implementations which
> use the techniques you define as a means of reducing redundant flooding
> associated with adjacency bringup when there are parallel links between two
> nodes. Note this can be (and is) done without  requiring protocol
> extensions/specification i.e., a node can do this today without introducing
> any interoperability issues. So while this is definitely a good idea, it isn’t
> directly related to the work on flooding topologies and I think is better
> removed from the draft.

Okay -- it seems like this technique is not documented anyplace, and could be used for all adjacencies.

😊 /r

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 1 Apr 2019 11:21:57 +0000

Hi Russ, 

I won't have time to read your new version this week but you should align your distributed algorithm with  the WG flooding infra-structure draft. Anything that doesn't fit should remain in the OpenFrabric experimental draft. 

Thanks,
Acee

    

    

    
    
    😊 /r

---

From: [email-masked]
Date: Mon, 1 Apr 2019 08:43:49 -0700

> Okay -- it seems like this technique is not documented anyplace, and could be used for all adjacencies.

I’m going to risk disagreeing with Les again and suggest that this should be documented.  It need not be in this draft, but it is useful to have in an RFC somewhere.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 1 Apr 2019 16:00:48 +0000

Tony -

> From: Tony Li <[email-masked]> On Behalf Of [email-masked]
> Sent: Monday, April 01, 2019 8:44 AM
> To: [email-masked]
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
> I’m going to risk disagreeing with Les again

[Les:] :-)

 and suggest that this should be
> documented.  It need not be in this draft, but it is useful to have in an RFC
> somewhere.

[Les:] If someone wants to write this up in a draft that's fine with me - but it should be an Informational/BCP draft.

My point in the context of this thread is that it isn’t directly related to flooding optimization work and therefore doesn’t belong in such drafts.

   Les