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

[Gyan Mishra <[e-mail]>]

Hi Tony,

On Mon, Mar 8, 2021 at 11:39 PM Tony Li <[e-mail]> wrote:

>
> Hi Gyan,
>
> >     Gyan> In previous threads BFD multi hop has been mentioned to track
> IGP liveliness but that gets way overly complicated especially with large
> domains and not viable.
>
>
> This is not tracking IGP liveness, this is to track BGP endpoint liveness.
>

   Gyan> Agreed BGP endpoint liveliness recursive next hop - BGP callback
to IGP - Next hop tracking ..

>
> Here in 2021, we seem to have (finally) discovered that we can automate
> our management plane. This ameliorates a great deal of complexity.
>

   Gyan> Ok.  How do you propose to automate?

>
>
> >     Gyan> As we are trying to signal the IGP to trigger the control
> plane convergence, the flooding machinery in the IGP already exists well as
> the prefix originator sub TLV from the link or node failure.  IGP seems to
> be the perfect mechanism for the control plane signaling switchover.
>
>
> You’re trying to fix a problem in the overlay by morphing the underlay.
> How can that seem like a good idea?
>

    Gyan> I mention overlay but it’s really the underlay as the BGP next
hop is in the global table recursive route to IGP.

>
>
> >       Gyan>As I mentioned advertising flooding of the longer prefix
> defeats the purpose of summarization.
>
>
> PUA also defeats summarization.  If you really insist on faster
> convergence and not building a sufficiently redundant topology, then yes,
> your area will partition and you will have to pay the price of additional
> state for your longer prefixes.
>

    Gyan> We are talking a typical Metro Edge use case with a pair of PEs
which is redundant.  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 cannot build the LSP to the
egress PE.  Please see the diagram in the slide deck it details this
special use case.

>
>
> > In order to do what you are stating you have to remove the summarization
> and go back to domain wide flooding
>
>
> No, I’m suggesting you maintain the summary and ALSO advertise the longer
> prefix that you feel is essential to reroute immediately.


    Gyan> ok understood.  How would you know or figure out the logic on the
ABR to find what the backup egress PE next hop to advertise the LSP.  This
is a unique data plane failure condition with RFC 5283 inter area LSP
extension where this problem statement occurs.

>
>
>
> > which completely defeats the goal of the draft which is to make host
> route summarization viable for operators.  We know the prefix that went
> down and that is why with the PUA negative advertisement we can easily
> flood a null0 to block the control plane from installing the route.
>
>
> So you can also advertise the more specific from the connected ABR…


   Gyan> As this is MPLS exact match FEC host route you would have to flood
the single next hop          loopback let’s say if it’s one backup PE for
simplicity

> throughout the domain so that LDP downstream unsolicited can allocate the
> labels downstream from destination downstream to source upstream, and then
> in reverse forward direction of the LSP unidirectional path is established
> and the traffic is now forwarded to FEC binding label switched to egress PE
> to now domain wide flooded exact match host route.  You cannot use the
> summary route on the ABR as that LPM FEC binding is only supported if using
> RFC 5283.  You cannot go half way you either have to use domain wide
> flooding or use the RFC 5283 inter area LSP LPM match.
>
>
> > We don’t have any prior knowledge of the alternate for the egress PE bgp
> next hop attribute for the customer VPN overlay.  So the only way to
> accomplish what you are asking is not do any summarization and flood al
> host routes.  Of course  as I stated defeats the purpose of the draft.
>
>
> Please read again.
>
> Tony
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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