Dino, This has in fact always been an option with ISATAP, i.e., it is perfectly reasonable to have site-within-site nesting with site border routers acting as ETRs on one site and ITRs on another. This is also now documented in RANGER/VET/SEAL.
Fred [EMAIL PROTECTED] >-----Original Message----- >From: Dino Farinacci [mailto:[EMAIL PROTECTED] >Sent: Wednesday, December 10, 2008 1:28 PM >To: Shane Amante >Cc: [email protected]; Noel Chiappa >Subject: Re: [rrg] Map and Encaps > >Brian Carpenter wrote a paper (and had some slideware) indicating how >we can iterate the map-n-encap designs. So for each level of >encapsulation you have another x-to-y mapping with a separate mapping >database system. > >I believe LISP can do this and is documented in the main LISP Internet >Draft. This is how we allow Loc/ID split to be done in site-based ITRs/ >ETRs as well as by core-based TE-ITRs/TE-ETRs for ISP based Traffic >Engineering. > >This is an example of "recursive tunneling" much like MPLS has a VC- >label inside of a transport-label. > >We also see cases for "re-encapsulate tunneling" where an ETR sits on >a Data Center edge decapsulates for Loc/ID split purposes but is also >an ITR to add encapsulation for ETRs that are directly connected to >server host clusters. This is desirable for implementing server load >balancing where a virtual IP address (i.e. known as VIPs in the SLB >community) is used as an EID to lookup a set of RLOCs which have >measured load against them. > >Dino > >On Dec 10, 2008, at 11:35 AM, Shane Amante wrote: > >> Scott, All, >> >> On Dec 10, 2008, at 10:23 AM, Scott Brim wrote: >>> Excerpts from Noel Chiappa on Wed, Dec 10, 2008 09:23:07AM -0500: >>>>> From: Scott Brim <[EMAIL PROTECTED]> >>>> >>>>> A LISP EID names a network attachment point. >>>> >>>> Well.... sort of. (And there are two kinds, IPv4 EIDs and IPv6 >>>> EIDs.) What >>>> the IPv4 EID really names is whatever a vanilla 'IPv4 address' >>>> names, which >>>> is somewhat ambiguous itself. >>>> >>>> It definitely names an entity with a collection of higher-level >>>> protocols and >>>> their ports (UDP, ICMP, TCP, etc). It also seems to name an >>>> interface >>>> (because to get packets to a different interface on a dual-homed >>>> host, you >>>> need to use a different IPv4 address). This is another 'axis of >>>> confusion' >>>> with IPv4 addresses (which are also muddied on the location/ >>>> identity axis). >>> >>> First I admit I wrote too quickly, because an EID might be >>> virtualized. We may be disentangling identifier and locator but we >>> still will not have disentanbled locator and "forwarding directive". >>> >>> Second, the reason I said it names a network attachment point is that >>> from the point of view of the network -- which is what matters here >>> -- >>> it knows attachment points, not stacks or interfaces. But that's a >>> nit. >> >> Related to your second point, I've also started to ponder the longer >> term "flexibility" of a map-and-encaps approach. More specifically: >> 1) First, as time progresses, will components within/of the network >> become more virtualized? In other words, isn't it increasingly >> likely that we'll want to "name" not only network attachment points, >> but also stacks, interfaces, virtual machines, processes, etc.? >> 2) Assuming that #1 is desirable (or required), how would the >> current crop of map-and-encaps proposals (easily) accommodate that? >> For example, are we reliant on both mapping and encapsulation (and, >> within what "scopes") to accommodate the above, or not? >> >> In summary, I'm asking: what is the roadmap beyond this "first-gen" >> set of map-and-encaps proposals to attain those goals, (assuming >> people agree they are valid goals)? >> >> Although there's been a lot of emphasis on the feasibility & speed >> of deployment related to specific (classes of) proposals, there >> doesn't seem to have been much, if any, detailed discussion related >> to their flexibility to accommodate, say, #1 among other things that >> we can reasonably predict might happen in the near future. In the >> end, a "roadmap" should also be given serious consideration when >> evaluating all of the (classes of) proposals. >> >> Thoughts? >> >> -shane >> _______________________________________________ >> rrg mailing list >> [email protected] >> https://www.irtf.org/mailman/listinfo/rrg > >_______________________________________________ >rrg mailing list >[email protected] >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
