Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: NANOG: users

Shim6, was: Re: filtering /48 is going to be necessary

 

 

First page Previous page 1 2 3 4 Next page Last page  View All NANOG users RSS feed   Index | Next | Previous | View Threaded


josh.hoppes at gmail

Mar 14, 2012, 6:37 PM

Post #51 of 81 (418 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Wed, Mar 14, 2012 at 1:45 PM, Owen DeLong <owen [at] delong> wrote:
> I fully expect them to develop an HDCP-or-equivalent enabled protocol to run over IP Multicast.
>
> Do you have any reason you believe that won't happen?
>
> Owen

I'm pretty sure it's already in place for IPTV solutions.


mohta at necom830

Mar 14, 2012, 9:18 PM

Post #52 of 81 (414 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

Randy Bush wrote:

> none of which seem to move us forward. i guess the lesson is that, as
> long as we are well below moore, we just keep going down the slippery,
> and damned expensive, slope.

As long as we keep using IPv4, we are mostly stopping at /24 and
must stop at /32.

But, see the subject. It's well above moore.

For high speed (fixed time) routed look up with 1M entries, SRAM is
cheap at /24 and is fine at /32 but expensive and power consuming
TCAM is required at /48.

That's one reason why we should stay away from IPv6.

Masataka Ohta


mohta at necom830

Mar 14, 2012, 9:48 PM

Post #53 of 81 (414 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

William Herrin wrote:

> I've been an IRTF RRG participant and in my day job I build backend
> systems for mobile messaging devices used in some very challenging and
> very global IP and non-IP environments.

I know non-IP mobile environment is heavily encumbered. So, I
can understand why you insist on using DNS for mobility only
to make IP mobility as encumbered as non-IP ones.

> Au contraire. Triangle elimination is a problem because the IP address
> can't change with session survivability. But that's because TCP and
> UDP require it. If A follows from B and B follows from C then A
> follows from C: TCP is at fault.

If a correspondent host CH send packets to a mobile host MH,
it may be tunneled by a home agent HA or, with triangle
elimination, tunneled by CH itself, in both of which cases,
IP address of internal packets within tunnels are that of
CH and MH's home address, which is handled by TCP just
normally.

>> Ignoring that DNS does not work so fast, TCP becomes "it wasn't
>> sure what addresses it should be talking to" only after a long
>> timeout.
>
> Says who? Our hypothetical TCP can become "unsure" as soon as the
> first retransmission if we want it to. It can even become unsure when
> handed a packet to send after a long delay with no traffic. There's
> little delay kicking off the recheck either way.

That may be a encumbered way of doing things in non-IP, or
bell headed, mobile systems, where 0.05 second of voice
loss is acceptable but 0.2 second of voice loss is
significant.

However, on the Internet, 0.05 second of packet losses can
be significant and things work end to end.

In this case, your peer, a mobile host, is the proper
end, because it is sure when it has lost or are
losing a link.

Then, the end establishes a new link with a new IP and
initiate update messages for triangle elimination at
proper timing without unnecessary checking.

According to the end to end argument of Saltzer et. al:

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.

the mobility module of the mobile host has "the knowledge"
for proper timing to update triangle elimination "the function
in question".

Masataka Ohta


bill at herrin

Mar 15, 2012, 12:40 AM

Post #54 of 81 (409 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

2012/3/15 Masataka Ohta <mohta [at] necom830>:
> William Herrin wrote:
>> I've been an IRTF RRG participant and in my day job I build backend
>> systems for mobile messaging devices used in some very challenging and
>> very global IP and non-IP environments.
>
> I know non-IP mobile environment is heavily encumbered. So, I
> can understand why you insist on using DNS for mobility only
> to make IP mobility as encumbered as non-IP ones.

I don't understand your statement. None of the technologies I work
with use the word "encumbered" in a comparable context. Perhaps you
could rephrase?


>>> Ignoring that DNS does not work so fast, TCP becomes "it wasn't
>>> sure what addresses it should be talking to" only after a long
>>> timeout.
>>
>> Says who? Our hypothetical TCP can become "unsure" as soon as the
>> first retransmission if we want it to. It can even become unsure when
>> handed a packet to send after a long delay with no traffic. There's
>> little delay kicking off the recheck either way.
>
> That may be a encumbered way of doing things in non-IP, or
> bell headed, mobile systems, where 0.05 second of voice
> loss is acceptable but 0.2 second of voice loss is
> significant.
>
> However, on the Internet, 0.05 second of packet losses can
> be significant and things work end to end.

Get real. Even EAPS takes 0.05 seconds to recover from an unexpected
link failure and that's on a trivial Ethernet ring where knowledge
propagation is far less complex than a mobile environment.

For expected link failures, you can't get any fewer than zero packets
lost, which is exactly what my add/drop approach delivers.


> In this case, your peer, a mobile host, is the proper
> end, because it is sure when it has lost or are
> losing a link.

Correct, but...

> Then, the end establishes a new link with a new IP and
> initiate update messages for triangle elimination at
> proper timing without unnecessary checking.

This is where the strategy falls apart every time. You know when your
address set changes but you don't know the destination endpoint's
instant address set unless either (1) he tells you or (2) he tells a
3rd party which you know to ask. Your set and his set are both in
motion so there _will_ be times when your address set changes before
he can tell you the changes for his set. Hence #1 alone is an
_incomplete_ solution.

It was incomplete in SCTP, it was incomplete in Shim6 and it'll be
incomplete in MPTCP as well.

And oh-by-the-way, if you want to avoid being chatty on every idle
connection every time an address set changes and you want either
endpoint to be able to reacquire the other when it next has data to
send then the probability your destination endpoint has lost all the
IP addresses you know about goes way up.

Regards,
Bill Herrin


--
William D. Herrin ................ herrin [at] dirtside  bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


eugen at leitl

Mar 15, 2012, 3:54 AM

Post #55 of 81 (410 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Thu, Mar 15, 2012 at 01:18:04PM +0900, Masataka Ohta wrote:

> As long as we keep using IPv4, we are mostly stopping at /24 and
> must stop at /32.
>
> But, see the subject. It's well above moore.
>
> For high speed (fixed time) routed look up with 1M entries, SRAM is
> cheap at /24 and is fine at /32 but expensive and power consuming
> TCAM is required at /48.
>
> That's one reason why we should stay away from IPv6.

What prevents you from using
http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html
with IPv6?


mohta at necom830

Mar 15, 2012, 5:52 AM

Post #56 of 81 (408 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

William Herrin wrote:

>> I know non-IP mobile environment is heavily encumbered. So, I
>> can understand why you insist on using DNS for mobility only
>> to make IP mobility as encumbered as non-IP ones.
>
> I don't understand your statement. None of the technologies I work
> with use the word "encumbered" in a comparable context. Perhaps you
> could rephrase?

OK. You are bell headed.

>> However, on the Internet, 0.05 second of packet losses can
>> be significant and things work end to end.
>
> Get real. Even EAPS takes 0.05 seconds to recover from an unexpected
> link failure

If you keep two or more links, keep them alive, and let them
know their IP addresses each other, which can be coordinated
by mobile hosts as the ends, links can cooperate to avoid
broken links for a lot faster recovery than 0.05s.

> and that's on a trivial Ethernet ring where knowledge
> propagation is far less complex than a mobile environment.

The previous statement of mine merely assumes radio links with
sudden link failure by, say, phasing.

Its spatial diversity arranged by the mobile hosts as the ends.

If link failure is expected several seconds before, which is
usual with radio links, mobile hosts can smoothly migrate to
a new link without any packet losses, because it has much
time to resend possibly lost control packets.

>> In this case, your peer, a mobile host, is the proper
>> end, because it is sure when it has lost or are
>> losing a link.
>
> Correct, but...
>
>> Then, the end establishes a new link with a new IP and
>> initiate update messages for triangle elimination at
>> proper timing without unnecessary checking.
>
> This is where the strategy falls apart every time. You know when your
> address set changes but you don't know the destination endpoint's
> instant address set unless

Certainly, if two communicating mobile hosts, two ends, changes
their IP addresses simultaneously, they can not communicate
*DIRECTLY* each other, because they can not receive new IP
addresses of their peers.

The proper end for the issue is the home agent.

Just send triangle elimination messages to the home agent
without triangle eliminations.

With the new layer of indirection by the home agent, control
messages for triangle elimination are sent reliably (though
best effort).

The home agent knows reachable foreign addresses of mobile hosts,
as long as the mobile hosts can tell the home agent their new
foreign addresses before the mobile hosts entirely loses their
old links.


> either (1) he tells you or (2) he tells a
> 3rd party which you know to ask.

(3) he tells his home agent, his first party, to which you,
his second party, ask packet forwarding.

Unlike DNS servers, the first party is responsible for its
home agent.

> Your set and his set are both in
> motion so there _will_ be times when your address set changes before
> he can tell you the changes for his set. Hence #1 alone is an
> _incomplete_ solution.

A difficulty to understand the end to end principle is to
properly recognize ends.

Here, you failed to recognize home agents as the essential
ends to support reliable communication to mobile hosts.

> It was incomplete in SCTP, it was incomplete in Shim6 and it'll be
> incomplete in MPTCP as well.

It is complete though shim6 is utterly incomplete.

> And oh-by-the-way, if you want to avoid being chatty on every idle
> connection every time an address set changes and you want either
> endpoint to be able to reacquire the other when it next has data to
> send then the probability your destination endpoint has lost all the
> IP addresses you know about goes way up.

Idle connections may have timeouts for triangle elimination after
which they use home agents of their peers.

That's how the end to end Internet is working without any packet
losses not caused by congestion nor unexpected sudden link failures.

Masataka Ohta


mohta at necom830

Mar 15, 2012, 5:57 AM

Post #57 of 81 (407 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

Eugen Leitl wrote:

>> For high speed (fixed time) routed look up with 1M entries, SRAM is
>> cheap at /24 and is fine at /32 but expensive and power consuming
>> TCAM is required at /48.
>>
>> That's one reason why we should stay away from IPv6.
>
> What prevents you from using
> http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html
> with IPv6?

Though I didn't paid $32 to read the full paper, it's like
a proposal of geography based addressing.

So, I should ask what prevents you from using it with IPv4?

Masataka Ohta


eugen at leitl

Mar 15, 2012, 6:58 AM

Post #58 of 81 (410 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Thu, Mar 15, 2012 at 09:57:10PM +0900, Masataka Ohta wrote:

> >> That's one reason why we should stay away from IPv6.
> >
> > What prevents you from using
> > http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html
> > with IPv6?
>
> Though I didn't paid $32 to read the full paper, it's like
> a proposal of geography based addressing.

You can access the free full text at http://arxiv.org/pdf/1009.0267v2.pdf

> So, I should ask what prevents you from using it with IPv4?

Because IPv4 will be legacy by the time something like this lands,
and because IPv6 needs more bits/route so more pain there.


bill at herrin

Mar 15, 2012, 7:25 AM

Post #59 of 81 (410 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Thu, Mar 15, 2012 at 9:58 AM, Eugen Leitl <eugen [at] leitl> wrote:
> On Thu, Mar 15, 2012 at 09:57:10PM +0900, Masataka Ohta wrote:
>> >> That's one reason why we should stay away from IPv6.
>> > What prevents you from using
>> > http://www.nature.com/ncomms/journal/v1/n6/full/ncomms1063.html
>> > with IPv6?
>>
>> Though I didn't paid $32 to read the full paper, it's like
>> a proposal of geography based addressing.
>
> You can access the free full text at http://arxiv.org/pdf/1009.0267v2.pdf

Hi Eugen,

Geographic routing strategies have been all but proven to irredeemably
violate the recursive commercial payment relationships which create
the Internet's topology. In other words, they always end up stealing
bandwidth on links for which neither the source of the packet nor it's
destination have paid for a right to use.

This is documented in a 2008 Routing Research Group thread.
http://www.ops.ietf.org/lists/rrg/2008/msg01781.html

If you have a new geographic routing strategy you'd like to table for
consideration, start by proving it doesn't share the problem.

Regards,
Bill Herrin




--
William D. Herrin ................ herrin [at] dirtside  bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


eugen at leitl

Mar 15, 2012, 7:41 AM

Post #60 of 81 (408 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Thu, Mar 15, 2012 at 10:25:46AM -0400, William Herrin wrote:

> Geographic routing strategies have been all but proven to irredeemably
> violate the recursive commercial payment relationships which create
> the Internet's topology. In other words, they always end up stealing
> bandwidth on links for which neither the source of the packet nor it's
> destination have paid for a right to use.
>
> This is documented in a 2008 Routing Research Group thread.
> http://www.ops.ietf.org/lists/rrg/2008/msg01781.html
>
> If you have a new geographic routing strategy you'd like to table for
> consideration, start by proving it doesn't share the problem.

I think the problem can be tackled by implementing this in
wireless last-mile networks owned and operated by end users.
(Obviously the /64 space is enough to carry that information.
Long-range could be done via VPN overlay over the Internet).

This will reduce the local chatter for route discovery and remove
some of the last-mile load on wired connections, which is in
ISPs' interest. I think we'll see some 1-10 GBit/s effective
bandwidth in sufficiently small wireless cells.

If this scenario plays out, this will inch up to low-end gear
like Mikrotik and eventually move to the core.

I don't think this will initially happen in the network core for the
reasons you mentioned.


scott.brim at gmail

Mar 15, 2012, 7:44 AM

Post #61 of 81 (407 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Thu, Mar 15, 2012 at 10:41, Eugen Leitl <eugen [at] leitl> wrote:
> On Thu, Mar 15, 2012 at 10:25:46AM -0400, William Herrin wrote:
>
>> Geographic routing strategies have been all but proven to irredeemably
>> violate the recursive commercial payment relationships which create
>> the Internet's topology. In other words, they always end up stealing
>> bandwidth on links for which neither the source of the packet nor it's
>> destination have paid for a right to use.
>>
>> This is documented in a 2008 Routing Research Group thread.
>> http://www.ops.ietf.org/lists/rrg/2008/msg01781.html

> I think the problem can be tackled by implementing this in
> wireless last-mile networks owned and operated by end users.

Interesting point, and the growth in municipal networks could help.
But they are still a vast minority.

Scott


bill at herrin

Mar 15, 2012, 10:11 AM

Post #62 of 81 (401 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Thu, Mar 15, 2012 at 10:41 AM, Eugen Leitl <eugen [at] leitl> wrote:
> On Thu, Mar 15, 2012 at 10:25:46AM -0400, William Herrin wrote:
>> Geographic routing strategies have been all but proven to irredeemably
>> violate the recursive commercial payment relationships which create
>> the Internet's topology. In other words, they always end up stealing
>> bandwidth on links for which neither the source of the packet nor it's
>> destination have paid for a right to use.
>
> I think the problem can be tackled by implementing this in
> wireless last-mile networks owned and operated by end users.
> (Obviously the /64 space is enough to carry that information.
> Long-range could be done via VPN overlay over the Internet).

If an endpoint is allowed to have multiple addresses and allowed to
rapidly change addresses then a more optimal last-mile solution is
dynamic topological address delegation. Each IP represents a
current-best-path coreward through the ISP's network. When the path
changes, so do the downstream addresses. Instead of a routing protocol
you have an addressing protocol. In theory, such a thing automatically
aggregates into very small routing tables.

Very much a work in progress:
http://bill.herrin.us/network/name/nr1.gif
http://bill.herrin.us/network/name/nr2.gif
http://bill.herrin.us/network/name/nr3.gif

Regards,
Bill Herrin

--
William D. Herrin ................ herrin [at] dirtside  bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


bill at herrin

Mar 15, 2012, 10:31 AM

Post #63 of 81 (403 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

2012/3/15 Masataka Ohta <mohta [at] necom830>:
> William Herrin wrote:
>>> I know non-IP mobile environment is heavily encumbered. So, I
>>> can understand why you insist on using DNS for mobility only
>>> to make IP mobility as encumbered as non-IP ones.
>>
>> I don't understand your statement. None of the technologies I work
>> with use the word "encumbered" in a comparable context. Perhaps you
>> could rephrase?
>
> OK. You are bell headed.

If you want to be snippy in English, you should first gain a better
command of the language. Neither of your previous statements has a
meaning recognized beyond the confines of your own brain.


>> Your set and his set are both in
>> motion so there _will_ be times when your address set changes before
>> he can tell you the changes for his set. Hence #1 alone is an
>> _incomplete_ solution.
>
> A difficulty to understand the end to end principle is to
> properly recognize ends.
>
> Here, you failed to recognize home agents as the essential
> ends to support reliable communication to mobile hosts.

A device which relays IP packets is not an endpoint, it's a router. It
may or may not be a worthy part of a network architecture but it is
unambiguously not an endpoint.

If that isn't clear to you then don't presume to lecture me about the
end to end principle.

Regards,
Bill Herrin



--
William D. Herrin ................ herrin [at] dirtside  bill [at] herrin
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


hvgeekwtrvl at gmail

Mar 15, 2012, 10:38 AM

Post #64 of 81 (402 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

2012/3/14 Masataka Ohta <mohta [at] necom830>:
< stuff deleted >
> For high speed (fixed time) routed look up with 1M entries, SRAM is
> cheap at /24 and is fine at /32 but expensive and power consuming
> TCAM is required at /48.
>
> That's one reason why we should stay away from IPv6.
>
>                                                Masataka Ohta
>

I found this bit of research from 2007 (
http://www.cise.ufl.edu/~wlu/papers/tcam.pdf ). It seems to me there
are probably more ways to mix and match different types of ram to be
able to deal with this beast.

james


Valdis.Kletnieks at vt

Mar 15, 2012, 10:48 AM

Post #65 of 81 (403 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Thu, 15 Mar 2012 13:31:42 EDT, William Herrin said:
> 2012/3/15 Masataka Ohta <mohta [at] necom830>:
> > OK. You are bell headed.
>
> If you want to be snippy in English, you should first gain a better
> command of the language. Neither of your previous statements has a
> meaning recognized beyond the confines of your own brain.

http://www.pcmag.com/encyclopedia_term/0,2542,t=Bellhead&i=38536,00.asp

I don't think the term means what Masataka thinks it means, because nobody
in this discussion is talking in terms of circuits rather than packet routing.


tim at pelican

Mar 15, 2012, 11:23 AM

Post #66 of 81 (403 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

> I don't think the term means what Masataka thinks it means, because nobody
> in this discussion is talking in terms of circuits rather than packet routing.

Geographical addressing can tend towards "bellhead thinking", in the sense that it assumes a small number (one?) of suppliers servicing all end users in a geographical area, low mobility, higher traffic volumes towards other end-users in the same or a close geography, relative willingness to renumber when a permanent change of location does occur, and simple, tightly defined interconnects where these single-suppliers can connect to the neighbouring single-supplier and their block of geography.

I'm not sure he's right, but I think I understand what he's getting at.

Regards,
Tim.


Valdis.Kletnieks at vt

Mar 15, 2012, 12:03 PM

Post #67 of 81 (402 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Thu, 15 Mar 2012 21:52:54 +0900, Masataka Ohta said:

> > Get real. Even EAPS takes 0.05 seconds to recover from an unexpected
> > link failure
>
> If you keep two or more links, keep them alive, and let them
> know their IP addresses each other, which can be coordinated
> by mobile hosts as the ends, links can cooperate to avoid
> broken links for a lot faster recovery than 0.05s.

May work for detecting a dead access point in a wireless mesh, but
it doesn't scale to WAN sized connections.

Standard systems control theory tells us that you can't control a
system in less than 2*RTT across the network. There's *plenty* of
network paths where endpoint-homebase-endpoint will be over 50ms.
Consider the case where one endpoint is in Austria, the other is in Boston,
and the node handling the mobility is in Japan. Now a router fails in
Seattle. How long will it take for the endpoints to notice?

(Alternatively, explain how you locate a suitable home base node
closer than Japan. Remember in your explanation to consider that
you may not have a business relationship with the carrier that
would be an optimum location)


mohta at necom830

Mar 15, 2012, 3:56 PM

Post #68 of 81 (400 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

Eugen Leitl wrote:

>> So, I should ask what prevents you from using it with IPv4?
>
> Because IPv4 will be legacy by the time something like this lands,

Maybe. But, IPv6 will be so before IPv4 (or, is already IMHO).

> and because IPv6 needs more bits/route so more pain there.

Feel free to propose filter everything beyond /32 and get
accepted by the community.

Masataka Ohta


mohta at necom830

Mar 15, 2012, 4:31 PM

Post #69 of 81 (391 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

William Herrin wrote:

>> A difficulty to understand the end to end principle is to
>> properly recognize ends.
>>
>> Here, you failed to recognize home agents as the essential
>> ends to support reliable communication to mobile hosts.
>
> A device which relays IP packets is not an endpoint, it's a router.

If you want to call something which may not participate in
routing protocol exchanges a router, that's fine, it's your
terminology.

But, as far as HA has "the knowledge" obtained through
control packet exchanges with MH, it is the end that can
give "the help" to make mobile IP correct and complete.

> It
> may or may not be a worthy part of a network architecture but it is
> unambiguously not an endpoint.

Even ordinary routers are ends w.r.t. routing protocols, though
they also behave as intermediate systems to other routers.

As LS requires less intelligence than DV, it converges faster.

> If that isn't clear to you then don't presume to lecture me about the
> end to end principle.

Here is an exercise for you insisting on DNS, an intermediate
system.

What if DNS servers, including root ones, are mobile?

Masataka Ohta


mohta at necom830

Mar 15, 2012, 5:05 PM

Post #70 of 81 (394 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

james machado wrote:

>> For high speed (fixed time) routed look up with 1M entries, SRAM is
>> cheap at /24 and is fine at /32 but expensive and power consuming
>> TCAM is required at /48.
>>
>> That's one reason why we should stay away from IPv6.

> I found this bit of research from 2007 (
> http://www.cise.ufl.edu/~wlu/papers/tcam.pdf ). It seems to me there
> are probably more ways to mix and match different types of ram to be
> able to deal with this beast.

But it's not fixed time.

Worse, it synthesis IPv6 table from the current IPv4 ones, which
means the number of routing table entries is a lot less than 1M.

Masataka Ohta


Valdis.Kletnieks at vt

Mar 15, 2012, 5:08 PM

Post #71 of 81 (394 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Fri, 16 Mar 2012 08:31:07 +0900, Masataka Ohta said:
> Here is an exercise for you insisting on DNS, an intermediate
> system.
>
> What if DNS servers, including root ones, are mobile?

So, is this question more like:

What if computers worked in trinary?

or

What if people show criminal negligence in misdesigning their networks?

You're asking a "what if" for a usage case that nobody sane has suggested.


mohta at necom830

Mar 15, 2012, 5:25 PM

Post #72 of 81 (395 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

Valdis.Kletnieks [at] vt wrote:

>> If you keep two or more links, keep them alive, and let them
>> know their IP addresses each other, which can be coordinated
>> by mobile hosts as the ends, links can cooperate to avoid
>> broken links for a lot faster recovery than 0.05s.
>
> May work for detecting a dead access point in a wireless mesh,

That's not my point. My point is to avoid dead links.

Base stations try sending packets to a MH and if it fails
a few times, they forward the packet to other base stations
which may have live links to the MH.

> but
> it doesn't scale to WAN sized connections.

Regardless of whether links are wireless or wired, the
coordination is necessary only within (small number of)
links to which MH, the end, is attached, which means the
coordination is a local coordination if coordinated by
the end.

There is no WAN involved for the coordination.

> Consider the case where one endpoint is in Austria, the other is in
Boston,
> and the node handling the mobility is in Japan. Now a router fails in
> Seattle. How long will it take for the endpoints to notice?

Huh?

> (Alternatively, explain how you locate a suitable home base node

No home agent is involved for the recovery.

Masataka Ohta


mohta at necom830

Mar 15, 2012, 5:29 PM

Post #73 of 81 (393 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

Valdis.Kletnieks [at] vt wrote:

> You're asking a "what if" for a usage case that nobody sane has suggested.

If you are saying it's insane to use DNS to manage frequently
changing locations of mobile hosts instead of relying on
immobile home agents, I fully agree with you.

Masataka Ohta


mysidia at gmail

Mar 15, 2012, 5:49 PM

Post #74 of 81 (394 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

2012/3/15 Masataka Ohta <mohta [at] necom830>:
> Valdis.Kletnieks [at] vt wrote:
>> You're asking a "what if" for a usage case that nobody sane has suggested.
>
> If you are saying it's insane to use DNS to manage frequently
> changing locations of mobile hosts instead of relying on
> immobile home agents, I fully agree with you.
>                                                Masataka Ohta

Non sequitur.

Mobile root DNS servers are what is insane, because the queries must
terminate somewhere, and ultimately there must be something that
doesn't have a circular dependency -- requiring working DNS to get
DNS.

As for using DNS to manage frequently changing locations of mobile hosts,
DNS is almost perfect for that -- it's just the sort of thing DNS is
designed for,
depending on how frequent you mean by "frequently changing".


--
-JH


Valdis.Kletnieks at vt

Mar 15, 2012, 5:55 PM

Post #75 of 81 (394 views)
Permalink
Re: Shim6, was: Re: filtering /48 is going to be necessary [In reply to]

On Fri, 16 Mar 2012 09:29:44 +0900, Masataka Ohta said:
> Valdis.Kletnieks [at] vt wrote:
>
> > You're asking a "what if" for a usage case that nobody sane has suggested.
>
> If you are saying it's insane to use DNS to manage frequently
> changing locations of mobile hosts instead of relying on
> immobile home agents, I fully agree with you.

I'm specifically saying that "what if the root servers are mobile?" is a stupid
question, because nobody sane has proposed that they be mobile.

Hope that makes it clearer for you.

First page Previous page 1 2 3 4 Next page Last page  View All NANOG users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.