-----Original Message----- From: Vitkovský Adam <[email protected]> Date: Wednesday, June 11, 2014 at 2:03 AM To: Peter Psenak <[email protected]>, "[email protected]" <[email protected]> Cc: Adrian Farrel <[email protected]>, ytsun <[email protected]>, "[email protected]" <[email protected]>, Routing WG <[email protected]> Subject: RE: 答复: Re: Reply to comments -- Comparison between FAR and OSPF
> >> From: rtgwg [mailto:[email protected]] On Behalf Of Peter Psenak >> Sent: Wednesday, June 11, 2014 10:07 AM >> To: [email protected] >> >> Richard, >> >> On 6/11/14 06:11 , [email protected] wrote: >> > Peter: >> > >> > "First, links have high bandwidth, CPUs are fast and any serious IGP >> > implementation has addressed the bottlenecks you are talking about." >> > As the number of nodes increases and the high bandwidth is required, >> > the number of protocol packets which are transmitted and needed to be >> > processed is growing exponentially. But the CPU of a switch can only >> > process a few hundred packets per second; therefore, the processing >> > capacity of the CPU limits the increase of the number of nodes. I have >> > tried to adjust the processing capacity of the CPU in the actual >> > commercial systems, the processing capacity may be increased to >> > thousands packets per second in some way, but at the expense of other >> > protocol processing performance. Therefore, in the large-scale FAT >> > TREE system, the processing capacity of the CPU in those commercial >> > systems cannot cope with a large number of OSPF protocol packets. >> > >> > 'These days IGPs can support thousands of nodes in an area without any >> > problem, and converge sub-second, with precomputed backups, even >> > withing few tens of miliseconds.' >> > For thousands of nodes, it is still a small scale. Once it comes up to >> > tens of thousands of nodes, IGP will not do the job. >> >> above is an academic statement. >> >> First, you need to provide a real world scenario where tens of >>thousands of >> nodes need to be deployed in a flat area. Secondly you need to describe >>why >> the current IGPs would not be able to do the job or be improved to do >>it. > >Well Tear 1 ISPs have been struggling with the number of nodes in IGP for >ages already. >Also new deployments with MPLS all the way to the access layer (for LTE >mostly) face the IGP scalability issues. >To date the only cure is RFC 3107 aka MPLS hierarchy i.e. solving the >problem with another layer of indirection which of course makes other >things more complicated. > >There are real world requirements for ISIS and OSPF to support well over >100k prefixes. There are many factors that affect IGP scaling. However, 100K IGP prefixes without too many neighbors is no problem for commercial backbone and edge routers. >(at least one request I know of was for 1M). I haven’t seen a requirement for 1M. > >Although I'm really surprised there are Data-Center deployments which >struggle with IGP scalability so it seems the problem has escaped the ISP >world now. > >However to be honest I'd like to see the existing protocols to scale >better. Bring your use cases requirements to the OSPF and ISIS WGs. The OSPF MANET experimental RFCs all reduce the flooding overhead and my experience has been that, at least, OSPF is I/O bound. I suspect the same can be said for ISIS. Thanks, Aceee >In my opinion any new IGP protocol would get a cold welcome in carrier >grade environments even though it could heal all the problems. > > > >adam >_______________________________________________ >rtgwg mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
