Robert,
On 22/11/2021 16:14, Robert Raszuk wrote:
All,
If you want to know real world scenarios lot's of networks uses separate
IGP domains not areas or levels. And yes I do know that 1000s of host
routes are present everywhere. MPLS networks build in early 2000s are
still running as is.
That means that your unreachable propagation of host routes from one
area/ASN would need to be magically transponded between ASBRs (all under
same administration). We know how to do that with host routes using say
RFC3107 safi 4.
depends on how domains are interconnected.
If it is done without BGP, using IGP redistribution, that can be done
for pulses as well. No standardization required.
If there is BGP in between these IGP domains inside the SP network, you
typically are carrying the PE loopbacks inside BGP itself. If not and
you want to benefit from the pulses, you would have to define something
in BGP to carry them between ASs.
thanks,
Peter
How would one propagate those pulses ? New BGP SAFI ?
Put it back to BGP sounds like a problem on its own as some folks here
just do not get the concept of BGP recursion and that BGP can signal
next hops going down in milliseconds (+detection time + light
propagation time) across your network.
Thx,
R.
On Mon, Nov 22, 2021 at 3:56 PM Gyan Mishra <[email protected]
<mailto:[email protected]>> wrote:
+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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> 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 [email protected] <mailto:[email protected]>//
/
/M 301 502-1347
/
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
