Re: [Lsr] https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05

[Gyan Mishra <[e-mail]>]

Hi Acee

On Thu, Mar 11, 2021 at 2:48 PM Acee Lindem (acee) <[e-mail]> wrote:

> Hi Gyan,
>
>
>
> I think we are starting to communicate but there are still some problems.
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Thursday, March 11, 2021 at 1:27 PM
> *To: *Acee Lindem <[e-mail]>
> *Cc: *Aijun Wang <[e-mail]>,
> draft-wang-lsr-prefix-unreachable-annoucement <
> [e-mail]>, lsr <[e-mail]
> >
> *Subject: *Re:
> https://tools.ietf.org/html/draft-wang-lsr-prefix-unreachable-annoucement-05
>
>
>
> Hi Acee
>
>
>
> Thank you for your comments.
>
>
>
> Answers in-line.
>
>
>
> Thank you
>
>
>
> Gyan
>
>
>
> On Thu, Mar 11, 2021 at 11:01 AM Acee Lindem (acee) <[e-mail]>
> wrote:
>
> Hi Gyan,
>
>
>
> I guess you didn’t understand my first PUA question. See inline.
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Monday, March 8, 2021 at 8:11 PM
> *To: *Acee Lindem <[e-mail]>
> *Cc: *Aijun Wang <[e-mail]>,
> draft-wang-lsr-prefix-unreachable-annoucement <
> [e-mail]>, lsr <[e-mail]
> >
> *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) <[e-mail]> 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?
>
>
>
>  Gyan>  In section 6 of the draft under implementation considerations we have a MAA (Max Address Announcement) threshold value that is configurable.
>
>     1.  If the number of unreachable prefixes is less than MAA, the ABR
>
>    should advertise the summary address and the PUA.
>
>
>
>    2.  If the number of reachable address is less than MAA, the ABR
>
>    should advertise the detail reachable address only.
>
>
>
>    3.  If the number of reachable prefixes and unreachable prefixes
>
>    exceed MAA, then advertise the summary address with MAX metric.
>
>
>
>        If a prefix is already missing when the ABR establishes adjacency
> on the path the prefix is not in the lsdb and so a PUA would not be sent
> for a prefix that is unknown to the ABR.  Any traffic sent to that bgp next
> hop would still be impacted as this is an adjacency forming timing issue.
> We will have investigated this issue with the authors and are thinking of
> maybe a delay timer after the adjacency is formed as to when the PUA
> mechanism becomes activated that we can add to the considerations section.
>
>
>
> So once an intra-area prefix within the range is reachable, you’ll
> maintain semi-permanent state that it is going to be protected by the PUA
> mechanism? Prior to that, it will not be protected? That is what you are
> implying. All these details need to be specified.
>
>  Gyan>  We will add the details mentioned to the draft.
>
>
>
>
>
>
>
> 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 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.
>
>         Gyan>> If the OSPFv3 router does not support the prefix originator
> TLV is a Sub-TLV of the Inter-Area Prefix TLV advertised in the
> E-Inter-Area-Prefix-LSA then it would use the summary address advertised by
> the ABR and black hole as the control plane would not converge to not use
> the summary on that non supporting OSPFv3 router.  Agreed.  That support
> dependency we will add to the considerations section 6.
>
>
>
> It is worse than that. For OSPFv3 routers that don’t support this
> extension, the E-Inter-Area-LSA will attract blackhole traffic since it
> will be rightly treated as a reachable more-specific advertisement.
>
> Gyan>  We will add some details surrounding the scenario with non
> supporting routers. The scope of the black hole is a limited set of routers
> being the egress PE node failure that would cause the loopback0 next hop
> attribute to become unreachable as that is the LPM FEC element binding that
> needs to be triggered to for the down FEC LPM to be removed from the LFIB
> so the new LSP can be established to the backup node.  In most cases both
> egress PEs are active with 50/50 load split so it’s a matter of getting FEC
> element for down node removed from LFIB and that is exactly what PUA
> accomplishes with the negative advertisement.  As LSP interesting traffic
> is only destined for egress FEC, and not any connected interface if the PUA
> did not happen for any connected interface that went down there would be no
> operational impact from that black hole of traffic from any node in the
> domain.  So that does reduce the impact of non supporting routers.  We
> could make it a requirement at a minimum that the software revision on all
> PEs must support the sub TLV to use this feature.  As this is the main use
> case, operators would have to upgrade to take advantage of the loopbacks
> next hop attribute summarization with RFC 5283.
>





>
>
> 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).
>
>         Gyan>  The issue is not redundancy.  The issue is when
> summarization is used  as the component prefixes BGP next hop recursive to
> the IGP are now hidden and with MPLS RFC 5283 inter area LSP use case, the
> failover is broken.  It’s not just faster convergence it’s any convergence
> as the traffic black hole dead ends on the ABR and cannot build the LSP to
> the egress PE.  Please see the diagram below in the slide deck it details
> this special use case. The LSP ends up dead ending  black hole on the ABR
> once the FEC LPM goes away for the next hop when the PE has a link or node
> failure.
>
>
>
>
>
> I don’t why the ABR couldn’t stitch the LSPs through a different path as
> long as that path is part of the non-backbone area. I simply suggested
> providing more redundancy in your non-backbone area. Though not shown in
> your picture 😉 I see no reason why it wouldn’t work.
>

Gyan> The problem is the signaling from egress PE to ABR and forcing the
ABR convergence to remove the LPM FEC binding.  That’s the problem.
Unfortunately any LSP stitching between ABRs or even TE tLDP stitch or
seamless MPLS BGP-LU overlay or any other idea won’t help as that would be
a redesign replacement of LDP.  Unfortunately MPLS maintains state, and
that is the big advantage of SRV6 even with LPM match.   SR-MPLS as it
reuses MPLS data plane would have the same issue with FEC exact match.
With RFC 5823 the FEC elements are the egress PE loopbacks are now
advertised via LDP inter area extension instead of IGP and IGP in the
backbone and ingress and egress non zero area have the summary only in
IGP.  Once the PUA is sent and flooded it triggers ingress area to converge
immediately removing FEC element loopback LPM of down node in egress area
which now LDP inter area extension updates the LFIB on egress node via the
PUA negative signaling and now the down PE FEC element is removed from the
LFIB and the backup LSP can be  built to the egress PE.  If both egress PEs
are active in most cases 50/50 load split now the 50% traffic now shifts
off the down PE to the other existing active LSP.  Without this PUA feature
the convergence using RFC 5283 convergence of LDP LFIB is very slow black
hole of traffic so operators end up using the inter area extension just for
summarization of connected interface and domain wide flood all egress PE
loopbacks as a workaround.  With this draft the summarization can now be
realized by operators for the loopbacks FEC element as well.

>
>
> Thanks,
>
> Acee
>
>
>
> Thanks,
> Acee
>
>
>
>
>
> Thanks,
> Acee
>
>
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Monday, March 8, 2021 at 6:57 PM
> *To: *Acee Lindem <[e-mail]>, Aijun Wang <[e-mail]>,
> draft-wang-lsr-prefix-unreachable-annoucement <
> [e-mail]>, lsr <[e-mail]
> >
> *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
>
>
>
> --
>
> *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: Image removed by sender.] <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
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD