Re: [Lsr] UPA for option C

Robert, On 25/07/2023 22:19, Robert Raszuk wrote: Hey Peter and Lsr, At the risk of being called troublemaker by Les again :) can you refresh my failing memory how UPA would work in case of Inter-AS option C (where original next hops are maintained for service routes across two or more

[Lsr] UPA for option C

Hey Peter and Lsr, At the risk of being called troublemaker by Les again :) can you refresh my failing memory how UPA would work in case of Inter-AS option C (where original next hops are maintained for service routes across two or more ASNs) and reachability to next hops is redistributed (often

Re: [Lsr] UPA and planned/unplanned signalling

Shraddha - Glad we have come to a common understanding. One point inline. > -Original Message- > From: Shraddha Hegde > Sent: Monday, March 27, 2023 10:47 PM > To: Les Ginsberg (ginsberg) ; lsr@ietf.org > Subject: RE: UPA and planned/unplanned signalling > > Les, > > Pls see inline..

Re: [Lsr] UPA and planned/unplanned signalling

Les, Pls see inline.. Juniper Business Use Only -Original Message- From: Les Ginsberg (ginsberg) Sent: Tuesday, March 28, 2023 11:02 AM To: Shraddha Hegde ; lsr@ietf.org Subject: RE: UPA and planned/unplanned signalling [External Email. Be cautious of content] Shraddha - Thanx

Re: [Lsr] UPA and planned/unplanned signalling

Shraddha - Thanx for the response. So the way you are proposing to use UPA on the receiving nodes is: 1)For unplanned loss of reachability trigger BGP-PIC for immediate response 2)For planned loss of reachability, don't trigger BGP-PIC - simply trigger a best path calculation considering the

Re: [Lsr] UPA and planned/unplanned signalling

Hi Shraddha, So are you saying that ABR will inject UPA with U Flag when it notices unreachability and it will inject UP Flag when it notices Max Metric ? And the remote end point receiving UPA will still in both cases result in identical action ? Thx, R On Mon, Mar 27, 2023 at 9:25 PM

Re: [Lsr] UPA and planned/unplanned signalling

Hi Les, Pls see inline for replies. Juniper Business Use Only -Original Message- From: Les Ginsberg (ginsberg) Sent: Tuesday, March 28, 2023 9:10 AM To: Shraddha Hegde ; lsr@ietf.org Subject: UPA and planned/unplanned signalling [External Email. Be cautious of content] Shraddha -

[Lsr] UPA and planned/unplanned signalling

Shraddha - To follow up on our discussion over chat at the LSR meeting yesterday... At a remote ABR, if BGP had already been told about a planned node maintenance event (by means that is outside the scope of the UPA draft), then BGP would have moved traffic away from the node on which the

Re: [Lsr] UPA/PUA

t; >>> >>> >>>PUAM can track the unreachability of the important component >>> >>>prefixes to ensure traffic is not black hole sink routed for the >>> >>> above overlay services. >>> >>> >>> >&g

Re: [Lsr] UPA/PUA

ic is not black hole sink routed for the >> >>above overlay services. >> >> >> >> Then considering only the BFD sessions among PEs are not enough, even we >> put aside the BFD sessions overhead on each PE. >> >> >> >> >> >>

Re: [Lsr] UPA/PUA

re preferable? > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* lsr-boun...@ietf.org *On Behalf Of *Greg > Mirsky > *Sent:* Monday, July 18, 2022 8:39 AM > *To:* Robert Raszuk > *Cc:* Christian Hopps ; Peter Psenak ; > l

Re: [Lsr] UPA/PUA

an we say that the PUA/UPA solution is more preferable? >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> *From:* lsr-boun...@ietf.org *On Behalf Of *Greg >> Mirsky >> *Sent:* M

Re: [Lsr] UPA/PUA

China Telecom From: Greg Mirsky Sent: Monday, July 18, 2022 11:06 AM To: Aijun Wang Cc: Robert Raszuk ; Christian Hopps ; Peter Psenak ; lsr Subject: Re: [Lsr] UPA/PUA Hi Aijun, I cannot figure out how you draw such a conclusion from my comments to Robert. You may recall that from very

Re: [Lsr] UPA/PUA

s more preferable? > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *From:* lsr-boun...@ietf.org *On Behalf Of *Greg > Mirsky > *Sent:* Monday, July 18, 2022 8:39 AM > *To:* Robert Raszuk > *Cc:* Christian Hopps ; Peter Psenak ;

Re: [Lsr] UPA/PUA

Raszuk Cc: Christian Hopps ; Peter Psenak ; lsr Subject: Re: [Lsr] UPA Hi Robert, top-posting and then my notes in-line under the GIM>> tag: As mentioned it is still not the same. BFDs on the link tell me that link is up and part of the line card responder to BFD is alive. G

Re: [Lsr] UPA

Hi Robert, top-posting and then my notes in-line under the GIM>> tag: As mentioned it is still not the same. BFDs on the link tell me that link is up and part of the line card responder to BFD is alive. GIM>> I assume you refer to BFD single-hop. Then I have a question What do you mean by "link is

Re: [Lsr] UPA

 Multi-hop BFD as well as single hop BFD. > >       > >     Thanx. > >       > >    Les > >       > >       > >       > >     From: Lsr On Behalf Of Robert Raszu

Re: [Lsr] UPA

to >     Multi-hop BFD as well as single hop BFD. > >       > >     Thanx. > >       > >    Les > >       > >       > >       > >     From: Lsr On Behalf Of Robert Raszu

Re: [Lsr] UPA

ontrol plane > > failures. > > > > But this would affect multi-hop BFD as well as single hop BFD. > > > > And, I would argue, your issue is really with the vendor who > > ships such a product which has a serious functionality gap. > > > &

Re: [Lsr] UPA

e hop BFD.   Thanx.       Les       From: Lsr On Behalf Of Robert Raszuk Sent: Sunday, July 17, 2022 4:49 AM To: Christian Hopps Cc: Peter Psenak (ppsenak) ; lsr Subject: Re: [Lsr] UPA   Hi Christian,   > It seems you saying use m

Re: [Lsr] UPA

senak (ppsenak) < > ppse...@cisco.com>; lsr > *Subject:* Re: [Lsr] UPA > > > > Hi Les, > > > > Your excerpted top posting may not have enough context for everyone to > easily follow the point being discussed – hopefully that is not the case. > >

Re: [Lsr] UPA

PM To: Les Ginsberg (ginsberg) Cc: Christian Hopps ; Peter Psenak (ppsenak) ; lsr Subject: Re: [Lsr] UPA Hi Les, Your excerpted top posting may not have enough context for everyone to easily follow the point being discussed – hopefully that is not the case. Well just trying to respond

Re: [Lsr] UPA

Hi Les, Your excerpted top posting may not have enough context for everyone to > easily follow the point being discussed – hopefully that is not the case. > Well just trying to respond to the points raised. *[LES:] Sooo, you apparently think it is OK to declare a node unreachable > even though

Re: [Lsr] UPA

t;> >> Finally, I am not certain you are saying this – but you seem to be saying >> that BFD itself does not tell you whether the BFD client is fully sane. >> This I agree with – but again it applies to Multi-hop BFD as well as single >> hop BFD. >> >> >> >>

Re: [Lsr] UPA

with – but again it applies to Multi-hop BFD as well as single > hop BFD. > > > > Thanx. > > > > Les > > > > > > > > *From:* Lsr *On Behalf Of * Robert Raszuk > *Sent:* Sunday, July 17, 2022 4:49 AM > *To:* Christian Hopps > *Cc:* Pet

Re: [Lsr] UPA

ot tell you whether the BFD client is fully sane. > This I agree with – but again it applies to Multi-hop BFD as well as single > hop BFD. > > > > Thanx. > > > > Les > > > > > > > > *From:* Lsr *On Behalf Of * Robert Raszuk > *Sent:* Sunday, Jul

Re: [Lsr] UPA

Hi Christian, > It seems you saying use multi-hop BFD for fast detection b/c you've gone and configured one of those same hops along the > multi-hop path to an incredibly slow link-local BFD rate in comparison to the BFD multi-hop rate. Yes. That is exactly the case. What is however missing in

Re: [Lsr] UPA

Robert Raszuk writes: 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.  First, I don't like any of these unreachable things, and so I don't want my

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

[Lsr] UPA

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 ? I think such text is not an implementation detail, but it is