Subject: [Lsr] Prefix Unreachable Announcement Use Cases

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 14 Nov 2020 21:33:03 +0000

Speaking as WG member…

With respect to the use cases in section 3:

  3.1 Inter-Area Node Failure Scenario – With respect to this use case, the node in question is actually unreachable. In this case, the ABRs will normally install a reject route for the advertised summary and will send an ICMP unreachable when the packets are received for the unreachable prefix. This is the expected behavior and there really isn’t that much of advantage to move the point of unreachable detection a couple hops closer. If faster detection is required, BFD or other mechanisms are available.

  3.3 Intra-Area Node Failure Scenario – In the first place, multiple areas with overlapping summaries is just a bad network design. If the prefix is unreachable, the case digresses to getting the ICMP unreachable from the ABR with the invalid overlapping summary.

3.2 Inter-Area Links Failure Scenario – This is the case where the prefix is reachable but only through a subset of the area ABRs. This is really the only valid use case. IMO, it is better to solve this case with intra-area tunnels through the backbone as described in section 6.1. I think this is preferable to the complexity proposed in this draft and especially section 6. It is “interesting” when non-implementors specify implementation details.

Thanks,
Acee

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 14 Nov 2020 23:30:20 +0100

Hi Acee,

> 3.1 *Inter-Area Node Failure Scenario – *With respect to this use case,
the node
> in question is actually unreachable. In this case, the ABRs will normally
install a
> reject route for the advertised summary and will send an ICMP unreachable
when
> the packets are received for the unreachable prefix.

And what will the network do with such ICMP unreachable ? Is there some
draft I missed where encapsulating PE will choose a path with different
tunnel endpoint upon reception of ICMP unreachable message ?

See the entire idea behind this draft is to trigger faster switchover to
other PEs in the case of a multihomed attached site.

Option 1 - withdraw a service route in BGP. Use aggregate withdraw to speed
this up (say withdraw just RDs)

Option 2 - signal next hop unreachability (aka negative route) of more
specific prefix then the aggregate itself.

While I think just option 1 is ok for the vast majority of services your
answer seems to be talking about ICMP unreachable which IMO would not help
much with the issue. The proposal is not about failing ... the proposal is
about faster connectivity restoration.

> If faster detection is required, BFD or other mechanisms are available.

Now running a full mesh of BFD multihop sessions from each PE to each other
PE may be ok in theory but rather no-op in practice. Just think 1000 PEs
with 100 ms BFD timers in a full mesh of BFD sessions. Then rethink the
same with  BFD packets maxed to 1500 or 4K bytes packets as per some
proposals floating around.

If we want to move that way I would rather suggest we define a local BFD
anchor explorers (one per area) which will probe all "interesting" next
hops in a given area. Upon failure it would signal to those remote PEs
which indicated interest in such tracking the event of failure.

Again using BFD for this in any form or shape needs to be weighed for
cost/benefit against option 1 and option 2 above.

Thx,
Robert.

PS . Now option 1 can easily be sub second if BFD is enabled on IBGP
sessions between RRs and PEs. However I think there was some concerns
expressed in the past by a vendor for this type of deployment of BFD
between loopbacks. Maybe it would be beneficial for this discussion to
better understand this concern. If valid I think the option 2 which IMO is
the objective of this draft does present a valid problem to be solved.
Today practically speaking networks flood in IGPs globally 1000s of /32
prefixes instead of summarizing them as this is the only way they can
signal liveness of the remote PEs.

On Sat, Nov 14, 2020 at 10:34 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

>   3.1 *Inter-Area Node Failure Scenario – *With respect to this use case,
> the node in question is actually unreachable. In this case, the ABRs will
> normally install a reject route for the advertised summary and will send an
> ICMP unreachable when the packets are received for the unreachable prefix.
> This is the expected behavior and there really isn’t that much of advantage
> to move the point of unreachable detection a couple hops closer. If faster
> detection is required, BFD or other mechanisms are available.
>
>
>
>   3.3 *Intra-Area Node Failure Scenario *– In the first place, multiple
> areas with overlapping summaries is just a bad network design. If the
> prefix is unreachable, the case digresses to getting the ICMP unreachable
> from the ABR with the invalid overlapping summary.
>
>
>
> 3.2 *Inter-Area Links Failure Scenario – *This is the case where the
> prefix is reachable but only through a subset of the area ABRs. This is
> really the only valid use case. IMO, it is better to solve this case with
> intra-area tunnels through the backbone as described in section 6.1. I
> think this is preferable to the complexity proposed in this draft and
> especially section 6. It is “interesting” when non-implementors specify
> implementation details.
>
>
>
> Thanks,
> Acee
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: 王爱俊 <[email-masked]>
Date: Sun, 15 Nov 2020 08:36:52 +0800 (GMT+08:00)

Hi, Acee:
I think Robert have given the good explaination for the purpose of this draft.
The aim of this draft is to improve the service convergence time, which can be notified quickly the failure of underlying network link or node.
BFD is another possible solution, but it requires massive configuration and other costs as that pointed out by Robert.

With PUA, the failure informaiton of link or node will be advertised automatically and quickly. It keeps also the summary behaviour on ABRs to limit the amounts of reachable prefixes advertisment. 

More detail responses are inline below.

Thanks in advance.
Aijun Wang
China Telecom

发件人：Robert Raszuk <[email-masked]>
发送日期：2020-11-15 06:30:20
收件人："Acee Lindem (acee)" <acee=[email-masked]>
抄送人："[email-masked]" <[email-masked]>
主题：Re: [Lsr] Prefix Unreachable Announcement Use Cases
Hi Acee,

> 3.1 Inter-Area Node Failure Scenario – With respect to this use case, the node 
> in question is actually unreachable. In this case, the ABRs will normally install a 
> reject route for the advertised summary and will send an ICMP unreachable when 

And what will the network do with such ICMP unreachable ? Is there some draft I missed where encapsulating PE will choose a path with different tunnel endpoint upon reception of ICMP unreachable message ? 

See the entire idea behind this draft is to trigger faster switchover to other PEs in the case of a multihomed attached site. 

Option 1 - withdraw a service route in BGP. Use aggregate withdraw to speed this up (say withdraw just RDs) 

Option 2 - signal next hop unreachability (aka negative route) of more specific prefix then the aggregate itself. 

While I think just option 1 is ok for the vast majority of services your answer seems to be talking about ICMP unreachable which IMO would not help much with the issue. The proposal is not about failing ... the proposal is about faster connectivity restoration. 

> If faster detection is required, BFD or other mechanisms are available.  

Now running a full mesh of BFD multihop sessions from each PE to each other PE may be ok in theory but rather no-op in practice. Just think 1000 PEs with 100 ms BFD timers in a full mesh of BFD sessions. Then rethink the same with  BFD packets maxed to 1500 or 4K bytes packets as per some proposals floating around. 

If we want to move that way I would rather suggest we define a local BFD anchor explorers (one per area) which will probe all "interesting" next hops in a given area. Upon failure it would signal to those remote PEs which indicated interest in such tracking the event of failure. 

Again using BFD for this in any form or shape needs to be weighed for cost/benefit against option 1 and option 2 above. 

Thx,
Robert. 

PS . Now option 1 can easily be sub second if BFD is enabled on IBGP sessions between RRs and PEs. However I think there was some concerns expressed in the past by a vendor for this type of deployment of BFD between loopbacks. Maybe it would be beneficial for this discussion to better understand this concern. If valid I think the option 2 which IMO is the objective of this draft does present a valid problem to be solved. Today practically speaking networks flood in IGPs globally 1000s of /32 prefixes instead of summarizing them as this is the only way they can signal liveness of the remote PEs. 

On Sat, Nov 14, 2020 at 10:34 PM Acee Lindem (acee) <acee=[email-masked]> wrote:

Speaking as WG member…

  3.1 Inter-Area Node Failure Scenario – With respect to this use case, the node in question is actually unreachable. In this case, the ABRs will normally install a reject route for the advertised summary and will send an ICMP unreachable when the packets are received for the unreachable prefix. This is the expected behavior and there really isn’t that much of advantage to move the point of unreachable detection a couple hops closer. If faster detection is required, BFD or other mechanisms are available.
[WAJ] Please see the explainations above from Robert.
 
  3.3 Intra-Area Node Failure Scenario – In the first place, multiple areas with overlapping summaries is just a bad network design. If the prefix is unreachable, the case digresses to getting the ICMP unreachable from the ABR with the invalid overlapping summary.
[WAJ] It is common, for example, ISIS level1-2 router will announce the default route to the level 1 area. And, also in the OSPF totally stubby area. 
 
3.2 Inter-Area Links Failure Scenario – This is the case where the prefix is reachable but only through a subset of the area ABRs. This is really the only valid use case. IMO, it is better to solve this case with intra-area tunnels through the backbone as described in section 6.1. I think this is preferable to the complexity proposed in this draft and especially section 6. It is “interesting” when non-implementors specify implementation details.
[WAJ] The tunnel soultions described in section 6 is the last resort of the path switch procedure. If we deploy the PUA mechanism, normally the routers within another area will switch automatically to other ABR when it receives the PUA from one ABR.  Only in the critical scenario that described in beginning of section 6, the solution described in section 6.1 or 6.2 will be used.
 
Thanks,
 Acee

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 15 Nov 2020 11:48:51 +0100

Hi Aijun,

As I think what you are proposing overall is useful let me in turn comment
on some of your statements ...

[WAJ] It is common, for example, ISIS level1-2 router will announce the
>> default route to the level 1 area. And, also in the OSPF totally stubby
>> area.
>>
>
Well let's just take OSPF and imagine:

 Area1 --- ABR1 --- Area0 ---ABR2 --- Area2

So you are saying that unreachable should be always flooded/leaked domain
wide. That's news - I was always thinking of this functionality only in the
case when a summary route covering such more specific is present. Default
should not count ... at least I am not sure if this is safe or makes sense
at this point.

[WAJ] The tunnel soultions described in section 6 is the last resort of the
>> path switch procedure. If we deploy the PUA mechanism, normally the routers
>> within another area will switch automatically to other ABR when it receives
>> the PUA from one ABR.  Only in the critical scenario that described in
>> beginning of section 6, the solution described in section 6.1 or 6.2 will
>> be used.
>>
>
I think this is where you are starting to confuse people. In my option this
solution should have nothing to do with selecting which ABR to use to cross
area boundary.

The cases when one ABR has full remote reachability and the other one
partial one in my view are symptoms of a very poorly designed network and
to stretch protocol thin to cover for those mistakes with a patch is not a
good thing.

I would actually trim most use cases leaving just one - to signal remote
service node (ex: PE) going down in the presence of summary route being
advertised from remote area or pop.

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Sun, 15 Nov 2020 21:17:00 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 15, 2020, at 18:49, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 
> As I think what you are proposing overall is useful let me in turn comment on some of your statements ... 
> 
> So you are saying that unreachable should be always flooded/leaked domain wide. That's news - I was always thinking of this functionality only in the case when a summary route covering such more specific is present. Default should not count ... at least I am not sure if this is safe or makes sense at this point. 
[WAJ] The situation is the same. If there is any special situation that is not safe, we can analyze it together.

> I think this is where you are starting to confuse people. In my option this solution should have nothing to do with selecting which ABR to use to cross area boundary. 
[WAJ] This situation may occur when both ABR can’t send PUA messages to divert the traffic and it will apply when the PUA mechanism is not in effect. The last resort for the traffic forwarding.
> 
> The cases when one ABR has full remote reachability and the other one partial one in my view are symptoms of a very poorly designed network and to stretch protocol thin to cover for those mistakes with a patch is not a good thing. 
[WAJ] The situation is not exist from the design or from the beginning. It may appear after some links failure, although it is scarce scenario, we should consider it for completeness.

> 
> I would actually trim most use cases leaving just one - to signal remote service node (ex: PE) going down in the presence of summary route being advertised from remote area or pop. 
> 
[WAJ] Yes, this may be the most useful use case, but the PUA mechanism can also apply to other scenarios. We want to make it one general solution.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 15 Nov 2020 17:44:05 +0100

Hi Aijun,

I would in fact only propose that the presented mechanism is narrowed down
to invalidate BGP (service) routes - in fact their next hops.

The reason being that the moment you make the solution generic, moreover
the moment you want it to be used in RIB and data plane I am afraid you are
running into similar (even if local) deaggregation mechanism like recently
described in RIFT. That would kill all the scalability of advertising
summary routes in the first place and I bet would face lots of opposition.

Thx,
R.

>  [WAJ] Yes, this may be the most useful use case, but the PUA mechanism
can also apply to other scenarios. We want to make it one general solution.

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 15 Nov 2020 11:29:18 -0800

As RIFT chair - I’d like to respond to Robert’ comment -  the example is rather  unfortunate, in RIFT disaggregation is conditional and well contained within its context, it doesn’t  affect overall scalability.

Regards,
Jeff

> On Nov 15, 2020, at 08:44, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 
> I would in fact only propose that the presented mechanism is narrowed down to invalidate BGP (service) routes - in fact their next hops. 
> 
> The reason being that the moment you make the solution generic, moreover the moment you want it to be used in RIB and data plane I am afraid you are running into similar (even if local) deaggregation mechanism like recently described in RIFT. That would kill all the scalability of advertising summary routes in the first place and I bet would face lots of opposition. 
> 
> Thx,
> R.
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 15 Nov 2020 15:01:13 -0500

Robert & Acee

I have been working with Aijun to help clean up the verbiage in the draft
which after IETF 109 will plan to do an update based on feedback.

I will be presenting this draft as well as the passive interface draft
tomorrow morning.

It has been challenging trying to graphically depict Aijun’s goals and
intentions but I have tried my best to do so in the presentation tomorrow
morning.

Kind Regards

Gyan

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 15 Nov 2020 21:03:36 +0100

Jeff,

I was not bringing RIFT's negative routies example as something inherently
negative. I was just pointing it out to illustrate that today's data plane
lookup does not really support "if does not match" checks.

So if you intend to use unreachable prefixes in data plane as result you
need to break summary into as atomic prefixes as your unreachable
advertisement mask.

Hence my recommendation to use IGP to flood unreachable only for the
purpose of control plane (namely BGP paths invalidation).

Cheers,
R.

On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura <[email-masked]>
wrote:

> As RIFT chair - I’d like to respond to Robert’ comment -  the example is
> rather  unfortunate, in RIFT disaggregation is conditional and well
> contained within its context, it doesn’t  affect overall scalability.
>
> Regards,
> Jeff
>

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 15 Nov 2020 12:19:58 -0800

Thanks for clarification Robert, makes sense.

Cheers,
Jeff
On Nov 15, 2020, 12:03 PM -0800, Robert Raszuk <[email-masked]>, wrote:
> Jeff,
>
> I was not bringing RIFT's negative routies example as something inherently negative. I was just pointing it out to illustrate that today's data plane lookup does not really support "if does not match" checks.
>
> So if you intend to use unreachable prefixes in data plane as result you need to break summary into as atomic prefixes as your unreachable advertisement mask.
>
> Hence my recommendation to use IGP to flood unreachable only for the purpose of control plane (namely BGP paths invalidation).
>
> Cheers,
> R.
>
> > On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura <[email-masked]> wrote:

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 16 Nov 2020 11:07:17 +0800

Hi, Robert:

Does the following responses satisfy your concerns If I understand your questions correctly? 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, November 16, 2020 4:04 AM
To: Jeff Tantsura <[email-masked]>
Cc: lsr <[email-masked]>; Aijun Wang <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

Jeff, 

[WAJ] In data plane, the device do still the “match” check, not “does not match” check.  When the router receives the PUA information, it will install one black hole route for a short time. 

[WAJ] When the number of unreachable prefixes is limited(this is the common situation),  Summary Route+PUA is the most efficient solution.

[WAJ]  PUA and “Smart Disaggregation” in RIFT aim to the same problems, but there are some differences:

1.     In RIFT, the parallel node will advertise the detailed prefix when it detects that another node on the same level can’t reach the mentioned prefix. But for PUA, the decision/advertisement is made by the ABR node itself that knows the failure of links/nodes. 

2.     The advertisement information is different. In RIFT, the detail prefix information is advertised(by another node that can reach the failure prefix); in PUA, the detail unreachable prefix information is advertised instead(by the node that can’t reach the failure prefix). 

 After knowing this information, the receiver node can switch the path to send the traffic, or trigger the BGP control plane switchover as you said.

Cheers,

R.

On Sun, Nov 15, 2020 at 8:29 PM Jeff Tantsura <[email-masked] <mailto:[email-masked]> > wrote:

Regards,

Jeff

On Nov 15, 2020, at 08:44, Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

Hi Aijun,

Thx,

R.

_______________________________________________
Lsr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 16 Nov 2020 09:25:24 +0100

> *[WAJ] In data plane, the device do still the “match” check, not “does not
> match” check.  When the router receives the PUA information, it will
> install one black hole route for a short time.*
>

So your idea is that you install route for unreachable prefix to /dev/null
?

And how would that help connectivity restoration ?

Moreover it seems that it will just also prevent any local protection to
locally bypass the failed destination.

Bottom line is that I agree with one problem statement. However IMHO
described actions upon reception of PUA are questionable at best.

Cheers,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 16 Nov 2020 08:45:26 +0000

When the PUA use cases were presented today in the LSR meeting, I made the comment that the RIB interactions for each use case would be different and needed to be specified.
Thanks,
Acee

From: Robert Raszuk <[email-masked]>
Date: Monday, November 16, 2020 at 3:25 AM
To: Aijun Wang <[email-masked]>
Cc: Jeff Tantsura <[email-masked]>, lsr <[email-masked]>, Acee Lindem <[email-masked]>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

So your idea is that you install route for unreachable prefix to /dev/null ?

Moreover it seems that it will just also prevent any local protection to locally bypass the failed destination.

Bottom line is that I agree with one problem statement. However IMHO described actions upon reception of PUA are questionable at best.

Cheers,
R.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 16 Nov 2020 02:35:48 -0800

+1 with Robert.

So you expect the following RIB state after PUA has been advertised:
10.0.0.1 - drop
10/24 - forward 

Unless there’s a recursively discarded next-hop (ala RTBH )  - how do you envision it?

Regards,
Jeff

> On Nov 16, 2020, at 00:25, Robert Raszuk <[email-masked]> wrote:
> 
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 17 Nov 2020 14:20:56 +0800

Hi, Jeff and Robert:

Please see the response inlines.

From: Jeff Tantsura <[email-masked]> 
Sent: Monday, November 16, 2020 6:36 PM
To: Robert Raszuk <[email-masked]>
Cc: Aijun Wang <[email-masked]>; lsr <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

+1 with Robert.

10.0.0.1 - drop

10/24 - forward 

[WAJ] Yes, this is the expected result.

[WAJ] This is the action that the node receives the PUA should do. Existing router may not support it, so we define the PUA capabilities announcement in section-6.3 of this draft <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-04#section-6.3>  

Regards,

Jeff

On Nov 16, 2020, at 00:25, Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

[WAJ] Yes.

[WAJ] This action will trigger the path protection procedures, which will divert the traffic to other backup path.

[WAJ] No, It will trigger the local protection instead, not prevent.

Cheers,
R.

---

From: [email-masked]
Date: Mon, 16 Nov 2020 22:31:12 -0800

>> [WAJ] This action will trigger the path protection procedures, which will divert the traffic to other backup path.

This seems to be making some major assumptions about how path protection features operate. Those assumptions need to be
very explicitly called out.

The path protection features that I’m familiar with are triggered by topological changes along the existing operable path. A PUA
does not provide that.  Rather, it’s something of a temporary signal saying ’this broke’. Without more specifics about the failure, it’s difficult to 
understand exactly what path protection should make of this.  If a prefix is unreachable, the obvious implication is that the associated link has
failed.  Path protection in a remote area is highly unlikely to have the topological details necessary to find an alternate path to that prefix.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 02:51:35 -0500

Tony

I agree.  We have to be careful not to confuse path protection mentioned to
RSVP FRR protection based on TEDs or LFA style local protection.  We will
redo the verbiage carefully to not call use pre-existing terminology term
that will add confusion.

Thanks for the feedback!!

Thanks

Gyan

On Tue, Nov 17, 2020 at 1:31 AM <[email-masked]> wrote:

> *[WAJ] This action will trigger the path protection procedures, which will
> divert the traffic to other backup path.*
>
>
>
> This seems to be making some major assumptions about how path protection
> features operate. Those assumptions need to be
> The path protection features that I’m familiar with are triggered by
> topological changes along the existing operable path. A PUA
> does not provide that.  Rather, it’s something of a temporary signal
> saying ’this broke’. Without more specifics about the failure, it’s
> difficult to
> understand exactly what path protection should make of this.  If a prefix
> is unreachable, the obvious implication is that the associated link has
> failed.  Path protection in a remote area is highly unlikely to have the
> topological details necessary to find an alternate path to that prefix.
>
> Tony
>

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 02:54:28 -0500

Thanks Acee for the feedback.

We will add more detail to the use cases.

Gyan

On Mon, Nov 16, 2020 at 3:45 AM Acee Lindem (acee) <acee=
[email-masked]> wrote:

> When the PUA use cases were presented today in the LSR meeting, I made the
> comment that the RIB interactions for each use case would be different and
> needed to be specified.
>
> Thanks,
>
> Acee
>
>
>
>
>
> *From: *Robert Raszuk <[email-masked]>
> *Date: *Monday, November 16, 2020 at 3:25 AM
> *To: *Aijun Wang <[email-masked]>
> *Cc: *Jeff Tantsura <[email-masked]>, lsr <[email-masked]>, Acee
> Lindem <[email-masked]>
> *Subject: *Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>

-- 

*Gyan Mishra*

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Nov 2020 09:05:59 +0100

> *[WAJ] No, It will trigger the local protection instead, not prevent.*
>
>
You missed my point.

I am talking about *local* protection in a sense of adjacent node(s) to the
PE/ASBR which failed. *Local* to the failure.

You are talking about *local* protection on ingress to the network. Let's
focus on this:

Q1 - You are installing a /dev/null route in a router. That means that any
packet sent to this destination will be dropped. How is this of any
protection ?

Q2 - What you may be actually trying to say is that by installing such PUA
into RIB you will via RIB let know those clients (ex: BGP) which track this
route that it is gone and that their possibly best path is no longer valid.
Sure that is one way to share such information between IGP and BGP. But
this needs to be described in the document that this is your intention.
Otherwise when you say you are installing a drop route in RIB & FIB I am
not sure how helpful that is (well other then transiently relaxing the
network to drop some traffic few router hops away).

Thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 03:20:47 -0500

On Tue, Nov 17, 2020 at 3:06 AM Robert Raszuk <[email-masked]> wrote:

> I am talking about *local* protection in a sense of adjacent node(s) to
> the PE/ASBR which failed. *Local* to the failure.
>

   Robert, I believe the original intention was related to having the data
plane converge quickly when summarization is used and flip so traffic
converges from the Active ABR to the Backup ABR.

   However PUA can be used in the absence of area segmentation within a
single area when a link or node fails to converge the data plane quickly by
sending PUA for the backup path so the active path.

    With the IGP tuned with BFD fast detection on ISIS or OSPF links and
LFA & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks
the convergence is well into sub second.  So for Intra area convergence
with all the optimizations mentioned I am not sure how much faster the data
plane will converge with PUA.

    The  one use case I had mentioned to you in the past a while back is
related to BGP PIC core convergence which I mentioned during the
presentation as you brought up BGP next hop convergence as a use case on
the ML.  So in cases where you run BGP PIC edge and have the pre programmed
backup path best-external add-paths advertised backup paths you are set,
however with BGP PIC core prefix independent convergence with the H-FIB
next hop rib convergence - with next-hop-self rewrite to the loopback, the
loopback never goes down so that does impact iBGP path PIC core
convergence.  So a workaround is to not do next hop self and so when link
goes down its detected and that fixes the issue.  Downside is you now have
a massive LFIB FEC binding database if you have tons of customer edges.  So
I think PUA could help for this but I was trying to connect the dots and I
think there is something missing but maybe we can figure out how PUA can be
leveraged to fix the PIC Core convergence.  I am assuming that is what you
meant on the ML with next hop tracking convergence would be the obvious use
case for PUA.  So the tricky part here is you you can send a PUA when your
PE-CE link goes down and now your H-FIB IGP forwarding plane would now
converge immediately on the alternate PUA path, however you still have
next-hop-self rewrite happening to the loopback which is still Up.  So even
though PUA fixed the Core IGP detection of the PE-CE link failure, it did
not fix the next hop self rewrite to the loopback which is always Up.  I
guess there would be still an improvement with data plane convergence for
the PE-CE with the PUA being sent to converge the BGP next hop when "next
hop self" is not used.  It would be nice if there was some way to make PUA
fix the next-hop-self rewrite to loopback to improve PIC core convergence.
You would need a flag to tie the loopback to the PE-CE connected interfaces
state to be tracked.  I believe you wrote a draft way back that fixes that
issue but was never adopted I believe.  I would have to dig up on ML to
find it.

-- 

*Gyan Mishra*

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Nov 2020 09:36:24 +0100

> converges from the Active ABR to the Backup ABR.

I do not buy this use case. Flooding within the area is fast such that both
ABRs will get the same info. As mentioned before there is no practical use
of PUA for making any routing or fwd decision on which ABR to use. If your
ABRs are not connected with min redundancy this draft is a worst patch ever
to work around such a design.

Please present us a picture indicating before and after ABRs behaviour.

> sending PUA for the backup path so the active path.

If there is no area segmentation then there is no summaries. So what are we
missing in the first place ?

> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA &
> RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the
> convergence is well into sub second.  So for Intra area convergence with
> all the optimizations mentioned I am not sure how much faster the data

Even without any of the above listed chain of acronymous things will
generally work well intra-area without PUAs.

Thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 04:01:46 -0500

On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <[email-masked]> wrote:

> I do not buy this use case. Flooding within the area is fast such that
> both ABRs will get the same info. As mentioned before there is no practical
> use of PUA for making any routing or fwd decision on which ABR to use. If
> your ABRs are not connected with min redundancy this draft is a worst patch
> ever to work around such a design.
>

   Gyan> Agreed.  The point of PUA in ABR use case is the ability to track
the component prefixes and in case where component is down and traffic is
still forwarded to the ABR and dropped.  The other more important use case
is when links are down within the area and the area is partitioned and so
one ABR has all component prefixes however other ABR is missing half the
component prefixes.  So since the ABR will by default advertise the summary
as long as their is one component UP the summary is still advertised.  So
this use case is severely impacting as now you have an ECMP path to the
other area for the summary via the two ABRs and you drop half your
traffic.  So now with PUA the problem is fixed and the PUA is sent and now
traffic is only sent to the ABR that has the component prefixes.

> Please present us a picture indicating before and after ABRs behaviour.

     Gyan> will do

> If there is no area segmentation then there is no summaries. So what are
> we missing in the first place ?
>

    Gyan> Sorry I am stating that PUA feature can also be used intra area
where if a link or node goes down to improve data plane convergence.

>
>
>
>> With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA
>> & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the

    Gyan> Agreed which is why I mentioned the BGP next hop self use case if
I could figure out how PUA could help there that would be a major benefit
of PUA.

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 09:28:44 -0500

On Tue, Nov 17, 2020 at 4:01 AM Gyan Mishra <[email-masked]> wrote:

>>    Robert, I believe the original intention was related to having the
>>> data plane converge quickly when summarization is used and flip so traffic
>     Gyan> Agreed which is why I mentioned the BGP next hop self use case
> if I could figure out how PUA could help there that would be a major
> benefit of PUA.
>

      Gyan>. We could use Aijun’s passive interface new top level TLV to
link the next hop rewrite loopback to the PE-CE links all being set to
passive. So if any PE-CE link goes down a PUA is sent and the next hop
converges PIC core PE-CE link which is now associated with the Loopback.
This would be a major benefit of PUA for PIC core convergence when
next-hop-self is used which applies to MPLS and SR and IP based core.

https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/

So the two main critical  use cases where this solution solves a problem is
partitioned area scenario and nest hop convergence when next-hop-self is
used scenario.

I will update the presentation deck and share.

*Gyan Mishra*

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Nov 2020 15:42:54 +0100

Hi Gyan,

> next-hop-self is used which applies to MPLS and SR and IP based core.

I have read the above three sentences five times and came with two basic
observations:

* You are mixing PIC Core with PIC Edge - Please do not. Those are
completely separate features and it is a feature not a bug to keep them
that way.

* You are mixing external PE-CE interfaces with IGP passive interfaces -
Please do not. There should be no IGP flooding of any sort associated with
state of PE-CE interface. No need.

Thx a lot,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 Nov 2020 14:43:53 +0000

Speaking as WG member:

I think it would be good to hone in on the BGP PE failure convergence use case as suggested by Robert. It seems there is some interest here although I’m not convinced the IGP is the right place to solve this problem.

Thanks,
Acee

From: Lsr <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Tuesday, November 17, 2020 at 4:02 AM
To: Robert Raszuk <[email-masked]>
Cc: lsr <[email-masked]>, Jeff Tantsura <[email-masked]>, Aijun Wang <[email-masked]>, "Acee Lindem (acee)" <acee=[email-masked]>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

   Robert, I believe the original intention was related to having the data plane converge quickly when summarization is used and flip so traffic converges from the Active ABR to the Backup ABR.

I do not buy this use case. Flooding within the area is fast such that both ABRs will get the same info. As mentioned before there is no practical use of PUA for making any routing or fwd decision on which ABR to use. If your ABRs are not connected with min redundancy this draft is a worst patch ever to work around such a design.

   Gyan> Agreed.  The point of PUA in ABR use case is the ability to track the component prefixes and in case where component is down and traffic is still forwarded to the ABR and dropped.  The other more important use case is when links are down within the area and the area is partitioned and so one ABR has all component prefixes however other ABR is missing half the component prefixes.  So since the ABR will by default advertise the summary as long as their is one component UP the summary is still advertised.  So this use case is severely impacting as now you have an ECMP path to the other area for the summary via the two ABRs and you drop half your traffic.  So now with PUA the problem is fixed and the PUA is sent and now traffic is only sent to the ABR that has the component prefixes.

     Gyan> will do

   However PUA can be used in the absence of area segmentation within a single area when a link or node fails to converge the data plane quickly by sending PUA for the backup path so the active path.

If there is no area segmentation then there is no summaries. So what are we missing in the first place ?

    Gyan> Sorry I am stating that PUA feature can also be used intra area where if a link or node goes down to improve data plane convergence.

With the IGP tuned with BFD fast detection on ISIS or OSPF links and LFA & RLFA for MPLS or TI-LFA for SR local protection - with those tweaks the convergence is well into sub second.  So for Intra area convergence with all the optimizations mentioned I am not sure how much faster the data plane will converge with PUA.

Even without any of the above listed chain of acronymous things will generally work well intra-area without PUAs.

    Gyan> Agreed which is why I mentioned the BGP next hop self use case if I could figure out how PUA could help there that would be a major benefit of PUA.

Thx,
R.

--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 14:09:32 -0500

Agreed.

Robert

Can you explain the BGP scenario you had in mind that you have mentioned a
number of times that you think this PUA feature would pertain?

I will respond to your other email separately.  I was trying to guess  as
to the BGP next hop use case you were referring to but apparently was way
off.

Thank you

Gyan

On Tue, Nov 17, 2020 at 9:43 AM Acee Lindem (acee) <[email-masked]> wrote:

> Speaking as WG member:
>
>
>
> I think it would be good to hone in on the BGP PE failure convergence use
> case as suggested by Robert. It seems there is some interest here although
> I’m not convinced the IGP is the right place to solve this problem.
>
>
>
> Thanks,
>
> Acee
>
>
>
> *From: *Lsr <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Tuesday, November 17, 2020 at 4:02 AM
> *To: *Robert Raszuk <[email-masked]>
> *Cc: *lsr <[email-masked]>, Jeff Tantsura <[email-masked]>, Aijun
> Wang <[email-masked]>, "Acee Lindem (acee)" <acee=
> [email-masked]>
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
> *Silver Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 15:31:33 -0500

> completely separate features and it is a feature not a bug to keep them

   Gyan> Sorry for the confusion. I agree we are not taking BGP PIC core
which is H-FIB core feature for core failures resulting in IGP next hop
update.  Also we are not talking about BGP PIC edge pre programmed backup
paths.  What I was trying to address is use of PUA to resolve a issue with
BGP convergence related to using BCP use of next hop self rewrite so PE-CE
link next hops do not have to be flooded into the IGP.  Down side of
next-hop-self is for convergence in the core from edge failure, the edge
failure is not detected and you have to wait for route to be withdrawn. So
I was thinking maybe PUA data plane convergence mechanism would be a way to
help with convergence.  Not sure how or if possible but was thinking that
as a possible use case for PUA.

> state of PE-CE interface. No need.

    Understood.  Bad idea.

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 15:40:19 -0500

Robert

I am recalling now the BGP use case you mentioned.

If the next hop is being summarized between areas which it would be, the
next hop failure component prefix is now hidden in the summary and now you
have to wait for BGP timer to pop and route withdrawal.

So for this failure scenario one option is multihop BFD but that does get
way complicated.

So here the obvious and best use case for PUA would be for the data plane
detection of the next hop component down at which time PUA is sent flooded
and the routers in the other area now set next hop to null for that next
hop and are forced to converge on alternate next hop.

Let me update the presentation to add this use case.

Thanks

Gyan

On Tue, Nov 17, 2020 at 2:09 PM Gyan Mishra <[email-masked]> wrote:

>>    Gyan> Agreed.  The point of PUA in ABR use case is the ability to
>> track the component prefixes and in case where component is down and
>> traffic is still forwarded to the ABR and dropped.  The other more
>> important use case is when links are down within the area and the area is
>> partitioned and so one ABR has all component prefixes however other ABR is
>> missing half the component prefixes.  So since the ABR will by default
>> advertise the summary as long as their is one component UP the summary is
>> still advertised.  So this use case is severely impacting as now you have
>> an ECMP path to the other area for the summary via the two ABRs and you
>> drop half your traffic.  So now with PUA the problem is fixed and the PUA
>> is sent and now traffic is only sent to the ABR that has the component
>> prefixes.
>>
>>
>>

*Gyan Mishra*

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 17 Nov 2020 23:31:35 +0100

Yes that is the case where I see some potential use case.

Especially considering also https://tools.ietf.org/html/rfc5283 - which by
many network operators is very desired, but not configured due to "slow BGP
convergence" - pls let's not go there :)

But again if someone knows how to configure BGP properly I think IGP
speedup would be marginal or even null hence a grain of hesitation if we
should use IGP flooding for it. Maybe in some scenarios ... which PUA
authors need to spell out to move fwd I suppose.

Cheers,
R.

On Tue, Nov 17, 2020 at 9:40 PM Gyan Mishra <[email-masked]> wrote:

>> Can you explain the BGP scenario you had in mind that you have mentioned
>> a number of times that you think this PUA feature would pertain?
>>
>>> I think it would be good to hone in on the BGP PE failure convergence
>>> use case as suggested by Robert. It seems there is some interest here
>>> although I’m not convinced the IGP is the right place to solve this problem.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Acee
>>>
>>>
>>>
>>> *Cc: *lsr <[email-masked]>, Jeff Tantsura <[email-masked]>,
>>> Aijun Wang <[email-masked]>, "Acee Lindem (acee)" <acee=
>>>     Gyan> Sorry I am stating that PUA feature can also be used intra
>>> area where if a link or node goes down to improve data plane convergence.
>>>
>>>
>>>
>>>
>>>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 17 Nov 2020 17:44:44 -0500

Thanks Robert!

I will work on spelling out the scenario in updated LSR presentation.

Thanks

Gyan
On Tue, Nov 17, 2020 at 5:31 PM Robert Raszuk <[email-masked]> wrote:

> Especially considering also https://tools.ietf.org/html/rfc5283 - which
> by many network operators is very desired, but not configured due to "slow
> BGP convergence" - pls let's not go there :)
>
>>> I will respond to your other email separately.  I was trying to guess
>>>  as to the BGP next hop use case you were referring to but apparently was
>>> way off.
>>>
>>> Thank you
>>>
>>> Gyan
>>>
>>>>     Gyan> Agreed which is why I mentioned the BGP next hop self use
>>>> case if I could figure out how PUA could help there that would be a major
>>>> benefit of PUA.
>>>>
>>>>
>>>>
>>>> Thx,
>>>> R.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>> *Silver Spring, MD
>>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>>
>>>>
>>>>
>>> --
>>>
>>> *M 301 502-134713101 Columbia Pike
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g> *Silver
>>> Spring, MD
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+%0D%0A+Silver+Spring,+MD?entry=gmail&source=g>
>>>
>>> --
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

*Gyan Mishra*

---

From: Huzhibo <[email-masked]>
Date: Wed, 18 Nov 2020 02:36:31 +0000

Hi Tony:

In fact, this protection use case protects the SRv6 mid-point. https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/. When the SRv6 mid-point fails, the PLR node can perform the next SID operation, which is triggered by FIB miss. However, if there is a summary or default route in the area, FIB Miss cannot be triggered.

Thanks

Zhibo

From: Lsr [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, November 17, 2020 2:31 PM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; Jeff Tantsura <[email-masked]>; Robert Raszuk <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

Tony

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 17 Nov 2020 19:33:59 -0800

We have been discussing for quite some time and in different wg's (there’s IX with RS use case) BFD verification based on next-hop extraction, Robert - you should know. (also built a well working prototype in previous life).

Very simple logic:

Upon route import (BGP update received and imported), extract next-hop, walk BFD session table, if no match (no existing session) - establish (S)BFD session (Discriminators distribution is a solved problem) to the next-hop, associate fate of all routes received from it, keep timers reasonable to prevent false positives.

State is limited to PE’s importing each others routes (sharing a service) only
High degree of automation
No IGP pollution

Cheers,
Jeff
On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) <[email-masked]>, wrote:
> > quote_type
> > > quote_type
> > quote_type
> > quote_type
> > > quote_type
> > quote_type
> > > quote_type
> > quote_type
> <>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 18 Nov 2020 08:38:11 +0100

Hi Zhibo,

> However, if there is a summary or default route in the area, FIB Miss
cannot be triggered.

If PUA is a /dev/null route this is not a FIB miss. It's a FIB hit.

Thx,
R.

On Wed, Nov 18, 2020 at 3:36 AM Huzhibo <[email-masked]> wrote:

> Hi Tony:
>
>
>
> In fact, this protection use case protects the SRv6 mid-point.
> https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/.
> When the SRv6 mid-point fails, the PLR node can perform the next SID
> operation, which is triggered by FIB miss. However, if there is a summary
> or default route in the area, FIB Miss cannot be triggered.
>
>
>
> Thanks
>
>
>
> Zhibo
>
>
>
> *From:* Lsr [mailto:[email-masked]] *On Behalf Of [email-masked]
> *Sent:* Tuesday, November 17, 2020 2:31 PM
> *To:* Aijun Wang <[email-masked]>
> *Cc:* lsr <[email-masked]>; Jeff Tantsura <[email-masked]>; Robert
> Raszuk <[email-masked]>; Acee Lindem (acee) <acee=
> *Subject:* Re: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 18 Nov 2020 08:48:38 +0100

Jeff,

Please notice that WAN is not an IX.

While you can have full mesh of BFD sessions among all IXP participants
each bombarding each over over TB fabric every 100 ms or so to map the same
over global WAN is a different game. If nothing else RTT between IXP
participants in healthy IX is around 1 ms while RTT between PEs distributed
globally is often 100-200 ms.

Just imagine 1000 PEs in 10 areas distributed all over the world. That
means that in worst case scenario (say same mgmt VPN present on each PE)
you will establish 1000*999 BFD sessions. Now for this to make sense timer
needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will
defeat the purpose as BGP withdraw will be faster.

Then we go into queuing issues. If BFD packets are queued at any interface
meltdowns may occur which can be far worse in consequences then waiting for
BGP service route removal. Such meltdowns often result in cascading effects
to the applications itself.

So this is not at all about autodiscovery with which address to setup the
BFD session. It is much more about operational aspects of going that
direction.

With that I am supportive of this work even if we label it as experimental
for some time. As each network is different what is optimal solution for
one design and deployment may not be optimal for the other.

Many thx,
Robert

On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura <[email-masked]>
wrote:

> We have been discussing for quite some time and in different wg's (there’s
> IX with RS use case) BFD verification based on next-hop extraction, Robert
> - you should know. (also built a well working prototype in previous life).
>
> Very simple logic:
>
> Upon route import (BGP update received and imported), extract next-hop,
> walk BFD session table, if no match (no existing session) - establish
> (S)BFD session (Discriminators distribution is a solved problem) to the
> next-hop, associate fate of all routes received from it, keep timers
> reasonable to prevent false positives.
>
> *From:* Lsr <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date:* Tuesday, November 17, 2020 at 4:02 AM
> *To:* Robert Raszuk <[email-masked]>
> *Cc:* lsr <[email-masked]>, Jeff Tantsura <[email-masked]>, Aijun
> <> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *M 301 502-1347 13101 Columbia Pike * Silver Spring, MD
>
>
>
>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 18 Nov 2020 16:05:30 +0800

Hi, Robert:

The trigger and propagation of PUA info can be standardized, the actions based on the PUA can be different in different situation. 

We can discuss and describe the actions based on different scenarios after its WG adoption?

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk <[email-masked]> 
Sent: Wednesday, November 18, 2020 3:49 PM
To: Jeff Tantsura <[email-masked]>
Cc: Gyan Mishra <[email-masked]>; Acee Lindem (acee) <[email-masked]>; lsr <[email-masked]>; Aijun Wang <[email-masked]>; Acee Lindem (acee) <acee=[email-masked]>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

Jeff,

While you can have full mesh of BFD sessions among all IXP participants each bombarding each over over TB fabric every 100 ms or so to map the same over global WAN is a different game. If nothing else RTT between IXP participants in healthy IX is around 1 ms while RTT between PEs distributed globally is often 100-200 ms. 

Just imagine 1000 PEs in 10 areas distributed all over the world. That means that in worst case scenario (say same mgmt VPN present on each PE) you will establish 1000*999 BFD sessions. Now for this to make sense timer needs to be 100 ms or so with 3x or 5x multiplier. Anything slower will defeat the purpose as BGP withdraw will be faster. 

Then we go into queuing issues. If BFD packets are queued at any interface meltdowns may occur which can be far worse in consequences then waiting for BGP service route removal. Such meltdowns often result in cascading effects to the applications itself. 

So this is not at all about autodiscovery with which address to setup the BFD session. It is much more about operational aspects of going that direction. 

With that I am supportive of this work even if we label it as experimental for some time. As each network is different what is optimal solution for one design and deployment may not be optimal for the other. 

Many thx,

Robert

On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura <[email-masked] <mailto:[email-masked]> > wrote:

Very simple logic:

Cheers, 

Jeff

On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> >, wrote:

Speaking as WG member:

Thanks,

Acee

From: Lsr <[email-masked] <mailto:[email-masked]> > on behalf of Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Date: Tuesday, November 17, 2020 at 4:02 AM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Cc: lsr <[email-masked] <mailto:[email-masked]> >, Jeff Tantsura <[email-masked] <mailto:[email-masked]> >, Aijun Wang <[email-masked] <mailto:[email-masked]> >, "Acee Lindem (acee)" <acee=[email-masked] <mailto:[email-masked]> >
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

On Tue, Nov 17, 2020 at 3:36 AM Robert Raszuk <[email-masked] <mailto:[email-masked]> > wrote:

     Gyan> will do 

 

Thx,
R.

--

 <http://www.verizon.com/> <>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 18 Nov 2020 16:42:15 +0000

Speaking as WG Co-Chair:

From: Aijun Wang <[email-masked]>
Date: Wednesday, November 18, 2020 at 3:05 AM
To: Robert Raszuk <[email-masked]>, Jeff Tantsura <[email-masked]>
Cc: 'Gyan Mishra' <[email-masked]>, Acee Lindem <[email-masked]>, 'lsr' <[email-masked]>, "'Acee Lindem (acee)'" <acee=[email-masked]>
Subject: RE: [Lsr] Prefix Unreachable Announcement Use Cases

Hi, Robert:

There will be no adoption call until there is a coherent draft with use case(s) and viable actions.

Thanks,
Acee

Best Regards

Aijun Wang
China Telecom

Jeff,

Many thx,
Robert

On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
We have been discussing for quite some time and in different wg's (there’s IX with RS use case) BFD verification based on next-hop extraction, Robert - you should know. (also built a well working prototype in previous life).

Very simple logic:

Cheers,
Jeff
On Nov 17, 2020, 6:43 AM -0800, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>, wrote:

Speaking as WG member:

Thanks,
Acee

From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 17, 2020 at 4:02 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: lsr <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Aijun Wang <[email-masked]<mailto:[email-masked]>>, "Acee Lindem (acee)" <acee=[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

     Gyan> will do

Thx,
R.

--

<><http://www.verizon.com/>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 19 Nov 2020 10:37:37 +0800

Hi, Acee:

OK, we will try to improve this document to meet this criteria. 

And, as this topic has been discussed intensely on the mail list, we are also eager to invite more interested experts to join us as co-authors to refine the solutions for more scenarios.

Thanks in advance.

Best Regards

Aijun Wang

China Telecom

From: Acee Lindem (acee) <[email-masked]> 
Sent: Thursday, November 19, 2020 12:42 AM
To: Aijun Wang <[email-masked]>; 'Robert Raszuk' <[email-masked]>; 'Jeff Tantsura' <[email-masked]>
Cc: 'Gyan Mishra' <[email-masked]>; 'lsr' <[email-masked]>; 'Acee Lindem (acee)' <acee=[email-masked]>
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

Speaking as WG Co-Chair:

From: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Date: Wednesday, November 18, 2020 at 3:05 AM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >, Jeff Tantsura <[email-masked] <mailto:[email-masked]> >
Cc: 'Gyan Mishra' <[email-masked] <mailto:[email-masked]> >, Acee Lindem <[email-masked] <mailto:[email-masked]> >, 'lsr' <[email-masked] <mailto:[email-masked]> >, "'Acee Lindem (acee)'" <acee=[email-masked] <mailto:acee=[email-masked]> >
Subject: RE: [Lsr] Prefix Unreachable Announcement Use Cases

Hi, Robert:

Thanks,

Acee

Best Regards

Aijun Wang

China Telecom

From: Robert Raszuk <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, November 18, 2020 3:49 PM
To: Jeff Tantsura <[email-masked] <mailto:[email-masked]> >
Cc: Gyan Mishra <[email-masked] <mailto:[email-masked]> >; Acee Lindem (acee) <[email-masked] <mailto:[email-masked]> >; lsr <[email-masked] <mailto:[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; Acee Lindem (acee) <acee=[email-masked] <mailto:acee=[email-masked]> >
Subject: Re: [Lsr] Prefix Unreachable Announcement Use Cases

Jeff,

Many thx,

Robert

Very simple logic:

Cheers, 

Jeff

Speaking as WG member:

Thanks,

Acee

 

 

     Gyan> will do 

 

Thx,
R.

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Nov 2020 21:27:57 -0500

Aijun

I am thinking per the feedback received let’s keep it really simple.  We
need a solid use case to move the ball forward were the PUA data plane
convergence capabilities can fills a gap that exists today.

I have two simple solutions to start that I will update the presentation
with to start and present to the WG and we can go from there.

1.  BGP NH tracking via PUA of NH component prefix to converge the data
plane

2.  Area partitioned scenario where PUA is used for data plane convergence
to ABR that has reachability to component prefixes.

I will send out tomorrow.

Thanks

Gyan

On Wed, Nov 18, 2020 at 9:37 PM Aijun Wang <[email-masked]>
wrote:

> And, as this topic has been discussed intensely on the mail list, we are
> also eager to invite more interested experts to join us as co-authors to
> refine the solutions for more scenarios.
>
>
>
> Thanks in advance.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
>
>
> *From:* Acee Lindem (acee) <[email-masked]>
> *Sent:* Thursday, November 19, 2020 12:42 AM
> *To:* Aijun Wang <[email-masked]>; 'Robert Raszuk' <
> [email-masked]>; 'Jeff Tantsura' <[email-masked]>
> *Cc:* 'Gyan Mishra' <[email-masked]>; 'lsr' <[email-masked]>; 'Acee
> Lindem (acee)' <acee=[email-masked]>
> *From: *Aijun Wang <[email-masked]>
> *Date: *Wednesday, November 18, 2020 at 3:05 AM
> *To: *Robert Raszuk <[email-masked]>, Jeff Tantsura <
> [email-masked]>
> *Cc: *'Gyan Mishra' <[email-masked]>, Acee Lindem <[email-masked]>,
> 'lsr' <[email-masked]>, "'Acee Lindem (acee)'" <
> acee=[email-masked]>
> *Subject: *RE: [Lsr] Prefix Unreachable Announcement Use Cases
>
>
>
> Hi, Robert:
>
>
>
> The trigger and propagation of PUA info can be standardized, the actions
> based on the PUA can be different in different situation.
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Wednesday, November 18, 2020 3:49 PM
> *To:* Jeff Tantsura <[email-masked]>
> *Cc:* Gyan Mishra <[email-masked]>; Acee Lindem (acee) <
> [email-masked]>; lsr <[email-masked]>; Aijun Wang <[email-masked]>;
> Acee Lindem (acee) <acee=[email-masked]>
> case as suggested by Robert. It seems there is some interest here although I
> ’m not convinced the IGP is the right place to solve this problem.
>
>
>
> Thanks,
>
> Acee
>
>
>
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
> --

*Gyan Mishra*

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Nov 2020 09:03:06 +0100

Gyan,

I like and support your use case #1

For use case #2 I have doubts. Imagine indeed an area which get's
partitioned such that ABR will loose connectivity to bunch of nodes. Does
this mean that now such ABR will be blasting globally perhaps 1000s of PUAs
? How would the ABR be able to send PUA summary provided some disconnected
POPs within area could be nicely summarized ? Isn't it better to design
your area such that ABRs are interconnected with redundancy ?

Thx,
R.

On Fri, Nov 20, 2020 at 3:28 AM Gyan Mishra <[email-masked]> wrote:

>> [email-masked]>; lsr <[email-masked]>; Aijun Wang <
>> [email-masked]>; Acee Lindem (acee) <
>> Then we go into queuing issues. If BFD packets are queued at any
>> interface meltdowns may occur which can be far worse in consequences then
>> waiting for BGP service route removal. Such meltdowns often result in
>> cascading effects to the applications itself.
>>
>>
>>
>> With that I am supportive of this work even if we label it as
>> experimental for some time. As each network is different what is optimal
>> solution for one design and deployment may not be optimal for the other.
>>
>>
>>
>> Many thx,
>>
>> Robert
>>
>>
>>
>>
>>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Nov 2020 03:42:54 -0500

Robert

Let me send it over graphical depiction as a picture is worth a thousand
words should be easy to see the concept.

Trying to keep as simple as possible.

Thanks

Gyan

On Fri, Nov 20, 2020 at 3:03 AM Robert Raszuk <[email-masked]> wrote:

>> 2.  Area partitioned scenario where PUA is used for data plane
>> convergence to ABR that has reachability to component prefixes.
>>
>>> *Cc:* 'Gyan Mishra' <[email-masked]>; 'lsr' <[email-masked]>;
>>> 'Acee Lindem (acee)' <acee=[email-masked]>
>>> So this is not at all about autodiscovery with which address to
>>> setup the BFD session. It is much more about operational aspects of going
>>> that direction.
>>>
>>>
>>>
>>> We have been discussing for quite some time and in different wg's (there
>>> ’s IX with RS use case) BFD verification based on next-hop extraction,
>>> Robert - you should know. (also built a well working prototype in previous
>>> life).
>>>
>>> Very simple logic:
>>>
>>> *Cc:* lsr <[email-masked]>, Jeff Tantsura <[email-masked]>,
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+Silver+Spring,+MD?entry=gmail&source=g> *Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

*Gyan Mishra*

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 20 Nov 2020 01:44:45 -0800

Yes, acknowledging the idea of negative disaggregation is inspired by RIFT
work is fine (and normally, when inspired by an idea at least in research
cycles it is considered basic courtesy to refer to the according source,
something has been lost more and more in IETF over time I dare to observe
which in itself reflects on the community IMO) but please do not try to
compare the two beyond that. Disaggregation works well on directed graphs
(lattices) or arguably if your addressing scheme is aligned with regular
topology (hypercube e.g.). it works in generic graphs in super special
cases only & it will be @ best a crutch that may under all the correct
circumstances have some utility but probably ends up hurting operationally
more than helping. The indication that "magic timer" is needed in the draft
should be first warning, all kind of seat-of-pants heuristics to dis- and
re-aggregate 2nd.  Just quickly flying through the draft I see lots of
logic problems already that will lead to vexing effects, e.g. indication of
missing neighbor will work in specific type of topologies, in others
varying by one link only may lead to stable blackholes.

my 2c

-- tony

---

From: Aijun Wang <[email-masked]>
Date: Fri, 20 Nov 2020 22:27:22 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Nov 20, 2020, at 17:45, Tony Przygienda <[email-masked]> wrote:
> 
> 
> Yes, acknowledging the idea of negative disaggregation is inspired by RIFT work is fine (and normally, when inspired by an idea at least in research cycles it is considered basic courtesy to refer to the according source, something has been lost more and more in IETF over time I dare to observe which in itself reflects on the community IMO) but please do not try to compare the two beyond that.
[WAJ] PUA has no relation with RIFT. I have not yet study what’s problem it encountered, but welcome the experts have such design experience to point out the pitfall that PUA can bypass.

> Disaggregation works well on directed graphs (lattices) or arguably if your addressing scheme is aligned with regular topology (hypercube e.g.). it works in generic graphs in super special cases only & it will be @ best a crutch that may under all the correct circumstances have some utility but probably ends up hurting operationally more than helping.
[WAJ] PUA will try to avoid the solution that can only fit some special topology or address schema.

> The indication that "magic timer" is needed in the draft should be first warning, all kind of seat-of-pants heuristics to dis- and re-aggregate 2nd. 

[WAJ] “timer” is not uncommon in IGP protocol. Using it within PUA mechanism is just to assure the service switch successfully upon it receives the PUA.

> Just quickly flying through the draft I see lots of logic problems already that will lead to vexing effects, e.g. indication of missing neighbor will work in specific type of topologies, in others varying by one link only may lead to stable blackholes. 
[WAJ] Would you like to state the above conclusion more clearly?

> 
> my 2c
> 
> -- tony 
> 
>> On Sun, Nov 15, 2020 at 11:29 AM Jeff Tantsura <[email-masked]> wrote:

---

From: Aijun Wang <[email-masked]>
Date: Fri, 20 Nov 2020 22:48:00 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Nov 20, 2020, at 16:10, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Gyan,
> 
> For use case #2 I have doubts. Imagine indeed an area which get's partitioned such that ABR will loose connectivity to bunch of nodes. Does this mean that now such ABR will be blasting globally perhaps 1000s of PUAs ? How would the ABR be able to send PUA summary provided some disconnected POPs within area could be nicely summarized ?
[WAJ] If ABR can do PUA summary, it is certainly better.  Or else, send the “PUA+Summary” for failure prefixes or send the “detailed reachable information-summary“ for connected prefixes, depend which one is less. Do you have other proposals?

> Isn't it better to design your area such that ABRs are interconnected with redundancy ? 

[WAJ] Such requirement is certainly reasonable, but it still can’t avoid the extreme situation. 

>> I am thinking per the feedback received let’s keep it really simple.  We need a solid use case to move the ball forward were the PUA data plane convergence capabilities can fills a gap that exists today. 
>> 
>> I have two simple solutions to start that I will update the presentation with to start and present to the WG and we can go from there.
>> 
>> 1.  BGP NH tracking via PUA of NH component prefix to converge the data plane
>> 
>> 2.  Area partitioned scenario where PUA is used for data plane convergence to ABR that has reachability to component prefixes.  
>> 
>>> On Wed, Nov 18, 2020 at 9:37 PM Aijun Wang <[email-masked]> wrote:
>>> Hi, Acee:
>>> 
>>>  
>>> 
>>> On Wed, Nov 18, 2020 at 4:34 AM Jeff Tantsura <[email-masked]> wrote:
>>>

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 20 Nov 2020 12:08:38 -0800

On Fri, Nov 20, 2020 at 6:27 AM Aijun Wang <[email-masked]>
wrote:

> compare the two beyond that.
>
> [WAJ] PUA has no relation with RIFT. I have not yet study what’s problem
> it encountered, but welcome the experts have such design experience to
> point out the pitfall that PUA can bypass.
>
>
aha, ok, I just chimed in because I saw people somehow implying a map of
RIFT negative disaggregation in relation to this work but if this is a
completely different mechanism than I just watch from the sidelines

thanks

-- tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 20 Nov 2020 21:45:12 +0100

Hey Tony,

>  people somehow implying a map of RIFT negative disaggregation in
relation to this work

I think those people just made a subtle point that considering IGP alone if
you want to influence your data plane forwarding by advertising PUA in
today's hardware you really need to install more specific blocks of the
summary routes which PUA punched the hole in as sent by say one of the
ABR's. Analogy made to RIFT was just limited to this data plane fragment
only.

And that comment was not to compare PUA to RIFT negative routing in any
way. It was just to a) realize what could be required if such a use case
continues and more importantly b) highlight that if we just use PUA in the
control plane to for example invalidate BGP next hops or other overlay
service routes the disaggregation piece does not apply.

Cheers,
R.

On Fri, Nov 20, 2020 at 9:09 PM Tony Przygienda <[email-masked]> wrote:

>> Yes, acknowledging the idea of negative disaggregation is inspired by
>> RIFT work is fine (and normally, when inspired by an idea at least in
>> research cycles it is considered basic courtesy to refer to the according
>> source, something has been lost more and more in IETF over time I dare to
>> observe which in itself reflects on the community IMO) but please do not
>> try to compare the two beyond that.
>>

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 20 Nov 2020 13:02:08 -0800

Yeah, so to give e'one his due, negative disaggregation is Pascal's
brilliant brain-child, I bow to this. And I bow to his patience grinding me
down to convince me the complexity of it is by far outweighted by elegance
it brings to ugly failure repair. Then it took a lot of brow-beating until
e'one on RIFT understood that no, we will not get negative entry silicon
and hence need to remap negative to proper resolution as positive. Not the
simplest things but once you implemented it it turns out simpler than it
looks @ first

my 2c, I'll be watching here from a distance probably until it gelled a bit
more

-- tony

On Fri, Nov 20, 2020 at 12:45 PM Robert Raszuk <[email-masked]> wrote:

> I think those people just made a subtle point that considering IGP alone
> if you want to influence your data plane forwarding by advertising PUA in