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

[Gyan Mishra]

Hi Acee


On Thu, Jul 29, 2021 at 9:40 PM Acee Lindem (acee)  wrote:

> Hi Gyan,
>
>
>
> *From: *Gyan Mishra 
> *Date: *Thursday, July 29, 2021 at 9:13 PM
> *To: *Acee Lindem 
> *Cc: *"draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" <
> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, "lsr@ietf.org" <
> lsr@ietf.org>
> *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)  40cisco@dmarc.ietf.org> wrote:
>
> 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.
>
>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>.
>
>
>
> 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.
>
>
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?
>
> 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?
>
> 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.

> 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
>
 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.   .
>
> 2.   This is somewhat minor compared to the other
>

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

[Acee Lindem (acee)]

Hi Gyan,

From: Gyan Mishra 
Date: Thursday, July 29, 2021 at 9:13 PM
To: Acee Lindem 
Cc: "draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" 
, "lsr@ietf.org" 

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) 
mailto:40cisco@dmarc.ietf.org>> wrote:
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.
   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>.



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.   .

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.
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
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

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

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com>

M 301 502-1347

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

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

[Gyan Mishra]

Hi Acee

Answers in-line

On Thu, Jul 29, 2021 at 7:02 PM Acee Lindem (acee)  wrote:

> 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.
>
>Gyan> Yes to use the PUA feature all nodes must be upgraded.

Section 7 has been updated to reflect.

7 
.
Deployment Considerations

   To support the PUA advertisement, the ABRs should be upgraded
   according to the procedures described in 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr