Re: [Lsr] New Version Notification for draft-xu-lsr-flooding-reduction-in-clos-01.txt

yeah, that's roughly the reality though you yourself basically say
link-state is being run now out of need/desperation ;-) (whether it's
open/r or bgp-ls hacks to generate equivalent of link-state, BGP is a
diffused computation and not distributed and hence will only provide you
topology if you engage into egregious hacks [which BGP _almost_ never does
;-]) ;-) and although bgp ended up being used mostly today for the original
routing (accident as much as anything else really) thnking through the
stuff from clean slate (for reason enconomic or aesthetic ;-) will most
likley lead clear thinking architecture folks to realize that what you need
a mix down to reduce state and link-state up for the top to decide and
possibly do smart stuff based on topology knowledge (and yes, controller on
top if the flows leave long and are known is not a bad thing at all AFAIS
[since we bassically move into provisioning and not control]). throiw DF
into the mix and nudge, nudge, we have something like this ;-)

the currently adopted flooding reduction drafts have their own merit in
general sense, I'm of course all for dist-topoflood due to its simplicuty,
based on previous art (MANET), good implementation experience (for me
personally in rift which is variant of this really [thanks Pascal]), not
only reduction but balancing and architecture which allows to parallelize
the necessary computations if you're a clever implementer to the point
they're neglectible overhead for the gains under heavy flooding ;-)

-- tony

On Sun, Nov 26, 2023 at 10:49 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> I agree with all aforementioned comments.
>
> Wrt AI/ML networking - if a controller is used, what is required is link
> state exposure northbound and not link state protocol  in the fabric. (I
> could argue for RIFT though ;-))
> I’d urge you to take a look at Meta’s deployment  in their ML clusters
> (publicly available) - they use BGP as the routing protocol to exchange
> reachability (and build ECMP sets) and provide a backup if controller
> computed next hop goes away/before new one has been computed.
> Open R is used northbound to expose the topology (in exactly same way -
> BGP-LS could be used).
>
> To summarize: an LS protocol brings no additional value in scaled-out
> leaf-spine fabrics, without significant modifications -  it doesn’t work in
> irregular topologies such as DF, etc.
> Existing proposals - there are shipping implementations and experience in
> operating it, have proven their relative value in suitable deployments.
>
> Cheers,
> Jeff
>
> > On Nov 26, 2023, at 12:20, Acee Lindem <acee.ietf@gmail.com> wrote:
> >
> > Speaking as WG member:
> >
> > I agree. The whole Data Center IGP flooding discussion went on years ago
> and the simplistic enhancement proposed in the subject draft is neither
> relevant or useful now.
> >
> > Thanks,
> > Acee
> >
> >> On Nov 24, 2023, at 11:55 PM, Les Ginsberg (ginsberg) <ginsberg=
> 40cisco.com@dmarc.ietf.org> wrote:
> >>
> >> Xiaohu –
> >> I also point out that there are at least two existing drafts which
> specifically address IS-IS flooding reduction in CLOS networks and do so in
> greater detail and with more robustness than what is in your draft:
> >> https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
> >> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/
> >> I do not see a need for yet another draft specifically aimed at CLOS
> networks.
> >> Note that work on draft-ietf-lsr-isis-spine-leaf-ext was suspended due
> to lack of interest in deploying an IGP solution in CLOS networks.
> >> You are suggesting in draft-xu-lsr-fare that AI is going to change
> this. Well, maybe, but if so I think we should return to the solutions
> already available and prioritize work on them.
> >>    Les
> >>  From: Lsr <lsr-bounces@ietf.org> On Behalf Of Tony Li
> >> Sent: Thursday, November 23, 2023 8:39 AM
> >> To: xuxiaohu_ietf@hotmail.com
> >> Cc: lsr@ietf.org
> >> Subject: Re: [Lsr] New Version Notification for
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> Hi,
> >> What you’re proposing is already described in IS-IS Mesh Groups (
> https://www.rfc-editor.org/rfc/rfc2973.html) and improved upon in Dynamic
> Flooding (
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding).
> >> Regards,
> >> Tony
> >>
> >>
> >> On Nov 23, 2023, at 8:29 AM, xuxiaohu_ietf@hotmail.com wrote:
> >> Hi all,
> >> Any comments or suggestions are welcome.
> >> Best regards,
> >> Xiaohu
> >> 发件人: internet-drafts@ietf.org <internet-drafts@ietf.org>
> >> 日期: 星期三, 2023年11月22日 11:37
> >> 收件人: Xiaohu Xu <xuxiaohu_ietf@hotmail.com>
> >> 主题: New Version Notification for
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> A new version of Internet-Draft
> draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> has been successfully submitted by Xiaohu Xu and posted to the
> >> IETF repository.
> >>
> >> Name:     draft-xu-lsr-flooding-reduction-in-clos
> >> Revision: 01
> >> Title:    Flooding Reduction in CLOS Networks
> >> Date:     2023-11-22
> >> Group:    Individual Submission
> >> Pages:    6
> >> URL:
> https://www.ietf.org/archive/id/draft-xu-lsr-flooding-reduction-in-clos-01.txt
> >> Status:
> https://datatracker.ietf.org/doc/draft-xu-lsr-flooding-reduction-in-clos/
> >> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-xu-lsr-flooding-reduction-in-clos
> >> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-xu-lsr-flooding-reduction-in-clos-01
> >>
> >> Abstract:
> >>
> >>   In a CLOS topology, an OSPF (or ISIS) router may receive identical
> >>   copies of an LSA (or LSP) from multiple OSPF (or ISIS) neighbors.
> >>   Moreover, two OSPF (or ISIS) neighbors may exchange the same LSA (or
> >>   LSP) simultaneously.  This results in unnecessary flooding of link-
> >>   state information, which wastes the precious resources of OSPF (or
> >>   ISIS) routers.  Therefore, this document proposes extensions to OSPF
> >>   (or ISIS) to reduce this flooding within CLOS networks.  The
> >>   reduction of OSPF (or ISIS) flooding is highly beneficial for
> >>   improving the scalability of CLOS networks.
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >> _______________________________________________
> >> 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
> >
> >
> > _______________________________________________
> > 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
>