+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.
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.
> >
>
> --
<http://www.verizon.com/>
*Gyan Mishra*
*Network Solutions A**rchitect *
*Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>*
*M 301 502-1347*
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
