Acee, Wide communities actually are designed to help operators in their tasks. I am not sure why you brought it here.
Besides please observe that communities are optional attributes. Lack of support on any BGP speaker will not break things or cause a permanent loop by design. Thx R. On Thu, Sep 16, 2021 at 10:16 PM Acee Lindem (acee) <[email protected]> wrote: > Hi Robert, > > > > *From: *Robert Raszuk <[email protected]> > *Date: *Thursday, September 16, 2021 at 5:34 AM > *To: *Peter Psenak <[email protected]> > *Cc: *Linda Dunbar <[email protected]>, Tony Li <[email protected]>, > "[email protected]" <[email protected]>, Bruno Decraene <[email protected]>, > Acee Lindem <[email protected]>, "Acee Lindem (acee)" <acee= > [email protected]> > *Subject: *Re: [Lsr] draft-ietf-lsr-flex-algo > > > > > > I believe flex-algo with additional constraints would be sufficient. > > > > Aren't we putting too much operational complexity to the operators ? > > > > The architecture supports it additional constraints. Nobody says they have > to be used. This is an interesting comment coming from the originator of > https://www.ietf.org/archive/id/draft-ietf-idr-wide-bgp-communities-05.txt > 😉 > > > > How can anyone practically assure that such constraints will be understood > across a zoo of software versions and various implementations ? > > > > IIRC, only routers supporting the FAD will participate in the flex > algorithm computation. I’ll defer to the authors for elaboration as I’m > busy with something else right now. > > > > Thanks, > Acee > > > > For well known metrics it could be ok - but for new metrics and selective > use in FAD I am afraid this is going to be a pandora box. > > > > Best, > R. > > > > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
