Subject: [Lsr] Comments on "Prefix Unreachable Announcement" - draft-wang-lsr-prefix-unreachable-annoucement

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 29 Jul 2021 23:02:16 +0000

Speaking as WG member:

Authors,

I have comments and questions on the draft – many of them that I have raised before.

  1.  If you use the standard advertisements and overload the prefix-originator information, all the routers in the domain will need to support it and you will have a fork lift upgrade. Otherwise, the ABRs which don’t advertise a prefix unreachable will actually attract traffic from down level routers. I’ve raised this several times in the past.
  2.  How do you know what prefixes to protect with this PUA mechanism? Is it any prefix you’ve seen in the past? What if the prefix is actually taken out of service? What if it was a misconfiguration? What if the prefix is unreachable when the ABR IGP is started?
  3.  The forwarding plane behavior is non-standard? How does it work? This is clearly under specified.
  4.  This is somewhat minor compared to the other comments, in section 6 both conditions 1 and 2 can be true at the same time. In the event the other comments are resolved, this section needs some work.

Thanks,
Acee

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 29 Jul 2021 21:13:05 -0400

Hi Acee

Answers in-line

On Thu, Jul 29, 2021 at 7:02 PM Acee Lindem (acee) <acee=
[email-masked]> wrote:

>    1. If you use the standard advertisements and overload the
>    prefix-originator information, all the routers in the domain will need to
>    support it and you will have a fork lift upgrade. Otherwise, the ABRs which
>    don’t advertise a prefix unreachable will actually attract traffic from
>    down level routers. I’ve raised this several times in the past.
>
>        Gyan> Yes to use the PUA feature all nodes must be upgraded.

Section 7 has been updated to reflect.

7 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7>.
Deployment Considerations

   To support the PUA advertisement, the ABRs should be upgraded
   according to the procedures described in Section 4
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-4>.

>    1.
>    2. How do you know what prefixes to protect with this PUA mechanism?
>    Is it any prefix you’ve seen in the past? What if the prefix is actually
>    taken out of service? What if it was a misconfiguration? What if the prefix
>    is unreachable when the ABR IGP is started?
>
> So the main scenario this is used for is RFC 5283  inter area LDP
extension for LPM match instead for MPLS standard exact match for FEC.  For
this MPLS scenario where the operators had carved core AS into multiple
areas or levels.  So the BGP next hop attribute update source loop0 is what
we are tracking that is summarized so when the egress PE goes down the LSP
now does not black hole on the ABR and the control plane convergence occurs
with the PUA mechanism and forces the LSP to get built to the alternate
PE.  In this scenario and maybe even others the PUA is being used to track
the next hop and force the failover. This solution can apply as well to non
MPLS, IP based scenario BGP next hop convergence to trigger the control
plane convergence with PUA negative advertisement so can also apply to SRv6.

>    1.
>    2. The forwarding plane behavior is non-standard? How does it work?
>    This is clearly under specified
>
> There is no change to the data plane forwarding
 behavior.  The change is with the control plane to set the next hop
loopback from the down PE that no longer in the RIB/FIB to null so the
control plane converges on the alternate next hop.  When the control plane
convergence occurs based on the PUA negative advertisement the data plane
follows and the RIB/FIB get programmed as they would normally.

>    1. .
>    2. This is somewhat minor compared to the other
>
>

>    1. comments, in section 6 both conditions 1 and 2 can be true at the
>    same time. In the event the other comments are resolved, this section needs
>    some work.
>
>  We would make #1 less then or equal to do both conditions can never be
> true simultaneously in the next update.
>
> Thanks,
> Acee
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 30 Jul 2021 01:40:19 +0000

Hi Gyan,

From: Gyan Mishra <[email-masked]>
Date: Thursday, July 29, 2021 at 9:13 PM
To: Acee Lindem <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Lsr] Comments on "Prefix Unreachable Announcement" - draft-wang-lsr-prefix-unreachable-annoucement

Hi Acee

Answers in-line

On Thu, Jul 29, 2021 at 7:02 PM Acee Lindem (acee) <acee=[email-masked]<mailto:[email-masked]>> wrote:
Speaking as WG member:

Authors,

7<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7>.  Deployment Considerations

   according to the procedures described in Section 4<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-4>.

This just says the ABRs need to be upgraded. I’m saying all the routers need to be upgraded since any router in the path misinterpreting the PUA and actually installing it as a positive route could result in a blackhole or worse, a loop.

1.

2.   How do you know what prefixes to protect with this PUA mechanism? Is it any prefix you’ve seen in the past? What if the prefix is actually taken out of service? What if it was a misconfiguration? What if the prefix is unreachable when the ABR IGP is started?
So the main scenario this is used for is RFC 5283  inter area LDP extension for LPM match instead for MPLS standard exact match for FEC.  For this MPLS scenario where the operators had carved core AS into multiple areas or levels.  So the BGP next hop attribute update source loop0 is what we are tracking that is summarized so when the egress PE goes down the LSP now does not black hole on the ABR and the control plane convergence occurs with the PUA mechanism and forces the LSP to get built to the alternate PE.  In this scenario and maybe even others the PUA is being used to track the next hop and force the failover. This solution can apply as well to non MPLS, IP based scenario BGP next hop convergence to trigger the control plane convergence with PUA negative advertisement so can also apply to SRv6.

So how would the ABRs know which prefixes these are? Is it any summary component or are they configured?

1.

2.   The forwarding plane behavior is non-standard? How does it work? This is clearly under specified
There is no change to the data plane forwarding
 behavior.  The change is with the control plane to set the next hop loopback from the down PE that no longer in the RIB/FIB to null so the control plane converges on the alternate next hop.  When the control plane convergence occurs based on the PUA negative advertisement the data plane follows and the RIB/FIB get programmed as they would normally.

Ahh… I was about to ask this same question on the “IS-IS and OSPF Extension for Event Notification” draft. So while both these drafts claim to not upgrade the route table, both do but indirectly when next-hop for the BGP loopback is removed.

1.   .

1.   comments, in section 6 both conditions 1 and 2 can be true at the same time. In the event the other comments are resolved, this section needs some work.
 We would make #1 less then or equal to do both conditions can never be true simultaneously in the next update.
Ok – this needs to be clarified as well as whether one stops as soon as a condition is satisfied, i.e., an implied “else” between conditions.
Thanks,
Acee

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

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

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 29 Jul 2021 22:07:30 -0400

Hi Acee

On Thu, Jul 29, 2021 at 9:40 PM Acee Lindem (acee) <[email-masked]> wrote:

> Hi Gyan,
>
>
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Thursday, July 29, 2021 at 9:13 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Lsr] Comments on "Prefix Unreachable Announcement" -
> draft-wang-lsr-prefix-unreachable-annoucement
>
>
>
>
>
> Hi Acee
>
>
>
> Answers in-line
>
>
>
> *7 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7>.  Deployment Considerations*
>
>
>
>    according to the procedures described in Section 4 <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-4>.
>
>
>
    Gyan> Good catch & you are correct all devices need to be upgraded.
Will update the draft.

>
>
> 1.
>
> 2.   How do you know what prefixes to protect with this PUA mechanism? Is
> it any prefix you’ve seen in the past? What if the prefix is actually taken
> out of service? What if it was a misconfiguration? What if the prefix is
> unreachable when the ABR IGP is started?
>
> Gyan> So it could be any prefix within the summary range that could have
> the PUA action occur, but the most important one is the BGP next hop
> attribute loop to be tracked.
>
   We will add text around that we can have an ACL to match only
interesting prefixes which in this case the only one is the next hop
attribute.

> Ahh… I was about to ask this same question on the “IS-IS and OSPF
> Extension for Event Notification” draft. So while both these drafts claim
> to not upgrade the route table, both do but indirectly when next-hop for
> the BGP loopback is removed
>
 Gyan> It does but the IGP control plane perspective but does  not in any
> way change the data plane behavior which of course automatically follows
> the control plane.
>
> 1.   .
>
> Ok – this needs to be clarified as well as whether one stops as soon as a
> condition is satisfied, i.e., an implied “else” between conditions.
>
>
       Gyan>Yes  Will do

    Thanks Acee!!

> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*