On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak <ppse...@cisco.com> wrote:
> Hi Chris, > > On 22/11/2021 22:29, Christian Hopps wrote: > > > > 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? > > It's more like tens of thousands from what I have seen. > I don't know the specific network talked about here by Guayn where he claims to see 100s of Ks of host routes on a router either. Though IME seeing igp RIB is excess of few 10Ks routes (in a single instance/topology) is quiet exceptional for a lot of practical reasons in real deployments. As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a drastically different, novel way of addressing tunnel endpoints. Nothing prevents you from summarizing (v6) loopback addresses on PEs AFAIS in any other tunneling technology (that preconditions having an addressing discipline of course but it seems the same is true for SRv6). I stand enlightened but AFAIS a tunnel is a tunnel is a tunnel, what we talk about here is adding something that provides a partial (since it does not verify the data path needed for the control or transport tunnels) SSAP liveliness indication to IGP on whatever endpoint (which happens in IP being roughly <address>:port whereas we imply by a loss of address the loss of all services which in itself is an assumption which is probably fair enough as long BGP has all services on the same routing instance, not a given thing in the future AFAIS ;-) Where I agree with TLi again that it's not something that should be in IGP scope (or at minimum not shared with the instance responsible to do the IP reachability computation). -- tony > > thanks, > Peter > > > > > 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. > >> > > > > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
