> As side discussion, I'm getting lost how a SRv6 PE-PE is somehow a drastically different,
It is not. You can deliver all of your services using MPLS (as service demux only) over UDP and IPv4 summarized endpoints for a long long time. Contrail was/is doing just that :) Best, R. On Tue, Nov 23, 2021 at 11:14 AM Tony Przygienda <[email protected]> wrote: > > > On Tue, Nov 23, 2021 at 9:30 AM Peter Psenak <[email protected]> wrote: > >> Hi Chris, >> >> On 22/11/2021 22:29, Christian Hopps wrote: >> > >> > Gyan Mishra <[email protected]> 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 <[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]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
