headers
Iljitsch van Beijnum | 1 Dec 01:14
Favicon

Re: Some Comments on ID/Loc Separation Proposals

On 1-dec-03, at 0:30, Masataka Ohta wrote:

>> Personally, I prefer to talk about hosts, as this is a well-known 
>> concept. 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.

> "virtualize" means "as if it is real.

> "virtualized host" means "muptiple entities behaving as if it is a
> single host".

> So, for the purpose of network protocol, treat it as a plain host.

Right.

> All the rest is internal implementation details within a host.

Yes. This is more or less my point.

> There is no room of confusion.

There is always room for two things: desert and confusion.  ;-)
Permalink | Reply | 0 comments |
headers
Masataka Ohta | 1 Dec 06:07
Picon

Re: delayed multihoming/mobility set-up

Dave Crocker;

> Iljitsch,
> 
> IvB>  The reason that BGP
> IvB> rerouting can take so long is that the RFC mandates a 90 second hold 
> IvB> time,

And a 90 second hold time is already too long.

> The reason that BGP has a long hold is because short times lead to route
> flapping.
> 
> This is an inherent property of doing route calculations.  A scheme that
> is too quick to change will be constantly changing.  Hence the
> assessment of a particular route always needs to be pretty slow to
> change the assessment.

And the definition on "too quick" is affected by time required
for BGP route computation, IGP route propagation and so on, all
of which are reduced with smaller routing table.

I think hold time for EBGP peering over point to point optical
ethernet should be (like SONET) several tens of milli seconds
(though it violates BGP4). However, the same timing can not
be applicable to IBGP peering.

Have smaller global routing table and make BGP converge as quickly
as that of telephone routing.
(Continue reading)

Permalink | Reply | 0 comments |
headers
marcelo bagnulo | 1 Dec 10:24
Picon

RE: Some Comments on ID/Loc Separation Proposals

> >    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
(Continue reading)

Permalink | Reply | 1 comment |
headers
marcelo bagnulo | 1 Dec 10:24
Picon

RE: Some Comments on ID/Loc Separation Proposals

> 
> 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>
> 
>
Permalink | Reply | 1 comment |
headers
Spencer Dawkins | 1 Dec 14:03
Favicon

Re: Some Comments on ID/Loc Separation Proposals

----- Original Message ----- 
From: "marcelo bagnulo" <mbagnulo <at> ing.uc3m.es>
To: "Dave Crocker" <dcrocker <at> brandenburg.com>; <multi6 <at> ops.ietf.org>
Sent: Monday, December 01, 2003 3:24 AM
Subject: RE: Some Comments on ID/Loc Separation Proposals

> >
> > 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

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
Permalink | Reply | 0 comments |
headers
Christian Huitema | 1 Dec 18:18
Picon
Favicon

RE: delayed multihoming/mobility set-up

> > IvB>  The reason that BGP
> > IvB> rerouting can take so long is that the RFC mandates a 90 second
> hold
> > IvB> time,
> 
> And a 90 second hold time is already too long.

... which is why I am convinced that the solution to preserving existing
communication is closest to "transport protocols" than "routing
protocols". The time scale of transport protocols is the RTT; the time
scale of routing protocols is the minute. If we wait for a routing event
to be somehow signaled to the transport stack, the connection will be
gone. The natural solution is to use a transport event, e.g. a
retransmission timer. This event can trigger an end-to-end "connection
rehoming" exchange.

My preferred time-line would be:

1) Start a communication using one of the available pairs of src/dest
addresses.
2) If the communication is determined to be worth it (i.e. last long
enough), engage in "multi-homing signaling" to obtain a "set of
equivalent addresses"
3) On a transport event such as retransmission time-out, probe alternate
pairs of src/dest addresses, and pick a "better one" if available.

I would note that a lot of the communication we have today do not meet
the "worth it" requirement. The top applications in the Internet today
are web pages, which mostly consist of a large number of very short
exchanges, and p2p file sharing, which includes its own application
(Continue reading)

Permalink | Reply | 614 comments |
headers
Erik Nordmark | 1 Dec 19:44
Picon

Re: Some Comments on ID/Loc Separation Proposals

>    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.

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
Permalink | Reply | 546 comments |
headers
Dave Crocker | 1 Dec 17:25

Re: Some Comments on ID/Loc Separation Proposals

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/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>
Permalink | Reply | 1 comment |
headers
Masataka Ohta | 1 Dec 20:48
Picon

Re: delayed multihoming/mobility set-up

Christian;

>>>IvB>  The reason that BGP
>>>IvB> rerouting can take so long is that the RFC mandates a 90 second
>>
>>hold
>>
>>>IvB> time,
>>
>>And a 90 second hold time is already too long.

> ... which is why I am convinced that the solution to preserving existing
> communication is closest to "transport protocols" than "routing
> protocols".

As you say "preserving", you really are talking about "connection",
not "communication" in general.

The proper argument is that

	preserving existing connection is a function of not the
	connectionless Internetworking layer but the transport
	layer (or above)

But, note that your argument is insufficient ignoring simple UDP
query-response type communication such as that of DNS.

> The time scale of transport protocols is the RTT; the time
> scale of routing protocols is the minute. If we wait for a routing event
> to be somehow signaled to the transport stack, the connection will be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Crocker | 1 Dec 20:59

Re: Some Comments on ID/Loc Separation Proposals

>> >            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").

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/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane