Subject: [rrg] ILNP q1: Scalability

From: Dae Young KIM <[email-masked]>
Date: Wed, 26 May 2010 20:47:09 +0900

Hi,

Now that the decision is made for ILNP and there's not yet the ILNP WG
formed, would it yet be appropriate to raise some questions in regard
to ILNP to facilitate better and clearer understanding of the
technology?

Although some previous responses have been sometimes something like
'you read the draft', to some slow people like me, there still remain
curiosities not to be cleared only out of the given text. Or the text
is too long to know where to find the answer.

As long as this is a research group(RG), I'd assume there'd be some
room for pedagogical purposes, I'd hope.

So, could anyone bother to give some comments to my following line of
thoughts, please?

   o I understand the granularity of the Locator is a subnet.
   o As seen from outside of a given site, the effective granularity
of the Locators stemming out is a site, for all such Locators will
eventually be aggregated to a number representing the very site in a
single entry in the IDR router table.
   o Even with the current Internet, the whole network prefixes
belonging to a well-behaved site would be aggregated to a single
shorter prefix representing the very site in a single entry in the IDR
router table. (.. except for some multi-homed hosts inside the site.)

Then, here's the question:

   Q1: What is the gain of ILNP over the current system in terms of
its effectiveness in reducing the IDR table size?

Perhaps, so obvious for the author or pros, but not to me at the moment, yet.

-- 
DY

---

From: <[email-masked]>
Date: Wed, 26 May 2010 16:42:34 +0200

Dear Dae Young,

Me too I failed to understand how ILNP solves the scalability issue. This is not analysed in the three ILNP drafts neither in the recommendations document edited by Tony. I suggested to Tony in the past to have more analysis text on this point.

The ILNP draft does not specify how to implement INLP in IPv4 environments. Only a L32 is defined in the DNS ILNP draft. 

BTW, I'm not sure if the scalability issue can be solved in a PI scheme.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dae Young KIM
Envoyé : mercredi 26 mai 2010 13:47
À : RRG
Objet : [rrg] ILNP q1: Scalability

Hi,

-- 
DY
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Tony Li <[email-masked]>
Date: Wed, 26 May 2010 08:51:20 -0700

> its effectiveness in reducing the IDR table size?

ILNP allows sites to be effectively multi-homed by allowing each host to
have multiple locators simultaneously and transitioning across locators
seamlessly.  This allows us to migrate to a PA based addressing
architecture.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 27 May 2010 01:32:52 +0900

At least, I'm not the only one lagging behind.

-- 
DY

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 26 May 2010 14:09:47 -0400

> seamlessly.  This allows us to migrate to a PA based addressing

It's also fair to say that some/all of the gain is explained in the
GSE/8+8 paperwork... Individual site-level information doesn't have to
be globally exposed in the routing table(s). (noting this as a pointer
to other docs on the subject.)

-Chris

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 May 2010 11:30:25 -0700

The ILNP Locator is, in effect, an IPv6 Prefix. The important question is in the rules by which it is generated; that is simple to implement but perhaps a little more difficult to describe.

In theory, you could have a 1:1/onto mapping between any 64 bit prefix within an edge network and a different 64 bit prefix at its ISP. Speaking in practical terms, doing so means some form of configuration or state maintenance that maintains the mapping. A stateless version of that might be found in http://tools.oetf.org/draft-mrw-behave-nat66; neglecting the matters of checksum calculation (which are unnecessary in an ILNP world), the mapping between an internal and an external prefix is literally to overwrite some number of bits in the prefix. If for example the internal network is using a /48 ULA and the external network is using a /56 prefix, one would overwrite 56 bits of the prefix in either direction, leaving the remaining 8 bits as they stand. There is the question of topology obfuscation (which I consider a red herring but I hear folks talk about); an option would be to literally overwrite 64 bits as though the internal network was a flat /64; that has issues in proving that the EID is in fact unique within the internal network, but could be made to work.

So, yes, a locator is in some sense a subnet, but can also be aggregates of subnets in various ways. That becomes, if you will, a site.

> its effectiveness in reducing the IDR table size?

The way I see it, the fundamental benefit of GSE or any of its successors, of which ILNP is one, is that the edge network is able to operate as if its address was provider-independent, and the transit domain is able to operate as if the address is provider-allocated. Neither adds additional complexity, as compared to (say) shim6, which forces the edge network to accept the additional complexity of routing multiple prefixes for the same subnet, or a truly PI network, which forces the transit domain to enumerate edge networks.

I think you will find, from the potaroo numbers, that there are on the order of 5000 transit networks in the world. Apart from BGP Traffic Engineering, which none of these address, that says that you should expect about 5000 PA prefixes, as opposed to O(10^6) to O(10^7) PI prefixes. There are of course some edge networks that really do work best with their own prefix at the edge; if you wave your hands and accept that anyone that has an AS number now falls in that category (which I would dispute, but that's another discussion), we're looking at O(30,000) such prefixes today. Again, the comparison is O(10^4) as opposed to O(10^6) or O(10^7).

> Perhaps, so obvious for the author or pros, but not to me at the moment, yet.

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Wed, 26 May 2010 12:53:04 -0700

Dumb question... do we need an ILNP WG? What would its charter be?

On May 26, 2010, at 4:47 AM, Dae Young KIM wrote:

> formed

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 27 May 2010 09:22:25 +0900

Hi, Tony,

I have two problems in communication:

  o I'm in fact not a routing expert, even without any field
experience. I'm just a teacher, so that I have to know clearer to
teach my students in the right direction.

  o Over more than 40 years, English is still my foreign language so
that I sometimes have a problem in extracting the full
meaning/implication out of beautiful/concise wordings.

And so, please be patient with me a little bit more, and let me give
you an ensuing question below.

> seamlessly.  This allows us to migrate to a PA based addressing

Suppose the same situation in the current Internet that a site is
multi-homed. So, for example, my site has got two sets of PA addresses
from two ISPs.

Then each host in my site would have two IP addresses.

Then, think about any host transitioning across these two addresses.

Is there any other problem with this activity than the one you
described above in terms of ILNP?

To me, it looks quite equivalent. My host will know of the two in
existence, and will switch between the two as need arises.

I assume we're talking about multi-homing, not mobility here
specifically in this context. If it's about mobility, I can see that
ILNP has an advantage for TCP connection is not associated with
locator while it would be with the current IP address.

But as long as you were talking about multi-homing, you would not mean
fast transitioning without breaking a TCP connection. You would
implicitly mean a situation where the same host would be associated
with a connection at one point in time and with another at a different
point in time. Or even with two simultaneous yet separate connections.

In all these connection scenarios, I would assume that the effect
would be the same in both cases of ILNP and the current Internet.

I must be missing a critical point here.

But, if I'm not, wouldn't it the description of yours apply in the
same way to the current Internet? The same situation with multiple PA
addresses?

Remember, in my scenario, I'm not using PI addresses.

Help me out, please.

-- 
DY

---

From: Tony Li <[email-masked]>
Date: Wed, 26 May 2010 17:52:08 -0700

Hi Dae,

> multi-homed. So, for example, my site has got two sets of PA addresses

In today's world, the cannonical approach for that site is to use PI
addressing.  This is necessary since the existence of two sets of PA
addresses would NOT give correspondent hosts a seamless failover experience.
Instead, it would result in an unacceptable service interruption.  Thus,
sites argue for, and get PI addresses.

These subsequently are distributed globally by BGP, and are a signficant
contributor to the global routing table, especially in IPv6.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 27 May 2010 09:53:46 +0900

Hi, Fred,

> The way I see it, the fundamental benefit of GSE or any of its successors, of which ILNP is one, is that the edge network is able to operate as if its address was provider-independent, and the tran…

- quote end -

This let's me raise two more questions.

  1. Would it mean that, as long as routing scalability is concerned,
adopting GSE would provide the same effect and so we wouldn't need the
extra (small?) pain of adopting ILNP?

  2. As I understand, in a multi(double)-homing situation, a site
would be given two sets of PA locators. And so, subnet locators inside
would be aggregated to two shorter aggregated locators; two, not one.
You say above that, even with ILNP, there would be only single PA
locater visible in DFZ. Perhaps, you're mistaken?

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 27 May 2010 10:09:33 +0900

> sites argue for, and get PI addresses.

Even in ILNP, the remote correspondent host would see two PA locators
for my host, not one. The the same failover problem would exist. Not
correct?

If correct, then do you mean the failover would be seamless with ILNP
and not with the current Internet, even though both are involved with
the same number of multiple PA locators/addresses?

I'm wondering whether your description above is meant to blame the
current Internet architecture itself or the wrong policy of ever start
allocating PI addresses.

If the PI address practice is to blame, why should we ever look for
new architecture?

If the Internet architecture itself is to blame, because it cannot do
the 'seamless' failover as could be done with ILNP, then I could
understand why we ever started this whole RRG procedure.

Which is the case?

-- 
DY

---

From: Toni Stoev <[email-masked]>
Date: Thu, 27 May 2010 13:11:41 +0300

On Thursday 27 May 2010 at 03:22:25 Dae Young KIM sent:

> experience.

Who's a routing expert in this group? And in what routing? The one that lacks scalability?

> I'm just a teacher, so that I have to know clearer to 

I am a student in the University of Life.

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 27 May 2010 10:38:17 -0400

> the same number of multiple PA locators/addresses?

like 8+8/GSE ILNP allows the hosts to separate their identifiers (PA
addresses on interface(s)) from the L4 headers/conversation. The same
sort of thing is proposed in MIP and SHIM6, you can rotate the
underlying interface identifiers at will, as long as you communicate
with the far end that you're identifier addressing has changed,
independent of the ongoing TCP/UDP/ICMP conversations.

> understand why we ever started this whole RRG procedure.

I don't think it's as simple as 'the internet architecture is to
blame' but the addition of the L3 header info in L4 checksums is
certainly part of the problem... the fact that host stacks also tie
the connection to a block of ip/proto/port is another problem. ILNP
tries to correct that (in the same basic way 8+8/gse did).

-chris

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 May 2010 08:33:27 -0700

> described above in terms of ILNP?

There can be at the transport or application layers, in two forms. In both cases, the issue is that a network layer address is meaningful at the network layer and not really meaningful above it, but we have collectively not done well in remembering that. For a good rant on the topic, I would suggest reading the works of Saltzer such as 

http://www.ietf.org/rfc/rfc1498.txt
1498 On the Naming and Binding of Network Destinations. J. Saltzer.
     August 1993. (Format: TXT=24698 bytes) (Status: INFORMATIONAL)

or listening to John Day.

At the Transport Layer, if the transport considers a session to be with a remote destination at a locator, and the locator changes during a session, the transport layer will not recognize it and as a result the session will fail. That, specifically, is why ILNP specifies that the locator is not included in transport layer checksums; some would argue that it should not be communicated to the transport at all.

At the Application Layer, any use of a network layer address has pitfalls. You might want to review 

http://www.ietf.org/rfc/rfc2993.txt
2993 Architectural Implications of NAT. T. Hain. November 2000.
     (Format: TXT=74136 bytes) (Status: INFORMATIONAL)

for a reminder of why IPv4/IPv4 Network Address Translation has been a headache. These issues remain in ILNP when the application uses a network layer address indiscriminately; routing protocols can have difficulties across the boundary between addressing domains, HTTP Referrals may not be meaningful, SIP/SDP can fail when it communicates the address of a communicant, and so on. The rule has to be that IF ONE IS GOING TO USE A NETWORK LAYER ADDRESS one uses the address appropriate to the peer (an "inside" address if the peer is in the same domain, and an "outside" address in other cases), or (much better) applications confine themselves to using application layer identifiers such as DNS names.

> existence, and will switch between the two as need arises.

There I disagree, or disagree in part. My DNS system will need to know of all of the addresses; my host needs to know only if it is responsible for populating them into DNS. 

Let me draw a picture for you. 
                                             ,-.
                         ,---------.        /   \
                      ,-'           `+-+  +-+    \     ,-.
           ,-----. +---+    ISP 1    |R+--+R|     :   /   \
        ,-'       `+DMZ+.           ,+-+  +-+     :  /     \
       /+-+        +-+-+ `---------'     ;       +---+ +-+  :
      / |A|           \                  |       |DMZ| |C|  |
     ;  +-+            :                 | ISP 3 +-+-+ +-+  ;
     |           +-+   |                 |         | \Your /
     :           |B| +---+---------.     :         ;  \Domain
      \ MyDomain +-+ |DMZ|          +-+   +-+     ;    `-'
       \             +---+  ISP 2   |R+---+R|     ;
        `-.       ,-'  `.           +-+   +-+    /
           `-----'       `---------'        \   /
                                             `-'

In my domain, I have two hosts: my own is A, and B is another one. In your domain, you have some host C. When B or C want to communicate with A, they ask DNS for A's set of addresses. Ideally, B gets A's "inside" address and C gets A's two "outside" addresses; more probably, each will get all three, and sort among them by discovering, in B's case, that A has an address that is "more similar" (matches a longer subset of its prefix) than the other two, or some of the addresses simply don't work. The question is how the DNS system gets A's 3 addresses. A is actually only aware of the "inside" address and will only use that; however, DNS knows the translation to the external set of addresses, and if A is posting addresses via Dynamic DNS, will do that translation when addresses are posted. If the DNS system isn't doing that, then of course A will have be aware of its addresses.

> locator while it would be with the current IP address.

Actually, multihoming becomes a special case of mobility.

> point in time. Or even with two simultaneous yet separate connections.

If the locator is irrelevant at transport and above, this also helps with the multipath TCP case. It requires the application to send not to a given remote address but to all of them, but it has that possibility.

> same way to the current Internet? The same situation with multiple PA

yes and no; TCP in the present internet cares a great deal about the locator, and applications do as well. Shim6 tries to address those issues, but a shim6 internet is not the same as the present one either.

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 May 2010 08:38:17 -0700

> extra (small?) pain of adopting ILNP?

ILNP addresses a failure mode of GSE. No, we don't *need* ILNP, but then we don't get a solution to the on-path attack it corrects.

> locater visible in DFZ. Perhaps, you're mistaken?

Perhaps I didn't say what I said clearly. If I have service from multiple ISPs and therefore multiple PA addresses, each of the PA addresses will be visible in the DFZ, and each of my ISPs will only service its own PA address. 

What I said above is that within the edge network, ILNP configures one "inside" prefix per subnet where SHim6 configures multiple provider-allocated "outside" prefixes on the same subnet. ILNP carries with it a translation - at the DMZ between the edge network and the transit network, the locator is changed between the "inside" prefix and the ISP's prefix.

---

From: Steven Blake <[email-masked]>
Date: Thu, 27 May 2010 12:26:59 -0400

On Thu, 27 May 2010 08:38:17 -0700, Fred Baker <[email-masked]> wrote:

>>> The way I see it, the fundamental benefit of GSE or any of its
>>> successors, of which ILNP is one, is that the edge network is able to
>>> operate as if its address was provider-independent, and the transit
>>> domain is able to operate as if the address is provider-allocated.
>>> Neither adds additional complexity, as compared to (say) shim6, which
>>> forces the edge network to accept the additional complexity of routing
>>> multiple prefixes for the same subnet, or a truly PI network, which
>>> forces the transit domain to enumerate edge networks.
>> 
>> - quote end -
>> 
> ILNP addresses a failure mode of GSE. No, we don't *need* ILNP, but then
> we don't get a solution to the on-path attack it corrects.

I think you mean "off-path attack" (i.e., the source address spoofing
issue with GSE that ILNP addresses using ICMP locator updates + nonce, and
the separate I & L DNS records + DNSSEC).

> Perhaps I didn't say what I said clearly. If I have service from
multiple
> ISPs and therefore multiple PA addresses, each of the PA addresses will
be
> visible in the DFZ, and each of my ISPs will only service its own PA
> address. 
> 
> What I said above is that within the edge network, ILNP configures one
> "inside" prefix per subnet where SHim6 configures multiple
> provider-allocated "outside" prefixes on the same subnet. ILNP carries
with
> it a translation - at the DMZ between the edge network and the transit
> network, the locator is changed between the "inside" prefix and the
ISP's
> prefix.

Locator translation at the site edge is optional with ILNP.  So if one
wishes to expose PA prefixes into the edge network, they can.

Strictly speaking, locator translation is also optional in GSE, but I
don't think that anyone ever considered deploying it that way.

Regards,

// Steve

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 May 2010 10:27:34 -0700

On May 27, 2010, at 9:26 AM, Steven Blake wrote:

> Locator translation at the site edge is optional with ILNP.  So if one wishes to expose PA prefixes into the edge network, they can.

well, yes, but then I don't want to hear about the issues related to renumbering when the edge network changes upstream providers. That was its choice. If it changes providers and keeps using the PA prefix internally, it will have problems communicating with whoever next gets allocated that prefix.

I would expect that, in an ILNP world, edge networks will all use some variant on a local prefix, and do so for this reason.

---

From: Tony Li <[email-masked]>
Date: Thu, 27 May 2010 10:43:21 -0700

>> Locator translation at the site edge is optional with ILNP.  So if one wishes
>> to expose PA prefixes into the edge network, they can.
> 
> well, yes, but then I don't want to hear about the issues related to
> renumbering when the edge network changes upstream providers. That was its
> choice. If it changes providers and keeps using the PA prefix internally, it
> will have problems communicating with whoever next gets allocated that prefix.
> 
> I would expect that, in an ILNP world, edge networks will all use some variant
> on a local prefix, and do so for this reason.

Well, we could work on renumbering, to make that a bit more efficient.  ;-)

It's not that hard, all the piece parts are there...  We need to be able to
inject a set of locators into the IGP.  Then we need an option in ND to
propagate that to the hosts.

Tony

---

From: Fred Baker <[email-masked]>
Date: Thu, 27 May 2010 15:07:09 -0700

> propagate that to the hosts.

See RFC 4192. It turns out that if people are sensible, renumbering is almost trivial. The biggest problems are configurations in routers that require explicit statement of addresses or prefixes (ACLs, Route Maps, etc) and shortcuts people take in applications. But those configurations and shortcuts... When I wrote the first cut at that document, I sent a note to some operational lists saying "I know you're going to tell me I'm nuts; what I need to understand is *why* I'm nuts". It was quite an education.

I would not underestimate the operational issues in renumbering.

---

From: Tony Li <[email-masked]>
Date: Thu, 27 May 2010 15:22:53 -0700

Hi Fred,

I never underestimate operational issues.  ;-)  In previous lives I've been
a sysadmin/network admin/ISP.  Got those scars the hard way.

When systems explicitly know that locators are separate from addresses, when
locators can be automagically changed, then we can GREATLY reduce the
sysadmin's manual work and make it that much easier (read cheaper) to
renumber.  

We just need to spend the time to work on this technology.

Tony

On 5/27/10 3:07 PM, "Fred Baker" <[email-masked]> wrote:

> See RFC 4192. It turns out that if people are sensible, renumbering is almost
> trivial. The biggest problems are configurations in routers that require
> explicit statement of addresses or prefixes (ACLs, Route Maps, etc) and
> shortcuts people take in applications. But those configurations and
> shortcuts... When I wrote the first cut at that document, I sent a note to
> some operational lists saying "I know you're going to tell me I'm nuts; what I
> need to understand is *why* I'm nuts". It was quite an education.
>

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 28 May 2010 07:55:42 +0900

> independent of the ongoing TCP/UDP/ICMP conversations.

You're talking about host mobility here, since you're concerned with
TCP connections. I can understand this situation. And, if only for
mobility, there're a number of other proposals already out there
including HIP.

Was the initial/primary goal in regard to mobility? I don't think so.
It was to multi-homing.

With multi-homing situation, I don't think we're so much sensitively
concerned with breakage of TCP connections. Our primary concern here
is how our new scheme would significantly contribute to reduction of
DFZ routing table size, i.e., routing scalability.

Would you please compare the performance quality of the current
Internet (assuming use of only PA addresses, not PI) against ILNP in
terms of routing scalability?

> tries to correct that (in the same basic way 8+8/gse did).

I think your concern here also seems to be focused on mobility. Let's
take the example in view of multi-homing.

And please be kind to elaborate more why ILNP would outperform the
current Internet

   - with ILNP hosts seamlessly transitioning/failover across multiple Locators
   - against old hosts transitioning across multiple PA addresses.

-- 
DY

---

From: Tony Li <[email-masked]>
Date: Thu, 27 May 2010 16:13:12 -0700

> concerned with breakage of TCP connections.

Disagree strongly.  People multi-home for service reliability, both inbound
and outbound.  They use PI because when there is a failure, routing will
reconverge and sessions will continue.

> terms of routing scalability?

? That's assuming the solution.  The whole point is to wean the Internet
from PI.

>    - against old hosts transitioning across multiple PA addresses.

Old hosts don't transition.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 28 May 2010 08:22:37 +0900

Hi, Fred,

Of course, I know at least this much. This is the rationale for all
those ID/Loc separation. And ILNP is one of them.

I'm not here to argue against ID/Loc separation. As far as I take for
granted that ILNP will be our choice by RRG, I'm not arguing against
ID/Loc separation.

As far as I know, some ID/Loc separation was started to improve
mobility; HIP would be one such example.

Other LIS proposal were more focused to multi-homing; Shim6 might be,
if I'm not wrong, one such example.

And here, we're also primarily concerned with multi-homing to improve
routing scalability, hence ILNP.

Now I want to know more in depth how practically ILNP improves on
routing scalability in DFZ, and how significantly?

I was trying to catch this aspect by comparing

   - how ILNP deals with multiple Locators and
   - how the current Internet deals with multiple PA addresses.
> Let me draw a picture for you.

I think you're describing here a case of NAT, e.g., private address.

In my question to Tony, I was specifically confining the case to PA
addresses; multi-home sites in both ILNP and my example of the current
Internet would use PA Locators or addresses.

I'd like to know the performing difference in these two scenarios.

> Actually, multihoming becomes a special case of mobility.

I know, but not completely.

Multi-homing can be considered as slow mobility. With fast mobility,
you'd be sensitive about continuity of TCP connections. With
multi-homing, you'd be more relaxed and only concerned about roaming
aspects. A host in a site-multi-homed host would have multiple PA
addresses, and the host or remote correspondent nodes would be more
concerned about which address to use in a newly initiating connection.

> If the locator is irrelevant at transport and above, this also helps with the multipath TCP case. It requires the application to send not to a given remote address but to all of them, but it has th…

Of course. But, again, let's please focus on behavior in
transitioning/failover across multiple-PA Locators/addresses.

> yes and no; TCP in the present internet cares a great deal about the locator, and applications do as well. Shim6 tries to address those issues, but a shim6 internet is not the same as the present o…

I think, we're shooting at different targets here. Your statement here
is of course correct. My focus is how to reduce the DFZ routing table
size.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 28 May 2010 08:37:24 +0900

> What I said above is that within the edge network, ILNP configures one "inside" prefix per subnet where SHim6 configures multiple provider-allocated "outside" prefixes on the same subnet. ILNP carr…

At the bottom of page 6 of ILNP intro v3, it says

  "In the new scheme, when a node is multi-homed, it has more than one
valid Locator value."
  "In the new scheme, site multi-homing works in a similar manner,
   with nodes having one Locator for each upstream connection to
   the Internet.

So, I'd think your description about ILNP multi-homing is incorrect.
>From seen from outside, multi-homed sites would be seen to have
multiple site Locators; of course, only one each will be traced back
through each ISP.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 28 May 2010 08:52:40 +0900

> propagate that to the hosts.

OK. This is the answer to the point.

Thanks.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 28 May 2010 08:54:03 +0900

Thanks.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 28 May 2010 08:54:33 +0900

Sorry, misposting.

-- 
DY

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 27 May 2010 22:19:07 -0400

> You're talking about host mobility here, since you're concerned with

no, mobility is 'free' with ilnp/gse/8+8, it's just a class of
multihoming with a higher rate of underlying change. I was
specifically talking about multihoming.

> mobility, there're a number of other proposals already out there

which has gotten stellar adoption so far, right up there with SCTP...
we're off topic some. I was talking about multihoming. The ability to
have redundant/resilient/cost-effective paths to/from remote
destinations, and (with ilnp/gse/8+8) the ability to do that without
introducing lots of state in the global routing system.

> DFZ routing table size, i.e., routing scalability.

sure, DFZ has, in the most simple form, 1 route per 'ISP', folks can
attach/detach from the best option for them at the time in question.
They can do this without having to tell the whole of the routing world
'I moved'.

> terms of routing scalability?

assuming ONLY pa? the internet wouldn't be what it is today. If you
could assume that there were ONLY PA addresses in use and thus no one
wanted to 'multihome' then... it's the same as ILNP modulo some DNS
hackery which ILNP requires.

Note, you lose all redundancy, resiliency and convenience of having
local identifiers which are stable.

> take the example in view of multi-homing.

it's not mobility, though mobility is just multihoming at a faster change rate.

>   - against old hosts transitioning across multiple PA addresses.

old-hosts don't do this, they have a locator. if that locator changes
(they renumber) then all their current connections stop, all reset and
all restart when all distant endpoints re-learn the new locators.

under ILNP you have the option to move locators 'at will' (gated by
how quickly you can tell the exisitng endpoints "and start talking to
me via this new locator, NOW.")  When you change attachment points all
existing communications just keeps on going, without
loss/reset/restart/timeout.

Further to do something similar in today's internet you must announce
new state into the global routing table, you keep your local
'identifier' (which is your ip address) unchanged and you move
attachment points as you want. You make everyone else pay for the
extra state management in the routing system though :( (nicely they
make you pay for their extra state...)

-chris

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 28 May 2010 12:04:35 +0900

> specifically talking about multihoming.

OK. Taken.

>> if only for

OK. You're talking about multi-homing.

> hackery which ILNP requires.

OK.

> local identifiers which are stable.

This will be my private homework yet, if the local identifier(host IP
address) would not point to the interface but to the node itself.

I know a lot of people out there already know much about this
scenario, which they say will only be futile.

I'm not convinced about this yet, and not to annoy other experts here,
I'll keep this to my private homework. Whether local addressing could
survive for routing scalability.

> all restart when all distant endpoints re-learn the new locators.

Sad there's no mechanism (or inherently impossible) that a multi-home
site and so all nodes inside deal with multiple PA addressed assigned
to them in a seamless (not causing the breakages you describe above)
manner.

> loss/reset/restart/timeout.

Of course with ILNP.

> make you pay for their extra state...)

Not if there'd be a mechanism that you keep your local node address
and not to have to report your intra-site moving to change any state
in the global routing table... which, apparently, is already a
nonsense to most routing experts in this group.

-- 
DY

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 28 May 2010 01:03:07 -0400

> address) would not point to the interface but to the node itself.

this is how some (for instance) root servers today do anycast
services. Put the 'service' ip address on the loopback interface (or
similar alternate interface) then just route traffic over the other
locally connected interfaces ... This works fine, it's not something
an average user wants (or really can) manage though. It requires still
some knowledge, at least in the local network realm, that ip-X is down
one of several interfaces. Expanding this to 'down several providers'
means that the providers must know, and thus the world must know that
this /32 (ip-X) is globally reachable. This is done with PI space and
we all pay a penalty (we all dfz router operators and users of the
internet) for this 'feature'.

> survive for routing scalability.

can't.

> to them in a seamless (not causing the breakages you describe above)

Oh you CAN do this, you don't WANT to, there are lots and lots of
dependencies and timelines to satisfy. All of which make the pain of
changing things far to costly and complex to implement 'quickly'. For
a simple case: 1 host, 2 providers 1 router. Here's a short list of
things to consider (no particular order)

o access controls on the host (from which ip, to which ip)
o dns updates for changes
o publishing dns records for each identifier/address
o traffic engineering to assure that folks use the addresses being
advertised over DNS properly/fairly
o upstream uRPF checks (must send to the internet with the right
source-address, based on which outbound port is choosen)

There are a few others I'm sure, never mind the case of a more complex
Enterprise network deployment.

>> loss/reset/restart/timeout.

this is one of the strengths of the ilnp/8+8/gse solutions, really.
Once/if the mapping-foo can be addressed in a sane/simple manner I
think this has some promise.

> Not if there'd be a mechanism that you keep your local node address

you can, it's PI (provider independent space).

> nonsense to most routing experts in this group.

uhm, so my host has ip address A, it's got attachments to networks B, C, D.

how does the world know that services on A are behind B, C, D except
for bgp telling them?
If you choose to tell them via DNS you're telling them "Find me at B"
and their packets (today) get addressed to B, not A. This only works,
today, if you tell them, in DNS, "A is me, send to A"... but then as
we move from B, C, D we have to tell the world with BGP how to find
us.

-chris

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 28 May 2010 14:58:32 +0900

> internet) for this 'feature'.

(You keep me continuing this line of my 'silly' arguments. :-)).

Not if there's a mechanism wherein you don't have to advertise your
local address to outside.

> Enterprise network deployment.

Thank you for a list of concerns to clear up.

> how does the world know that services on A are behind B, C, D except

So.. you mean subnets by networks B, C, D, don't you? We're still
inside a site in this moving, aren't we?

My illusive homework is to find a mechanism wherein telling BGP I'm
inside the site S will suffice. So that I can live with local
addressing without breaking the Internet.

-- 
DY