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

From: Shraddha Hegde <[email-masked]>
Date: Wed, 2 Dec 2020 17:30:07 +0000

Hi Les,

Thanks for the review and comments.
Pls see inline for replies.

Juniper Business Use Only
From: Les Ginsberg (ginsberg) <ginsberg=[email-masked]>
Sent: Monday, November 30, 2020 11:44 AM
To: Shraddha Hegde <[email-masked]>; [email-masked]
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

[External Email. Be cautious of content]

Draft authors -

I note that as the draft has evolved over the years a number of mechanisms have been removed (revised adjacency formation and auto tier detection) and the draft now focuses exclusively on flooding optimizations.

The draft now also references the recent work done in draft-ietf-lsr-dynamic-flooding.

A couple of things are not clear to me.

1)Is it your intent to use the mechanisms defined in draft-ietf-lsr-dynamic-flooding? I am specifically - though not exclusively - referring to how flooding adapts to topology changes.

It isn't clear from Section 3 whether you are actually intending to use the mechanisms defined in https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07*section-6.8__;Iw!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXymgguZIt$> or whether you simply want to use the Flooding sub-TLV defined in draft-ietf-lsr-dynamic-flooding to (optionally??) advertise your algorithm and all other procedures are specific to your algorithm.

<Shraddha> We want to use the " IS-IS Dynamic Flooding Sub-TLV" defined in sec 5.1.2 of the lsr-dynamic-flooding draft just to flood the information
that nodes support the algorithm specified in draft-white-lsr-distoptflood. I agree it's not writen very well. I'll update that section in next version.

2)The text at the end of https://tools.ietf.org/html/draft-white-lsr-distoptflood-00#section-2.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-white-lsr-distoptflood-00*section-2.1__;Iw!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXyucq9YRN$> states:

" LSPs transmitted to adjacent

   neighbors on the DNR list, however, MUST be transmitted using a

   circuit scope PDU as described in [RFC7356]."

Although this text is not new to this revision, it raises a number of questions/concerns - some of which relate to how this draft fits with draft-ietf-lsr-dynamic-flooding.

For "DNR neighbors", although a circuit scoped LSP was received, the actual content is a traditional area scoped LSP.

<Shraddha> yes.

This presumably needs to be used internally (e.g., when running the Decision Process) in the same way as an area scoped LSP.

<Shraddha> yes.

So there are now two internal databases (traditional area LSPs and Circuit Scoped LSPs) which have to be used as if they are a single database?

<Shraddha> Yes that is correct

When a node sends a traditional CSNP does it include the LSPs it received as Circuit-Scoped LSPs?

If not, how is resynchronization achieved when necessary?

<Shraddha> yes. CSNPs includes circuit scoped LSPs.

Since you raised this point, I am thinking that we need a protocol extension to indicate that "this circuit scoped LSP" should be treated

In this special way.

Given the base work defined in draft-ietf-lsr-dynamic-flooding why is the use of Circuit Scoped LSPs required/useful?

<Shraddha> I am not sure which base work you are suggesting to use. Could you pls provide details?

The flooding algorithm as written in the draft breaks if circuit scoped flooding is not done.

Because, the distributed algorithm does not flood the LSP back in the direction from where it was originated.

In general, it would be helpful to more completely define the relationship between this draft and draft-ietf-lsr-dynamic-flooding.

<Shraddha> yes. I'll produce next version soon.

Thanx.

   Les

> -----Original Message-----

> From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Shraddha Hegde

> Sent: Sunday, November 29, 2020 8:36 PM

> To: [email-masked]<mailto:[email-masked]>

> Subject: [Lsr] FW: New Version Notification for draft-white-lsr-distoptflood-

> 00.txt

> WG members,

> We have posted new version of the draft-white-lsr-distoptflood.

> This draft has been around for sometime by name openfabric and

> draft-white-distoptflood. The current revision has the name changed

> to reflect LSR WG.

> This draft describes a flood reduction mechanism in ISIS which is based on

> similar mechanisms implemented in OSPF for mobile-ad-hoc Networks

> ([RFC5449], [RFC5614], and [RFC7182]).

> Request working group to review and provide inputs.

> Rgds

> Shraddha

> Juniper Business Use Only

> -----Original Message-----

> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

> Sent: Monday, November 30, 2020 9:59 AM

> To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Russ White <[email-masked]<mailto:[email-masked]>>;

> Shawn Zandi <[email-masked]<mailto:[email-masked]>>

> Subject: New Version Notification for draft-white-lsr-distoptflood-00.txt

> [External Email. Be cautious of content]

> A new version of I-D, draft-white-lsr-distoptflood-00.txt

> has been successfully submitted by Shraddha Hegde and posted to the IETF

> repository.

> Name:           draft-white-lsr-distoptflood

> Revision:       00

> Title:          IS-IS Optimal Distributed Flooding for Dense Topologies

> Document date:  2020-11-29

> Group:          Individual Submission

> Pages:          12

> URL:

> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-white-<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-white-lsr-distoptflood-00.txt__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSEm2FfjO$>

> lsr-distoptflood-00.txt__;!!NEt6yMaO-<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-white-lsr-distoptflood-00.txt__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSEm2FfjO$>

> gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSEm2FfjO<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-white-lsr-distoptflood-00.txt__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSEm2FfjO$>

> $<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-white-lsr-distoptflood-00.txt__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSEm2FfjO$>

> Status:

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-white-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-white-lsr-distoptflood/__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSC0pwavY$>

> lsr-distoptflood/__;!!NEt6yMaO-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-white-lsr-distoptflood/__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSC0pwavY$>

> gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSC0pwav<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-white-lsr-distoptflood/__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSC0pwavY$>

> Y$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-white-lsr-distoptflood/__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSC0pwavY$>

> Htmlized:

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-white-lsr-distoptflood__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSFYebZSl$>

> white-lsr-distoptflood__;!!NEt6yMaO-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-white-lsr-distoptflood__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSFYebZSl$>

> gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSFYebZSl<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-white-lsr-distoptflood__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSFYebZSl$>

> $<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-white-lsr-distoptflood__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSFYebZSl$>

> Htmlized:       https://urldefense.com/v3/__https://tools.ietf.org/html/draft-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-white-lsr-distoptflood-00__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSANTt6Q2$>

> white-lsr-distoptflood-00__;!!NEt6yMaO-<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-white-lsr-distoptflood-00__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSANTt6Q2$>

> gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSANTt6Q<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-white-lsr-distoptflood-00__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSANTt6Q2$>

> 2$<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-white-lsr-distoptflood-00__;!!NEt6yMaO-gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSANTt6Q2$>

> Abstract:

>    In dense topologies, such as data center fabrics based on the Clos

>    and butterfly fabric topologies, flooding mechanisms designed for

>    sparse topologies, when used in these dense topologies, can

>    "overflood," or carry too many copies of topology and reachability to

>    fabric devices.  This results in slower convergence times and higher

>    resource utilization.  The modifications to the flooding mechanism in

>    the Intermediate System to Intermediate System (IS-IS) link state

>    protocol described in this document reduce resource utilization to a

>    minimum, while increaseing convergence performance in dense

>    topologies.

>    Note that a Clos fabric is used as the primary example of a desne

>    flooding topology throughout this document.  However, the flooding

>    optimizations described in this document apply to any dense topology.

> Please note that it may take a couple of minutes from the time of submission

> until the htmlized version and diff are available at tools.ietf.org.

> The IETF Secretariat

> _______________________________________________

> Lsr mailing list

> [email-masked]<mailto:[email-masked]>

> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXylitwgOR$>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 2 Dec 2020 18:16:50 +0000

Shraddha -

Thanx for the responses.

Please see inline.

From: Shraddha Hegde <shraddha=[email-masked]>
Sent: Wednesday, December 02, 2020 9:30 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked]
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

Hi Les,

Juniper Business Use Only
From: Les Ginsberg (ginsberg) <ginsberg=[email-masked]<mailto:ginsberg=[email-masked]>>
Sent: Monday, November 30, 2020 11:44 AM
To: Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

Draft authors -

<Shraddha> yes.

<Shraddha> yes.

In this special way.

[Les:] If you use the mechanisms defined in draft-ietf-lsr-dynamic-flooding there would be no need to use Circuit Scoped Flooding to send normal area scoped LSPs.

Each node in the topology would know to which neighbors it should have flooding enabled - either because you operate in centralized mode and the Area Leader distributes the flooding topology or because you operate in distributed mode and all nodes employ the same algorithm. (The latter assumes the algorithm supports deterministic choices for each node.) And when topology changes occur the mechanisms defined in https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07#section-6.8<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-07*section-6.8__;Iw!!NEt6yMaO-gk!VproGis8uUGmcl-cCplFMwuNceAo-3roUZT7ZdTlwvY7nJSszUo9AeWXymgguZIt$> assure that flooding continues to be reliable during the transition period (i.e., until a new flooding topology is calculated).

The fact that you apparently do NOT want to use the extensions defined in the dynamic-flooding draft means that (as you agree above) you have to introduce additional protocol extensions which aren't really necessary. This makes the solution much less appealing to me - independent of the merits/demerits of the algorithm itself.

The use of Circuit Scoped LSPs to send traditional area scoped LSPs is not at all what RFC 7356 intends. And it causes difficulties (as you have noted above) in what the content of CSNPs should be and how the different LSPDBs are used internally.

I really do not like these aspects.

The dynamic flooding draft wasn't in existence when Russ wrote the early versions of this draft. I am suggesting you might want to rethink your approach to take advantage of what dynamic flooding draft has defined.

   Les

Thanx.

   Les

---

From: <[email-masked]>
Date: Sat, 19 Dec 2020 07:49:22 -0500

> Given the base work defined in draft-ietf-lsr-dynamic-flooding why is
> the use of Circuit Scoped LSPs required/useful?

Circuit scoped flooding is required to prevent unnecessary floods from being
carried beyond where they are needed in the network.

One thought ... the way I originally worded the draft was not to have two
separate databases, but rather just to insert LSPs received as circuit local
in the normal database and then clear the SRM for those LSPs, so the local
flooding process believes they have already been flooded, but they will be
included in the CSNP, etc., as normal. I'm not certain why we need two
databases here.

> [Les:] If you use the mechanisms defined in
> draft-ietf-lsr-dynamic-flooding there would be no need to use Circuit
> Scoped Flooding to send normal area scoped LSPs.

> Each node in the topology would know to which neighbors it should have
> flooding enabled - either because you operate in centralized mode and
> the Area Leader distributes the flooding topology or because you operate
> in distributed mode and all nodes employ the same algorithm. (The latter

Using an area leader, even to centrally calculate a flooding topology,
breaks the distributed nature of the solutions, and creates a much more
complex solution. If you operate in distributed mode, with a common
algorithm, I think you still need to specify what that algorithm is ... this
draft describes such an algorithm ... I think ... ??

> The fact that you apparently do NOT want to use the extensions defined
> in the dynamic-flooding draft means that (as you agree above) you have
> to introduce additional protocol extensions which aren't really
> necessary. This makes the solution much less appealing to me -
> independent of the merits/demerits of the algorithm itself.

Not really... we are modifying already existing protocol extensions, rather
than creating new ones. 

The process described in this draft has already been tested, and is widely
used, in OSPF, btw (and doesn't use two databases there).

> The use of Circuit Scoped LSPs to send traditional area scoped LSPs is
> not at all what RFC 7356 intends. And it causes difficulties (as you
> have noted above) in what the content of CSNPs should be and how the
> different LSPDBs are used internally.

> The dynamic flooding draft wasn't in existence when Russ wrote the
> early versions of this draft. I am suggesting you might want to rethink
> your approach to take advantage of what dynamic flooding draft has
> defined.

The dynamic flooding draft assumes an area leader, which is what this draft
is attempting to avoid.

/r