"dre" <[EMAIL PROTECTED]> commented,
>""Howard C. Berkowitz"" <[EMAIL PROTECTED]> wrote in message
>news:p05001905b6d4554abd7f@[63.216.127.100]...
>
>> 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.
>>
>> 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.
>
>I don't think I've seen POP/access or server sites that are implementing
>subsecond reconvergence (especially on the collocation side) with even
>IGPs at this point.
The technology isn't there yet. Without getting into NDA issues, I
have gotten customer RFPs that are interested in it, but it's
certainly not a requirement yet.
There may be less ambitious approaches than full IGP reconvergence in
milliseconds, along the lines of precomputing backup routes. MPLS
has some fast failover concepts.
>Combining this with some of the other concepts you
>brought up is very key. To add another one into the mix, try to solve the
>problem of stateful failover using "n to many" clustering/high-availability
>for servers in these environments.
Yes. One of the nastiest ones is keeping crypto sync in this sort of
environment. Some people want instantaneous IPsec failover, which I
tend to regard as insane, incredibly resource-intensive, possibly
opening up security holes, etc. Resyncing a session key is more
within the range of the realistic.
There's a huge issue of deciding what is good enough. In the fault
tolerance chapter of my WAN Survival Guide, I quote some of the
specifications for a Minuteman ICBM launch control capsule and its
communications (i.e., basically keep working through a nuclear attack
where you aren't directly hit), and then pose the question -- does
your fault tolerance budget match this one?
>Bringing this to the network layers
>becomes difficult when considering multiple paths and convergence,
>be it long-haul, metro, or even across logical local areas (VLANs)
>at the lower network layers, or external or internal routing at the higher
>network layers (IGP, MPLS-TE, Content routing, Content switching, etc).
>
>> 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:
><snipped redefinition of network hierarchy>
>> 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.
>
>Howard, thank you for defining some new terminology. I always feel
>that certain words can help me understand something better ;>
>
>In terms of understanding this big picture, I have been coming to terms
>with new designs for edge networks and trying to fit all these concepts
>together. Content networking is the big one that seems to break a lot
>of the mold of networking (as I know it, at least) that we've come to
>rely on over the years. So I deeply understand the need for consensus.
>Sounds like Stockholm will be ground-shaking ;>
Well, content routing is part of the Stockholm presentation. Not sure
who is going to try to bell that cat. There's quite a bit of
academic research there as well as product evolution. Don't know if
Dmitri Krioukov is still reading this list, but he's far more of an
expert on content routing than I am.
>
>> 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.
>>
>> 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.
>
>Core networks (as you describe them here) are definitely changing.
>I am having a hard time with the idea of Carrier's Carrier networks,
>and some of the other challenging concepts with core networking.
>
>I always thought of the Core as where IBGP lives, not "passed over",
>as in transport. It sounds like your concept of a core here is an IGP
>carrying infrastructure addresses and maybe "a bunch of LSRs".
>
>If this were ATM overlay and not MPLS, would it still be called the
>same thing? What if it's Optical? What if it's MP(Lambda)S?
Some of my True Believer Optical colleagues at Nortel may tar and
feather me for this, but I find most people that wave their hands and
it's "optical routing," or "MP lambda switching" simply don't
understand routing. I have yet to see anything unique to optical
routing that can't be handled with reasonable extensions to existing
routing mechanisms. Sure, the number of lambdas on a fiber is a
constraint, and you have to keep track of the color you are assigning
to path. But is that really so different from OSPF/ISIS-TE, where
you need to keep track of reserved bandwidth, and keep track of the
layer 2 identifier to which the next hop maps? I think not.
In fact, the IETF is setting up a new "temporary area directorate,"
much as was done for IPv6, for "sub-IP protocols". A lot of its
charter is how IP routing communicates with specific intelligent
lower layers, be they MPLS (e.g., LDP, CR-LDP, RSVP-TE), dialup
(DDR), optical (optical whatever) or RFC 1149 (Multipigeon Label
Switching).
>
>So, yes, "Internet core" as in carrying Internet (or ISP customer)
>prefixes. But, no, not "Internet core" as in exchanging prefixes with
>other AS's (although I'm sure IBGP mesh, route-reflection, and
>confederations complicate the idea even further -- but at least these
>terms are currently well understood and defined).
>
>Hrmn... how about "BGP Core" and "Core Transmission"? These
>are words taken from Cisco. BGP Core could define IBGP
>carrying Internet/customer prefixes across/into/throughout the
>ISP backbone. Core Transmission could define the MPLS-TE
>and/or MPLS VPN architecture (LSRs and P-routers) and the
>underlying transport (could be IP+ATM, could be Optical, etc).
Unfortunately, throughout the industry, marketing seems to want to
leap up and invent words that really don't have a precise definition.
Again and again, I see people on this list struggling to find precise
meaning in terms that don't have precise meaning. A similar syndrome
exists when people insist on coercing everything into a layer of the
classic OSI model, when the OSI model itself (i.e., the ISO
standards) have themselves evolved beyond the original definition.
I wonder how many people here have encountered some of the more
evolved OSI terminology, such as the Application Control Service
Element and Remote Operations Service Element in the lower half of
the application layer, the Subnetwork Dependent Convergence Facility
between layer 2 and layer 3 (think an abstraction of ARP), the B-ISDN
evolution of protocols into U/C/M planes, and the further evolution
of U/C/M into forwarding and control planes.
>
>> 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)
>
>Extensive routing and extensive filtering. Sounds like the classic
>Cisco distribution layer, which I guess is moving up in the world ;>
>So why the term "edge" here instead of "distribution"?
I was chatting with a couple of colleagues today, and we were
actually trying to figure out who introduced the concept "edge". I'm
finding that the edge/core model is being simplistically interpreted
to mean that everything can be collapsed into two levels of
hierarchy. Lots of people make this incorrect assumption about OSPF
or ISIS as well -- if either of these protocols are running, then
everything must fit either into backbone or non-backbone.
The reality, of course, is that these IGPs are just part of an
overall routing design. I've designed a lot of networks in which
the lowest-tier (dare I say access?) routers had static or floating
static routes up to a "distribution" ASBR in a not-so-stubby area,
which redistributed the statics (or static aggregates) into OSPF.
This area, in turn, fed into an area 0.0.0.0 of one of several OSPF
routing domains, which were then linked by a backbone of backbones.
Depending on the topology, I've done backbones of backbones that are
static routed, or done them as BGP confederations, etc.
>
>There are so many different devices that provide "edge" services
>that work on different layers and have totally different functionality,
>this becomes very confusing. A carrier is going to have a totally
>different perspective than a Hosting ISP. Some "edge" devices
>offer some interface capabilities and not others. Some "edge"
>devices offer certain [QoS|VPN/Security] policies and not others.
>
>-dre
>
>
>
>
>_________________________________
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
