[rrg] Map and Encaps

[Dino Farinacci]

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 <swb at employees.org>
>>>
>>>> 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
> rrg at irtf.org
> https://www.irtf.org/mailman/listinfo/rrg