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

From: "sunletong" <[email-masked]>
Date: Wed, 25 Nov 2009 09:09:58 +0800

Dear Prof.Zhang:

I'm a new comer in this area and make bold to raise a proposal for Internet's scaling problem. Attached is the first draft and I will refine it to a final piece before 12.15.

Thank you!

Sun Letong

Computer Science and Technology Department of Tsinghua University, Beijing, China

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 25 Nov 2009 18:42:25 +0200

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

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 25 Nov 2009 16:24:18 -0500 (EST)

> From: Michael Menth <[email-masked]>

    >> "locator and identifier" is not really optimal terminology, because
    >> those refer to specific kinds of names, and it's better to refer to
    >> the generic concepts, i.e. 'identity' and 'location'.

    > Many proposals actually deal with network attachment points (RLOCs)
    > and names of endpoints (EIDs) which both serve to find the desired
    > endpoint/interface. ... They usually do not imply an identity that
    > could easily move from one to another network or from one to another
    > device.

There is something to this, but I was speaking in the abstract, not about
any particular proposal.

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. So, IMO, trying to apply these pure, theoretical terms to actual
proposals is necessarily problematic...

	Noel

---

From: [email-masked]
Date: Wed, 25 Nov 2009 17:35:01 EST

In einer eMail vom 25.11.2009 22:24:34 Westeuropäische Normalzeit schreibt  
[email-masked]:

Noel, you can only back this statement by your own reputation - and not by  
reality.
 
On the other hand, I conclude from reading your other comments, that we  
need location based routing and  not loc/-id-split based routing (whatever  
the later one is).
 
Heiner