Hi Acee Answers in-line
On Thu, Jul 29, 2021 at 7:02 PM Acee Lindem (acee) <acee= [email protected]> 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>. > 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 protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
