Hi, Peter:
I must remind you that the following things:
1) The newly defined “U/UP flags” MUST be removed, as you declared they are trying to “give the reason of unreachable”, which is not suitable for IGP protocol, and also not enough to describe various reasons for the unreachability.
2) Remove the “partition” related description. Current contents doesn’t solve the problem, no useful information provided to the reader.
3) Remove the control knob considerations on the ABR. Because they are first provided by other proposal, and current contents covers only part of them.
After the above adjustments, there will be nothing needs to be standardized, the document should be changed to “Information Track”.
Robert,
On 30/04/2025 17:02, Robert Raszuk
wrote:
Indeed we agreed on the list but I never noticed text being
added to address it into section 4. In -04 it is not there.
we have not added it yet, but we agreed I would. I will do when
the next version is pushed, but wanted to wait for some more
comments to include.
thanks,
Peter
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]
|
