Subject: Re: [lisp] My proposed revisions to the charter

From: [email-masked] (Noel Chiappa)
Date: Mon, 23 Mar 2009 22:25:56 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

    > Darrel discussed an idea with the authors of expanding EID as end-site
    > identifier.

That's not really correct, though, because an _individual_ LISP EID names an
individual host (well, perhaps even an interface, as Fred Templin pointed
out). So they don't identify "sites".

If the term 'LISP EID' is not acceptable, I suggest you pick a term which i)
recognizes that an individual example names an individual 'something'
(machine or interface), and ii) properly captures the ambiguity, and
potentially changing semantics, of the LISP EID. E.g. something like 'LISP
device name'. (I picked 'device' to be deliberately amniguous as to whether
an LEID names a host or an interface, to avoid semi-endless debates about
what it does name. :-)

Comments on the draft charter:

    > In general, these proposals are based on the "Locator/Identifier
    > separation".

I think 'location and identity separation' is a better term. (I tend to use
'separation of location and identity', actually, preferring the flow of that
version.)

"Locator", as originally defined in RFC-1992, is a particular kind of name,
not a generic concept. (If anyone looks at RFC-1992, the term 'node' in that
document means 'node in an RFC-1992 map', not 'node' in the more generic
sense.)

    > the Internet architecture combines two functions, Routing Locators,
    > (where you are attached to the network) and Endpoint Identifiers (who
    > you are) in one number space: The IP address. 

"Locators" and "Endpoint Identifiers" are particular _kinds_ of name; to
describe "functions", terms like 'location, for the purposes of routing' and
'identity, for use in end-end interactions' would be more apropos.

Also, did you want to mention how the internet architecture also confuses
whether what is being named by an IP address is an interface, or the host
itself ('stack', if one wishes)? Making this point is not necessary, if you
think it will distract.

    > end-site Identifiers (EIDs) 

Same comment as above about "site".

    > LISP EIDs are composed of three parts: a portion that identifies an
    > organization, a portion that identifies a subnet within an
    > organization, and a portion that identifies an interface on that subnet

Ah, one 'organization' might have multiple ETRs, and multiple LEID blocks
(and RLOC sets associated with each one), so I think 'site' is better than
'organization'. Also, not all sites will adopt that two-layer division
internally. I think this would better put as:

  LISP EIDs are composed of two parts: a 'global' portion that uniquely
  identifies a particular site, and a 'local' portion which identifies a
  device within that site. The 'local' portion may be further subdivided
  internal to a site, e.g. to identify a particular physical network within
  that site, and a device on that network, but that division may not be
  visible outside the site.

Again, 'device' is deliberately ambiguous.

    > Generally, the same IP address cannot be used as both an EID and an
    > RLOC, especially if the entities named by the EID and RLOC are
    > different.

I'm not sure about this; if routes are tagged as to whether they are routes
to 'legacy' addresses , LEIDs or RLOCs, (which I claim they will almost
certainly have to be, to enable routing efficiencies by restricting the
scopes over which they are carried), one could indeed have a particular
32-bit value used as both an EID and an RLOC (and in different places).

Do we need to cover this in the charter, or can we just drop this sentence?

    > The LISP WG is chartered to work on the LISP base protocol
    > (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system
    > (draft-fuller-lisp-alt-05.txt), LISP Interworking
    > (draft-lewis-lisp-interworking-02.txt), LISP Map Server
    > (draft-fuller-lisp-ms-00.txt), and LISP multicast
    > (draft-farinacci-lisp-multicast-01.txt)

This wording might be taken to read as saying only these documents can be
produced. I wonder if that will be too limiting (e.g. if we want to split
draft-farinacci-lisp-12.txt into, say a 'LISP Overview' document and a 'LISP
protocol specification' document)? Is there some way to clarify that?

Also, I wonder what will happen if, in the course of deploying testbeds, we
decide we need something else (like the Map Server thing, which is a _very_
recent addition). Would we have to modify the charter if we decide we need
something else to get the test-bed operational?

The rest looks fine.

	Noel

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Mar 2009 12:37:40 -0400

>>>>> "Noel" == Noel Chiappa <[email-masked]> writes:

    >> From: Sam Hartman <[email-masked]> Darrel discussed an
    >> idea with the authors of expanding EID as end-site identifier.

    Noel> That's not really correct, though, because an _individual_
    Noel> LISP EID names an individual host (well, perhaps even an
    Noel> interface, as Fred Templin pointed out). So they don't
    Noel> identify "sites".

    Noel> If the term 'LISP EID' is not acceptable, I suggest you pick
    Noel> a term which i) recognizes that an individual example names
    Noel> an individual 'something' (machine or interface), and ii)
    Noel> properly captures the ambiguity, and potentially changing
    Noel> semantics, of the LISP EID. E.g. something like 'LISP device
    Noel> name'. (I picked 'device' to be deliberately amniguous as to
    Noel> whether an LEID names a host or an interface, to avoid
    Noel> semi-endless debates about what it does name. :-)

I think it's very clear that it names an interface within the scope of
LISP that we are chartering.

    Noel> Comments on the draft charter:

    >> In general, these proposals are based on the
    >> "Locator/Identifier separation".

    Noel> I think 'location and identity separation' is a better
    Noel> term. (I tend to use 'separation of location and identity',
    Noel> actually, preferring the flow of that version.)

I didn't change this part other than to remove acronyms.  We've seen
an explicit request from Scott to remove identity where I used it.  At
least in the applications area, never using the term identity
definitely seems to be the running approach.

    Noel> Also, did you want to mention how the internet architecture
    Noel> also confuses whether what is being named by an IP address
    Noel> is an interface, or the host itself ('stack', if one
    Noel> wishes)? Making this point is not necessary, if you think it
    Noel> will distract.
I was not actually changing this part of the charter.

    >> end-site Identifiers (EIDs)

    Noel> Same comment as above about "site".

I'd like some expansion for the acronym.  I'm not overly attached to
what it is:-) I suspect that end-site will make a few people happier,
although I agree with your comment that it is ambiguous.

    >> LISP EIDs are composed of three parts: a portion that
    >> identifies an organization, a portion that identifies a subnet
    >> within an organization, and a portion that identifies an
    >> interface on that subnet

    Noel> Ah, one 'organization' might have multiple ETRs, and
    Noel> multiple LEID blocks (and RLOC sets associated with each
    Noel> one), so I think 'site' is better than 'organization'. 
I agree.

    Noel> Also,
    Noel> not all sites will adopt that two-layer division
    Noel> internally. I think this would better put as:
How with LISP as we are scoping it today can you avoid some internal
subnetting?

    Noel>   LISP EIDs are composed of two parts: a 'global' portion
    Noel> that uniquely identifies a particular site, and a 'local'
    Noel> portion which identifies a device within that site. The
I'd like to say that the global portion is what is mapped into an RLOC.
Also, I'd like to say interface rather than device.
Besides that I think your wording is much better than mine.

    Noel> 
    Noel> 'local' portion may be further subdivided internal to a
    Noel> site, e.g. to identify a particular physical network within
    Noel> that site, and a device on that network, but that division
    Noel> may not be visible outside the site.
    >> Generally, the same IP address cannot be used as both an EID
    >> and an RLOC, especially if the entities named by the EID and
    >> RLOC are different.

    Noel> I'm not sure about this; if routes are tagged as to whether
    Noel> they are routes to 'legacy' addresses , LEIDs or RLOCs,
    Noel> (which I claim they will almost certainly have to be, to
    Noel> enable routing efficiencies by restricting the scopes over
    Noel> which they are carried), one could indeed have a particular
    Noel> 32-bit value used as both an EID and an RLOC (and in
    Noel> different places).

I do think we need to say something here.  I'm not sure I said a
factually correct thing, but I think that a case where the same 32-bit
number was used for an RLOC and an unrelated EID would be a
significant difference from LISP today.

So, I'm not sure what we say here, but I think Robin's concerns as
well as Margaret's call for something to be said answering to what
extent we expect EIDs and RLOCs to overlap.m