Hi Gyan, I guess you didn’t understand my first PUA question. See inline.
From: Gyan Mishra <hayabusa...@gmail.com> Date: Monday, March 8, 2021 at 8:11 PM To: Acee Lindem <a...@cisco.com> Cc: Aijun Wang <wang...@chinatelecom.cn>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>, lsr <lsr@ietf.org> Subject: Re: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05 On Mon, Mar 8, 2021 at 7:37 PM Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>> wrote: Speaking as a WG member: Hi Gyan, The first question is how do you know which prefixes within the summary range to protect? Are these configured? Is this half-assed best-effort protection where you protect prefixes within the range that you’ve installed recently? Just how does this work? It is clearly not specified in the draft. Gyan> All prefixes within the summary range are protected see section 4. [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator<https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#ref-I-D.ietf-lsr-ospf-prefix-originator>] draft both define one sub-tlv to announce the originator information of the one prefix from a specified node. This draft utilizes such TLV for both OSPF and ISIS to signal the negative prefix in the perspective PUA when a link or node goes down. ABR detects link or node down and floods PUA negative prefix advertisement along with the summary advertisement according to the prefix-originator specification. The ABR or ISIS L1-L2 border node has the responsibility to add the prefix originator information when it receives the Router LSA from other routers in the same area or level. Acee> So, the ABR will only know about missing prefixes that it has recently received? What if the prefix is already missing when the ABR establishes adjacencies on the path to the PE? What if the prefix is being permanently taken out of service – then this negative advertisement will persist permanently. What if there is an unintentional advertisement in the summary range and it is withdrawn? How do you decide whether or not to protect a prefix with in the range? When the ABR or ISIS L1-L2 border node generates the summary advertisement based on component prefixes, the ABR will announce one new summary LSA or LSP which includes the information about this down prefix, with the prefix originator set to NULL. The number of PUAs is equivalent to the number of links down or nodes down. The LSA or LSP will be propagated with standard flooding procedures. If the nodes in the area receive the PUA flood from all of its ABR routers, they will start BGP convergence process if there exist BGP session on this PUA prefix. The PUA creates a forced fail over action to initiate immediate control plane convergence switchover to alternate egress PE. Without the PUA forced convergence the down prefix will yield black hole routing resulting in loss of connectivity. When only some of the ABRs can't reach the failure node/link, as that described in Section 3.2<https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05#section-3.2>, the ABR th.at<http://th.at> can reach the PUA prefix should advertise one specific route to this PUA prefix. The internal routers within another area can then bypass the ABRs that can't reach the PUA prefix, to reach the PUA prefix. The second comment is that using the prefix-originator TLV is a terrible choice of encoding. Note that if there is any router in the domain that doesn’t support the extension, you’ll actually attract traffic towards the ABR blackholing it. Gyan> I will work with the authors to see if their is any alternative PUA process to signal and detect the failure in case prefix originator TLV is not supported. Acee> Note that in the case of OSPFv3, the prefix originator TLV is a Sub-TLV of the Inter-Area Prefix TLV advertised in the E-Inter-Area-Prefix-LSA. If there are any OSPFv3 routers in the domain that don’t support this functionality and receive traffic for the protected prefix, they will actually route it towards the blackhole. Further, I think your example is a bit contrived. I’d hope that an OSPF area with “thousands” of summarized PE addresses wouldn’t be portioned by a single failure as in figure 1 in the draft and your slides. I also that the option of a backbone tunnel between the ABRs was removed from the draft since it diminished the requirement for this functionality. Gyan> This is a real world Metro access edge example as the impact is customers that have LSP built to the down egress PE that has not failed over. In this scenario their is a Primary and Backup PE per Metro edge which is typical for an operator. The workaround used today is to flood all /32 next hop prefixes and not take advantage of summarization. This draft makes RFC 5283 inter area FEC binding now viable for operators. Acee> Or add a reliable intra-area link between your ABRs. Or, as a backup, a tunnel through the backbone area (as was previously in the draft). Thanks, Acee Thanks, Acee From: Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> Date: Monday, March 8, 2021 at 6:57 PM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, Aijun Wang <wang...@chinatelecom.cn<mailto:wang...@chinatelecom.cn>>, draft-wang-lsr-prefix-unreachable-annoucement <draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org<mailto:draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org>>, lsr <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05 Acee. Please ask the two questions you raised about the PUA draft so we can address your concerns. If anyone else has any other outstanding questions or concerns we would like to address as well and resolve. Once all questions and concerns are satisfied we would like to ask for WG adoption. Kind Regards Gyan -- Error! Filename not specified.<http://www.verizon.com/> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> Silver Spring, MD -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
