Hi Acee/All,
Before answering the question of the consensus call, I think it is really
important that the mechanism for signaling of flood reduction enablement,
capabilities, selection of algorithm, etc. be independent of the algorithm
definition by itself. This is the best and the right way to ensure that the
signaling mechanism is developed in a manner that would support the
development and deployment of any existing or potentially new algorithm for
flood reduction.
Coming to the consensus call itself, I would like to break my response as
follows:
1. Leaderless
- Not necessarily or I am not convinced as yet. If we see RFC9667, for
the distributed model, all that the “leader” is doing is selecting the
algorithm to be used. I don’t see an issue with that. We have successfully
deployed FlexAlgo where the FAD is configured on two (and rarely more)
routers and flooded through the area/level. We just didn’t call those
routers advertising FAD as “leader” but the concept for distributed flood
reduction with RFC9667 can be seen as somewhat similar. Perhaps we want to
improve the mechanism in RFC9667 to have flood reduction only in part of
the network – i.e., flood reduction is only enabled in part of the network
(where it is really needed) and there can be other parts where the normal
flooding happens. I believe this is already possible unless I have missed
something.
2. Flooding Algorithm for Distributed Flood Reduction
- Yes to distributed flood reduction
3. to allow reduced configuration
- What do we mean by this? Each router will have algorithm(s) that it
supports – I expect we want each of them to be configured for whether flood
reduction and specific algorithm is actually enabled by the operator. This
is especially important if we wanted to limit flood reduction to a specific
part of the network. The Dynamic Flooding sub-TLV of RFC9667 does convey
this to other routers in the network and it could potentially be used for
computing the flooding topology in a distributed manner.
- Then comes the configuration to select the specific algorithm to be
used – this could be done on all the routers (kind of like configuring FAD
on all routers and no need to flood it) or could be done on a couple of
routers (leaders) (same as what is widely done for FlexAlgo today)
4. minimal blast radius,
- this one I didn’t quite understand – are we talking about a
pathological state where all “leaders” go down or become unreachable?
5. and ease of incremental deployment
- Definitely, but again what extra do we need to do here?
I believe it will help us make progress if there is a separate individual
draft that captures this and other detailed requirements (we can leverage
RFC9667 – including leaving out what may be seen as not necessary). Then
evaluate the signaling mechanism for the distributed model in RFC9667 and
again leverage what is useful – then add/remove as required.
Thanks,
Ketan
On Mon, Nov 18, 2024 at 8:12 PM Acee Lindem <[email protected]> wrote:
> During the IETF 121 LSR meeting, we had a very good discussion of
> https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
>
> While the CDS flooding reduction algorithm itself was interesting, the
> main area of the discussion was distributed flooding reduction algorithm
> selection and its configuration and deployment.
>
> Today, we have RFC 9667 “Dynamic Flooding on Dense Graphs” which provides
> leader-based supporting both centralized and distributed flooding reduction
> algorithm selection. With the mechanism, an area leader is selected from
> among the OSPF routers in the area supporting flooding reduction and this
> leader selects the flooding reduction algorithm for the area.
>
> The question to be answered by this consensus call is whether or not we
> want to work on an additional mechanism just for distributed flooding
> reduction to allow for reduced configuration, minimal blast radius, and
> ease of incremental deployment.
>
> Please send your support or opposition to this list before Tuesday,
> December 3rd.
>
> As WG Co-Chair,
> Acee
> _______________________________________________
> Lsr mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
