Re: [Lsr] WG last call for draft-ietf-lsr-ospf-terminology-00

[Alvaro Retana]

On July 7, 2022 at 6:04:30 PM, Adrian Farrel wrote:


Adrian:

Hi!


...
> I checked the mailing list and couldn't find any discussion of this point so:
> is there any reason why the term "black hole" is also not being addressed? It
> seems to fall under the NIST guidance ("Avoid terms that use ‘black’ to mean
> something bad or negative") and is present in 5838.

No reason beyond the fact that we didn't comb through the documents enough -- 
the initial focus being put on terms that may show up on CLIs.

If there's no objection we can update the draft.

Also, if there are other terms that we missed, please point them out.

Thanks!

Alvaro. 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG last call for draft-ietf-lsr-ospf-terminology-00

[Adrian Farrel]

Chris, all,

I'm aware that the WG last call has gone by and I'd understand it if my 
comments are therefore put on one side. But rather than wait for IETF last 
call, I thought I'd ask now...

I checked the mailing list and couldn't find any discussion of this point so: 
is there any reason why the term "black hole" is also not being addressed? It 
seems to fall under the NIST guidance ("Avoid terms that use ‘black’ to mean 
something bad or negative") and is present in 5838.

Thanks,
Adrian

On 6/5/22, 5:55 AM, "Christian Hopps"  wrote:

Given the simplicity of this document and having received no objections or 
edits prior to or during the adoption call we'll be moving it immediately to 
WGLC...

This begins a 2 week WG Last Call, ending Jun 19th, 2022, for:

  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/

Authors,

  Please indicate to the list, your knowledge of any IPR related to this 
work.

Thanks,
Chris.



___
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] I-D Action: draft-ietf-lsr-ospf-terminology-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Update to OSPF Terminology
Authors : Mike Fox
  Acee Lindem
  Alvaro Retana
  Filename: draft-ietf-lsr-ospf-terminology-02.txt
  Pages   : 6
  Date: 2022-07-07

Abstract:
   This document updates some OSPF terminology to be in line with
   inclusive language used in the industry.  The IETF has designated
   National Institute of Standards and Technology (NIST) "Guidance for
   NIST Staff on Using Inclusive Language in Documentary Standards" for
   its inclusive language guidelines.

   This document updates RFC2328, RFC5340, RFC4222, RFC4811, RFC5243,
   RFC5614, and RFC5838.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-terminology-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-terminology-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA

[Robert Raszuk]

Peter,

In the scenario described there is really nothing to be tuned as you are
limited by the quality of local telco carriers.

Apparently you are not willing to consider it. Thank you.

Cheers,
R.


On Thu, Jul 7, 2022 at 2:43 PM Peter Psenak  wrote:

> 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  > > 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  > 
> >  > >> 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
> > mailto:ppse...@cisco.com>
> >  > >
> >  >  > 
> >  >  >  >
> >  >  > On 07/07/2022 11:38, Robert Raszuk wrote:
> >  >  >  >
> >  >  >  >  > there is no such thing.
> >  >  >  >
> >  >  >  

Re: [Lsr] UPA

[Peter Psenak]

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 > 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 mailto:ppse...@cisco.com>
 > >> 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
mailto:ppse...@cisco.com>
 >     >
 >      > 
      >
 >      >     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:
 >      >      

Re: [Lsr] UPA

[Robert Raszuk]

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  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  > > 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  > 
> >  > >> 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
> > mailto:ppse...@cisco.com>
> >  > >
> >  >  > 
> >  >  >  >
> >  >  > 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
> >  >

Re: [Lsr] UPA

[Peter Psenak]

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 > 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 mailto:ppse...@cisco.com>
 > >> 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
mailto:ppse...@cisco.com>
 >     >
 >      > 
      >
 >      >     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
 >     mailto:ppse...@cisco.com>

Re: [Lsr] UPA

[Robert Raszuk]

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 ?

Thx,
R.


On Thu, Jul 7, 2022 at 12:18 PM Peter Psenak  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  > > 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  > 
> >  > >> 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
> > mailto:ppse...@cisco.com>
> >  > >
> >  >  > 
> >  >  >  >
> >  >  > 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
> >
> >  >
> >   <
> 

Re: [Lsr] UPA

[Peter Psenak]

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 > 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 mailto:ppse...@cisco.com>
 > >> 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
mailto:ppse...@cisco.com>
 >     >
 >      > 
      >
 >      >     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


 >   
  >

 >      >
 > 
   >>

 >      >
 >      >      >
 >      >
 > 
   >

 >      >
 > 
   

Re: [Lsr] UPA

[Robert Raszuk]

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  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  > > 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  > 
> >  > >> 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
> >>>
> >  >
> >  >  > 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
> >  >  > 

Re: [Lsr] UPA

[Peter Psenak]

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 > 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 mailto:ppse...@cisco.com>
 > >> 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


 >   
  >

 >
 >      >
 >   
  
 >   
  >>

 >
 >      > 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA

[Robert Raszuk]

> 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.

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  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  > > 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
> >>
> >
> >  > 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA

[Peter Psenak]

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 > 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



 >
>

 > 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA

[Robert Raszuk]

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.

I am asking how you detect that transition on a far away ABR.

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  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>
>
> > 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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA

[Peter Psenak]

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 
 
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
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr