Hi Gyan, From: Gyan Mishra <hayabusa...@gmail.com> Date: Thursday, July 29, 2021 at 9:13 PM To: Acee Lindem <a...@cisco.com> 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) <acee=40cisco....@dmarc.ietf.org<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
