Robert,
On 09/03/2021 11:47, Robert Raszuk wrote:
> You’re trying to fix a problem in the overlay by morphing the
underlay. How can that seem like a good idea?
I think this really nails this discussion.
We have discussed this before and while the concept of signalling
unreachability does seem useful such signalling should be done where it
belongs.
Here clearly we are talking about faster connectivity restoration for
overlay services so it naturally belongs in overlay.
It could be a bit misleading as this is today underlay which propagates
reachability of PEs and overlay relies on it. And to scale,
summarization is used hence in the underlay, failing remote PEs remain
reachable. That however in spite of many efforts in lots of networks are
really not the practical problem as those networks still relay on exact
match of IGP to LDP FEC when MPLS is used. So removal of /32 can and
does happen.
think SRv6, forget /32 or /128 removal. Think summarization.
I'm not necessary advocating the solution proposed in this particular
draft, but the problem is valid. We need fast detection of the PE loss.
And forget BFD, does not scale with 10k PEs.
thanks,
Peter
In the same time BGP can pretty quickly (milliseconds) remove affected
service routes (or rather paths) hence connectivity can be restored to
redundantly connected endpoints in sub second. Such removal can be in a
form of atomic withdraw (or readvertisement), removal of recursive
routes (next hop going down) or withdraw of few RD/64 prefixes.
I am not convinced and I have not seen any evidence that if we put this
into IGP it will be any faster across areas or domains (case of
redistribution over ASBRs to and from IGP to BGP). One thing for sure -
it will be much more complex to troubleshoot.
Thx,
R.
On Tue, Mar 9, 2021 at 5:39 AM Tony Li <tony...@tony.li
<mailto:tony...@tony.li>> 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.
Here in 2021, we seem to have (finally) discovered that we can
automate our management plane. This ameliorates a great deal of
complexity.
> 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>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.
> 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.
> 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…
> 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
_______________________________________________
Lsr mailing list
Lsr@ietf.org <mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
