Robert,
people know how to tune IGPs for faster convergence. They may or may do,
it's their decision based on their requirements. BFD is a standard
mechanism used by IGPs for fast detection of the adjacency loss. I see
no reason to require anything more or special for the UPA.
thanks,
Peter
On 07/07/2022 14:28, Robert Raszuk wrote:
Peter,
I think you are still not clear on some deployment scenarios.
So allow me to restate ...
It is pretty often (if not always) a valid requirement to redundantly
connect your PEs over different physical paths to the P nodes in the area.
For simplicity let's assume there are two links (it could be more then
two which only makes the situation worse from perspective of UPA).
One link belongs to telko A and is clean and solid BFD runs on it and
can detect link/peer down in 10s or 100s of milliseconds. The other link
is pretty bad (yet is used as backup as there is no physical
alternative) and BFD timers on it are set to 2 sec probing x 3 = 6 sec
detection of link/peer down.
I think we all agree (including Aijun) that you MUST not advertise UPA
before you receive all flooding from all adjacent to failed PE nodes -
that in the above case may take 6 sec.
So I was asking if you see it feasible to run multihop BFD from ABRs to
PEs to detect node down much faster then long BFD timers would otherwise
permit you to achieve.
And it can be just say milliseconds slower then fastest BFD timers so
effectively you get much faster detection then slowest BFD on links
would expose.
That's the real life scenario which I am trying to map to UPA (or in
fact also DROID) mechanism.
Many thx,
Robert
On Thu, Jul 7, 2022 at 2:03 PM Peter Psenak <[email protected]
<mailto:[email protected]>> wrote:
On 07/07/2022 12:26, Robert Raszuk wrote:
> That's true.
>
> I am pointing out that this in some networks may be much slower then
> invalidating the next hops from BGP route reflectors by running
*local*
> multihop BFD sessions to subject PEs (all within an area).
>
> So I have a question ... Let's forget about BGP and RRs and just
stay
> focused on IGP:
>
> Would it be feasible to trigger UPA on ABRs by running multihop BFD
> sessions between ABRs and local area PEs and not wait for PE-P
detection
> of link down as well as flooding to carry the information to ABRs ?
I would think running BFD on each individual link in the local area
would be a much better solution. And people already often do that.
thanks,
Peter
>
> Thx,
> R.
>
>
> On Thu, Jul 7, 2022 at 12:18 PM Peter Psenak <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>
> Robert,
>
> BGP PIC depends on the IGP convergence. We are not changing
any of that
> by UPA.
>
> thanks,
> Peter
>
>
> On 07/07/2022 12:02, Robert Raszuk wrote:
> > Peter,
> >
> > All I am saying is that this may be pretty slow if even
directly
> > attached P routers must way say 6 seconds (3 x 2 sec BFD)
to declare
> > peer down.
> >
> > And that is in contrast to running BFD from say BGP RR to
all PEs
> in an
> > area.
> >
> > The fundamental point is that in the case of PUA you MUST wait
> for all P
> > routers to tell you that PE in fact went down. While in
case of
> > invalidating service routes the first trigger is good enough.
> >
> > To me this is significant architectural difference.
> >
> > Many thx,
> > R.
> >
> >
> > On Thu, Jul 7, 2022 at 11:54 AM Peter Psenak
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>> wrote:
> >
> > On 07/07/2022 11:38, Robert Raszuk wrote:
> > >
> > > > there is no such thing.
> > >
> > > By far away ABR I mean ABR far away from failing PE
> connecting local
> > > are to the area 0. There can be number of P routers in
> between.
> >
> > ABR has the full visibility of the local area and
knows when any
> > node or
> > prefix becomes unreachable. It is determined by the SPF
> computation and
> > prefix processing that is triggered as a result of the
change
> in the
> > local area.
> >
> > thanks,
> > Peter
> >
> > >
> > > Let me provide you with an illustration:
> > >
> > > PE can be in Honolulu. ABR in Huston. All in one
area. For me
> > this ABR
> > > is far away from PE.
> > >
> > > On Thu, Jul 7, 2022 at 11:35 AM Peter Psenak
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
> > > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>> wrote:
> > >
> > > Robert,
> > >
> > > On 07/07/2022 11:25, Robert Raszuk wrote:
> > > > Hi Peter,
> > > >
> > > > > Section 4:
> > > > >
> > > > > "The intent of UPA is to provide an event
driven
> signal
> > of the
> > > > > transition of a destination from
reachable to
> > unreachable."
> > > >
> > > > That is too vague.
> > >
> > > it's all that is needed.
> > >
> > > >
> > > > I am asking how you detect that transition on a
> far away ABR.
> > >
> > > there is no such thing. The detection is done
based on
> the prefix
> > > transition from reachable to unreachabile in a
local
> area by
> > local
> > > ABRs.
> > > Remote ABRs just propagate the UPA.
> > >
> > > thanks,
> > > Peter
> > >
> > > >
> > > > For example, are you tracking flooding on
all links to
> > subject PE
> > > from
> > > > all its neighbours and only when all of them
remove
> that
> > link from
> > > > topology you signal PUA ?
> > > >
> > > > If so practically such trigger may be pretty
slow and
> > > inconsistent as in
> > > > real networks as links over which PEs are
connected are
> > often of a
> > > > very different quality, coming from different
> carriers and may
> > > have for
> > > > stability varying BFD timers. So here you
would have to
> > wait for the
> > > > slowest link to be detected on the
neighbouring P
> router
> > as down.
> > > >
> > > > Thx,
> > > > R.
> > > >
> > > > On Thu, Jul 7, 2022 at 10:16 AM Peter Psenak
> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
> > > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> > > > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>>> wrote:
> > > >
> > > > Robert,
> > > >
> > > > On 06/07/2022 15:07, Robert Raszuk wrote:
> > > > > Hi Peter,
> > > > >
> > > > > Can you please point me in the draft
> > > > >
> > > >
> > >
> >
>
https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt
<https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>
>
<https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>
> >
>
<https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>
> > >
> >
>
<https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>
> > > >
> > >
> >
>
<https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>>
> > > >
> > > > >
> > > >
> > >
> >
>
<https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>
> > > >
> > >
> >
>
<https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>>>
> > > >
> > > > > to some section which specifies based
on exactly
> > what network
> > > > flooding
> > > > > changes UPA will be generated by ABRs ?
> > > >
> > > > Section 4:
> > > >
> > > > "The intent of UPA is to provide an
event driven
> > signal of the
> > > > transition of a destination from
reachable to
> > unreachable."
> > > > >
> > > > > I think such text is not an
implementation
> detail,
> > but it is
> > > > critical
> > > > > for mix vendor interoperability.
> > > > >
> > > > > Can UPA also be generated by P node(s) ?
> > > >
> > > > only if they are ABRs or ASBRs.
> > > >
> > > >
> > > > >
> > > > > Specifically I was looking to find some
> information on
> > > how do you
> > > > > achieve assurance that UPA really
needs to
> be generated
> > > when using
> > > > > various vendor's nodes with very
different
> flooding
> > behaviours
> > > > and when
> > > > > subjects PEs may have a number of
different
> links
> > each with
> > > > different
> > > > > node/link down detection timer ?
> > > >
> > > > sorry, I don't understand the above.
> > > >
> > > > thanks,
> > > > Peter
> > > >
> > > > >
> > > > > Many thx,
> > > > > R.
> > > > >
> > > >
> > >
> >
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
