>"dre" <[EMAIL PROTECTED]> wrote,
>""Howard C. Berkowitz"" <[EMAIL PROTECTED]> wrote in message
>news:p05001902b6d33bdfc13c@[63.216.127.100]...
>
>I think that many ISP routers can be "core", not as in the core layer --
>but an ISP router at any layer could be one of those described in the
>http://lightreading.com/testing Internet Core Router Test.
>
>I mean, first you have to define ISP.... and don't even think about
>saying "Tier 1" ISP because we've been through that one enough.
>
>Many ... "ISPs" ... use GSR 12000's for all their routing in a transit-AS
>(even Hotmail and Ebay). These are clearly peering or border routers.
>Juniper routers (from M5 to M160) will do great BGP and aggregate
>a lot of IP routes and a lot of interfaces (especially packet SONET),
>making it another great choice for ISP connectivity and peering.
>
>> It's misleading to think that all ISP routers need to be "core."
>> Arguably, the highest-bandwidth "core" routers inside an ISP may not
>> need to run full BGP, but have more stringent demands on OSPF, ISIS,
>> and/or MPLS. Think of RFC 2547 "P" routers.
>
>IBGP runs in the core with full routes.
Depending on the design of the core, the routers at the edge of the
core will use full routes to set up MPLS LSPs from one side of the
core to the other, but routers internal to the core may not need it
if they are under LDP or RSVP-TE control from the edge routers.
>Are you talking about MP-BGP?
>MPLS-TE doesn't bother with IBGP information directly (i.e. the constraint-
>based routing is for SPF calculations and doesn't factor into the BGP
>decision process or convergence). MPLS-TE and MPLS-VPN are pretty
>separate topics. Yes, you don't have to do MP-BGP in the core, but I am
>sure that since most ISP's use IBGP in the core, it's also MP-BGP (no bgp
>default ipv4-unicast).
>
>This is a the primary place for "core" routers from what I have seen.
>I mean, it is called the "core layer".
If you think of the core as interconnecting the POP/access and server
sites inside an ISP or an enterprise, there's a good deal of interest
in subsecond reconvergence times. This probably is achievable with
link state IGPs, using millisecond or microsecond hellos (or relying
on hardware failure detection on optical links), and more advanced
algorithms than the 40-year-old Dijkstra.
In the short to moderate term, there is no foreseeable way to get
convergence times this fast with exterior routing. Actually,
superfast convergence in the global Internet may be a Really Bad Idea
with respect to Internet stability.
> > An ISP POP access router might have the greatest number of BGP routes
>> and paths, but not as much bandwidth requirements. If the POP router
>> primarily deals with customers, it will advertise only default and
>> partial routes to many of them. Only a small proportion of customers
>> want full routes. A POP router will also generally accept only a
>> small number of routes from customers.
>
>It sounds like you are describing the access layer, which may or may not
have BGP at all.
If the customers want to multihome to multiple providers, or even to
multiple POPs of the same provider, BGP is really the only game in
town. I agree that single-homed customers don't need it, and, for
some situations, multiple defaults will work at the cost of
suboptimal routing.
>IP and circuit aggregation is more important here than
>transit or anything else IMO.
>
>"core" routers can also be placed at this layer, although they would
>be called "border" or "access" instead. Most of the "core" routers
>described in the test don't have enough integrated access and different
>types of interfaces to shine in the access layer. Technically, this should
>all be transport (Cable, DSL, ATM, Optical) for best use of resources
>and superior aggregation (PPPoE, PPPoA, PVC/PVP, VCI/VPI, and
>especially DWDM). The days of a separate router with a separate
>CSU/DSU with a separate circuit for each separate customer for access
>are hopefully long and gone.
This is a huge discussion right here. I agree that a very high
density of logical interfaces is the requirement for an ISP "edge"
rather than "core" router. The aggregation to these interface may
very well be in what variously is called the access or collection
tier.
While there's no industry consensus on terminology for the hierarchy
associated with ISPs, Cisco has been getting away from
core/distribution/access in some of its carrier-oriented
presentation. The newer usages seem to be:
access: customer site routers, which may either be customer provided
(CPE)or carrier provided at the customer location (CLE).
collection: the broadband access network (DSL, cable, etc.), which
may aggregate into VLANs, etc.
distribution or edge: POP, possibly interprovider interconnect,
at least some servers (e.g., cache)
core: intraprovider backbone
I will be co-organizing a session this June at the Internet Society
meeting in Stockholm, along with Lyman Chapin of Verizon/GTE/BBN
(chair) and Sue Hares of NextHop. One of our goals is to present
multivendor views of what constitutes the edge. There's certainly no
consensus, and I haven't begun to discuss content routing here.
>
>> Interprovider routers at tier 1 are unlikely to need to exchange full
>> routes Such routers are bandwidth-intense, but the definition of a
>> tier 1 is that you exchange only customer routes (perhaps
>> oversimplifying, but that's close) with other tier 1 providers.
>
>This is the peering situation I mentioned above. "core" routers definitely
>have a place here, but they would be called something else (e.g. "border").
Absolute agreement that we need a term. Some people call these core
routers "because they are part of the Internet core," but it's really
stretching it to say that the Internet has a distinct core.
>
>I think there is even more places an ISP could find uses for a "core"
>router. For example, in the distribution layer, a "core" router could be
>used for IP aggregation, separation of IGP areas, route filtering, route
>dampening, etc ... to provide more flexible routing stability and control.
>
>So while the Foundry NetIron does not currently fit the bill for MP-BGP
>and MPLS-VPNs (or any MPLS for that matter), it could still easily do
>simple peering, simple distribution/control, etc. It also *could* do ISP
>core routing, but (as shown in the tests) Juniper and Cisco would make
>better choices.
Can you get along with the idea that an ISP core router has lots of
bandwidth, perhaps lots of MPLS paths, perhaps a big _forwarding_
table (as distinct from routing table), but not much filtering or
policy controls? Limited traffic conditioning? Also, all its
interfaces tend to be the same general speed.
In contrast, an ISP edge router has lots of logical interfaces,
extensive filtering, policy, and traffic shaping. It has the most
extensive routing (I am including the "border" function here). It
may be asymmetrical with respect to interfaces (e.g., 10/100/1000
Ethernet toward the customer, OC-48 or better toward the core)
>
>As you can see, I definitely agree there is no *best* "core" Internet
>router,
>because each has its own limitations and areas of excellence.
>
>-dre
--
"What Problem are you trying to solve?"
***send Cisco questions to the list, so all can benefit -- not
directly to me***
Howard C. Berkowitz [EMAIL PROTECTED]
Technical Director, CertificationZone.com
Senior Mgr. IP Protocols & Algorithms, Advanced Technology Investments,
NortelNetworks (for ID only) but Cisco stockholder!
"retired" Certified Cisco Systems Instructor (CID) #93005
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
