Which text ? https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-igp-ureach-prefix-announce-03&url2=draft-ietf-lsr-igp-ureach-prefix-announce-04&difftype=--html
Thx, R. On Wed, Apr 30, 2025 at 4:52 PM Acee Lindem <[email protected]> wrote: > Hi Robert, > > I guess you are now fine with the draft with this text. > > Thanks, > Acee > > > On Apr 23, 2025, at 10:51 AM, Robert Raszuk <[email protected]> wrote: > > > > > ok, I'm fine adding some text for your case. > > > > Thx Peter ! > > > > It is not "my use case" but ability to trigger UPA for make-before-break > which I think always is rather a good thing. > > > > Cheers, > > R. > > > > > > On Wed, Apr 23, 2025 at 4:40 PM Peter Psenak <[email protected]> wrote: > > Hi Robert, > > > > On 23/04/2025 16:35, Robert Raszuk wrote: > >> Hi Peter, > >>> If the egress PE is the only BGP NH, then reacting to max-metric or > OL-bit set would make some BGP destinations unreachable. > >> > >> Well this entirely depends on how one reacts on UPA if UPA is > signalling the only one left BGP path/NH as down irrespective of the > trigger. Does it stop the service to the destination or not ... > >> > >> If there are alternate paths the best path can install new next hop. > >> > >> If there are no alternate paths I would rather keep one installed > active - for example to address the case where one ABR can still reach > egress PE and the other one generated UPA. > >> > >>> So why not trigger UPA in such cases to hint him to switch to > alternate next hops if available ? > >> I'm not saying it can not be done. The implementation can chose to > advertise the UPA for the summary component prefix if the such prefix > metric in the source area/domain crosses certain value or if the prefix > originator is overloaded. > >> But this would make it not compliant with current text in section 4 > which was the main point of my question. So why not leave the door a bit > open for it in the spec ? > > ok, I'm fine adding some text for your case. > > thanks, > > Peter > > > >> > >> Thx, > >> R. > > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
