Subject: RE: Some Comments on ID/Loc Separation Proposals

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 1 Dec 2003 10:24:12 +0100

> >    Endpoint
>
> >            refers to "the fundamental entity of and end-end
> >            communication" [EID]. It is an end-system that participates
> >            in an association. Endpoints are distinguished from
> >            intermediate, infrastructure nodes and from hosts.
>
> An endpoint is an end-system but not a host: I think this isn't all
> that clear.
>
> Personally, I prefer to talk about hosts, as this is a well-known
> concept.

I guess this is exactly the problem :-)
People has a pre defined concept about what a host is, so they assume
properties about it.
That is why it is good to use a different term such as endpoint, that can be
defined properly

> The fact that there is some ambiguity because hosts can be
> clustered and virtualized also isn't a huge surprise to most people,
> and can be spelled out for good measure.

I guess that something about the relation between a host and an endpoint can
be inlcuded.

>
> If you want to stick to "endpoints" you should say whether an endpoint
> is host that may or may not be virtual, a transport protocol or a
> process. This has pretty serious consequences for the number of
> identifiers that is necessary and some other stuff as well. For
> instance, certain types of communication may be handled by more than a
> single processes. When identifiers are tied to processes this makes
> referral very complex.
>
> >    Identifier
>
> >            refers to a unique label for an endpoint.
>
> Hm, maybe this is just my English but to me it is unclear whether you
> mean the identifier <-> endpoint relationship is 1-to-1, 1-to-n or
> n-to-1, only that it isn't n-to-m.
>

good point

i would say that the relation is n-to-1

but this should be defined and clarified in the text

> I think "an identifier identifies a specific endpoint" is enough.
>

I think we need more than this, in order to be clear. The proposed text with
a modification to explicitly define the n-to-1 relation should be good
enough IMHO

> >            The label is used
> >            simply for distinguishing one endpoint from another.
> >            Because a locator is usually globally unique, it might be
> >            able to serve as an identifier. However this use will often
> >            suffer administrative and referential limitations as a
> >            global identifier for mobile endpoints. This is exemplified
> >            by the current problems experienced with the dual role of
> >            IP Addresses.
>
> This is too much text and largely not relevant for defining
> "identifier". The only additional remark that's necessary is that an
> identifier is independent of an endpoint's attachment to the network
> ("location").

I guess that this is not what Dave is trying to say...
the locator can be used as an identifier, since it is unique, but its usage
as an identifier presents some limitations

Regards. marcelo

>
> > As with others, I do not think it is useful to have ID refer to an
> > interface.  Stack, endpoint or process all seem more helpful.
>
> Absolutely. While multi6 is about site multihoming and not host
> multihoming, it would be a mistake only allow jumping locators when
> those locators are tied to the same interface.
>
> "Endpoint" is usable, but "stack" isn't a very good word as it will
> probably confuse people who haven't followed what has happened in the
> NSRG and identifying processes is too granular and dynamic, IMO.
>
>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 1 Dec 2003 10:24:12 +0100

> 
> Speaking of 'stack', what definition text would folks like.  The NSRG
> paper introduces the construct nicely, but I'm not sure the text there
> is what we should live with.
> 
> For that matter, what is the difference between endpoint and stack?

I don't see any difference between the definition of endpoint and stack...
I would just keep one of them (i like endpoint better)
regards, marcelo

> 
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 1 Dec 2003 07:03:34 -0600

----- Original Message ----- 
From: "marcelo bagnulo" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; <[email-masked]>
Sent: Monday, December 01, 2003 3:24 AM
Subject: RE: Some Comments on ID/Loc Separation Proposals

> I would just keep one of them (i like endpoint better)

When I saw Dave's note, I wondered how "stack" mapped onto "dual-stack
ipv4/ipv6". If everybody thinks "dual-stack" is still one stack for
the purposes of this discussion, fine, but if we don't all have the
same answer to this question, I like endpoint better, too.

Spencer

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 1 Dec 2003 10:44:31 -0800 (PST)

>            intermediate, infrastructure nodes and from hosts.

Dave,

Do you intentionally want the definition of endpoint to be open to
the endpoint being any of
 - (an instance of) the IP protocol processing on a node
 - a IP service access point (i.e. the point where the transport protocols
   attach to IP)
 - a transport service access point 
 - something higher up in the protocol stack

The reason I'm asking is because there are proposals that explore the
first three in the list. If you want to keep the definition open
to applying at different layers it would be good to make that very explicit
in the definition.

  Erik

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Dec 2003 08:25:00 -0800

Eliot,

EL> Once so spelt out, an end point would would have been defined in all but
EL> word, so why not define it?  Personally I believe the term "host" has
EL> become ambiguous, and so itself is worthy of a good clarification, if
EL> not definition.

I think that the term host is dandy for referring to a machine running
IP on the Internet.

We need a term for a finer-grained entity that is the processing
unit for a transport association.

Given usage of 'stack' and 'endpoint', it is worth considering how the
two relate.  Are the really the same thing, or is there a useful
distinction that is worth keeping?

d/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Dec 2003 11:59:11 -0800

>> identifier is independent of an endpoint's attachment to the network

mb> I guess that this is not what Dave is trying to say...
mb> the locator can be used as an identifier, since it is unique, but its usage
mb> as an identifier presents some limitations

correct.

The first sentence is the definition. The second sentence notes a type
of string that can be used. The rest notes known problems with the
string.

d/

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Dec 2003 05:12:41 +0900

Dave;

> unit for a transport association.

A transport layer protocol may or may not use the finer-grained
entity, which is totally dependent on a specific transport layer
protocol.

Terminlogies for such an entity too, of course, is totally
dependent on a specific transport layer protocol.

Attempts to force all the transport layer protocols use a
certain Internetworking layer property or terminology is the
layer violation.

Even TCP is not designed to work only over IP, as is stated
in RFC793:

	In principle, the TCP should be able to operate above
	a wide spectrum of communication systems ranging from
	hard-wired connections to packet-switched or
	circuit-switched networks.

or

	TCP is designed to work in a very general environment of
	interconnected networks.

though its specification assumes IPv4.

							Masataka Ohta

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Dec 2003 13:56:39 -0800

Erik,

EN> Do you intentionally want the definition of endpoint to be open to
EN> the endpoint being any of
EN>  - (an instance of) the IP protocol processing on a node
EN>  - a IP service access point (i.e. the point where the transport protocols
EN>    attach to IP)
EN>  - a transport service access point 
EN>  - something higher up in the protocol stack

1.  I want the term to be precise.  Anything in the definition that
permits ambiguity is a bad thing, in my view.  So you should assume
that any of the text I offered that results in ambiguity is an error
in my text and needs to be fixed.

2. The difference in focus, between IP processing, transport
processing, and application processing is exactly what makes all this
difficult.  I am loathe to believe that we need lots of new terms.  So
I think we need to understand exactly how we want to use this one (or
two) new term(s) and then calculate the definition back from it.

And, yes, the fact that I am not giving you a more concrete response
is intentional. I've offered some specific text.  I want others to fix
it.  (Or, rather, I can't come up with anything better...)

EN> The reason I'm asking is because there are proposals that explore the
EN> first three in the list. If you want to keep the definition open
EN> to applying at different layers it would be good to make that very explicit
EN> in the definition.

I think it will serve us well to _start_ with reference to a local
instance of an application, and then derive text back from it.
Focusing only on the lower layers causes us to miss what is most
interesting and useful, I fear.

d/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Dec 2003 12:57:51 +0100

On 4-dec-03, at 22:56, Dave Crocker wrote:

> EN>  - a IP service access point (i.e. the point where the
> EN>    transport protocols attach to IP)

[...]

> it.  (Or, rather, I can't come up with anything better...)

We can't fix your definition for you if we don't know what you want to 
define...

> interesting and useful, I fear.

Aggregating processes into applications, applications under a single 
ULP and ULPs under IP helps minimize the amount of work that an 
implementation needs to do, which is good CPU/bandwidth and delay wise.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Dec 2003 17:26:37 +0100

After some travel and some flu, I've caught up with this thread, but I 
think it's clearer to comment on Dave's original post.

Firstly, co-chair hat on, we need consistent terminology. When we use a
word, we should all try to use it in the same sense. In the end, we may need
a specific multi6 terminology draft. It is also best if we use existing
definitions rather than inventing our own with subtle changes. So, for example,
if we do use "stack" let's agree on the NSRG definition unless we have a
very strong reason to change it. Otherwise, confusion lies ahead.

Co-chair hat off. Personal comments below.

Dave Crocker wrote:
> 
> Folks,
> 
> draft-crocker-mast-analysis (which will be
> draft-crocker-multiaddr-analysis in its next version) has a section
> for defining some terms.  The section has been prompted by exactly the
> kind of vagueness that the current thread is also trying to fix.
> 
> My primary interest is in having precise definitions that we all find
> useful and use consistently. Some of the current versions of
> definitions in the draft are:
> 
>    Endpoint
> 

Yes. But this is too generic to be really very useful... and trying to
get more precision always ends in a rat hole.

> 
>    Identifier
> 
>            refers to a unique label for an endpoint. The label is used

But to use OSI terminology, this doesn't tell me enough, because I don't know 
whether you are talking about a layer 2, 3, 4 or higher endpoint. That's the
advantage of "stack" - we know it's layer 3.

>            Because a locator is usually globally unique, it might be

I wish. But every single time I travel, I find myself ending up with an
identifier that *isn't* globally unique. I don't think "usually" is at all
accurate. "supposedly unique" might be more accurate.

>            by the current problems experienced with the dual role of

I don't think so. You're correct of course that id/loc overlap is a problem
with mobility. But the problems *today* are caused mainly by non-uniqueness
and that is what is exemplified each time you hook up in a hotel.

> 
> Suggestions for improving the text are eagerly sought.
> 

True. Interfaces are a somewhat elastic concept and not interesting
at systems level. Personally I prefer NSRG-stack to endpoint, because
as mentioned above it has more precision.

> is what we should live with.

Do you have precise criticisms of that definition?

> For that matter, what is the difference between endpoint and stack?

As an ex-NSRG member, I can tell you that "stack" was chosen because
people couldn't reach precise consensus on what "end point" means. 

   Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 6 Dec 2003 14:07:28 -0600

Dear Brian,

Excellent. So we have someone who can channel the spirit of NSRG...

You may have been buried while traveling and recovering (and I
apologize for contributing to your e-mail load), but I wonder if you
could comment on my question about "dual-stack" - is a dual-stacked
host one thing or two, in the NSRG sense of the term "stack"?

Spencer

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, December 06, 2003 10:26 AM
Subject: Terminology [Re: Some Comments on ID/Loc Separation
Proposals]

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 07 Dec 2003 07:54:55 +0900

Brian;

> It is also best if we use existing
> definitions rather than inventing our own with subtle changes.

It is best not to introduce any terminology, even though someone
recently gave some random definition on some word.

> So, for example,
> if we do use "stack"

Don't try to introduce useless terminology.

					Masataka Ohta

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 7 Dec 2003 22:56:35 +0100

On lördag, dec 6, 2003, at 17:26 Europe/Stockholm, Brian E Carpenter 

> get more precision always ends in a rat hole.

couldn't we split this into a several definitions. Like

	Host  		Describes a physical instance connected to the internet for 
the purpose of a certain task, such as workstation, web-server etc.
				A host can have multiple idenntifiers and locators

	Virtual host	Several logical implementations of "Host" running on one 
or more physical instances.

	Stack 		(see NSRG....)

	Interface		The connection point for a host or virtual host to the 
Internet. This COULD be through a Stack..xxxxxx

	Endpoint		refers to "the fundamental entity of and end-end 
communication" . It is an end-system that participates in an 
association. The associations can be made between one or 				more hosts 
or virtual hosts.

	Identifier	SHOULD provide a unique identity to be used for creating 
associations between Endpoints.

	Association	The exchange or one-way communication between applications 
at layer 4 or higher between XXXX
		.
		.
		.
		.

etc. Idea is to try and create a "onion" of definitions. Just go to the 
right layer. The above is to vague tough...

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Dec 2003 17:41:20 +0900

Kurt;

> couldn't we split this into a several definitions.

No, thank you.

Why you and Brian (even with WG chair hat on) are disturbbing
constructive discussion by insisting on introducing useless
terminology?

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Dec 2003 10:13:19 +0100

> constructive discussion by insisting on introducing useless

While I don't think that having precise terminology is useless, it's 
probably better to work on solutions now and solve terminology issues 
later. If not, we run the risk of very precisely defining things that 
we're not going to use anyway.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 8 Dec 2003 11:57:39 +0100

Hi Kurtis,

My problem with this is that i fail to see differences between some of the
terms that are being defined...
For instance stack, endpoint perhaps virtual host...

I mean, is there a difference between this two, if so, do we need them both
for the multi6 discussion? or we can just pick one?

SO i agree we should define as much terms a we feel we need, but we
shouldn't define more that we need, at least we should be able to precisely
describe the difference between the defined terms

IMHO we should just pick one of the above for now and see if it is enough.
By now, i just don't care which one, stack, endpoint...

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Kurt Erik Lindqvist
> Enviado el: domingo, 07 de diciembre de 2003 22:57
> Para: Brian E Carpenter
> CC: Dave Crocker; [email-masked]
> Asunto: Re: Terminology [Re: Some Comments on ID/Loc Separation
> Proposals]
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.2
>
> iQA/AwUBP9OiFaarNKXTPFCVEQLAxQCfSWOKPPSEtziOtWLOHB7RBEKN/44An22M
> eTwNU1ghLK9M6fPZDz/fLGg7
> =Zfyd
> -----END PGP SIGNATURE-----
>
>

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Dec 2003 21:25:37 +0900

marcelo;

> By now, i just don't care which one, stack, endpoint...

What's wrong with the "end system", which is the most authentic
terminology directly related to the end to end principle?

						Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 8 Dec 2003 14:40:36 +0100

> terminology directly related to the end to end principle?

i guess there is nothing wrong with it, as long as we define it precisely.

could you provide a definition of what do you mean by end system? would it
be similar to JNC's endpoint definiton? or NSRG stack definition?

I mean, are those three different names for the same concept or do we have a
conceptual discrepancy here?
As far as i can understand it, we only have one class of objects and we are
just discussing about the name to name it. That's why i am fine with any
name we choose as long as we define it properly

A more important issue would be that we are considering three different
objects and that we are arguing which one is the fundamental entity that we
should consider in multi6 discussions, but IMHO this is not the case.

Regards, marcelo

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 8 Dec 2003 16:37:10 +0100

> describe the difference between the defined terms

I agree with Iljitsch remark that we should focus on the solutions, 
rather than the terminology. At the same time, when there are 
ambiguities that makes us go into spin for a week, I think we do gain 
from having a clear set of terms. Which ones we need and don't need 
will very much depend on which solutions we are looking at. I didn't 
mean to cast the proposal in stone. It was meant as an example. But I 
do think that we need an authoritative list of terminology. But we 
could define that as we go along and needs arises.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Dec 2003 04:58:41 +0900

marcelo;

> i guess there is nothing wrong with it, as long as we define it precisely.

It is a word appears in RFC1958, editor of which is Brian.

> be similar to JNC's endpoint definiton? or NSRG stack definition?

As I searched reference of the RFC, "end point" seems to be an
alternative wording of "end system" that if JNC is saying "endpoint"
with the difinition of Saltzer's paper, that is fine.

Forget NSRG.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2003 10:38:10 +0100

> could define that as we go along and needs arises.

Agreed. As we've seen, attempts to define "end point" go into a rathole.
But in practical terms it *does* matter whether we are talking about
multihoming affecting one physical interface, a set of interfaces on
one machine, a set of interfaces on a cluster of machines, or something
else. 

   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Dec 2003 19:11:11 +0900

Brian;

> one machine, a set of interfaces on a cluster of machines, or something

It does NOT matter.

Physical interface is not a meaningful entity.

As I and Iljitsch discussed, a cluster of machines virtually acting
as a single host can be treated as a single host.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2003 11:35:16 +0100

Ohta-san,

In practical terms it matters very much. If the end point is distributed,
multihoming it is a much more complex operation (assuming you want sessions
to survive a multihoming event). Perhaps if you speak to some people actually
implementing virtualized server pools this would be clearer to you.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Dec 2003 19:47:49 +0900

Brian;

> implementing virtualized server pools this would be clearer to you.

Practically, the servers in a pool is concentrated, not distributed,
which means all the members shares external connectivity.

Or, if you are talking about servers distributed over multiple
sites, it is complex not because of M6 but because of involving
multiple sites.

Let's make a site or something members of which shares fate of
connectivity multihomed.

							Masataka Ohta

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 9 Dec 2003 13:13:41 +0100

> > i guess there is nothing wrong with it, as long as we define it

Id oes appears in RFC1958, but i couldn't find any precise definition of
what an end-system is in there

> with the difinition of Saltzer's paper, that is fine.

Sorry but i couldn't find any definition of an end-system in Saltzer paper
"END-TO-END ARGUMENTS IN SYSTEM DESIGN
", actually i couldn't even find the end-system expression on the paper
What i did found is the end-point expression a couple of times:

Like in:
"The function in question can completely and correctly be implemented only
with the knowledge and help of the application standing at the end points of
the communication system. "
or in
"Thus the end-to-end argument is not an absolute rule, but rather a
guideline that helps in application and protocol design analysis; one must
use some care to identify the end points to which the argument should be
applied."

However i couldn't find any precise definition about endpoint, so i reffer
to JNC's endpoint docuemnte where several really nice definition of endpoint
can be found.

The definition are (so you don't have to look for it)

"To recap, however, an "endpoint" is, in order of increasing
formality:

    - one participant of an end-end communication
    - the fundamental agent of end-end communication
    - the entity which is performing a reliable communication on an
      end-end basis

    - a fatesharing region
    - a boundary drawn around a set of state and/or computations such
      that it lives or dies as a unit"

So, so far i like using endpoint because we have a definition for it and
IMHO it suit our needs.

> Forget NSRG.

Why?

stack is also well defined in the nsrg report as: ".  A stack is defined as
one participant or the process on one side of an end-to-end communication.
"

So, IMHO we have endpoint and stack well defined
I haven't been able to find a definition for end-system, so i would adhere
to your own argument and propose that we just use an existent already
defined term and not try to introduce a new definition for a term here.

However, i still don't understand the difference between an endpoint and a
stack (especially since the definition of stack is the same as the first
definition of an endpoint...)

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2003 15:02:21 +0100

It's my fault for mentioning the need to document our terminology,
but this thread serves no useful purpose for multi6 that I can see.
I suggest that those interested now continue it off-list.

Thanks
    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 9 Dec 2003 15:39:44 +0100

On 9-dec-03, at 11:35, Brian E Carpenter wrote:

> to survive a multihoming event). Perhaps if you speak to some people 
> actually implementing virtualized server pools this would be clearer 
> to you.

This depends where we put the demarcation point. I think a place that 
puts multihoming functionality on one side, and host virtuality on the 
other would be a very good choice. In other words: this is something 
for the cluster software implementers to worry about.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Dec 2003 00:32:12 +0900

marcelo;

>>>i guess there is nothing wrong with it, as long as we define it
>>
>>precisely.

> what an end-system is in there

It depends on how precisely you understand RFC1958.

It is a concise draft.

> Sorry but i couldn't find any definition of an end-system in Saltzer paper

As I wrotge, it's in the RFC.

> So, so far i like using endpoint because we have a definition for it and

That is fine, as long as end system in RFC 1958 is no differnt from
end point in Saltzer's paper.

Can we reach the consensus?

> Why?

Because it is a new terminology useful for no new goals.

> one participant or the process on one side of an end-to-end communication.

People who engaged in NSRG activity has demonstrated that it is no
well defined.

However, if they repent that "stack" is identical to "end system"
of RFC1958 and Saltzer's "end point", I'm fine, though we still
have no reason to introduce terminlogy of "stack".

> I haven't been able to find a definition for end-system,

See RFC1958, especially, its reference.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Dec 2003 00:39:34 +0900

Brian;

> I suggest that those interested now continue it off-list.

If you are saying Erik's threats draft serves no useful purpose for
multi6, I can agree with you.

However, if you are not, we still have to discuss any possible
usefulness of Erik's and my threats drafts.

We agreed in the last meeting that we will have multiple drafts,
as not all of us are satisfied with Erik's.

You may still argue against, as long as you won't wear the hat.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2003 17:04:42 +0100

> for the cluster software implementers to worry about.

Architecturally, I agree. The devil is in the details, i.e. avoiding the
need for the cluster software to contain even more outrageous hacks
than today to make the virtualization work.

   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Dec 2003 07:03:12 +0900

Brian;

> than today to make the virtualization work.

Discontinue this thread. It is useless for any M6 purpose.

						Masataka Ohta