Gyan Mishra <hayabusa...@gmail.com> writes:
+1 As I mentioned the requirements for E2E LSP with seamless MPLS or SR-MPLS requires domain wide flooding of host routes. For large operators with a thousands of routes per area you can image if you total that all up can equate to hundreds of thousands of host routes. That is what we live with today real world scenario. Summarization is a tremendous optimization for operators.
I'm having a hard time imagining 300,000 or 500,000 PEs that need this "liveness as a host route" notification for. Where are these hundreds of thousands of hosts coming from that ever need to be in the IGP? Large operators may have prefixes for each of their internal links or each of their router loopback addresss, so this can lead to 1000s of routes; however, it does not imply 100 times that many host routes being present at all. Perhaps this is just a hole in my knowledge though. Thanks, Chris.
With RFC 5283 the issue why it was never deployed is that it fixes
half the problem. If fixed the IGP for with the LDP inter area
extension can now support LPM IGP match summarization so the RIB/FIB
is optimized, however the LFIB still has to maintain all the host
routes FEC binding RFC 5036.
With the RFC 5283 solution we still have to track the liveliness of
the egress LSR which states can be done by advertising reachability
via IGP and then you are back to domain wide flooding even in the
IGP.
Section 7.2
- Advertise LER reachability in the IGP for the purpose of the
control plane in a way that does not create IP FIB entries in the
forwarding plane.
Here stated the LFIB remains not optimized
- The solution documented in this document reduces te link state database size
in the control plane and the number of FIB
entries in the forwarding plane. As such, it solves the scaling of
pure IP routers sharing the IGP with MPLS routers. However, it does
not decrease the number of LFIB entries so is not sufficient to solve
the scaling of MPLS routers. For this, an additional mechanism is
required (e.g., introducing some MPLS hierarchy in LDP). This is out
of scope for this document.
So this is quite unfortunate for RFC 5283 and why it was never deployed by
operators.
SRv6 is an answer but majority of all SPs are not there yet and we
need to be able support MPLS for a long time to come beyond our
lifetime.
Kind Regards
Gyan
On Mon, Nov 22, 2021 at 9:40 AM Peter Psenak <ppse...@cisco.com>
wrote:
Robert,
On 22/11/2021 15:26, Robert Raszuk wrote:
>
> Peter - the spec does not present full story. Hardly no RFC
> presents full A--Z on how to run a network or even a
given feature. It
> provides mechanism which can still permit for building LDP LSPs
> without host routes.
>
> So anyone claiming it is impossible by architecture of MPLS is
simply
> incorrect.
>
> As example - some vendors support ordered LDP mode some do not.
Some
> support BGP recursion some do not. And the story goes on.
>
> But I am not sure what point are you insisting on arguing ...
If it is
> ok to run host routes across areas we have no problem to start
with so
> why to propose anything new there.
all I'm trying to say is that IGPs do advertise host routes
across areas
today. Yes, it is sub-optimal, but hardly architecturally
incorrect
IMHO. We want to improve and allow effective use of aggregation,
while
keeping the fast notification about egress PE reachability loss
in place
to help overlay protocols converge fast. The situation would be
much
improved compared to what we have today.
thanks,
Peter
>
> Moreover as you very well know tons of opaque stuff is attached
today to
> leaked host routes and this curve is going up. So when you
summarise you
> stop propagating all of this. Is this really ok ?
>
> Do not get me wrong I love summarization but it seems as
discussed off
> line - we would be much better to leak host routes with opaque
stuff
> when needed rather then then leak blindly everything
everywhere.
>
> Cheers,
> R.
>
>
>
>
> On Mon, Nov 22, 2021 at 3:12 PM Peter Psenak <ppse...@cisco.com
> <mailto:ppse...@cisco.com>> wrote:
>
> On 22/11/2021 15:00, Robert Raszuk wrote:
> >
> > it's not a choice, that is an MPLS architectural
requirement
> and it
> > happens in every single SP network that offers
services on
> top of MPLS.
> > If that is considered architecturally incorrect,
then the
> whole MPLS
> > would be. But regardless of that, it has been used
very
> successfully
> > for
> > last 30 years.
> >
> >
> > No. Please read RFC5283.
>
> and how many SPs have deployed it?
>
> Hardly any, and maybe because of what is described in
section-7.2
>
> "For LER failure, given that the IGP
> aggregates IP routes on ABRs and no longer advertises
specific
> prefixes, the control plane and more specifically the
routing
> convergence behavior of protocols (e.g., [MP-BGP]) or
applications
> (e.g., [L3-VPN]) may be changed in case of failure of
the egress LER
> node."
>
>
> And what RFC5283 suggests in the same section is:
>
> "Advertise LER reachability in the IGP for the
purpose of the
> control plane in a way that does not create IP FIB
entries in the
> forwarding plane."
>
> Above defeats the prefix aggregation.
>
>
> Peter
>
>
> >
> > Thx,
> > R.
>
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
