On 7/30/20, 1:31 PM, "Lsr on behalf of Acee Lindem (acee)"
<lsr-boun...@ietf.org on behalf of acee=40cisco....@dmarc.ietf.org> wrote:
On 7/30/20, 12:37 PM, "Lsr on behalf of Peter Psenak" <lsr-boun...@ietf.org
on behalf of ppsenak=40cisco....@dmarc.ietf.org> wrote:
On 30/07/2020 18:03, Acee Lindem (acee) wrote:
> So, how do we define a reachable route - is it any route subsumed by
the summary LSA that we knew about in the past that becomes unreachable? When
the PUA is withdrawn, how do we know whether it is because of expiration of the
interval or the route becoming reachable again? This is a slippery slope.
I'm not suggesting the unreachable stuff to affect forwarding in any
way.
That would be better. Also, as I stated offline, it would also be better to
use encodings that would be ignored by routers that don't support the
extension. I tried to dissuade the authors of PUA not to overload the
prefix-originator LSA but was unsuccessful.
Of course, I meant prefix-originator Sub-TLV and the existing LSAs indicating
reachability -
https://www.ietf.org/id/draft-ietf-lsr-ospf-prefix-originator-06.txt
Thanks,
Acee
Thanks,
Acee
thanks,
Peter
> Thanks,
> Acee
>
> On 7/30/20, 10:34 AM, "Lsr on behalf of Peter Psenak"
<lsr-boun...@ietf.org on behalf of ppsenak=40cisco....@dmarc.ietf.org> wrote:
>
> On 30/07/2020 16:30, Robert Raszuk wrote:
> > Hey Peter,
> >
> > Not sure how smart you really want to be here but keep in mind
that BGP
> > say option C may never hear about it all the way to the egress
PE in
> > other domain or area ... It is almost always incongruent with
IGP.
> >
> > So if the BGP path is installed it will indeed be at risk to
resolve via
> > less specific when it is still active BGP path and you too
quickly
> > remove info about unreachability.
>
> again, if you are smart you can use this info to your advantage,
even
> without putting it in the forwarding and leaving the less
specific stuff
> intact.
>
> Peter
>
>
> >
> > Thx
> > R.
> >
> > On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak <ppse...@cisco.com
> > <mailto:ppse...@cisco.com>> wrote:
> >
> > On 30/07/2020 16:14, Robert Raszuk wrote:
> > > > 2：For bgp example，when the pe node down，the bgp
peer
> > must down
> > > within
> > > > 30 mintus，It will not get it up via cancle
advertise pua.
> > >
> > > for the above it is sufficient to advertise the
> > unreachability for few
> > > seconds from each ABR independently. That would be
a much
> > more solid
> > > proposal.
> > >
> > >
> > > Not sure about "few seconds" ... IBGP def hold time in
number of
> > > implementations is 180 sec :) .. but few minutes will
work for sure.
> >
> > depends how you use it.
> >
> > If you can use the unreachable info in a smart way, it's
sufficient if
> > it is present for a very short time interval.
> >
> > thanks,
> > Peter
> >
> > >
> > > Thx,
> > > R.
> > >
> >
>
> _______________________________________________
> 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
