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

[Robert Raszuk]

> This is true, btw, of the centralized flood reduction mechanisms I've
seen,

Really ?

My understanding it that only LSP originator limits the flooding scope
based on the optimized topology reception (or in distributed case local
computation) not any via node.

Cheers,
R.



On Sat, Jan 9, 2021 at 12:30 AM  wrote:

>
> > I agree with Les. While you might get some flooding reduction out of
> > this, it wouldn’t be hard to better with a flooding next-neighbor
> > algorithm that was more well-thought (e.g., RFC 5614). Here are my
> > concerns:
>
> We are trying to avoid the LLS work in OSPF ...
>
> In testing, this shows a dramatic decrease in the amount of flooding in 3
> and 5 stage fabrics. Of course, this would also work for any random
> topology (even MANET networks), so it's not really limited to DC fabric use.
>
> > 1.It seems that while it is a distributed algorithm, the change of
> > flooding scope makes it somewhat quasi-centralized as you are making the
> > flooding decision for your neighbor. Perhaps, these parts of the
> > algorithm were developed with different Email addresses 😉
>
> I switched off gmail ... which is probably a good thing. 😊
>
> > 2.I don’t like the fact that IS-IS routers are changing the
> > flooding scope of an LSP that they didn’t originate themselves (Les’s
> > concern). This flooding scope modification could be removed but then
> > that would take away the novelty of the algorithm.
>
> This, it seems to me, is always going to be true of any flooding
> optimization -- unless you have the originator "mark" where each LSP
> "should go," something like a BIER bitfield embedded in the packet. This is
> true, btw, of the centralized flood reduction mechanisms I've seen, and is
> even true of 5614.
>
> > 3.The mechanisms for recovering from flooding failures is pretty
> > brute force…. A CNSP with every neighbor at sub-second intervals? Seems
> > this could negate much of what you are saving in flooding.
>
> It's not constant subsecond CSNPs, but rather a single additional CSNP.
>
> > 4.The way the document is written, the flooding decision is made
> > independently for every LSP. This seems unnecessary and it be per
> > neighbor (or even less granular) with no loss of optimization.
>
> I don't think it's implemented this way ... perhaps Shraddha can comment
> on how she implemented it. The FR/R implementation is not per LSP, either,
> AFAIK, but I can poke at the code again.
>
> 😊 /r
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[opens]

> I agree with Les. While you might get some flooding reduction out of
> this, it wouldn’t be hard to better with a flooding next-neighbor
> algorithm that was more well-thought (e.g., RFC 5614). Here are my
> concerns:

We are trying to avoid the LLS work in OSPF ... 

In testing, this shows a dramatic decrease in the amount of flooding in 3 and 5 
stage fabrics. Of course, this would also work for any random topology (even 
MANET networks), so it's not really limited to DC fabric use.

> 1.It seems that while it is a distributed algorithm, the change of
> flooding scope makes it somewhat quasi-centralized as you are making the
> flooding decision for your neighbor. Perhaps, these parts of the
> algorithm were developed with different Email addresses 😉

I switched off gmail ... which is probably a good thing. 😊

> 2.I don’t like the fact that IS-IS routers are changing the
> flooding scope of an LSP that they didn’t originate themselves (Les’s
> concern). This flooding scope modification could be removed but then
> that would take away the novelty of the algorithm.

This, it seems to me, is always going to be true of any flooding optimization 
-- unless you have the originator "mark" where each LSP "should go," something 
like a BIER bitfield embedded in the packet. This is true, btw, of the 
centralized flood reduction mechanisms I've seen, and is even true of 5614.

> 3.The mechanisms for recovering from flooding failures is pretty
> brute force…. A CNSP with every neighbor at sub-second intervals? Seems
> this could negate much of what you are saving in flooding.

It's not constant subsecond CSNPs, but rather a single additional CSNP. 

> 4.The way the document is written, the flooding decision is made
> independently for every LSP. This seems unnecessary and it be per
> neighbor (or even less granular) with no loss of optimization.

I don't think it's implemented this way ... perhaps Shraddha can comment on how 
she implemented it. The FR/R implementation is not per LSP, either, AFAIK, but 
I can poke at the code again.

😊 /r

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Speaking as WG member:

I agree with Les. While you might get some flooding reduction out of this, it 
wouldn’t be hard to better with a flooding next-neighbor algorithm that was 
more well-thought (e.g., RFC 5614). Here are my concerns:


  1.  It seems that while it is a distributed algorithm, the change of flooding 
scope makes it somewhat quasi-centralized as you are making the flooding 
decision for your neighbor. Perhaps, these parts of the algorithm were 
developed with different Email addresses 😉
  2.  I don’t like the fact that IS-IS routers are changing the flooding scope 
of an LSP that they didn’t originate themselves (Les’s concern). This flooding 
scope modification could be removed but then that would take away the novelty 
of the algorithm.
  3.  The mechanisms for recovering from flooding failures is pretty brute 
force…. A CNSP with every neighbor at sub-second intervals? Seems this could 
negate much of what you are saving in flooding.
  4.  The way the document is written, the flooding decision is made 
independently for every LSP. This seems unnecessary and it be per neighbor (or 
even less granular) with no loss of optimization.

Thanks,
Acee

From: Lsr  on behalf of "Les Ginsberg (ginsberg)" 

Date: Monday, January 4, 2021 at 1:59 PM
To: "op...@riw.us" , "7ri...@gmail.com" <7ri...@gmail.com>, 
'Shraddha Hegde' , "lsr@ietf.org" 
Subject: Re: [Lsr] New Version Notification for 
draft-white-lsr-distoptflood-00.txt


Russ -



I think you have too many email addresses. 😊

Inline.



> -Original Message-

> From: op...@riw.us 

> Sent: Monday, January 04, 2021 10:01 AM

> To: Les Ginsberg (ginsberg) ; 7ri...@gmail.com;

> 'Shraddha Hegde' ; lsr@ietf.org

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

> 00.txt

>

>

> > [Les:] Signaling is required in your solution to indicate whether the

> neighbor

> > should/should not propagate the LSP(s) received from a given neighbor.

> > But Circuit Scoped LSPs as defined in RFC 7356 do not provide this

> functionality.

> >

> > A Circuit Scoped LSP is to be used to send information originated by a node

> to a

> > specific neighbor of that node. This information has circuit scope - meaning

> it is

> > NEVER meant to be flooded on other circuits.

> > It is not an encapsulation mechanism to forward area/domain scoped LSPs

> > originated by other nodes in the network.

>

> I guess I'm not seeing the conflict here ... I'm okay with defining a new way 
> to

> signal an LSP should not be reflooded, but it seems like re-using the existing

> mechanism is a better way to move forward.

>



[Les:] There is no "existing mechanism".

Please look a bit closer.



https://www.rfc-editor.org/rfc/rfc7356.html#section-3.1 defines the format of 
the header of a FS-LSP. In particular, the LSP-ID is defined as:





 +-+

 |   Source ID | ID Length

 +-+

 | Pseudonode ID   | 1

 +-+

 | FS LSP Number   | 1

 +-+



Now, suppose node A needs to originate both:



a)A Level-1 LSP (Scope 4)

b)A Level-1 Circuit Scoped LSP (Scope 1)



The LSP-ID for both of these LSPs will be: A.00-00



Since you propose that both of these LSPs be sent as a Circuit Scoped LSP the 
receiver will be unable to tell the difference.



You simply cannot do what you propose.





> > [Les:] I assume what you are referring to here is MANET and the Multipoint

> > Relay (MPR) functionality.

>

> No -- RFC5820, which was implemented by Cisco, and is widely deployed.



[Les:] RFC5820 is titled  “Extensions to OSPF to Support Mobile Ad Hoc 
Networking”

And there are signaling extensions defined in the RFC for which you jave no 
equivalents in your draft.



As I previously commented, in your proposal, how do you know whether a node 
supports the extensions or not?

This seems quite necesssary to your proposal.



>

> > [Les:] It does seem that you do NOT want to use dynamic flooding

> extensions.

> > Which makes me wonder why you suggest (Section 3) the election of an

> Area

> > Leader. What purpose does this serve in your solution?

>

> When this draft was first proposed, I received several emails stating it MUST

> fit within the framework of the larger framework document, so I proposed a

> way to indicate this type of flooding reduction within that larger framework.

> There is no "leader" in this draft of any kind.

>

> There seem to be two general criticisms here. The first is that it doesn't fit

> int

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

[Les Ginsberg (ginsberg)]

Russ -



I think you have too many email addresses. 😊

Inline.



> -Original Message-

> From: op...@riw.us 

> Sent: Monday, January 04, 2021 10:01 AM

> To: Les Ginsberg (ginsberg) ; 7ri...@gmail.com;

> 'Shraddha Hegde' ; lsr@ietf.org

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

> 00.txt

>

>

> > [Les:] Signaling is required in your solution to indicate whether the

> neighbor

> > should/should not propagate the LSP(s) received from a given neighbor.

> > But Circuit Scoped LSPs as defined in RFC 7356 do not provide this

> functionality.

> >

> > A Circuit Scoped LSP is to be used to send information originated by a node

> to a

> > specific neighbor of that node. This information has circuit scope - meaning

> it is

> > NEVER meant to be flooded on other circuits.

> > It is not an encapsulation mechanism to forward area/domain scoped LSPs

> > originated by other nodes in the network.

>

> I guess I'm not seeing the conflict here ... I'm okay with defining a new way 
> to

> signal an LSP should not be reflooded, but it seems like re-using the existing

> mechanism is a better way to move forward.

>



[Les:] There is no "existing mechanism".

Please look a bit closer.



https://www.rfc-editor.org/rfc/rfc7356.html#section-3.1 defines the format of 
the header of a FS-LSP. In particular, the LSP-ID is defined as:





 +-+

 |   Source ID | ID Length

 +-+

 | Pseudonode ID   | 1

 +-+

 | FS LSP Number   | 1

 +-+



Now, suppose node A needs to originate both:



a)A Level-1 LSP (Scope 4)

b)A Level-1 Circuit Scoped LSP (Scope 1)



The LSP-ID for both of these LSPs will be: A.00-00



Since you propose that both of these LSPs be sent as a Circuit Scoped LSP the 
receiver will be unable to tell the difference.



You simply cannot do what you propose.





> > [Les:] I assume what you are referring to here is MANET and the Multipoint

> > Relay (MPR) functionality.

>

> No -- RFC5820, which was implemented by Cisco, and is widely deployed.



[Les:] RFC5820 is titled  “Extensions to OSPF to Support Mobile Ad Hoc 
Networking”

And there are signaling extensions defined in the RFC for which you jave no 
equivalents in your draft.



As I previously commented, in your proposal, how do you know whether a node 
supports the extensions or not?

This seems quite necesssary to your proposal.



>

> > [Les:] It does seem that you do NOT want to use dynamic flooding

> extensions.

> > Which makes me wonder why you suggest (Section 3) the election of an

> Area

> > Leader. What purpose does this serve in your solution?

>

> When this draft was first proposed, I received several emails stating it MUST

> fit within the framework of the larger framework document, so I proposed a

> way to indicate this type of flooding reduction within that larger framework.

> There is no "leader" in this draft of any kind.

>

> There seem to be two general criticisms here. The first is that it doesn't fit

> into the general pattern of "elect a leader of some kind." IMHO, this is not a

> bug but a feature. The method described in this draft has been proven to

> work--there are two implementations, both of which show large reductions

> in flooding. Further, the general concept has been proven to work in

> implementations deployed in the real world. I'm not entirely certain what to

> make of this criticism -- we aren't trying to replace the existing proposals, 
> but

> rather provide a complimentary option. I don't see why it should be that

> every possible solution must elect a leader in some way to be valid or

> acceptable.

>



[Les:] If your intention is NOT to fit into dynamic flooding framework, you can 
state that. But stating that and then saying “go ahead and elect an Area Leader 
if your want” makes no sense.

Pleasel be clear and internally consistent.



   Les



> The second criticism seems to be that it doesn't use signaling correctly ...

> While I don't really understand this criticism, I think we can work together 
> to

> resolve it.

>

> 😊 /r


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[opens]

> [Les:] Signaling is required in your solution to indicate whether the neighbor
> should/should not propagate the LSP(s) received from a given neighbor.
> But Circuit Scoped LSPs as defined in RFC 7356 do not provide this 
> functionality.
> 
> A Circuit Scoped LSP is to be used to send information originated by a node 
> to a
> specific neighbor of that node. This information has circuit scope - meaning 
> it is
> NEVER meant to be flooded on other circuits.
> It is not an encapsulation mechanism to forward area/domain scoped LSPs
> originated by other nodes in the network.

I guess I'm not seeing the conflict here ... I'm okay with defining a new way 
to signal an LSP should not be reflooded, but it seems like re-using the 
existing mechanism is a better way to move forward.

> [Les:] I assume what you are referring to here is MANET and the Multipoint
> Relay (MPR) functionality.

No -- RFC5820, which was implemented by Cisco, and is widely deployed.

> [Les:] It does seem that you do NOT want to use dynamic flooding extensions.
> Which makes me wonder why you suggest (Section 3) the election of an Area
> Leader. What purpose does this serve in your solution?

When this draft was first proposed, I received several emails stating it MUST 
fit within the framework of the larger framework document, so I proposed a way 
to indicate this type of flooding reduction within that larger framework. There 
is no "leader" in this draft of any kind.

There seem to be two general criticisms here. The first is that it doesn't fit 
into the general pattern of "elect a leader of some kind." IMHO, this is not a 
bug but a feature. The method described in this draft has been proven to 
work--there are two implementations, both of which show large reductions in 
flooding. Further, the general concept has been proven to work in 
implementations deployed in the real world. I'm not entirely certain what to 
make of this criticism -- we aren't trying to replace the existing proposals, 
but rather provide a complimentary option. I don't see why it should be that 
every possible solution must elect a leader in some way to be valid or 
acceptable.

The second criticism seems to be that it doesn't use signaling correctly ... 
While I don't really understand this criticism, I think we can work together to 
resolve it.

😊 /r

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Russ -

Happy New Year.
Responses inline.

> -Original Message-
> From: Lsr  On Behalf Of 7ri...@gmail.com
> Sent: Saturday, December 19, 2020 4:49 AM
> To: 'Les Ginsberg (ginsberg)' ;
> 'Shraddha Hegde' ; lsr@ietf.org
> Subject: Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-
> 00.txt
> 
> 
> 
> > 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.
> 

[Les:] Signaling is required in your solution to indicate whether the neighbor 
should/should not propagate the LSP(s) received from a given neighbor.
But Circuit Scoped LSPs as defined in RFC 7356 do not provide this 
functionality.

A Circuit Scoped LSP is to be used to send information originated by a node to 
a specific neighbor of that node. This information has circuit scope - meaning 
it is NEVER meant to be flooded on other circuits. 
It is not an encapsulation mechanism to forward area/domain scoped LSPs 
originated by other nodes in the network.

The obvious conflict arises when a given Node needs to originate circuit scoped 
information. The LSP-ID associated with this information will be 
indistinguishable from the LSP-ID of an area/domain scoped LSP originated by 
that same node.
So your overloaded use case cannot be supported.

BTW, this isn't simply a theoretical issue. One of the documented use cases for 
Circuit Scoped LSPs is defined in 
https://tools.ietf.org/html/draft-ietf-lsr-isis-spine-leaf-ext-02 - which might 
well be relevant to the same deployment cases this draft targets.

> 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.

[Les:] What you have done is abuse an existing mechanism and try to use it in a 
way which conflicts with its defined functionality.

> 
> The process described in this draft has already been tested, and is widely
> used, in OSPF, btw (and doesn't use two databases there).
> 
[Les:] I assume what you are referring to here is MANET and the Multipoint 
Relay (MPR) functionality.
But MPR depends upon enhanced signaling of a node's willingness to participate 
in enhanced flooding - which you have not defined.
So in addition to abusing Circuit Scoped LSP functionality, you haven't defined 
a means to operate with partial deployment of the extensions or even to know 
whether a node supports the extensions.

Seems to me you have skipped some key steps here.

> > 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 d

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

[7riw77]

> 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



___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Shraddha -

Thanx for the responses.

Please see inline.

From: Shraddha Hegde 
Sent: Wednesday, December 02, 2020 9:30 AM
To: Les Ginsberg (ginsberg) ; lsr@ietf.org
Subject: RE: New Version Notification for draft-white-lsr-distoptflood-00.txt

Hi Les,

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



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org>>
Sent: Monday, November 30, 2020 11:44 AM
To: Shraddha Hegde mailto:shrad...@juniper.net>>; 
lsr@ietf.org
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
 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.

 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
 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.

 yes.

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

 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?

 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?

 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?

 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.



[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
 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-f

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

[Shraddha Hegde]

Hi Les,

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



Juniper Business Use Only
From: Les Ginsberg (ginsberg) 
Sent: Monday, November 30, 2020 11:44 AM
To: Shraddha Hegde ; lsr@ietf.org
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
 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.

 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
 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.

 yes.

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

 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?

 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?

 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?

 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.

 yes. I'll produce next version soon.



Thanx.



   Les





> -Original Message-

> From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
> Shraddha Hegde

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

> To: lsr@ietf.org

> 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: internet-dra...@ietf.org 
> mailto:internet-dra...@ietf.org>>

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

> To: Shraddha Hegde mailto:shrad...@juniper.net>>; Russ 
> White mailto:r...@riw.us>>;

> Shawn Zandi mailto:sza...@linkedin.com>>

> Subject: New Version Notification for draft-white-lsr-distoptfloo

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

[Les Ginsberg (ginsberg)]

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 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.



2)The text at the end of 
https://tools.ietf.org/html/draft-white-lsr-distoptflood-00#section-2.1 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. This presumably needs to be used 
internally (e.g., when running the Decision Process) in the same way as an area 
scoped LSP. 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?

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?

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



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



Thanx.



   Les





> -Original Message-

> From: Lsr  On Behalf Of Shraddha Hegde

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

> To: lsr@ietf.org

> 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: internet-dra...@ietf.org 
> mailto:internet-dra...@ietf.org>>

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

> To: Shraddha Hegde mailto:shrad...@juniper.net>>; Russ 
> White mailto:r...@riw.us>>;

> Shawn Zandi mailto:sza...@linkedin.com>>

> 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-

> lsr-distoptflood-00.txt__;!!NEt6yMaO-

> gk!T5HX4Enn7jt3zwKoZBiA85YlysK0tdcELjk7Fy829PRSockmshBtqxzkSEm2FfjO

> $

> Status:

> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-white-

> ls