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

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 4 Jan 2021 05:01:40 +0000

Russ -

Happy New Year.
Responses inline.

> -----Original Message-----
> From: Lsr <[email-masked]> On Behalf Of [email-masked]
> Sent: Saturday, December 19, 2020 4:49 AM
> To: 'Les Ginsberg (ginsberg)' <ginsberg=[email-masked]>;
> 'Shraddha Hegde' <shraddha=[email-masked]>; [email-masked]
> 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 draft assumes an area leader, which is what this draft
> is attempting to avoid.
> 
[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?

   Les

> /r
> 
> 
> 
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: <[email-masked]>
Date: Mon, 4 Jan 2021 13:01:03 -0500

> [Les:] Signaling is required in your solution to indicate whether the neighbor
> should/should not propagate the LSP(s) received from a given neighbor.
> 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.

> Relay (MPR) functionality.

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

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 4 Jan 2021 18:57:30 +0000

Russ -

I think you have too many email addresses. 😊

Inline.

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

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

> To: Les Ginsberg (ginsberg) <[email-masked]>; [email-masked];

> 'Shraddha Hegde' <[email-masked]>; [email-masked]

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

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

> 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

> 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

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 7 Jan 2021 19:04:59 +0000

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 <[email-masked]> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[email-masked]>
Date: Monday, January 4, 2021 at 1:59 PM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 'Shraddha Hegde' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] New Version Notification for draft-white-lsr-distoptflood-00.txt

Russ -

Inline.

                 |   Source ID             |     ID Length

                 | Pseudonode ID           |     1

                 | FS LSP Number           |     1

   Les

---

From: <[email-masked]>
Date: Fri, 8 Jan 2021 18:30:24 -0500

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 9 Jan 2021 00:45:30 +0100

> 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 <[email-masked]> wrote:

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