Hi Acee
On Thu, Jul 29, 2021 at 9:40 PM Acee Lindem (acee) <[email protected]> wrote: > Hi Gyan, > > > > *From: *Gyan Mishra <[email protected]> > *Date: *Thursday, July 29, 2021 at 9:13 PM > *To: *Acee Lindem <[email protected]> > *Cc: *"[email protected]" < > [email protected]>, "[email protected]" < > [email protected]> > *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 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>. > > > > 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 > > > > 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. > > Gyan>Yes Will do Thanks Acee!! > Thanks, > > Acee > > > > > > Thanks, > Acee > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > -- > > [image: Image removed by sender.] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <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
