Re: [Lsr] UPA for option C

[Peter Psenak]

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 
ASNs) and reachability to next hops is redistributed (often with labels) 
between ASBRs ?


If the redistrubuted next hop is not summarized, there is no need for 
UPA. If you would summarize the next-hop during the redistribution, then 
you could use the UPA to signal its unreachbaility in case the summary 
is still advertised due to other prefixes still being redistributed. UPA 
can be used for summarization used during both inter-area propagation 
and inetr-domain redistribution.




On a similar note how UPAs travel (if at all) between backbone area and 
remote areas in the single AS case ?


UPA is propagated as any other prefix. See section 2.2.



While reading mail from Bruno I also realized a bit more complex case 
where someone may use service routes in service BGP over "seamless MPLS 
3107/LU routes by BGP over IGP. In such cases signalling remote PE going 
down is not going to help much I am afraid.


- - -

As to the draft I think just adding a sentence that it should be 
used/enabled only for encapsulated services at ingress to the service 
nodes.


we can certainly say that above is the primary use-case.

thanks,
Peter



And actually to expand on what Bruno mentioned in the last note next hop 
validation can in some implementations be enabled to resolve in 
different RIBs on a per SAFI basis.


But how BGP (or any other app) takes such triggers is indeed outside of 
scope of the current draft IMO.


Thx,
R,




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

[Lsr] UPA for option C

[Robert Raszuk]

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 with labels)
between ASBRs ?

On a similar note how UPAs travel (if at all) between backbone area and
remote areas in the single AS case ?

While reading mail from Bruno I also realized a bit more complex case where
someone may use service routes in service BGP over "seamless MPLS 3107/LU
routes by BGP over IGP. In such cases signalling remote PE going down is
not going to help much I am afraid.

- - -

As to the draft I think just adding a sentence that it should be
used/enabled only for encapsulated services at ingress to the service
nodes.

And actually to expand on what Bruno mentioned in the last note next hop
validation can in some implementations be enabled to resolve in different
RIBs on a per SAFI basis.

But how BGP (or any other app) takes such triggers is indeed outside of
scope of the current draft IMO.

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

Re: [Lsr] UPA and planned/unplanned signalling

[Les Ginsberg (ginsberg)]

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..
> 
> 
> 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 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 high cost of reaching the node about to go
> into maintenance.
> You can "get away with doing this" because you assume that when you
> receive the UPA indicating planned maintenance that the node is still
> reachable i.e., maintenance hasn't actually started yet.
> 
> Do I understand you correctly?
>  That is correct.
> 
> This does help me to understand your motivation, but I am not fully
> appreciating the benefits.
> Whether you trigger BGP-PIC or not, you will have to do a new best path
> calculation. I don't see that not triggering BGP-PIC provides a benefit worth
> pursuing.
> But maybe we just will have to agree to disagree on that.
>  ok
> 
> If there is consensus to keep the two bits, I would suggest that the UP flag 
> be
> a modifier of the U flag i.e., the U flag is always set (planned or 
> unplanned),
> the UP flag is set in addition to the U flag when the trigger is planned
> maintenance. The UP flag would be ignored if sent without U flag set.
> This would provide a modest simplification for those implementations which
> don't care about the distinction - just look at the U flag.
> For those implementations that want to make the distinction you seem to
> favor, they would inspect both flags.
> 
> ??
>  The flags should be defined to mean one thing or the other which is
> how it is defined currently. I do not like the proposal  of defining the 
> meaning
> of the flags based on how one implementation wants to interpret them.
> It is quite surprising to me that looking at two different flags is presumably
> more complex for some implementations.
> However, I am not going to argue beyond this on this topic. I am fine with
> whatever co-authors decide on this.
> 
[LES2:] I don't want to overstate the importance of this modest change. But 
here is why I think it might be worth doing.

Whether the trigger is planned or unplanned, the UPA advertisement indicates 
the prefix is unreachable. U bit unambiguously signals that.
UP bit is really signaling additional context.
Suppose, in the future, someone comes up with yet another "context" associated 
with the  advertisement of unreachability. They might propose a "UX bit" (or 
whatever).
If we require only one bit to be set based on the "reason" for the UPA 
advertisement (U only, UP only, UX only), then existing implementations will 
have to be updated every time a new bit is defined.
If we say U bit is always set (because whatever the context the prefix still 
needs to be considered unreachable) and the additional bits provide additional 
information - then we can add additional bits in a backwards compatible manner.

   Les

>Les
> 
> 
> > -Original Message-
> > From: Shraddha Hegde 
> > Sent: Monday, March 27, 2023 9:25 PM
> > To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> > Subject: RE: 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 -
> >
> > 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 maintenance event is scheduled in advance of the arrival of the
> > UPA advertisement. In such a case the arrival of the UPA advertisement
> > would be of no significance. Since traffic has already moved away it
> > does not matter whether BGP processes the UPA or does not.
> >
> > If, however, BGP had NOT been told about planned maintenance in
> > advance, the arrival of the UPA should be treated in the same way
> > regardless of whether the trigger was a planned maintenance event or
> > not. The node associated with the address advertised in the UPA has
> > become unreachable 

Re: [Lsr] UPA and planned/unplanned signalling

[Shraddha Hegde]

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 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 high cost of reaching the node about to 
go into maintenance.
You can "get away with doing this" because you assume that when you receive the 
UPA indicating planned maintenance that the node is still reachable i.e., 
maintenance hasn't actually started yet.

Do I understand you correctly?
 That is correct.

This does help me to understand your motivation, but I am not fully 
appreciating the benefits.
Whether you trigger BGP-PIC or not, you will have to do a new best path 
calculation. I don't see that not triggering BGP-PIC provides a benefit worth 
pursuing.
But maybe we just will have to agree to disagree on that.
 ok

If there is consensus to keep the two bits, I would suggest that the UP flag be 
a modifier of the U flag i.e., the U flag is always set (planned or unplanned), 
the UP flag is set in addition to the U flag when the trigger is planned 
maintenance. The UP flag would be ignored if sent without U flag set.
This would provide a modest simplification for those implementations which 
don't care about the distinction - just look at the U flag.
For those implementations that want to make the distinction you seem to favor, 
they would inspect both flags.

??
 The flags should be defined to mean one thing or the other which is how it 
is defined currently. I do not like the proposal  of defining the meaning of 
the flags based on how one implementation wants to interpret them.
It is quite surprising to me that looking at two different flags is presumably 
more complex for some implementations.
However, I am not going to argue beyond this on this topic. I am fine with 
whatever co-authors decide on this.

   Les


> -Original Message-
> From: Shraddha Hegde 
> Sent: Monday, March 27, 2023 9:25 PM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: RE: 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 -
>
> 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 maintenance event is scheduled in advance of the arrival of the 
> UPA advertisement. In such a case the arrival of the UPA advertisement 
> would be of no significance. Since traffic has already moved away it 
> does not matter whether BGP processes the UPA or does not.
>
> If, however, BGP had NOT been told about planned maintenance in 
> advance, the arrival of the UPA should be treated in the same way 
> regardless of whether the trigger was a planned maintenance event or 
> not. The node associated with the address advertised in the UPA has 
> become unreachable and BGP needs to act accordingly.
>  This is the case when BGP is not aware of the planned maintenance 
> and is learning that info from IGP.
> You are right that the final outcome of the planned maintenance vs 
> unreachability is same that the traffic needs to be moved away From 
> the remote PE. The difference is in how that is achieved. In case of 
> unreachability, the action need to be immediate and mechanisms such as 
> BGP-PIC needed. In case of planned maintenance,  it would just be 
> costing out Igp metric for the PE and hence the control plane 
> convergence.
> There may be implementations which just choose to trigger one 
> mechanisms for both scenarios and draft does not Mandate/suggest any 
> of this and is left to implementations.
>
>
>
> I therefore see no value add in differentiating between 
> planned/unplanned in the UPA advertisement.
>
> I hope this is clear.
> Please point out what I might have missed.
>
> Thanx.
>
>Les

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

Re: [Lsr] UPA and planned/unplanned signalling

[Les Ginsberg (ginsberg)]

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 high cost of reaching the node about to 
go into maintenance.
You can "get away with doing this" because you assume that when you receive the 
UPA indicating planned maintenance that the node is still reachable i.e., 
maintenance hasn't actually started yet.

Do I understand you correctly?

This does help me to understand your motivation, but I am not fully 
appreciating the benefits.
Whether you trigger BGP-PIC or not, you will have to do a new best path 
calculation. I don't see that not triggering BGP-PIC provides a benefit worth 
pursuing.
But maybe we just will have to agree to disagree on that.

If there is consensus to keep the two bits, I would suggest that the UP flag be 
a modifier of the U flag i.e., the U flag is always set (planned or unplanned), 
the UP flag is set in addition to the U flag when the trigger is planned 
maintenance. The UP flag would be ignored if sent without U flag set.
This would provide a modest simplification for those implementations which 
don't care about the distinction - just look at the U flag.
For those implementations that want to make the distinction you seem to favor, 
they would inspect both flags.

??

   Les


> -Original Message-
> From: Shraddha Hegde 
> Sent: Monday, March 27, 2023 9:25 PM
> To: Les Ginsberg (ginsberg) ; lsr@ietf.org
> Subject: RE: 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 -
> 
> 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
> maintenance event is scheduled in advance of the arrival of the UPA
> advertisement. In such a case the arrival of the UPA advertisement would be
> of no significance. Since traffic has already moved away it does not matter
> whether BGP processes the UPA or does not.
> 
> If, however, BGP had NOT been told about planned maintenance in advance,
> the arrival of the UPA should be treated in the same way regardless of
> whether the trigger was a planned maintenance event or not. The node
> associated with the address advertised in the UPA has become unreachable
> and BGP needs to act accordingly.
>  This is the case when BGP is not aware of the planned maintenance
> and is learning that info from IGP.
> You are right that the final outcome of the planned maintenance vs
> unreachability is same that the traffic needs to be moved away
> From the remote PE. The difference is in how that is achieved. In case of
> unreachability, the action need to be immediate and mechanisms such as
> BGP-PIC needed. In case of planned maintenance,  it would just be costing
> out
> Igp metric for the PE and hence the control plane convergence.
> There may be implementations which just choose to trigger one mechanisms
> for both scenarios and draft does not
> Mandate/suggest any of this and is left to implementations.
> 
> 
> 
> I therefore see no value add in differentiating between planned/unplanned
> in the UPA advertisement.
> 
> I hope this is clear.
> Please point out what I might have missed.
> 
> Thanx.
> 
>Les

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

Re: [Lsr] UPA and planned/unplanned signalling

[Robert Raszuk]

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 Shraddha Hegde  wrote:

> 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 -
>
> 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
> maintenance event is scheduled in advance of the arrival of the UPA
> advertisement. In such a case the arrival of the UPA advertisement would be
> of no significance. Since traffic has already moved away it does not matter
> whether BGP processes the UPA or does not.
>
> If, however, BGP had NOT been told about planned maintenance in advance,
> the arrival of the UPA should be treated in the same way regardless of
> whether the trigger was a planned maintenance event or not. The node
> associated with the address advertised in the UPA has become unreachable
> and BGP needs to act accordingly.
>  This is the case when BGP is not aware of the planned maintenance and
> is learning that info from IGP.
> You are right that the final outcome of the planned maintenance vs
> unreachability is same that the traffic needs to be moved away
> >From the remote PE. The difference is in how that is achieved. In case of
> unreachability, the action need to be immediate and mechanisms such as
> BGP-PIC needed. In case of planned maintenance,  it would just be costing
> out
> Igp metric for the PE and hence the control plane convergence.
> There may be implementations which just choose to trigger one mechanisms
> for both scenarios and draft does not
> Mandate/suggest any of this and is left to implementations.
>
>
>
> I therefore see no value add in differentiating between planned/unplanned
> in the UPA advertisement.
>
> I hope this is clear.
> Please point out what I might have missed.
>
> Thanx.
>
>Les
>
> ___
> 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

Re: [Lsr] UPA and planned/unplanned signalling

[Shraddha Hegde]

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 -

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 maintenance event is 
scheduled in advance of the arrival of the UPA advertisement. In such a case 
the arrival of the UPA advertisement would be of no significance. Since traffic 
has already moved away it does not matter whether BGP processes the UPA or does 
not.

If, however, BGP had NOT been told about planned maintenance in advance, the 
arrival of the UPA should be treated in the same way regardless of whether the 
trigger was a planned maintenance event or not. The node associated with the 
address advertised in the UPA has become unreachable and BGP needs to act 
accordingly.
 This is the case when BGP is not aware of the planned maintenance and is 
learning that info from IGP.
You are right that the final outcome of the planned maintenance vs 
unreachability is same that the traffic needs to be moved away
>From the remote PE. The difference is in how that is achieved. In case of 
>unreachability, the action need to be immediate and mechanisms such as BGP-PIC 
>needed. In case of planned maintenance,  it would just be costing out
Igp metric for the PE and hence the control plane convergence. 
There may be implementations which just choose to trigger one mechanisms for 
both scenarios and draft does not
Mandate/suggest any of this and is left to implementations.



I therefore see no value add in differentiating between planned/unplanned in 
the UPA advertisement.

I hope this is clear.
Please point out what I might have missed.

Thanx.

   Les

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

[Lsr] UPA and planned/unplanned signalling

[Les Ginsberg (ginsberg)]

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 maintenance event is 
scheduled in advance of the arrival of the UPA advertisement. In such a case 
the arrival of the UPA advertisement would be of no significance. Since traffic 
has already moved away it does not matter whether BGP processes the UPA or does 
not.

If, however, BGP had NOT been told about planned maintenance in advance, the 
arrival of the UPA should be treated in the same way regardless of whether the 
trigger was a planned maintenance event or not. The node associated with the 
address advertised in the UPA has become unreachable and BGP needs to act 
accordingly.

I therefore see no value add in differentiating between planned/unplanned in 
the UPA advertisement.

I hope this is clear.
Please point out what I might have missed.

Thanx.

   Les

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

Re: [Lsr] UPA/PUA

[Robert Raszuk]

Hi Greg,

That in fact even further highlights the benefits of using app to app
> network quality detection. When app has been exposed with more then one
> network path.
>
GIM>> I imagine that application layer OAM would be more burdensome than
OAM in the underlay. Of course, the detection of some failures in an
application is based on the application mechanism, not on the OAM. I
consider that as a tradeoff.


There is one more (IMHO very important) consideration to this.

With respect to application detection if you run 1000 application instances
each one of them needs to detect it. And not all of them may be sending
packets with OAM all the time.

So when I was going with ABR to PE probing that it should be enough for one
application to detect the failure, ABR would intercept this and trigger UPA
for all PEs which host behind 999 application endpoints.

That way the vast majority of applications would not even notice the issue
which is what we are all aiming for (one could hope :).

Many thx,
R.

On Mon, Jul 18, 2022 at 3:40 PM Greg Mirsky  wrote:

> Hi Robert,
> a note on active OAM in-lined below under GIM>>.
>
> Regards,
> Greg
>
> On Sun, Jul 17, 2022 at 11:12 PM Robert Raszuk  wrote:
>
>> Good point !
>>
>> That proves that if PE-PE OAM does not follow app to app path it is
>> useless. I would tend to agree.
>>
> GIM>> I agree, and the requirement for the active OAM to follow the same
> path has always been placed at the front of all OAM requirement documents I
> am familiar with. That equally applies to Fault Management (echo
> request/reply or BFD) and Performance Monitoring OAM protocols. I think
> that that requirement can be addressed by using the same encapsulation in
> the underlay network.
>
>>
>> That in fact even further highlights the benefits of using app to app
>> network quality detection. When app has been exposed with more then one
>> network path.
>>
> GIM>> I imagine that application layer OAM would be more burdensome than
> OAM in the underlay. Of course, the detection of some failures in an
> application is based on the application mechanism, not on the OAM. I
> consider that as a tradeoff.
>
>>
>> Thx,
>> R.
>>
>>
>> On Mon, Jul 18, 2022 at 6:04 AM Aijun Wang 
>> wrote:
>>
>>> Hi, Greg:
>>>
>>>
>>>
>>> As indicated in the update draft
>>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
>>>
>>>
>>>
>>> The motivation behind this draft is for either MPLS LPM FEC binding,
>>>
>>>SRv6 etc. tunnel ,or BGP overlay service that are using LPM
>>>
>>>forwarding plane where the IGP domain has been carved up into OSPF
>>>
>>>areas or IS-IS levels and summarization is utilized.  In such
>>>
>>>scenario, a link or node failure can result in a black hole of
>>>
>>>traffic when the summary advertisement that covers the failure
>>>
>>>prefixes still exists.
>>>
>>>
>>>
>>>PUAM can track the unreachability of the important component
>>>
>>>prefixes to ensure traffic 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.
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* Greg Mirsky 
>>> *Sent:* Monday, July 18, 2022 11:06 AM
>>> *To:* Aijun Wang 
>>> *Cc:* Robert Raszuk ; Christian Hopps <
>>> cho...@chopps.org>; 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 early in the discussion, I was not
>>> enthusiastic, to put it lightly, about either of the solutions. Instead, I
>>> believe that multi-hop BFD should be used to monitor the continuity of a
>>> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my
>>> position clear.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang 
>>> wrote:
>>>
>>

Re: [Lsr] UPA/PUA

[Greg Mirsky]

Hi Robert,
a note on active OAM in-lined below under GIM>>.

Regards,
Greg

On Sun, Jul 17, 2022 at 11:12 PM Robert Raszuk  wrote:

> Good point !
>
> That proves that if PE-PE OAM does not follow app to app path it is
> useless. I would tend to agree.
>
GIM>> I agree, and the requirement for the active OAM to follow the same
path has always been placed at the front of all OAM requirement documents I
am familiar with. That equally applies to Fault Management (echo
request/reply or BFD) and Performance Monitoring OAM protocols. I think
that that requirement can be addressed by using the same encapsulation in
the underlay network.

>
> That in fact even further highlights the benefits of using app to app
> network quality detection. When app has been exposed with more then one
> network path.
>
GIM>> I imagine that application layer OAM would be more burdensome than
OAM in the underlay. Of course, the detection of some failures in an
application is based on the application mechanism, not on the OAM. I
consider that as a tradeoff.

>
> Thx,
> R.
>
>
> On Mon, Jul 18, 2022 at 6:04 AM Aijun Wang 
> wrote:
>
>> Hi, Greg:
>>
>>
>>
>> As indicated in the update draft
>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
>>
>>
>>
>> The motivation behind this draft is for either MPLS LPM FEC binding,
>>
>>SRv6 etc. tunnel ,or BGP overlay service that are using LPM
>>
>>forwarding plane where the IGP domain has been carved up into OSPF
>>
>>areas or IS-IS levels and summarization is utilized.  In such
>>
>>scenario, a link or node failure can result in a black hole of
>>
>>traffic when the summary advertisement that covers the failure
>>
>>prefixes still exists.
>>
>>
>>
>>PUAM can track the unreachability of the important component
>>
>>prefixes to ensure traffic 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.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* Greg Mirsky 
>> *Sent:* Monday, July 18, 2022 11:06 AM
>> *To:* Aijun Wang 
>> *Cc:* Robert Raszuk ; Christian Hopps <
>> cho...@chopps.org>; 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 early in the discussion, I was not
>> enthusiastic, to put it lightly, about either of the solutions. Instead, I
>> believe that multi-hop BFD should be used to monitor the continuity of a
>> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my
>> position clear.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang 
>> wrote:
>>
>> Then considering both the scalability and possible false negative of BFD
>> based solution,  can 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:* Monday, July 18, 2022 8:39 AM
>> *To:* Robert Raszuk 
>> *Cc:* Christian Hopps ; Peter Psenak <
>> ppse...@cisco.com>; 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.
>>
>> GIM>> I assume you refer to BFD single-hop. Then I have a question What
>> do you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in
>> the Down state may not indicate that the link is down but that the remote
>> peer is operating down.
>>
>>
>>
>> Multihop BFD sessions will tell me that PE is up or down and that at
>> least one connection to it is still up. That is subtle but there is an
>> important difference.
>>
>> GIM>> Not necessarily, depends on the implementation. I can imagine a
>> scenario, depending on the Detect Multiplier and Transmission 

Re: [Lsr] UPA/PUA

[Robert Raszuk]

Good point !

That proves that if PE-PE OAM does not follow app to app path it is
useless. I would tend to agree.

That in fact even further highlights the benefits of using app to app
network quality detection. When app has been exposed with more then one
network path.

Thx,
R.


On Mon, Jul 18, 2022 at 6:04 AM Aijun Wang 
wrote:

> Hi, Greg:
>
>
>
> As indicated in the update draft
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
>
>
>
> The motivation behind this draft is for either MPLS LPM FEC binding,
>
>SRv6 etc. tunnel ,or BGP overlay service that are using LPM
>
>forwarding plane where the IGP domain has been carved up into OSPF
>
>areas or IS-IS levels and summarization is utilized.  In such
>
>scenario, a link or node failure can result in a black hole of
>
>traffic when the summary advertisement that covers the failure
>
>prefixes still exists.
>
>
>
>PUAM can track the unreachability of the important component
>
>prefixes to ensure traffic 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.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Monday, July 18, 2022 11:06 AM
> *To:* Aijun Wang 
> *Cc:* Robert Raszuk ; Christian Hopps <
> cho...@chopps.org>; 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 early in the discussion, I was not
> enthusiastic, to put it lightly, about either of the solutions. Instead, I
> believe that multi-hop BFD should be used to monitor the continuity of a
> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my
> position clear.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang 
> wrote:
>
> Then considering both the scalability and possible false negative of BFD
> based solution,  can 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:* Monday, July 18, 2022 8:39 AM
> *To:* Robert 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.
>
> GIM>> I assume you refer to BFD single-hop. Then I have a question What do
> you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in
> the Down state may not indicate that the link is down but that the remote
> peer is operating down.
>
>
>
> Multihop BFD sessions will tell me that PE is up or down and that at least
> one connection to it is still up. That is subtle but there is an important
> difference.
>
> GIM>> Not necessarily, depends on the implementation. I can imagine a
> scenario, depending on the Detect Multiplier and Transmission Interval
> values, when the BFD multi-hop session going down indicates that the
> particular path to the remote PE lost continuity.
>
>
>
> And I repeat from the Abstract of RFC 5880:
>
>This document describes a protocol intended to detect faults in the
>
>bidirectional path between two forwarding engines, including
>
>interfaces, data link(s), and to the extent possible the forwarding
>
>engines themselves, with potentially very low latency.
>
> I believe that BFD cannot give us a reliable indication of the operational
> state of a node that hosts the BFD session, applications, and protocols
> hosted on that node.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk  wrote:
>
> 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 your picture is
> that UPA is not only about signalling that all links to a node went down.
>
>
>
> UPA is also about signalling node down while links are still up - con

Re: [Lsr] UPA/PUA

[Robert Raszuk]

Hi Greg,

I am observing we are partially on the same page.

But if we compare full mesh PE-PE multihop BFD sessions vs PE-ABR then
flooding or DROID to remote PEs don't you think that the latter model is
far more scalable and operationally friendly ?

To make it clear - I am not against PE-PE detection ... in fact I am
suggesting that correctly provisioned service should get multiple paths end
to end (app to app) and detect quality app to app keeping all network away
from doing it.

Best,
R.


On Mon, Jul 18, 2022 at 5:06 AM Greg Mirsky  wrote:

> Hi Aijun,
> I cannot figure out how you draw such a conclusion from my comments to
> Robert. You may recall that from very early in the discussion, I was not
> enthusiastic, to put it lightly, about either of the solutions. Instead, I
> believe that multi-hop BFD should be used to monitor the continuity of a
> path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my
> position clear.
>
> Regards,
> Greg
>
> On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang 
> wrote:
>
>> Then considering both the scalability and possible false negative of BFD
>> based solution,  can 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:* Monday, July 18, 2022 8:39 AM
>> *To:* Robert Raszuk 
>> *Cc:* Christian Hopps ; Peter Psenak <
>> ppse...@cisco.com>; 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.
>>
>> GIM>> I assume you refer to BFD single-hop. Then I have a question What
>> do you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in
>> the Down state may not indicate that the link is down but that the remote
>> peer is operating down.
>>
>>
>>
>> Multihop BFD sessions will tell me that PE is up or down and that at
>> least one connection to it is still up. That is subtle but there is an
>> important difference.
>>
>> GIM>> Not necessarily, depends on the implementation. I can imagine a
>> scenario, depending on the Detect Multiplier and Transmission Interval
>> values, when the BFD multi-hop session going down indicates that the
>> particular path to the remote PE lost continuity.
>>
>>
>>
>> And I repeat from the Abstract of RFC 5880:
>>
>>This document describes a protocol intended to detect faults in the
>>
>>bidirectional path between two forwarding engines, including
>>
>>interfaces, data link(s), and to the extent possible the forwarding
>>
>>engines themselves, with potentially very low latency.
>>
>> I believe that BFD cannot give us a reliable indication of the
>> operational state of a node that hosts the BFD session, applications, and
>> protocols hosted on that node.
>>
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>>
>>
>>
>> On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk  wrote:
>>
>> 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 your picture is
>> that UPA is not only about signalling that all links to a node went down.
>>
>>
>>
>> UPA is also about signalling node down while links are still up -
>> continue responding to BFD in the line cards.
>>
>>
>>
>> See what we need here is not a signalling moment when all peers of PE see
>> all links to it going down. What is really needed is to signal when such PE
>> can not perform its service function any more. And that BFD to interfaces
>> will not tell you.
>>
>>
>>
>>
>>
>> > Why would you do that? In fact you're defeating a fundamental scaling
>> aspect of link-state protocols here.
>>
>>
>>
>> Since I have no physical alternative to use as backup other then crappy
>> carrier's backup link.
>>
>>
>>
>>
>>
>> >  Now you have N multi-hop BFDs session

Re: [Lsr] UPA/PUA

[Aijun Wang]

Hi, Greg:

 

As indicated in the update draft 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10

 

The motivation behind this draft is for either MPLS LPM FEC binding,

   SRv6 etc. tunnel ,or BGP overlay service that are using LPM

   forwarding plane where the IGP domain has been carved up into OSPF

   areas or IS-IS levels and summarization is utilized.  In such

   scenario, a link or node failure can result in a black hole of

   traffic when the summary advertisement that covers the failure

   prefixes still exists.

 

   PUAM can track the unreachability of the important component

   prefixes to ensure traffic 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.

 

 

Best Regards

 

Aijun Wang

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 early in the discussion, I was not enthusiastic, 
to put it lightly, about either of the solutions. Instead, I believe that 
multi-hop BFD should be used to monitor the continuity of a path PE-PE, not 
ABR/ASBR-PE as suggested by Robert. I hope I've made my position clear.

 

Regards,

Greg

 

On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Then considering both the scalability and possible false negative of BFD based 
solution,  can we say that the PUA/UPA solution is more preferable?

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  mailto:lsr-boun...@ietf.org> > On Behalf Of Greg Mirsky
Sent: Monday, July 18, 2022 8:39 AM
To: Robert Raszuk mailto:rob...@raszuk.net> >
Cc: Christian Hopps mailto:cho...@chopps.org> >; Peter 
Psenak mailto:ppse...@cisco.com> >; lsr mailto:lsr@ietf.org> >
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. 

GIM>> I assume you refer to BFD single-hop. Then I have a question What do you 
mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in the Down 
state may not indicate that the link is down but that the remote peer is 
operating down.

 

Multihop BFD sessions will tell me that PE is up or down and that at least one 
connection to it is still up. That is subtle but there is an important 
difference. 

GIM>> Not necessarily, depends on the implementation. I can imagine a scenario, 
depending on the Detect Multiplier and Transmission Interval values, when the 
BFD multi-hop session going down indicates that the particular path to the 
remote PE lost continuity.

 

And I repeat from the Abstract of RFC 5880:

   This document describes a protocol intended to detect faults in the

   bidirectional path between two forwarding engines, including

   interfaces, data link(s), and to the extent possible the forwarding

   engines themselves, with potentially very low latency.

I believe that BFD cannot give us a reliable indication of the operational 
state of a node that hosts the BFD session, applications, and protocols hosted 
on that node.

 

Regards,

Greg

 

 

On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk mailto:rob...@raszuk.net> > wrote:

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 your picture is that 
UPA is not only about signalling that all links to a node went down. 

 

UPA is also about signalling node down while links are still up - continue 
responding to BFD in the line cards. 

 

See what we need here is not a signalling moment when all peers of PE see all 
links to it going down. What is really needed is to signal when such PE can not 
perform its service function any more. And that BFD to interfaces will not tell 
you. 

 

 

> Why would you do that? In fact you're defeating a fundamental scaling aspect 
> of link-state protocols here.

 

Since I have no physical alternative to use as backup other then crappy 
carrier's backup link. 

 

 

>  Now you have N multi-hop BFDs sessions (one per ABR) running over the link 
> instead of just *1* session running on that link.

 

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. 

 

Multihop

Re: [Lsr] UPA/PUA

[Greg Mirsky]

Hi Aijun,
I cannot figure out how you draw such a conclusion from my comments to
Robert. You may recall that from very early in the discussion, I was not
enthusiastic, to put it lightly, about either of the solutions. Instead, I
believe that multi-hop BFD should be used to monitor the continuity of a
path PE-PE, not ABR/ASBR-PE as suggested by Robert. I hope I've made my
position clear.

Regards,
Greg

On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang 
wrote:

> Then considering both the scalability and possible false negative of BFD
> based solution,  can 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:* Monday, July 18, 2022 8:39 AM
> *To:* Robert 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.
>
> GIM>> I assume you refer to BFD single-hop. Then I have a question What do
> you mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in
> the Down state may not indicate that the link is down but that the remote
> peer is operating down.
>
>
>
> Multihop BFD sessions will tell me that PE is up or down and that at least
> one connection to it is still up. That is subtle but there is an important
> difference.
>
> GIM>> Not necessarily, depends on the implementation. I can imagine a
> scenario, depending on the Detect Multiplier and Transmission Interval
> values, when the BFD multi-hop session going down indicates that the
> particular path to the remote PE lost continuity.
>
>
>
> And I repeat from the Abstract of RFC 5880:
>
>This document describes a protocol intended to detect faults in the
>
>bidirectional path between two forwarding engines, including
>
>interfaces, data link(s), and to the extent possible the forwarding
>
>engines themselves, with potentially very low latency.
>
> I believe that BFD cannot give us a reliable indication of the operational
> state of a node that hosts the BFD session, applications, and protocols
> hosted on that node.
>
>
>
> Regards,
>
> Greg
>
>
>
>
>
> On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk  wrote:
>
> 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 your picture is
> that UPA is not only about signalling that all links to a node went down.
>
>
>
> UPA is also about signalling node down while links are still up - continue
> responding to BFD in the line cards.
>
>
>
> See what we need here is not a signalling moment when all peers of PE see
> all links to it going down. What is really needed is to signal when such PE
> can not perform its service function any more. And that BFD to interfaces
> will not tell you.
>
>
>
>
>
> > Why would you do that? In fact you're defeating a fundamental scaling
> aspect of link-state protocols here.
>
>
>
> Since I have no physical alternative to use as backup other then crappy
> carrier's backup link.
>
>
>
>
>
> >  Now you have N multi-hop BFDs sessions (one per ABR) running over the
> link instead of just *1* session running on that link.
>
>
>
> 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.
>
>
>
> Multihop BFD sessions will tell me that PE is up or down and that at least
> one connection to it is still up. That is subtle but there is an important
> difference.
>
>
>
>
>
> > If your (possible multiple sessions of) multi-hop BFD can be sent over
> this "slow link" at fast rate X then why not do it just once using a link
> local BFD session at the same rate instead?
>
>
>
> As described, BFD over a link is not the same as BFD to the node.
>
>
>
>
>
> And to project a bigger picture why I asked this ...
>
>
>
> If I would do the fast signalling of PE going down in BGP RRs would likely
> have some form of detecting PE liveness anyway. Multihop BFD could be one
> such option. So I was thinking
>
> if the same can be done with IGP detecti

Re: [Lsr] UPA/PUA

[Aijun Wang]

Then considering both the scalability and possible false negative of BFD based 
solution,  can 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: Monday, July 18, 2022 8:39 AM
To: Robert 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. 

GIM>> I assume you refer to BFD single-hop. Then I have a question What do you 
mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in the Down 
state may not indicate that the link is down but that the remote peer is 
operating down.

 

Multihop BFD sessions will tell me that PE is up or down and that at least one 
connection to it is still up. That is subtle but there is an important 
difference. 

GIM>> Not necessarily, depends on the implementation. I can imagine a scenario, 
depending on the Detect Multiplier and Transmission Interval values, when the 
BFD multi-hop session going down indicates that the particular path to the 
remote PE lost continuity.

 

And I repeat from the Abstract of RFC 5880:

   This document describes a protocol intended to detect faults in the

   bidirectional path between two forwarding engines, including

   interfaces, data link(s), and to the extent possible the forwarding

   engines themselves, with potentially very low latency.

I believe that BFD cannot give us a reliable indication of the operational 
state of a node that hosts the BFD session, applications, and protocols hosted 
on that node.

 

Regards,

Greg

 

 

On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk mailto:rob...@raszuk.net> > wrote:

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 your picture is that 
UPA is not only about signalling that all links to a node went down. 

 

UPA is also about signalling node down while links are still up - continue 
responding to BFD in the line cards. 

 

See what we need here is not a signalling moment when all peers of PE see all 
links to it going down. What is really needed is to signal when such PE can not 
perform its service function any more. And that BFD to interfaces will not tell 
you. 

 

 

> Why would you do that? In fact you're defeating a fundamental scaling aspect 
> of link-state protocols here.

 

Since I have no physical alternative to use as backup other then crappy 
carrier's backup link. 

 

 

>  Now you have N multi-hop BFDs sessions (one per ABR) running over the link 
> instead of just *1* session running on that link.

 

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. 

 

Multihop BFD sessions will tell me that PE is up or down and that at least one 
connection to it is still up. That is subtle but there is an important 
difference. 

 

 

> If your (possible multiple sessions of) multi-hop BFD can be sent over this 
> "slow link" at fast rate X then why not do it just once using a link local 
> BFD session at the same rate instead?

 

As described, BFD over a link is not the same as BFD to the node. 

 

 

And to project a bigger picture why I asked this ... 

 

If I would do the fast signalling of PE going down in BGP RRs would likely have 
some form of detecting PE liveness anyway. Multihop BFD could be one such 
option. So I was thinking 

if the same can be done with IGP detection wise. 

 

Note also that there are folks who do recommend PE to PE full mesh of BFD. That 
orders of magnitude more BFD sessions then within an area. 

 

Many thx,

R.

 

 

 

 

On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps mailto:cho...@chopps.org> > wrote:


Robert Raszuk mailto:rob...@raszuk.net> > 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 
comment to reflect in any way on them one way or the other.

On a more fundamental level though, I don't see why Peter's answers are not 
sufficient here. In particular, unless I am misunderstanding your scenario it 
seems ... unrealistic -- but maybe I've missed something.

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 in

Re: [Lsr] UPA

[Greg Mirsky]

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 up"? If the link is Ethernet, p2p single-hop BFD in
the Down state may not indicate that the link is down but that the remote
peer is operating down.

Multihop BFD sessions will tell me that PE is up or down and that at least
one connection to it is still up. That is subtle but there is an important
difference.
GIM>> Not necessarily, depends on the implementation. I can imagine a
scenario, depending on the Detect Multiplier and Transmission Interval
values, when the BFD multi-hop session going down indicates that the
particular path to the remote PE lost continuity.

And I repeat from the Abstract of RFC 5880:
   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency.
I believe that BFD cannot give us a reliable indication of the operational
state of a node that hosts the BFD session, applications, and protocols
hosted on that node.

Regards,
Greg


On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk  wrote:

> 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 your picture is
> that UPA is not only about signalling that all links to a node went down.
>
> UPA is also about signalling node down while links are still up - continue
> responding to BFD in the line cards.
>
> See what we need here is not a signalling moment when all peers of PE see
> all links to it going down. What is really needed is to signal when such PE
> can not perform its service function any more. And that BFD to interfaces
> will not tell you.
>
>
> > Why would you do that? In fact you're defeating a fundamental scaling
> aspect of link-state protocols here.
>
> Since I have no physical alternative to use as backup other then crappy
> carrier's backup link.
>
>
> >  Now you have N multi-hop BFDs sessions (one per ABR) running over the
> link instead of just *1* session running on that link.
>
> 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.
>
> Multihop BFD sessions will tell me that PE is up or down and that at least
> one connection to it is still up. That is subtle but there is an important
> difference.
>
>
> > If your (possible multiple sessions of) multi-hop BFD can be sent over
> this "slow link" at fast rate X then why not do it just once using a link
> local BFD session at the same rate instead?
>
> As described, BFD over a link is not the same as BFD to the node.
>
>
> And to project a bigger picture why I asked this ...
>
> If I would do the fast signalling of PE going down in BGP RRs would likely
> have some form of detecting PE liveness anyway. Multihop BFD could be one
> such option. So I was thinking
> if the same can be done with IGP detection wise.
>
> Note also that there are folks who do recommend PE to PE full mesh of BFD.
> That orders of magnitude more BFD sessions then within an area.
>
> Many thx,
> R.
>
>
>
>
> On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps  wrote:
>
>>
>> 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 comment to reflect in any way on them one way or the other.
>>
>> On a more fundamental level though, I don't see why Peter's answers are
>> not sufficient here. In particular, unless I am misunderstanding your
>> scenario it seems ... unrealistic -- but maybe I've missed something.
>>
>> 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. Why would you do that? In fact you're defeating a fundamental scaling
>> aspect of link-state protocols here. Now you have N multi-hop BFDs sessions
>> (one per ABR) running over the link instead of just *1* session running on
>> that link.
>>
>> If your (possible multiple sessions of) multi-hop BFD can be sent over
>> this "slow link" at fast rate X then why not do it just once using a link
>> local BFD session at the same rate instead?
>>
>> If you configure the "down-detect" timer 

Re: [Lsr] UPA

[Christian Hopps]

t;     You seem to be suggesting that multi-hop BFD could be more
>     aggressive in failure detection than single hop BFD in the
>     presence of some link with slow single hop BFD timers.
>
>     This makes no sense to me. In order to avoid false failure
>     reports, the multi-hop BFD session has to allow for IGP FRR
to
>     occur, which means it cannot be more aggressive than worst
case
>     link protection mechanisms for the links which may be used
to
>     reach the multi-hop destination.
>
>      
>
>     You also seem to be concerned about headless Line Cards
>     continuing to maintain BFD sessions even after control
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.
>
>      
>
>     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.
>
>      
>
>     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 <
lsr@ietf.org
>     >
>     Subject: 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
your
>     picture is that UPA is not only about signalling that all
links
>     to a node went down. 
>
>      
>
>     UPA is also about signalling node down while links are
still up -
>     continue responding to BFD in the line cards. 
>
>      
>
>     See what we need here is not a signalling moment when all
peers
>     of PE see all links to it going down. What is really needed
is to
>     signal when such PE can not perform its service function
any
>     more. And that BFD to interfaces will not tell you. 
>
>      
>
>      
>
>     > Why would you do that? In fact you're defeating a
fundamental
>     scaling aspect of link-state protocols here.
>
>      
>
>     Since I have no physical alternative to use as backup other
then
>     crappy carrier's backup link. 
>
>      
>
>      
>
>     >  Now you have N multi-hop BFDs sessions (one per ABR)
running
>     over the link instead of just *1* session running on that
link.
>
>      
>
>     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. 
>
>      
>
>     Multihop BFD sessions will tell me that PE is up or down
and that
>     at least one connection to it is still up. That is subtle
but
>     there is an important difference. 
>
>      
>
>      
>
>     > If your (possible multiple sessions of) multi-hop BFD can
be
>     sent over this "slow link" at fast rate X then why not do
it just
>     once using a link local BFD session at the same rate
instead?
>
>      
>
>     As described, BFD over a link is not the same as BFD to the
>     node. 
>
>      
>
>      
>
>     And to project a bigger picture why I asked this ... 
>
>      
>
>     If I would do the fast signalling of PE going down in BGP
RRs
>     would likely have some form of detecting PE liveness
anyway.
>     Multihop BFD could be one such option. So I was thinking 
>
>     if the same can be done with IGP detection wise. 
>
>      
>
>     Note also that there are folks who do recommend PE to PE
full
>     mesh of 

Re: [Lsr] UPA

[Christian Hopps]

false failure
>     reports, the multi-hop BFD session has to allow for IGP FRR
to
>     occur, which means it cannot be more aggressive than worst
case
>     link protection mechanisms for the links which may be used
to
>     reach the multi-hop destination.
>
>      
>
>     You also seem to be concerned about headless Line Cards
>     continuing to maintain BFD sessions even after control
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.
>
>      
>
>     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.
>
>      
>
>     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 <
lsr@ietf.org
>     >
>     Subject: 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
your
>     picture is that UPA is not only about signalling that all
links
>     to a node went down. 
>
>      
>
>     UPA is also about signalling node down while links are
still up -
>     continue responding to BFD in the line cards. 
>
>      
>
>     See what we need here is not a signalling moment when all
peers
>     of PE see all links to it going down. What is really needed
is to
>     signal when such PE can not perform its service function
any
>     more. And that BFD to interfaces will not tell you. 
>
>      
>
>      
>
>     > Why would you do that? In fact you're defeating a
fundamental
>     scaling aspect of link-state protocols here.
>
>      
>
>     Since I have no physical alternative to use as backup other
then
>     crappy carrier's backup link. 
>
>      
>
>      
>
>     >  Now you have N multi-hop BFDs sessions (one per ABR)
running
>     over the link instead of just *1* session running on that
link.
>
>      
>
>     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. 
>
>      
>
>     Multihop BFD sessions will tell me that PE is up or down
and that
>     at least one connection to it is still up. That is subtle
but
>     there is an important difference. 
>
>      
>
>      
>
>     > If your (possible multiple sessions of) multi-hop BFD can
be
>     sent over this "slow link" at fast rate X then why not do
it just
>     once using a link local BFD session at the same rate
instead?
>
>      
>
>     As described, BFD over a link is not the same as BFD to the
>     node. 
>
>      
>
>      
>
>     And to project a bigger picture why I asked this ... 
>
>      
>
>     If I would do the fast signalling of PE going down in BGP
RRs
>     would likely have some form of detecting PE liveness
anyway.
>     Multihop BFD could be one such option. So I was thinking 
>
>     if the same can be done with IGP detection wise. 
>
>      
>
>     Note also that there are folks who do recommend PE to PE
full
>     mesh of BFD. That orders of magnitude more BFD sessions
then
>     within an area. 
>
>      
>
>     Many thx,
>
>     R.
>
>      
>
>      
>
>      
>
>      
>
>     On Sun,

Re: [Lsr] UPA

[Robert Raszuk]

Because you do not want to destabilize link state protocol. Even in the
area.

You do not want to compute SPF immediately at each link flap.

But you do want to signal to remote guys a hint (remember UPA is a hint not
a solid state) that paths coming with this next hop should be discouraged.

I think you and Les may be thinking of UPA as solid state PE unreachable
"pulse". For me however signalling issues (even if transient) about local
PE liveness is more important and has a value.

Many thx,
R.

PS. In fact that mutlihop session between ABRs and local PEs could be smart
and fail when there are some issues with data and control plane on the box
outside of BFD path and BFD components. Obviously outside of OSPF or ISIS
as well. In other words link state get's signalled to ABRs that some less
specifics have fever and those ABRs in turn issue a UPA or SPA (suspicious)
messages to remote guys.

I am not seeing it as local area trigger must be IGP native even if further
flooding would be.


On Sun, Jul 17, 2022 at 11:18 PM Christian Hopps  wrote:

>
> I feel like this is so obvious that I must still be misunderstanding you.
>
> Why is it ok for N * multi-hop sessions to run over this crappy-link at
> millisecond rates, but *not* ok for a single link local session to do the
> same?
>
> Thanks,
> Chris.
>
> Robert Raszuk  writes:
>
> > Hi Les,
> >
> >
> >> You seem to be suggesting that multi-hop BFD could be more
> > aggressive in failure detection than single hop BFD in
> >
> >> the presence of some link with slow single hop BFD timers.
> >
> >> This makes no sense to me. In order to avoid false failure reports,
> > the multi-hop BFD session has to allow for IGP FRR > to occur, which
> > means it cannot be more aggressive than worst case link protection
> > mechanisms for the links which
> >
> >> may be used to reach the multi-hop destination.
> >
> >
> > Not quite.
> >
> > Your and Chris comment is correct when both links connecting such PE
> > would be having the same metric and would be equal class citizens as
> > far as IGP connectivity to PE.
> >
> > This is however not the case I am presenting.
> >
> > To illustrate further:
> >
> > Good link PE-P has BFD timbers 10 ms x 3 = 30 ms
> > Bad link has timers 2 s x 3 = 6 sec detection.
> >
> > Good link is always preferred IGP wise.
> >
> > So when bad link fails and good link is ok - no false positive is
> > triggered.
> >
> > When good link fails multihop session must be just slower then this
> > link so it's timers would be 20 ms x 3 = 60 ms.
> >
> > When bad link remains the only one active multihop will detect the PE
> > down 100 times faster !
> >
> >> But this would affect multi-hop BFD as well as single hop BFD.
> >
> > Not if multihop BFD is going to RP/RE. Perhaps some vendors can
> > handle it on LCs.
> >
> >> And, I would argue, your issue is really with the vendor who ships
> > such a product which
> >> has a serious functionality gap.
> >
> > I would not be that fast. PEs today are compute nodes and I am yet to
> > see distributed BFD supported on the NICs.
> >
> > Many thx !
> > Robert
> >
> >
> >
> > On Sun, Jul 17, 2022 at 6:57 PM Les Ginsberg (ginsberg) <
> > ginsb...@cisco.com> wrote:
> >
> >
> > Robert –
> >
> >
> >
> > I continue to be a bit unclear on the relevance of the points you
> > are making.
> >
> > And I do want to express my agreement with the points Peter and
> > Chris have made.
> >
> >
> >
> > In that vein, some top posted comments.
> >
> >
> >
> > You seem to be suggesting that multi-hop BFD could be more
> > aggressive in failure detection than single hop BFD in the
> > presence of some link with slow single hop BFD timers.
> >
> > This makes no sense to me. In order to avoid false failure
> > reports, the multi-hop BFD session has to allow for IGP FRR to
> > occur, which means it cannot be more aggressive than worst case
> > link protection mechanisms for the links which may be used to
> > reach the multi-hop destination.
> >
> >
> >
> > You also seem to be concerned about headless Line Cards
> > continuing to maintain BFD sessions even after control 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 

Re: [Lsr] UPA

[Christian Hopps]

I feel like this is so obvious that I must still be misunderstanding you.

Why is it ok for N * multi-hop sessions to run over this crappy-link at 
millisecond rates, but *not* ok for a single link local session to do the same?

Thanks,
Chris.

Robert Raszuk  writes:


Hi Les,



You seem to be suggesting that multi-hop BFD could be more

aggressive in failure detection than single hop BFD in 


the presence of some link with slow single hop BFD timers.



This makes no sense to me. In order to avoid false failure reports,

the multi-hop BFD session has to allow for IGP FRR > to occur, which
means it cannot be more aggressive than worst case link protection
mechanisms for the links which 


may be used to reach the multi-hop destination.



Not quite. 

Your and Chris comment is correct when both links connecting such PE
would be having the same metric and would be equal class citizens as
far as IGP connectivity to PE. 

This is however not the case I am presenting. 

To illustrate further: 

Good link PE-P has BFD timbers 10 ms x 3 = 30 ms 
Bad link has timers 2 s x 3 = 6 sec detection. 

Good link is always preferred IGP wise. 

So when bad link fails and good link is ok - no false positive is
triggered. 

When good link fails multihop session must be just slower then this
link so it's timers would be 20 ms x 3 = 60 ms. 

When bad link remains the only one active multihop will detect the PE
down 100 times faster ! 


But this would affect multi-hop BFD as well as single hop BFD.


Not if multihop BFD is going to RP/RE. Perhaps some vendors can
handle it on LCs. 


And, I would argue, your issue is really with the vendor who ships

such a product which 

has a serious functionality gap.


I would not be that fast. PEs today are compute nodes and I am yet to
see distributed BFD supported on the NICs. 

Many thx !
Robert



On Sun, Jul 17, 2022 at 6:57 PM Les Ginsberg (ginsberg) <
ginsb...@cisco.com> wrote:


Robert –

 

I continue to be a bit unclear on the relevance of the points you
are making.

And I do want to express my agreement with the points Peter and
Chris have made.

 

In that vein, some top posted comments.

 

You seem to be suggesting that multi-hop BFD could be more
aggressive in failure detection than single hop BFD in the
presence of some link with slow single hop BFD timers.

This makes no sense to me. In order to avoid false failure
reports, the multi-hop BFD session has to allow for IGP FRR to
occur, which means it cannot be more aggressive than worst case
link protection mechanisms for the links which may be used to
reach the multi-hop destination.

 

You also seem to be concerned about headless Line Cards
continuing to maintain BFD sessions even after control 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.

 

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.

 

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 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 your
picture is that UPA is not only about signalling that all links
to a node went down. 

 

UPA is also about signalling node down while links are still up -
continue responding to BFD in the line cards. 

 

See what we need here is not a signalling moment when all peers
of PE see all links to it going down. What is really needed is to
signal when such PE can not perform its service function any
more. And that BFD to interfaces will not tell you. 

 

 

> Why would you do that? In fact you're defeating a fundamental
scaling aspect of link-state protocols here.

 

Since I have no physical alternative to use as backup other then
crappy carrier's backup link. 

 

 

>  Now you have N multi-hop BFDs sessions (one per ABR) running
over the link instead of just *1* session running on that link.

 

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. 

 

Multihop BFD sessions will tell me 

Re: [Lsr] UPA

[Robert Raszuk]

Hmm

I am not sure I follow what you just said.

1000s of PEs in an area ? Even if so you are worried about 1000s of
multihop BFD sessions to be handled at ABRs ?

But ABRs can be good vendor boxes and offload those 1000s of sessions to
LCs.

I was talking about PEs where they only do less then 10 multihop BFD
sessions to local area ABRs.

Please clarify.

Thx,
R.


On Sun, Jul 17, 2022 at 10:57 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> Throughout the discussions of various alternatives to solving this problem
> we have been consistently saying that the solution MUST work at scale – up
> to thousands of PEs.
>
> That’s because there are customers asking for this.
>
>
>
>Les
>
>
>
> *From:* Robert Raszuk 
> *Sent:* Sunday, July 17, 2022 1:12 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Christian Hopps ; Peter Psenak (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.
>
>
>
> Well just trying to respond to the points raised.
>
>
>
> *[LES:] Sooo, you apparently think it is OK to declare a node unreachable
> even though the criteria for determining that the link(s) being used to
> reach the node are down have not yet been met.*
>
>
>
> Yes. In fact I am not worrying about hard down. I am more worried
> about brownouts.
>
>
>
> *I would think this is prone to false negatives.*
>
>
>
> Well maybe yes maybe no.
>
>
>
> But let's think about it in the bigger context of UPA which is the subject
> here.
>
>
>
> Nodes receiving UPA will only deprioritize paths with such next hop. If
> there is no backup paths it will not harm anything. If there are
> backup paths the indication that some remote PE has a hiccup seems to me
> like very good signalling to use alternative path instead of continuing to
> go via potentially breaking node.
>
>
>
>
>
> Not if multihop BFD is going to RP/RE. Perhaps some vendors can handle it
> on LCs.
>
>
>
> *[LES:] Indeed they can – and if they cannot then the scalability of your
> proposed solution is limited.*
>
>
>
> Really ? How ?
>
>
>
> Do you see any scalability issues with 2 (oh maybe 4-8) multihop BFD
> sessions to *local* ABRs ? How is this not scalable ? Of course if your LC
> <--> RE/RP path takes up to 100 ms in the box your multihop timers must
> keep this in mind however this is I think obvious.
>
>
>
> Many thx,
>
> R.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA

[Les Ginsberg (ginsberg)]

Robert –

Throughout the discussions of various alternatives to solving this problem we 
have been consistently saying that the solution MUST work at scale – up to 
thousands of PEs.
That’s because there are customers asking for this.

   Les

From: Robert Raszuk 
Sent: Sunday, July 17, 2022 1:12 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 to the points raised.

[LES:] Sooo, you apparently think it is OK to declare a node unreachable even 
though the criteria for determining that the link(s) being used to reach the 
node are down have not yet been met.

Yes. In fact I am not worrying about hard down. I am more worried about 
brownouts.

I would think this is prone to false negatives.

Well maybe yes maybe no.

But let's think about it in the bigger context of UPA which is the subject here.

Nodes receiving UPA will only deprioritize paths with such next hop. If there 
is no backup paths it will not harm anything. If there are backup paths the 
indication that some remote PE has a hiccup seems to me like very good 
signalling to use alternative path instead of continuing to go via potentially 
breaking node.


Not if multihop BFD is going to RP/RE. Perhaps some vendors can handle it on 
LCs.

[LES:] Indeed they can – and if they cannot then the scalability of your 
proposed solution is limited.

Really ? How ?

Do you see any scalability issues with 2 (oh maybe 4-8) multihop BFD sessions 
to *local* ABRs ? How is this not scalable ? Of course if your LC <--> RE/RP 
path takes up to 100 ms in the box your multihop timers must keep this in mind 
however this is I think obvious.

Many thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] UPA

[Robert Raszuk]

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 the criteria for determining that the link(s) being used to
> reach the node are down have not yet been met.*
>

Yes. In fact I am not worrying about hard down. I am more worried
about brownouts.


> *I would think this is prone to false negatives.*
>

Well maybe yes maybe no.

But let's think about it in the bigger context of UPA which is the subject
here.

Nodes receiving UPA will only deprioritize paths with such next hop. If
there is no backup paths it will not harm anything. If there are
backup paths the indication that some remote PE has a hiccup seems to me
like very good signalling to use alternative path instead of continuing to
go via potentially breaking node.


Not if multihop BFD is going to RP/RE. Perhaps some vendors can handle it
> on LCs.
>
>
>
> *[LES:] Indeed they can – and if they cannot then the scalability of your
> proposed solution is limited.*
>

Really ? How ?

Do you see any scalability issues with 2 (oh maybe 4-8) multihop BFD
sessions to *local* ABRs ? How is this not scalable ? Of course if your LC
<--> RE/RP path takes up to 100 ms in the box your multihop timers must
keep this in mind however this is I think obvious.

Many thx,
R.

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

Re: [Lsr] UPA

[Robert Raszuk]

> I believe a lot of the false positive and / or negative issues are helped
with BFD Strict mode.

BFD strict mode is completely irrelevant to this discussion and UPA. At no
point we are here concerned with the interface up event which BFD strict
mode is addressing.


> I agree with Les on the comments related to BFD.

I recommend first to understand the scenario then provide cheerleading.

Many Thx,
R.


On Sun, Jul 17, 2022 at 7:31 PM Gyan Mishra  wrote:

>
> I agree with Les on the comments related to BFD.
>
> I believe a lot of the false positive and / or negative issues are helped
> with BFD Strict mode.
>
> Thanks
>
> Gyan
>
> On Sun, Jul 17, 2022 at 12:57 PM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
>> Robert –
>>
>>
>>
>> I continue to be a bit unclear on the relevance of the points you are
>> making.
>>
>> And I do want to express my agreement with the points Peter and Chris
>> have made.
>>
>>
>>
>> In that vein, some top posted comments.
>>
>>
>>
>> You seem to be suggesting that multi-hop BFD could be more aggressive in
>> failure detection than single hop BFD in the presence of some link with
>> slow single hop BFD timers.
>>
>> This makes no sense to me. In order to avoid false failure reports, the
>> multi-hop BFD session has to allow for IGP FRR to occur, which means it
>> cannot be more aggressive than worst case link protection mechanisms for
>> the links which may be used to reach the multi-hop destination.
>>
>>
>>
>> You also seem to be concerned about headless Line Cards continuing to
>> maintain BFD sessions even after control 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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 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 your picture is
>> that UPA is not only about signalling that all links to a node went down.
>>
>>
>>
>> UPA is also about signalling node down while links are still up -
>> continue responding to BFD in the line cards.
>>
>>
>>
>> See what we need here is not a signalling moment when all peers of PE see
>> all links to it going down. What is really needed is to signal when such PE
>> can not perform its service function any more. And that BFD to interfaces
>> will not tell you.
>>
>>
>>
>>
>>
>> > Why would you do that? In fact you're defeating a fundamental scaling
>> aspect of link-state protocols here.
>>
>>
>>
>> Since I have no physical alternative to use as backup other then crappy
>> carrier's backup link.
>>
>>
>>
>>
>>
>> >  Now you have N multi-hop BFDs sessions (one per ABR) running over the
>> link instead of just *1* session running on that link.
>>
>>
>>
>> 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.
>>
>>
>>
>> Multihop BFD sessions will tell me that PE is up or down and that at
>> least one connection to it is still up. That is subtle but there is an
>> important difference.
>>
>>
>>
>>
>>
>> > If your (possible multiple sessions of) multi-hop BFD can be sent over
>> this "slow link" at fast rate X then why not do it just once using a link
>> local BFD session at the same rate instead?
>>
>>
>>
>> As described, BFD over a link is not the same as BF

Re: [Lsr] UPA

[Robert Raszuk]

Hi Les,

> You seem to be suggesting that multi-hop BFD could be more aggressive in
failure detection than single hop BFD in

> the presence of some link with slow single hop BFD timers.

> This makes no sense to me. In order to avoid false failure reports, the
multi-hop BFD session has to allow for IGP FRR > to occur, which means it
cannot be more aggressive than worst case link protection mechanisms for
the links which

> may be used to reach the multi-hop destination.

Not quite.

Your and Chris comment is correct when both links connecting such PE would
be having the same metric and would be equal class citizens as far as IGP
connectivity to PE.

This is however not the case I am presenting.

To illustrate further:

Good link PE-P has BFD timbers 10 ms x 3 = 30 ms
Bad link has timers 2 s x 3 = 6 sec detection.

Good link is always preferred IGP wise.

So when bad link fails and good link is ok - no false positive is
triggered.

When good link fails multihop session must be just slower then this link so
it's timers would be 20 ms x 3 = 60 ms.

When bad link remains the only one active multihop will detect the PE down
100 times faster !

> But this would affect multi-hop BFD as well as single hop BFD.

Not if multihop BFD is going to RP/RE. Perhaps some vendors can handle it
on LCs.

> And, I would argue, your issue is really with the vendor who ships such a
product which
> has a serious functionality gap.

I would not be that fast. PEs today are compute nodes and I am yet to see
distributed BFD supported on the NICs.

Many thx !
Robert



On Sun, Jul 17, 2022 at 6:57 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> I continue to be a bit unclear on the relevance of the points you are
> making.
>
> And I do want to express my agreement with the points Peter and Chris have
> made.
>
>
>
> In that vein, some top posted comments.
>
>
>
> You seem to be suggesting that multi-hop BFD could be more aggressive in
> failure detection than single hop BFD in the presence of some link with
> slow single hop BFD timers.
>
> This makes no sense to me. In order to avoid false failure reports, the
> multi-hop BFD session has to allow for IGP FRR to occur, which means it
> cannot be more aggressive than worst case link protection mechanisms for
> the links which may be used to reach the multi-hop destination.
>
>
>
> You also seem to be concerned about headless Line Cards continuing to
> maintain BFD sessions even after control 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.
>
>
>
> 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.
>
>
>
> 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 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 your picture is
> that UPA is not only about signalling that all links to a node went down.
>
>
>
> UPA is also about signalling node down while links are still up - continue
> responding to BFD in the line cards.
>
>
>
> See what we need here is not a signalling moment when all peers of PE see
> all links to it going down. What is really needed is to signal when such PE
> can not perform its service function any more. And that BFD to interfaces
> will not tell you.
>
>
>
>
>
> > Why would you do that? In fact you're defeating a fundamental scaling
> aspect of link-state protocols here.
>
>
>
> Since I have no physical alternative to use as backup other then crappy
> carrier's backup link.
>
>
>
>
>
> >  Now you have N multi-hop BFDs sessions (one per ABR) running over the
> link instead of just *1* session running on that link.
>
>
>
> 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.
>
>
>
> Multihop BFD sessions will tell me that PE is up or down and that at least
> one connection to it is still up. That is subtle but there is a

Re: [Lsr] UPA

[Gyan Mishra]

I agree with Les on the comments related to BFD.

I believe a lot of the false positive and / or negative issues are helped
with BFD Strict mode.

Thanks

Gyan

On Sun, Jul 17, 2022 at 12:57 PM Les Ginsberg (ginsberg)  wrote:

> Robert –
>
>
>
> I continue to be a bit unclear on the relevance of the points you are
> making.
>
> And I do want to express my agreement with the points Peter and Chris have
> made.
>
>
>
> In that vein, some top posted comments.
>
>
>
> You seem to be suggesting that multi-hop BFD could be more aggressive in
> failure detection than single hop BFD in the presence of some link with
> slow single hop BFD timers.
>
> This makes no sense to me. In order to avoid false failure reports, the
> multi-hop BFD session has to allow for IGP FRR to occur, which means it
> cannot be more aggressive than worst case link protection mechanisms for
> the links which may be used to reach the multi-hop destination.
>
>
>
> You also seem to be concerned about headless Line Cards continuing to
> maintain BFD sessions even after control 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.
>
>
>
> 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.
>
>
>
> 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 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 your picture is
> that UPA is not only about signalling that all links to a node went down.
>
>
>
> UPA is also about signalling node down while links are still up - continue
> responding to BFD in the line cards.
>
>
>
> See what we need here is not a signalling moment when all peers of PE see
> all links to it going down. What is really needed is to signal when such PE
> can not perform its service function any more. And that BFD to interfaces
> will not tell you.
>
>
>
>
>
> > Why would you do that? In fact you're defeating a fundamental scaling
> aspect of link-state protocols here.
>
>
>
> Since I have no physical alternative to use as backup other then crappy
> carrier's backup link.
>
>
>
>
>
> >  Now you have N multi-hop BFDs sessions (one per ABR) running over the
> link instead of just *1* session running on that link.
>
>
>
> 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.
>
>
>
> Multihop BFD sessions will tell me that PE is up or down and that at least
> one connection to it is still up. That is subtle but there is an important
> difference.
>
>
>
>
>
> > If your (possible multiple sessions of) multi-hop BFD can be sent over
> this "slow link" at fast rate X then why not do it just once using a link
> local BFD session at the same rate instead?
>
>
>
> As described, BFD over a link is not the same as BFD to the node.
>
>
>
>
>
> And to project a bigger picture why I asked this ...
>
>
>
> If I would do the fast signalling of PE going down in BGP RRs would likely
> have some form of detecting PE liveness anyway. Multihop BFD could be one
> such option. So I was thinking
>
> if the same can be done with IGP detection wise.
>
>
>
> Note also that there are folks who do recommend PE to PE full mesh of BFD.
> That orders of magnitude more BFD sessions then within an area.
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
>
>
>
>
> On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps  wrote:
>
>
> 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 comment to reflect in any way on 

Re: [Lsr] UPA

[Robert Raszuk]

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 your picture is
that UPA is not only about signalling that all links to a node went down.

UPA is also about signalling node down while links are still up - continue
responding to BFD in the line cards.

See what we need here is not a signalling moment when all peers of PE see
all links to it going down. What is really needed is to signal when such PE
can not perform its service function any more. And that BFD to interfaces
will not tell you.


> Why would you do that? In fact you're defeating a fundamental scaling
aspect of link-state protocols here.

Since I have no physical alternative to use as backup other then crappy
carrier's backup link.


>  Now you have N multi-hop BFDs sessions (one per ABR) running over the
link instead of just *1* session running on that link.

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.

Multihop BFD sessions will tell me that PE is up or down and that at least
one connection to it is still up. That is subtle but there is an important
difference.


> If your (possible multiple sessions of) multi-hop BFD can be sent over
this "slow link" at fast rate X then why not do it just once using a link
local BFD session at the same rate instead?

As described, BFD over a link is not the same as BFD to the node.


And to project a bigger picture why I asked this ...

If I would do the fast signalling of PE going down in BGP RRs would likely
have some form of detecting PE liveness anyway. Multihop BFD could be one
such option. So I was thinking
if the same can be done with IGP detection wise.

Note also that there are folks who do recommend PE to PE full mesh of BFD.
That orders of magnitude more BFD sessions then within an area.

Many thx,
R.




On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps  wrote:

>
> 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 comment to reflect in any way on them one way or the other.
>
> On a more fundamental level though, I don't see why Peter's answers are
> not sufficient here. In particular, unless I am misunderstanding your
> scenario it seems ... unrealistic -- but maybe I've missed something.
>
> 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. Why would you do that? In fact you're defeating a fundamental scaling
> aspect of link-state protocols here. Now you have N multi-hop BFDs sessions
> (one per ABR) running over the link instead of just *1* session running on
> that link.
>
> If your (possible multiple sessions of) multi-hop BFD can be sent over
> this "slow link" at fast rate X then why not do it just once using a link
> local BFD session at the same rate instead?
>
> If you configure the "down-detect" timer to a slow rate, then it'll be
> slow detecting the link down. It's sort of tautological, right?
>
> Thanks,
> Chris.
>
> >
> > 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 

Re: [Lsr] UPA

[Christian Hopps]

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 
comment to reflect in any way on them one way or the other.

On a more fundamental level though, I don't see why Peter's answers are not 
sufficient here. In particular, unless I am misunderstanding your scenario it 
seems ... unrealistic -- but maybe I've missed something.

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. Why would you 
do that? In fact you're defeating a fundamental scaling aspect of link-state 
protocols here. Now you have N multi-hop BFDs sessions (one per ABR) running 
over the link instead of just *1* session running on that link.

If your (possible multiple sessions of) multi-hop BFD can be sent over this "slow 
link" at fast rate X then why not do it just once using a link local BFD session at 
the same rate instead?

If you configure the "down-detect" timer to a slow rate, then it'll be slow 
detecting the link down. It's sort of tautological, right?

Thanks,
Chris.



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 <
ppse...@cisco.com
>     
>      > >>
wrote:
>      >
>      >     Robert,
>      >
>      >     BGP PIC depends on the IGP convergence. We are not
changing
>     any of that
>      >     by UPA.
>      >
>      >     thanks,
>      >     Peter
> 

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

[Lsr] UPA

[Robert Raszuk]

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 critical for
mix vendor interoperability.

Can UPA also be generated by P node(s) ?

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 ?

Many thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr