Subject: Re: [rrg] ILNP q1: Scalability

From: Lixia Zhang <[email-masked]>
Date: Thu, 3 Jun 2010 00:54:53 -0700

On May 27, 2010, at 10:03 PM, Christopher Morrow wrote:

> On Thu, May 27, 2010 at 11:04 PM, Dae Young KIM <[email-masked]> wrote:
>> On Fri, May 28, 2010 at 11:19 AM, Christopher Morrow
>> <[email-masked]> wrote:
> 
>>> Note, you lose all redundancy, resiliency and convenience of having
>>> 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.
> 
> 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'.
> 
>> 
> .......
>>>>   - 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.
>> 
>> 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.
> 
> 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.

Chris, I was reading this and wondered whether I should should be concerned about "you don't WANT to" in the above.

Although ILNP stated it as an option to use a local prefix locally, I got this feeling that some people prefer the notion of propagating multiple PA prefixes into a site.

>>> 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.
>> 
>> Of course with ILNP.
> 
> 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.

It seems to me that ILNP's mapping is simple (through DNS or communicating ends can just inform each other), right?
but one thing I dont fully understand yet is how to relate traffic engineering needs with such host-originated locator (hence paths) changes.

Lixia

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 4 Jun 2010 00:21:38 +0300

On Fri, May 28, 2010 at 8:03 AM, Christopher Morrow
<[email-masked]> wrote:
>
> 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.
>

A is edge address space and B, C and D are core address space, i.e.
edge locators are not announced in DFZ but core locators are installed
in DFZ. Also the edge locators do no longer need to be globally unique
since a host is announced in DNS with a combination of an edge locator
and one or several core locators.
A question regarding ILNP and multi-homing scenario.
The primary path from A towards Internet goes via attachment point B
and this is announced in DNS. Then ISP taking care of attachment point
B have some performance problems and the service is not good enough
for host A - he decides to switch to attachment point C and updates
DNS. But how does the packet get routed from host A to attachment
point C instead of B in large enterprise network where there could be
a lot of routers and some security nodes between the host and the
attachment points?
I don't want to tweak the local routing domain but when I change the
DNS records host A should start to use new attachment point (C), some
other hosts might still use the old one (B).

-- patte

---

From: Tony Li <[email-masked]>
Date: Fri, 04 Jun 2010 05:36:29 +0800

> other hosts might still use the old one (B).

In ILNP, a host controls how packets arrive by changing the locators that
are advertised.  Outbound, intra-domain packet routing is separate, and
COULD be based on the hosts source locator, but this is a separate
enhancement that we could make.

Once the host updates DNS with the C locator, it should also concurrently
send ICMP locator updates to its active correspondents and inform them of
the C locator.  

Tony

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Jun 2010 17:44:56 -0400

I believe that Patrick is asking about outbound traffic routing, not 
inbound.

Which is very reasonable question to ask.

Unfortunately, until we are prepared to make a much larger set of 
changes, we do not have the tools to allow a host to choose which 
outbound site connection is used by the hosts outbound traffic.  (There 
are many use cases which would like those capabilities, but we have not 
found a good way to deliver them.)

yours,
Joel

Tony Li wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Jun 2010 16:07:05 -0700

Hello,

I'd like to announce that an update to the IRON architecture
draft is now available, along with updates to the functional
specifications for its constituent mechanisms VET and SEAL:

http://tools.ietf.org/html/draft-templin-iron-02
http://tools.ietf.org/html/draft-templin-intarea-vet
http://tools.ietf.org/html/draft-templin-intarea-seal

IRON now has what I believe to be a compelling new solution
that supports:

- portable PI
- mobility
- multihoming
- route optimization
- traffic engineering
- multi-protocol operation
- tunnel MTU determination
- other neat stuff

IRON now suggests that a new business model supporting PI
addressing will emerge. In the new model, companies that
hold highly-aggregated Virtual Prefixes (VPs) will lease
portions of their VPs to End User Networks (EUNs) which
can then use them as ISP-independent PI prefixes.

Each EUN registers a PI-prefix-to-ISP mapping with its
parent VP company's network. The VP company's network
then serves as a virtual "home network", and the EUN
appears as a mobile network that is always away from
home. The EUN can change its mapping to use a different
ISP at any time such that mobility and multihoming are
naturally supported.

This new approach specifically focuses on small EUNs that
are either mobile or connect through multiple ISPs (this
is the same class of EUNs that have led to the routing
scaling concerns that brought on the RRG interest in the
first place.) Larger and more fixed networks (e.g., large
enterprise networks, service provider networks, etc.) will
instead announce their prefixes into the IPv4 and/or IPv6
DFZs the same as they have always done.

Please take a moment to take a look at the materials and
post any comments or questions. I would also like to
request that the chairs now consider IRON as a candidate
for publication as an IRTF-stream RFC.

Thanks - Fred
[email-masked]

---

From: Tony Li <[email-masked]>
Date: Fri, 04 Jun 2010 07:16:14 +0800

> I would also like to

Done.  Fred will be acting as document shepherd.

Note that it is the responsibility of the shepherd to get the document to
the state where the RG gives consensus that it should be published.  This
applies to all of the documents that we have started, not just Fred's.

I'm concerned as I've seen no action from shepherds or membership on any of
the proposal-specific documents.

Regards,
Tony

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 6 Jun 2010 11:48:58 -0400 (EDT)

The key is hidden in this sentence:
This
> also means that the network path betwen host -> border has to do some
> internal TE such that when on exit path is 'bad' traffic naturally flows
> toward an alternate path internally toward a 'better' exit path.

If the path really doesn't work at all, yes, site TE should make sure
things go to the working exit.
But if ILNP wants some destiantiosn to be reached using exit 1, and some
reached using exit 2, most sites simply do not have any practical way to
do that.
And if you want the hosts to decide for itself whether it shoudl use exit
1 or exit 2 to reach rloc 1, rloc2, or rloc 3, then site TE can not solve
the problem.

So currently, it does not work very well.  And there are cases that we
would liek to work that simply don't.  (I believe shim6 ran into very
similar issues, and decided to not address them for now.)

Yours,
Joel
On Sat, June 5, 2010 2:32 pm, Christopher Morrow wrote:

> On Thu, Jun 3, 2010 at 5:44 PM, Joel M. Halpern <[email-masked]>
> wrote:
>
> I was under the impression that ILNP would permit the site border
> routers to change the locator bits on exit. This means the network devices
> and the hosts have to agree on the set of locators they all can use. This
> also means that the network path betwen host -> border has to do some
> internal TE such that when on exit path is 'bad' traffic naturally flows
> toward an alternate path internally toward a 'better' exit path.
>
>
> If the above all works, then the borders simple swap locator bits as
> appropriate on exit... easy, peasy.
>
> -chris
>
>
>> yours, Joel
>>
>>
>> Tony Li wrote:
>>
>>>
>>>
>>>>  and this is announced in DNS. Then ISP taking care of attachment
>>>> point B have some performance problems and the service is not good
>>>> enough for host A - he decides to switch to attachment point C and
>>>> updates DNS. But how does the packet get routed from host A to
>>>> attachment point C instead of B in large enterprise network where
>>>> there could be a lot of routers and some security nodes between the
>>>> host and the attachment points? I don't want to tweak the local
>>>> routing domain but when I change the DNS records host A should start
>>>> to use new attachment point (C), some other hosts might still use
>>>> the old one (B).
>>>
>>>
>>> In ILNP, a host controls how packets arrive by changing the locators
>>> that are advertised.  Outbound, intra-domain packet routing is
>>> separate, and COULD be based on the hosts source locator, but this is
>>> a separate enhancement that we could make.
>>>
>>> Once the host updates DNS with the C locator, it should also
>>> concurrently send ICMP locator updates to its active correspondents
>>> and inform them of the C locator. Tony
>>>
>>>
>>>
>>> rrg mailing list [email-masked] http://www.irtf.org/mailman/listinfo/rrg
>>>
>>>
>> rrg mailing list [email-masked] http://www.irtf.org/mailman/listinfo/rrg
>>

---

From: Tony Li <[email-masked]>
Date: Mon, 07 Jun 2010 00:16:22 -0700

Hi Chris,

>> However, what Patrick is asking is for something even stronger, which is
>> outbound exit selection by the host.  Most likely, this would imply routing
> 
> oh, yuck :)

I agree.  ;-)

>> towards the specific exit based on the packet's source locator in addition
>> to the destination locator.  This is not part of the base ILNP spec as it
>> exists today.
> 
> well, does it need to be? If the host puts a src-locator on the packet
> it creates it's up to the network/host folks to agree to src-route or
> agree to get overwritten. (Is the 'TE' at the whim of the host or the
> network? This sounds like shim6 discussions, to me)

No, I don't see this as a baseline requirement.  It's an open issue for
further study.

Tony

---

From: Tony Li <[email-masked]>
Date: Sun, 06 Jun 2010 11:15:12 -0700

Chris,

>> Unfortunately, until we are prepared to make a much larger set of changes,
>> we do not have the tools to allow a host to choose which outbound site
>> connection is used by the hosts outbound traffic.  (There are many use cases
>> which would like those capabilities, but we have not found a good way to
>> deliver them.)
> 
> routers to change the locator bits on exit. This means the network
> devices and the hosts have to agree on the set of locators they all
> can use. This also means that the network path betwen host -> border
> has to do some internal TE such that when on exit path is 'bad'
> traffic naturally flows toward an alternate path internally toward a
> 'better' exit path.

You are correct, ILNP allows the site border routers to change the locator
on exit.  

> appropriate on exit... easy, peasy.

In Patrick's scenario, swapping is not necessary, as the 'correct' exit has
been selected already.

In fact, locator swapping is necessary in all OTHER scenarios, as the exit
border router will need to ensure that all packets exiting to a given ISP
have a valid locator for that ISP, to insure that the ISP's RPF or other
filtering succeeds.

Regards,
Tony

---

From: Robin Whittle <[email-masked]>
Date: Mon, 07 Jun 2010 22:15:09 +1000

Hi Tom,

In the thread "Re: [rrg] Pumping IRON" you wrote, quoting Tony Li,
you wrote:

> Robin
> I would urge you to progress some of your ideas towards RFC, especially the one
> on CEE-CES split that you have explored on this list several times.

Thank for your interest in this.  I agree it would be good to
document this in an RFC.

A very short version of the distinction is at the end of section
17.3.3 of:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

and is quoted below.  In greater detail:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06250.html
  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html

CEE (Core Edge Elimination) involves hosts doing more work than at
present, which requires more packets, longer packets and frequently
extra delays establishing initial communications.  CES (Core Edge
Separation) involves no changes to host protocols.  The work is done
by new elements in the network, such as "Ingress Tunnel Routers",
"Egress Tunnel Routers" and various mapping servers.  I believe it is
possible to do CES with initial communications delays which are
generally minimal enough not to be a concern to anyone.

> I think that that idea is an important contribution to routing architectures and
> may well be significant when most of what we have discussed here has been
> forgotten.  

OK - its not my idea, but I tried to document it clearly and resolve
some problems I perceived in the terminology.

I can't imagine ILNP or LISP being widely adopted and so I guess the
whole question of scalable routing, mobility etc. will be revisited
in five or ten years.  Then, the CEE/CES distinction and some
approaches which are currently not widely favoured will be of
interest.  (Alternatively someone will develop a commercial service
based on TTR Mobility and DRTM - and IETF standards will have to
catch up.)

I assume the RRG archives will remain as they are, in perpetuity.  My
Ivip pages are there for keeps and archive.org will eventually catch
up with the current contents.  archive.org doesn't cover the RRG
archives.

> One caveat; I think that any such RFC would need to make sense to
> those who have never heard of hIPv4, NOL, RANGI, NMS, TIDR, EEMDP etc.  We who
> have followed this list have a knowledge that noone else will ever acquire and
> so any I-D that depends on that knowledge will generally be unintelligible.

I agree.  I think the messages mentioned above achieve this.
However, they tend to assume a particular understanding of the
problem and goals - something the RRG has never agreed on.  To see my
attempt at describing the problem/goals, please see section 17.2 of:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

> Rather, I would like to see CEE-CES presented in the more commonplace concepts
> of address, headers, tunnels etc, perhaps with reference to the specific
> instantiations discussed here as appendices, as opposed to starting off by
> saying 'these are CES, those are CEE', which will lose most of the audience:-(

In 2015, 2020 time-frame, I agree.  For RRG readers, I think it makes
sense to list the various proposals first.  From msg06219, here is
the very short version, which doesn't refer to any particular
architectures:

= = =

   CEE   Core-Edge (address) Elimination:  A class of scalable
         routing architectures in which the Locator / Identity
         Separation naming model is introduced, replacing the
         current IPv4/v6 model in which the IP address plays both
         the Identifier and Locator roles.

         Hosts have portability of Identifiers and are able to do
         multihoming and inbound TE on IP addresses derived from
         two or more PA prefixes from two or more ISPs.  These
         addresses are conventional PA "core" addresses and each such
         PA prefixes for an end-user network is fully aggregated into
         a shorter prefix the ISP advertises.  Therefore, this use of
         address space is regarded as scalable.  (This doubling or
         more of each end-user network's address requirements is one
         of the reasons CEE architectures are impractical for IPv4.)*

         Therefore there is no need for any "edge" addresses - the
         unscalable PI addresses which are currently the only way of
         achieving portability, multihoming and inbound TE.

         A fully adopted CEE architecture therefore eliminates the
         need for "edge" addresses, and so for the distinction
         between "core" and "edge" addresses.

         The full sense of "Elimination" in this term is "Elimination
         of the need to distinguish between core and edge addresses,
         since there is no longer a need for edge addresses."

   CES   Core-Edge (address) Separation: a subset of the global
         unicast address space is separated from the remaining
         "core" global unicast addresses and is supported by the
         CES system (ITRs, mapping system and ETRs) to be used as
         a new form of address space by which end-user networks
         can obtain the benefits of Portability, Multihoming and
         inbound TE in a scalable manner.  This space is used in a
         manner which involves far less impact on the DFZ control
         plane per end-user prefix than than current PI techniques.

         The full sense of "Separation" in this term is "Separation
         of the global unicast address space into a scalable 'edge'
         subset, with the remainder being 'core' addresses".  Since
         Portability, Multihoming and inbound TE can be provided
         with this new scalable "edge" space, there is no longer
         any need for the unscalable PI edge space.

= = =

* Since I wrote this, ILNP for IPv4 has been proposed, with a new,
  longer, header to accommodate a separate Identifier, and use full
  IPv4 addresses as Locators.  This doesn't have the same attraction
  (architectural "cleanliness" or "elegance") as ILNP for IPv6,
  because it requires upgrades to DFZ and other routers, longer
  packets to hosts etc.

> The other idea of yours that I think will be of long term benefit is real time
> mapping.  It does set your ideas apart from the others, and if and when the
> others find they need it too, then having a well-documented scheme will prove a
> valuable starting point.

OK - thanks for your interest in this.  The documentation at present
should be read in this order:

  1 -  http://www.firstpr.com.au/ip/ivip/drtm/   (Color diagrams.)

  2 -  http://tools.ietf.org/html/draft-whittle-ivip-drtm

  3 -  http://www.ietf.org/mail-archive/web/rrg/current/msg06128.html
       (Please read only the section on "DNS-based system so TRs can
        find DITR-Site-QSDs.)

Unfortunately, in the foreseeable future, I don't have time to work
on any of this, including writing RFCs.  I worked pretty much
full-time on RRG things, analysing all the proposals and developing
DRTM, in the first 3 months of this year.  Now I need to catch up on
paying work.

If anyone else wants to work on an RFC on these, I would be greatly
encouraged and will do my best to help.

  - Robin

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 7 Jun 2010 01:07:47 -0400

oh, yuck :)

> In Patrick's scenario, swapping is not necessary, as the 'correct' exit has

ok.

> have a valid locator for that ISP, to insure that the ISP's RPF or other

right, if uRPF is being used, I agree here. (I do hope it IS in use...
but not everyone does this)

> Tony

thanks, as always :)
-chris

---

From: Patrick Frejborg <[email-masked]>
Date: Mon, 7 Jun 2010 17:49:12 +0300

Tony & Joel,

outbound traffic is the topic that I'm trying to have a discussion on,
sort of  "first mile traffic engineering" at an enterprise.

I'm taking this scenario a little bit further, the link between
attachment point B and the corresponding ISP goes down - then we have
a black hole because nor the host neither the DNS system is aware of
the link failure. One way to overcome this situation would be to
create a "link state protocol" between ILNP border routers and the DNS
, e.g. if the upstream link fails the DNS becomes aware of this and
once DNS is aware of this situation it updates the records, updates
its own clients so they can send out ICMP messages to their
correspondents. This sounds a little bit scary to create a dynamic
protocol between the routing system and DNS  - I'm not really
comfortable with this approach but let us have a look on the option.

For outbound traffic from client A via either attachment point B, C
and D you would use today the 0/0 route concept towards one of the
attachment points, in this case B. From there you would use local
preferences to go out via the preferred border router - but this is
today prefix based. So if you could add a new attribute for ILNP, i.e.
"local identifier preference" to iBGP and each identifier can be given
an own value you can direct outbound traffic per host  to either
attachment points B, C and D (and achieve load balancing). But to
minimize administrative tasks you should be able to set the metric of
the "local identifier preference" at one place, e.g. DNS which then
informs the border routers how hosts should use  the attachment
points. So perhaps a "link and identifier state protocol" is needed
between the routing system and DNS ....

I'm still not happy what this "link and identifier state protocol" approach.

If I have three attachment points I would prefer to use all three
points concurrently for each host, i.e. a multipath transport protocol
would be great.
We have had SCTP for a while but is not widely deployed and I believe
the reason is that it cumbersome and expensive to deploy a multipath
enabled enterprise network from client A to the attachment points B, C
and D. You need to have three separate networks, three identical
security architectures that needs to have the same security rules -
the economics are not there - it just become too challenging to build,
maintain and troubleshoot.

And I'm afraid that MPTCP will have the same problem to get deployed
in an enterprise network for the very same reasons - mobility is a
different issue

If ILNP could  have a shim header where the host A sets the preferred
outgoing attachment point you could create a "first mile traffic
engineering" solution, i.e. you can establish three separate paths
from client A to the attachment points B, C and D. Some routers in
between needs to able to read the shim header and switch the packets
to the correct paths. The border router for the initiator shouldn't
rewrite the locator, instead the border router in front of the
responder would swap the locator headers (as in hIPv4). The outcome
would be that the hosts are located by an edge locator value and one
or several core locator values - the great thing with this approach is
that the economics for multipath transport protocols arrives. Only one
NIC on the hosts, only one local network at the enterprise and also
one security architecture - which could be build upon the identifier
values and _not_ on the locators. But then you should be able to
protect your identifier from being stolen, and here I haven't made my
mind up - should I trust ILNP that it will protect my identifier or
should I prefer HIP to take care of the identifier......
Also, it seems that "link and identifier state protocol" between the
routing system and DNS is no longer needed - responsibility to solve
the black hole issue is on the transport protocol.

Thoughts? Also, I might have missed something...

-- patte

---

From: Tony Li <[email-masked]>
Date: Mon, 07 Jun 2010 10:47:57 -0700

Patrick,

Here's another approach:

Leverage the existing link state IGP.  Each border router knows the locator
prefixes that it gets via its ISP.  If it's link to the ISP is up, then it
injects those prefixes into the IGP.

Now, each router in the domain collects these prefixes as part of its SPF
pass through the link state database.  It then uses an extension to ND to
advertise the associated locators to its neighbors.  (How to xlate a prefix
into a specific locator is TBD).

Hosts now listen to these locators in normal ND RA messages and sends
updates to DNS if it chooses to update its locator set.

Taking our example, suppose that the link to ISP B fails.  Then the B router
withdraws the locator from its IGP advertisement.   This in turn causes ND
to remove the B locator from ND.  The hosts then transition their locators.

Note that domain renumbering automatically falls out of this approach.  ;-)

Another outstanding question is how this can be done without turning this
into a DDOS attack on the DHS server.

Tony

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 8 Jun 2010 20:54:09 +0300

Hi Tony,

could be interesting to investigate - but there is also a bunch of
security nodes in between the border router and the endpoints, usually
the border router IGP is separated by a firewall (using only static
routing) from the internal IGP domain. So the firewall should be part
of this and pass ND messages, and at the same time ensure that this
are valid messages and no bogus DDoS attempts. I need to study ND...

About the renumbering issue - I believe that is not possible to
automate it that much. I have been involved lately in a topology
change at a data center, the network part and workstations are easy
to renumber and also some servers. But when you are dealing with DMZ
hosts you are hitting a super-massive pain point, especially when the
DMZ server is use for business-to-business solution for partners.
These servers are protected by firewalls at both ends, so when you are
changing the IP address you have to schedule a service window not only
for the enterprise but also for the partners - you and all the
affected partners has to change firewall rules at the very same
moment. And with several servers this will take time...and
expenses....
This is another reason why enterprises are eager to have PI-addresses
(multi-homed or not) their  firewall rule base remain intact though
the ISP is replaced

It would be wonderful if the firewall rules is based only on the
identifiers - get rid of the locator information in the rules. Then
the enterprise could change the locator values and no need to worry
about their partner connections, much less costs is caused by topology
changes. And also to outsource your services to a cloud provider would
be much easier - no L2 connectivity is needed from the enterprise to
the cloud provider during transition phase - instead the identifier of
the service is pointed to another location in DNS when it is started
at the cloud provider.

But I'm afraid that the security part in ILNP is too weak to convince
the security architects that you could build your security rules only
on identifier information - think that HIP is in better position here
(and that's why I haven't added an identifier to hIPv4). I could be
wrong about this...

To summarize, if the security solutions could be build on identifier
information renumbering would be a no-brainier compared what we have
today.
Also this has nothing to do with Internet routing scalability, we are
now in the enterprise domain but if you can find cost saving issues at
the enterprise domain you will catch the attention of the upper
management and get this thing started :-)

-- patte

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Jun 2010 09:38:50 -0700

Tony,

> Done.  Fred will be acting as document shepherd.

Very good. As document shepherd, I will observe the procedures
for IRTF document stream publication defined in RFC5743. This
in part entails a requirement for technical and editorial
review within the research group.

As such, I am now initiating a two week open review period
within the research group for technical and editorial review.
I will also solicit comments from a selected set of expert
reviewers to ensure a thorough review. The document version
offered for review is here:

http://www.ietf.org/id/draft-templin-iron-05.txt

To the research group, please post comments to the list as
replies to this subject thread by COB on Wednesday, June 23rd.

Thanks - Fred

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 11 Jun 2010 00:12:43 -0400

> replies to this subject thread by COB on Wednesday, June 23rd.

Hi Fred, I've looked over the document (and associated ones including 
RANGER, RANGERS, VET, and SEAL); here are some comments I have.

Summary:

The document is generally well-written, and can be understood by someone 
within the context of the other referenced documents (though certainly 
not without them).

The technical description is basically an overview of the concept and
how it could function, rather than a prescriptive protocol spec.  I
think as such it's definitely appropriate to publish through the RG as
Informational, though I'd suggest that it have a more clear listing of
some of the open research issues that exist which would be explored in
taking the concept into a large-scale deployed state.  It would be nice
to see a bulleted list of such things near the end of the document.

The only technical thing I might have an issue with is the reliance on 
the MVP, and the need to come up with hard numbers to show that this is 
a feasible architectural assumption to work at Internet scale without 
operational issues.  I think those studies would be fine as follow-on 
work and the absence of such should not block publication as an RFC from 
the RG.

I'm also a little skeptical of the applicability to mobile networks, but 
the claims made here are definitely no more specious than in other 
proposals, so I'm not overly concerned by them ;).

I would be interested in talking about how IRON compares to an 
architecture where instead of IR(VP)s you have NEMO Home Agents and
instead of IR(EP)s you have NEMO Mobile Routers (which don't necessarily
have to be mobile, just speak the protocol).  Assuming you port in the
use of SEAL for tunnels, there might be a lot of equivalence.  Since the
EPs and VPs would be routable prefixes in this case, I don't think there
would be a need for the MVP either, which seems highly desirable to 
dispose of.

Some comments on particular sections are:

(1) page 5 - in definitions of different types of IRON routers, the term
"VP company" is used several times.

(2) page 5 - in defining different types of IRs, some example diagrams 
might really help.  It's a royal pain to incorporate, so I think this is 
at the authors' discretion, but a couple simple pictures would add a lot 
here, I think.  The scenario in section 6.4 is fantastic for 
illustrating things, but comes too late in the document for readers that 
might get lost up front.

(3) page 6 says:
"""
    The IRON additionally requires a global mapping database to allow IRs
    to map EPs/VPs to RLOCs assigned to the interfaces of other IRs.
"""
This part looks scary at first, and gets a little scarier even when it's
compared to the way that IANA maintains the list of IPv4 and IPv6
delegations, and replication across multiple servers is discussed.  I 
think it's probably not as bad of an idea as it seems like at first, but 
I'm really not sure yet.

(4) In section 6.1, and the discussion of beaconing between IR(EP) and 
the IR(VP)s, I wondered how many IR(VP)s we would expect to see in 
operations, where the heuristic of "at least 2-4" was derived from, and 
how frequently it would be advisable to send the beacons at?  Those seem 
like useful details to be understood, though maybe they would be flushed 
out in later studies and through experience to some extent.

(5) The discussion of mobility management in 6.5.1 may be a bit 
premature. Whether this is usable or not for mobile systems will depend 
on other aspects of performance like how long the registration of the 
new maping from the EP to RLOC takes with the VP company.  All we have 
to analyze this is that the registration uses "an authenticated short 
transaction protocol", but that might involve handshakes with several 
numbers of steps, and the messages in some steps may be relatively 
large.  The specifics here will matter a lot as to whether IRON is 
viable for mobile networks.

(6) The security considerations are a handwave toward RANGER.  I think
this is not the whole story.  For instance, there are security 
considerations on the means used for customers to update (and establish) 
bindings with their VP companies.  I think the draft implies that the 
exact means could vary depending on the VP company, which is fine, but 
there should be some guidelines or analysis of what kind of bad things 
could happen, and how they might be mitigated or dealt with operationally.

--
Wes Eddy
MTI Systems

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 11 Jun 2010 09:16:36 -0700

Hi Wesley,

Thanks for taking a look at this. Please see below for some
follow-up:

> -----Original Message-----
> From: Wesley Eddy [mailto:[email-masked]]
> Sent: Thursday, June 10, 2010 9:13 PM
> To: Templin, Fred L
> Cc: Tony Li; RRG
> Subject: Re: [rrg] Pumping IRON
> 
> Templin, Fred L wrote:
> >

OK.

> to see a bulleted list of such things near the end of the document.

I think I can add something useful in the next document version.
This comment is similar to one I received off-list which suggested
citing the Thomas Narten draft.

> work and the absence of such should not block publication as an RFC from

What I was thinking here was a model that is sort of along the
lines of how linux kernel distributions are distributed. The
main repository is at kernel.org, but there are numerous mirror
sites to spread the load. (Linux kernel releases are also much
bigger than the largest size I can imagine the MVP database
becoming.) As a follow-on study, I will check to see if there
are statistics associated with this and other similar
distribution systems.
 
> would be a need for the MVP either, which seems highly desirable to

Well, the whole reason for having EPs and VPs are to reduce
the sizes of the RIBs and FIBs in all routers. The ability
to delegate EPs to customer sites without requiring that
they be advertised in the global routing table is the
fundamental basis for the IRON scalable PI. Or, perhaps
I misunderstood the comment?

About the NEMO and mobility, let's hold the thought for now
and I will say a few more words about mobility below.
 
> "VP company" is used several times.

Will fix.

> illustrating things, but comes too late in the document for readers that

I think I can add a few figures that might help.

> think it's probably not as bad of an idea as it seems like at first, but

OK. Again, I am basing my assumptions around the way linux
kernel distributions and similar distribution systems work
today. I will look into this in a follow-on study.

> out in later studies and through experience to some extent.

I can imagine that for a given VP there may be 10-20 IR(VP)s
worldwide, or perhaps even as many as (say) 50-100. We don't
want each IR(EP) to ping all of the IR(VP)s, so that is why
I was thinking to ping the 2-4 closest ones.

> viable for mobile networks.

You are right that the IRON "binding update" is coordinated
with all of the IR(VP)s within the VP company instead of with
just a singleton home agent as is the case for MIP. So, there
is certainly a delay for the update to propagate, but I was
thinking there would be some sort of dynamic routing protocol
within the VP company network that could quickly push the
updates to all IR(VP)s.

As to message numbers and sizes for coordinating the binding
update, in past efforts I proposed using cryptographically
signed messages that carry prefix ownership certificates. For
example, the mobile IR(EP) can send a "Router Advertisement"
with its prefix along with a certificate it got from the VP
company. In that way, there is no need for a global PKI, since
each IR(EP) only needs to coordinate its keys with its VP
company and not the entire Internet. Maybe I should bring
this back?  

> could happen, and how they might be mitigated or dealt with operationally.

I'll try to add something here. What do you think of the
idea above about having cryptographically signed messages
with certificates issued by the VP company and using the
VP company's private key distribution system instead of
a monolithic global PKI?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 23 Jun 2010 10:47:55 -0700

Per my message on June 9 (below), I have collected review
input for IRON and have produced an updated document version:

  http://www.ietf.org/id/draft-templin-iron-06.txt

This version has undergone major improvements based on input
received, and IMHO is now very close to completion. However,
I would now like to extend the review input deadline by one
week until COB on June 30, 2010. This will give reviewers
who have already contributed a chance to verify that their
comments have been addressed, and give new reviewers an
opportunity to comment on this updated document version.

To the research group, please post comments to the list as
replies to this subject thread by COB on Wednesday, June 30th.

Thanks - Fred

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Wednesday, June 09, 2010 9:39 AM
> To: Tony Li; RRG

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 30 Jun 2010 16:24:26 -0700

I am planning to submit an updated draft version soon
based on some new insights. Therefore, I am suspending
the deadline for comments until after the new draft
version has been submitted, and will announce a new
deadline at that time.

Thanks - Fred

> Sent: Wednesday, June 23, 2010 10:48 AM
> To: Tony Li; RRG