To cover the make-before-break situation you and Peter discussed in this thread.
>> >> 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. >> Thanks, Acee > On Apr 30, 2025, at 10:57 AM, Robert Raszuk <[email protected]> wrote: > > 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]
