Subject: Re: [rrg] moving towards recommendation: the current plan

From: Lixia Zhang <[email-masked]>
Date: Sat, 30 Jan 2010 23:38:47 -0800

On Nov 25, 2009, at 8:42 AM, Flinck, Hannu (NSN - FI/Espoo) wrote:

> Hello Lixia and others
>
> In the last meeting you presented the following ideas about the  
> evolutionary path
>
> http://www.ietf.org/proceedings/09nov/slides/RRG-3.pdf
>
> I agree with the presentation and the conclusions, but I am left  
> wondering how does the locator and identifier separation fit into  
> the story line. I do not mean LISP here specifically, but whole  
> class of solutions of "separation" as presented by you in IETF/ 
> IRTF72.  They separation seems to be orthogonal to the aggregation  
> based solutions.
>
> Best regards
> Hannu
>

Hi Hannu,

my apology for this belated reply, but better later than never:)
Thanks for your comments!

You are exactly right that the presentation forgot to clarify the EID  
separation issue, and that this issue is by and large orthogonal to  
the aggregation based solution.
(in my talk at July'09 IETF, I did mention that the aggregation based  
solution could be viewed as complementing host-based EID separation  
solutions).

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 31 Jan 2010 00:03:30 -0800

On Nov 25, 2009, at 1:24 PM, Noel Chiappa wrote:
> ......
> Also, as I've mentioned before, if we are to produce _practical_
> proposals, we are heavily constrained by what is already deployed, and
> that limits the clarity of what we can do. Yes, with a clean-sheet  
> design,
> one could carefully and completely separate location and identity.
> However, we do not have the luxury of a clean sheet; we can only
> _start_ to move in that direction.
>
>> The fact that local locators are often called "identifiers" does not
>> help to understand what proposals actually do.
>
> Differing definitions here are proving to be a problem. To me,  
> anything
> that can serve to identify one end of a TCP connection _cannot_ be a  
> pure
> 'locator', as to me, locators name interfaces, not stacks.
>
> Similarly, to me, anything which can identify one end of a TCP  
> connection
> is, by definition, an 'endpoint identifier'; it may have _other_
> functionality as well, but its base functionality is that of an  
> endpoint
> identifier.
>
> Again, due to TCP's past co-mingling of the concept of 'interface  
> name' and
> 'endpoint name', we cannot (alas) get cystal pure 'locators' and  
> 'endpoint
> identifiers' in any design, _especially_ if we wish to support  
> unmodified
> hosts.

Hi Noel, you are exactly right that if we "no change to hosts" as  
prerequisite, then we would not be able to have a clean solution to  
this end identifier problem.

But I do not think "no change to hosts" should be a prerequisite.

> So, IMO, trying to apply these pure, theoretical terms to actual
> proposals is necessarily problematic...

It is problematic only because of the "no change to hosts" prerequisite.

(personal opinion) I think we need to separate out two things:

1/ Requiring changes to (most if not all) hosts to reduce global  
routing table size,

versus

2/ Requiring host changes to solve the identifier separation problem.

To me, 2/ will necessarily happen to those hosts which need the  
separation.

Lixia