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

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

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

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

[Lsr] I-D Action: draft-ietf-lsr-ospf-terminology-02.txt

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

> 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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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

Re: [Lsr] UPA

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