Subject: [rrg] Consensus on identity/location separation

From: Toni Stoev <[email-masked]>
Date: Tue, 21 Sep 2010 12:52:29 +0300

ILNP: The Routing RG has had remarkably little consensus on anything, so virtually all Routing RG outputs are considered controversial.

I was surprised to know that Robin is against location/identity separation. Are you not, Robin?

Distinction between a node's identity and topological location is natural, because the same node can be attached to the general network at different points. So, to name the node independently of its point of attachment, we need an identifier assigned to the node. And we also need a locator to represent the node's topological position.

Do you consent?

---

From: Robin Whittle <[email-masked]>
Date: Wed, 22 Sep 2010 00:37:22 +1000

Short version:     Why I think CEE (Locator / Identifier Separation)
                   is inferior in general to CES - and in particular
                   why CEE cannot provide mobility in an acceptable
                   manner, while CES with TTR Mobility can.

                   CES continues the current pattern of the routing
                   system providing significant services to the hosts.

                   CEE requires the routing system to do less work,
                   and hosts to do more, including sending and
                   receiving more packets, holding more state,
                   running more complex software - and suffering
                   more delays and sensitivity to packet loss.
                   This is unacceptable in general, and is
                   particularly unacceptable for battery powered
                   hosts hanging on via slow and potentially
                   unreliable 3G etc. radio links.

Hi Toni,

You wrote:

> ILNP: The Routing RG has had remarkably little consensus on
> anything, so virtually all Routing RG outputs are considered
> controversial.
> 

Yes, I am opposed to altering the current host protocols in which the
IP address performs the role of both Identifier and Locator.
(Actually, its not the host which these apply to, but a particular
interface of the host.  Each interface can have one or more IP
addresses, but an IP address can't be on more than one interface.)

With the current arrangement, the routing system (that is, everything
outside the host) takes responsibility for getting the packet to the
host interface which has the IP address matching that in the packet's
destination field - otherwise, the packet will be dropped.  This means
the routing system ensures that a packet addressed to a host with IP
address XYZ will not be delivered to any host which does not have the
address XYZ.  (Normally there is only one host with the IP address
XYZ, but with anycast there are multiple hosts with the same IP address.)

In this way, the routing system provides an extremely valuable service
to the host.  This means a host BBB can respond to a packet which is
supposedly from host AAA (that is, the packet has AAA's IP address in
the source field) by sending a reply packet addressed to AAA's IP address.

It is possible that the initial packet was actually sent by malicious
host MMM, so there can be confusion and disruption.  However, TCP and
application problems have little or no problem coping with this sort
of attack.

In the usual case, the initial packet did come from AAA.  BBB
tentatively assumes this is the case, generates a reply and generates
a reply packet with the IP address AAA in the destination field.  This
way, it can send information to AAA knowing that the routing system
will not allow it to be delivered to any host other than one with
AAA's IP address - which means AAA itself, or in anycast, one of the
hosts which has the AAA IP address.

With this arrangement, BBB's stack and applications can take the
initial packet on face value, for the purposes of initiating a
communication session, without needing to do any DNS or other lookups.
 If there is to be a session, and BBB receives a valid response to its
reply, then it can continue the session without any further checks -
because it can reliably assume the session is with the host whose IP
address is AAA.

Locator / Identifier Separation is a conceptually attractive
arrangement in which hosts have one or more IP addresses (or some
other form of network address which acts as the Locator), but the host
stacks and applications do not consider these to be important, fixed
or to indicate anything persistently about the identity of themselves
or other hosts.

It would be possible to run a global network, including an Internet,
or modified versions of the IPv4 and IPv6 Internets, using Locator /
Identity Separation.

HIP, ILNP, Name Based Sockets, GLI Split and RANGI are some of the
architectures which do this.  These are all "Core Edge Elimination"
(CEE) architectures - so I regard "CEE" as meaning the same thing as
"Locator / Identifier Separation".

LISP, despite its name, does not implement Locator / Identifier
Separation.  It is a Core Edge Separation (CES) architecture - like
Ivip, TIDR and IRON.  See:

  LISP does not implement Locator / Identity Separation
  http://www.ietf.org/mail-archive/web/rrg/current/msg06190.html
  (2010-03-08)

CES involves no alterations to host functionality.  The routing system
still behaves the same way to each host, so it continues to support
the current "overloading" of both Identifier and Locator functions on
the IP address.

A CES architecture involves adding to the routing system some new
things, such as ITRs, ETRs and various things to support them, in
order that the routing system can scalably provide portability,
multihoming, inbound traffic engineering (TE) and ideally mobility.
Hosts continue to benefit from the Locator and Identifier
"overloading" of IP addresses.

An attempt at a concise description of the distinctions between CES
and CEE architectures is in section 17.3.3 of my proposed
Recommendation text: msg06219.  A more detailed version is: msg06250
and msg05865.

As I wrote here:

  "Overloading" of Loc & ID functions is good for hosts and should be
  maintained
  http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html
  (2010-06-22.)

adoption of Locator / Identity Separation (CEE) would mean that BBB in
our previous example would typically need to do a mapping lookup
before it could reply to a packet from AAA.  Also, CEE architectures
often involve longer packets (at least for the first few packets of an
exchange) and/or more packet to and from the hosts in order to make
the system work.

If BBB was a DNS server it wouldn't care about the identity of the
host it is sending a reply to.  So in this instance, CEE would be no
slower or more burdensome for BBB than the current "overloaded"
arrangements (or with a CES architecture).  In this instance, BBB
would simply send its reply to whatever IP address (or whatever it is
in the initial packet which specifies the Locator of the host which
ostensibly sent this packet) of the requesting host.  There would be
no need for any mapping lookups - and so no problem with delays etc.

However, in many or most communications, including setting up a TCP
session and many application protocol sessions, BBB sends a reply
packet on the basis that the reply will only go to the host whose
Identifier is in the source field of the initial packet.

With Loc / ID Separation, the only way BBB can do this is by
performing a lookup on that Identifier, to obtain a list of that
host's one or more current Locators.  Only then can BBB choose a
Locator with which to send the reply packet.

This means BBB can't send a reply packet until it has queried and
received a response from a secure global mapping system (perhaps an
extension of the current DNS system) to obtain the one or more
currently valid Locators for the host which ostensibly sent the
initial packet.   This might only take a few tens of milliseconds.
However, if the request and response needs to traverse continents and
oceans, and especially if the request needs to be redirected towards
the one or more authoritative mapping servers for this particular
Identifier, then it will often take a second or two.  This represents
a significant extra burden on BBB, and a significant delay in
completing this initial (and perhaps only) phase of the communication.

Let's say a malicious host has the Identifier MMM and Locator mmm.  (It
could have multiple Locators, but one is enough for this example.
Hosts can also have multiple Identifiers, I think.)

The malicious host launches an attack on two hosts:

  1 - Host with Identifier AAA and Locator aaa.
  2 - Host with Identifier BBB and Locator bbb.

It sends a packet to BBB:

   Source ID:   AAA      Source Loc:  mmm
   Dest   ID:   BBB      Dest   Loc:  bbb

If BBB doesn't implement the mapping lookup I just described, then it
has to assume that this packet really is from the host with Identifier
AAA, and that one of its current Locators is mmm.

So, without BBB performing the mapping lookup, it will reply, with the
reply packet being:

   Source ID:   BBB      Source Loc:  bbb
   Dest   ID:   AAA      Dest   Loc:  mmm

The malicious host has now obtained an answer from BBB with BBB
behaving as if it was replying to a request from AAA.  Furthermore,
the malicious host can now continue a session and impersonate AAA.

This is intolerable for many or most application protocols.  So either
before BBB replies at all, or at least before any meaningful
communication can occur, BBB must perform a mapping lookup to securely
determine whether this Locator mmm is really a valid Locator for the
host AAA.

Therefore, Loc / ID Separation requires all or almost all hosts (with
possible exceptions such as DNS servers) to do more work, send and
receive more packets, delay their initial or at least their meaningful
responses and to store more state, than in the current "overloaded"
arrangement.

There are other problems with the idea of changing the current
Internets to operate with Loc/ID Separation.  For instance, the
scaling benefits and the benefits to each adopter of the new system
only really exist once all, or almost all, hosts and networks adopt
the new scheme.  So it would be difficult or impossible to introduce
this successfully:

   http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

But even if we could choose to redesign the Net without concern about
adoption, backwards compatibility etc. I would still argue against
Loc/ID Separation.

Conceptually, it is nice and clean - with the routing system simply
working with Locators, and the hosts themselves fussing over the
concept of their own Identity.  This would make the routing system
simpler.  In particular, it would do away with the problems of
scalability we currently have, by making it possible for all hosts to
use purely PA addresses from their one or more ISPs.  Assuming there
was a Loc/ID (CEE) architecture which could reliably and efficiently
perform multihoming, TE and mobility, then this would be a good
outcome in some ways: the routing system could remain as it is, since
the interdomain routing system would only needs to handle as many
prefixes as are needed by the world's ISPs.  I think we all agree
that the BGP system can cope with this.  I think we all agree that the
BGP system can't cope with there being millions of separately
advertised prefixes, which is what would be required to use the
current BGP-based techniques for portability and multihoming, for the
millions of non-mobile end-user networks which want or need these.
Also, there's no way of making the BGP system adapt fast enough to
provide mobility - and we need global mobility for billions of
hand-held devices.

The current, architecturally "impure", "overloaded" arrangements means
the routing system provides a significant service to hosts: delivering
packets in a manner that the packet will never be sent to a host with
an IP address other than the one in the destination field.

I think this should be retained.

I think the BGP system is a good and arguably excellent system for the
interdomain routing system, as long as it is not expected to cope with
as many prefixes as there are non-mobile end-user networks which want
or need portability, multihoming and TE.  I support CES architectural
enhancements to the routing system, so hosts can continue to do what
they do today, and so the BGP system can continue as it does today -
ideally with fewer or no prefixes of end-user networks.

LISP and Ivip on their own don't provide mobility.  The TTR Mobility
approach could be applied to either of them, and would provide global
mobility, from any access network (including behind multiple layers of
NAT and on TTR Mobile addresses) - with generally optimal path
lengths.  This is for both IPv4 and IPv6 without any alterations to
host stack or application protocols (other than adding a tunneling
system to mobile hosts so they can make two-way tunnels to typically
nearby TTRs).

I haven't read the latest IRON drafts, but I understand IRON now
implements something similar to, or at least inspired by, TTR
Mobility.  TIDR is the other CES architecture too, but unfortunately
doesn't provide scaling benefits.

I think this CES architectural enhancement - making some new parts of
the routing system do extra work, while retaining the existing level
of service with the "overloaded" functions of IP addresses - is the
right division of labor.

CEE (Loc/ID Separation) proponents want all hosts to do a lot more
work, including delaying initial communications while they look up
mapping, all for the benefits of enabling the interdomain routing
system to continue as it is today, without any additions to the
routing system at all - though a highly reliable and substantial
mapping system needs to be added.

I think CEE is attractive in a general sense, since it continues the
Internet's well regarded tradition of keeping the network simple and
expecting the end-user devices (hosts) to implement the rest of the
entire system's required functionality.  This is in stark contrast to
the POTS telephone system, where the handsets are very simple and the
network has to be formidably complex.  (Cell-phones are complex, but
only for the purposes of talking to base-stations - still, the network
provides all the functionality of handling calls, voice mail etc.)

There is understandable reluctance to introducing any new
functionality or complexity into the network - into the routing
system.  Generally, hosts are inexpensive and have lots of CPU power -
so it is tempting to get them to do more work so we can retain a
simple routing system.

The average PC has heaps of CPU power and memory to implement the
additional functionality required by CEE.  However this is not so
clearly the case with battery operated hand-held devices, such as
cell-phones - and we should plan for every human having such a device,
with each one having global mobility via the Internet, presumably most
of them on an Internet other than IPv4.

Even if it could be argued that the CPU and RAM burden was not a
problem for cell-phones or any other hosts in the future (including
IPv6 light switches, and various other miniature wireless battery
operated devices which are imagined for the future . . . Hmmm, its
dark - does the light-switch needs a software update, a reboot or a
virus scan?), there is still at least four fundamental objections to
CEE Loc/ID Separation compared to implementing CES instead, and so
preserving the current "overloaded" arrangements of:

  IP address = Identifier = Locator

These are the four major objections - not counting CPU, RAM, software
complexity etc. required on all hosts.

  1 - CEE involves extra packets being sent and received by all
      hosts.  This is for the mapping lookups hosts typically need
      to do when replying to an incoming packet.  The initiating
      host starts with an Identifier, and has to do a mapping lookup
      to find the current Locator(s) of the destination host, but
      the current arrangements often involve an equivalent lookup:
      looking up an FQDN to get one or more IP addresses.  So the
      initiator doesn't always have do do more work than today - but
      the responder typically does.

      With the current arrangements, many initiating hosts can start
      with an IP  address, from a referral, a config file or even
      hard-wired into the application program and don't need to do
      any DNS lookup before sending the initial packet to the
      respondent host.  This is not possible with CEE, because a
      host's Locator(s) could change at any time - requiring a
      mapping lookup before every new communication.

  2 - CEE typically involves extra and/or longer packets being
      exchanged between the hosts, at least at the start of a session.
      This is for purposes such as enabling each host to get a nonce
      from the other.  The nonce sent by AAA to BBB will be used by
      BBB whenever it gets a new Locator ggg.  Then BBB will send AAA
      a packet from Locator ggg, with the nonce, and a message to the
      effect: "This is really the BBB host, but with this new Locator.
      Please sent further packets to ggg, rather than the Locator
      BBB was previously known to be using."

  3 - CEE involves extra delays in establishing most communication
      sessions, as noted above, due to the need for the replying host
      to do a mapping lookup before sending a reply, or at least
      before sending a reply which should only be sent to the host
      whose Identity was in the initial packet.

  4 - So far, no-one has developed a way that CEE can provide Mobility
      in an adequate way.  The basic CEE mechanism means every host
      can operate from any Locator, at any time, so in principle it
      looks like Mobility is already part of the system.

      If we assume AAA is not mobile and that its Locator(s) are
      stable, then it is OK for BBB to be mobile.  BBB can send
      a packet to AAA, with the nonce it sent during the initial
      session set-up, to tell AAA it has a new Locator.  However,
      this has several major problems:

         A - BBB has to do this for all its correspondent hosts
             every time it gains a new Locator.  In practice, CEE
             adaptations of IPv6 involve the Locator being much
             the same as, or exactly, an IPv6 address.  BBB will
             get a new Locator every time it switches from one
             access network to another, such as from 3G to WiFi,
             or from either of these to a cabled Ethernet
             connection.

             Furthermore, even on 3G, even without moving, BBB
             could get a new Locator, since the vagaries of the
             wireless network could mean it is now served by
             a different base-station, which uses a different
             IP gateway.

             Locator changes could happen every second or two.

             With CEE, every change of Locator would mean BBB
             needs to send nonce-equipped Locator Update messages
             to all its correspondent hosts.  This will burden
             all those hosts with extra packets, extra work etc.
             These updates need to be acknowledged, so BBB can
             resend if the first one is lost - so each such
             update involves at least two packets.

             The physical transmission of these packets over
             BBB's radio links, every time there is a new radio
             link, or change in access network, such as by
             driving into a tunnel or going into a train (losing
             the 3G and gaining a WiFi link) is an intolerable
             burden.  Even if the list of "currently active
             correspondent hosts" was pruned with a 1 minute
             time-out, this would be prohibitively onerous for
             mobile hand-held devices.  (To do so would require
             all hosts, or at least all hosts which somehow
             ascertain they are communicating with a mobile host,
             to perform a fresh mapping lookup every minute for
             each such mobile host.  This is highly inefficient,
             and would involve further unacceptable burdens on
             any hand-held mobile host which was doing this
             because it was communicating with other mobile
             hosts.)

         B - Along with each such Locator Update message, the
             mobile host needs to update its Locator information
             in the global mapping system.  That needs to be
             done rapidly and securely, so there will be at
             least one packet to the system and one ACK in
             return - assuming a nonce or some other crypto
             arrangement to secure this.  The mapping system
             may then have more work to do.

             If the mapping system involves a single
             authoritative server, for a given host's ID->Loc
             mapping, then there's no need to propagate the
             changed Locator information.  However, such an
             arrangement would not be robust, and would involve
             the most onerous approach to mapping lookup:
             no caching and all requests being forwarded via
             several levels of servers to this single mapping
             server.

             If the mapping system involves multiple authoritative
             mapping servers for a given host, then every time the
             mobile host changes its mapping, these servers need to
             exchange packets and do work so they are all updated.
             Such a system would be more robust and potentially
             faster than relying on a single authoritative mapping
             server - but it involves higher overheads for every
             change of Locator.

         C - This nonce-equipped "Locator Update" message
             approach will not work if both hosts change their
             Locators at the same time.  Since many communications
             will be between mobile hosts, this is an unacceptable
             arrangement.  The attempt to send the update message
             would go from BBB to AAA's previous, but no longer
             valid, Locator, while a similar message from AAA would
             go to BBB's previous Locator.

             Perhaps each host could detect this failure via
             ICMP destination unreachable messages.  However,
             these would have to be accepted only on a highly
             secure basis.  Otherwise the failure would need
             to be inferred by each host at a TCP or application
             level - but not all applications could do this
             promptly or at all.

             The only way the hosts have of retaining their
             session(s) is to start again with a mapping
             lookup, to find the current one or more Locators.
             AAA and BBB would both do this, which could take
             half a second, a second or whatever - longer if
             there is a single mapping server, which happens
             to be on the other side of the Earth, especially
             if a request or response packet is lost.

             This sort of delay is unacceptable, since we
             expect mobile hand-held devices to support VoIP
             without disruption, as long as it has at least
             one active method of connecting to the Net.

      TTR (Translating Tunnel Router) Mobility:

         http://www.firstpr.com.au/ip/ivip/#mobile

      involves none of these problems.  When the MN (Mobile Node)
      gets a new IP address, it establishes a new two-way tunnel
      to its current TTR (there may be more than one TTR, but
      typically there will be just one).  This TTR is typically,
      but not necessarily, nearby - such as within 1000km.  This
      can typically be done in a few tens of milliseconds, since
      the MN and TTR have already exchanged nonces or other crypto
      tokens and the TTR can therefore authenticate a suitable
      message from the MN, no matter what IP address the MN is now
      on.

      The MN using TTR-Mobility can still use tunnels to its TTR
      from any other IP addresses it still has, so there need be
      no break in communications due to getting a new IP address
      in a new access network, while other IP addresses are still
      active from other access networks.

      With TTR Mobility, there can be any number of correspondent
      hosts.  They don't need to know anything about mobility.

      There's no need for a mapping change when the MN gets a new
      IP address since the current TTR remains the ETR for the MN's
      EID prefix (LISP terminology) or micronet (Ivip).  The only
      time the mapping is changed is if a new TTR is used - and that
      would be a good idea if the MN moves more than about 1000km
      from the current TTR.  It will still work OK if the MN is
      on the other side of the Earth from the current TTR, but
      the path lengths would be long, so it is best to use a
      closer TTR.  Changing TTRs involves no loss of connectivity,
      even if there are minutes or perhaps an hour or so of delays
      in getting mapping to all the ITRs which need it (as might be
      the case with LISP).  This is because the MN will retain its
      tunnel(s) to the previous TTR and so will get any packets
      sent to that TTR, due to the original state of the mapping.

      CEE assumes that each host has a global unicast address
      - which may be OK if IPv6 or whatever develops without NAT.
      However, IPv4 is full of NATs, and most hosts other than
      servers can only get connections behind at least one level
      of NAT.

      TTR Mobility works fine with the MN's "care-of address" on a
      global unicast address or behind one or more layers of NAT -
      with the NAT box's public address being either Ivip/LISP
      mapped or ordinary (LISP: RLOC) address space.

      It will also work fine if the MN's care-of address is itself
      on an address provided by TTR Mobility.  (This means nested
      MN <==> TTR tunnels - it does not mean nested ITR --> ETR/TTR
      tunnels.)

So even if we were designing the Net from scratch, I would argue
against Loc / Id Separation and in favour of the current "overloading"
of both Identifier and Locator functions on the IP address.

> Distinction between a node's identity and topological location is
> natural, because the same node can be attached to the general
> network at different points. So, to name the node independently of
> its point of attachment, we need an identifier assigned to the
> node. And we also need a locator to represent the node's
> topological position.

I agree it is architecturally more "elegant" to uniquely identify each
node, and then to allow the node to use all of its potentially
multiple interfaces, each with potentially multiple Locators, for
communicating with other nodes.

But so far, no-one has figured out how to create a CEE architecture
which works as well as CES would.  So I think it is worth adding the
CES stuff to the routing system.  This can be done without altering
hosts (mobile hosts need tunneling software to their chosen commercial
TTR service) and without altering the interdomain routing system.

  - Robin

---

From: Toni Stoev <[email-masked]>
Date: Fri, 24 Sep 2010 10:15:47 +0300

>                    unreliable 3G etc. radio links.

OK. Half of us (who expressed opinion) are for, the other half are against location/identity separation.

Now node reference.
Endpoints of data communication in the general network are computers, i.e., nodes. Naming nodes is especially appropriate for path selection among nodes. It is the node that communicates with another node, so their location/identity needs to be expressed to the routing system.
In today's Internet naming endpoints is actually of their interfaces to links. This leads to weird situations where communication with a correspondent at a remote part of the 'Net is conducted on a per interface basis; and a change in the local interfaces of communication (i.e., links of attachment) means to the remote party a connection with different entity. (identity again)
In path selection, naming interfaces designates the norm that a route in one direction is totally different from the same route in the reverse direction, instead of being seen as a reverse path.

So, do you consent that nodes (instead of interfaces) have to be referenced with locators(addresses)/identifiers?

---

From: Toni Stoev <[email-masked]>
Date: Wed, 29 Sep 2010 16:02:06 +0300

> So, do you consent that nodes (instead of interfaces) have to be referenced with locators(addresses)/identifiers?

This time all of us (who expressed opinion) are for node reference (instead of interface's).

So, the easy part passed. Now the big mess and its even bigger clearance. Reiterating.

Inter/Intra Distinction/Separation

Inter-domain path selection and intra-domain next-hop resolution are unnecessarily entangled with the use of intra-domain prefixes in inter-domain path selection. So the inter-domain routing system has been filled up with routing domains' inner intelligence that is spilling all over.
But there are AS paths. They are the necessary and sufficient pointers for conducting inter-domain path selection; provided that routing domains start to convey inter-domain traffic as whole entities, acting similarly to nodes in intra-domain hop-by-hop forwarding.
Thus, inter-domain path selection will be based on AS numbers (only) and intra-domain next-hop resolution – on locators (currently IP addresses).

Do you agree that inter-domain and intra-domain routing have to be separated?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Sep 2010 09:15:42 -0400

Toni, you appear to be trying to assert that there is some sort of IRTF 
Rough Consensus on what should be named by Locators.
Since the question heavily depends upon other factors, I for one chose 
to ignore your asking an incomplete and underspecified question that is 
unrelated to the agreed work items of the RRG.

I would also note that it is for the Chair (or chairs) to decide when an 
idea or proposal has been discussed sufficiently, and has sufficient 
relevance that determining WG Rough Consensus is called for.  it is then 
the chairs job to conduct that, and to draw the conclusion.

Yours,
Joel M. Halpern

On 9/29/2010 9:02 AM, Toni Stoev wrote:
...

---

From: Toni Stoev <[email-masked]>
Date: Wed, 29 Sep 2010 17:32:03 +0300

> Rough Consensus on what should be named by Locators.

Nope. I am seeking consensus in the RRG on certain basic concepts. This I am doing upon approval of ILNP and its text:

"The Routing RG has had remarkably little consensus on anything, so virtually all Routing RG outputs are considered controversial."

> unrelated to the agreed work items of the RRG.

Ask, comment or point a direction on the matter, and I will complete and/or specify my question.
I am asking as simple as possible questions so that the least possible divertion of the topic occurs in replies.

> the chairs job to conduct that, and to draw the conclusion.

Ah, I see why the current recommendation "reflects the decision of the co-chairs", not the consesus of the group.
How about the chair checking the consensus on a set of documents, of which each contains the phrase "virtually all Routing RG outputs are considered controversial"?

I am provoking the resolution of controversial issues that have key effects upon the entire architecture.

Join.

---

From: Tony Li <[email-masked]>
Date: Wed, 29 Sep 2010 08:42:38 -0700

Folks,

According to my DRAM, the topics now in front of the RG are:

- Comments on the recommendation, currently in IRSG review
- Comments on the design goals document, which we should Last Call soon
- Comments on ILNP, soon to be in IRSG review
- Comments on IRON, currently in IRSG review
- Discussion of future RG topics

We can tolerate a certain amount of additional discussion, depending on its level of constructiveness.   Non-constructive commentary is, of course, discouraged.

Regards,
Tony

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Wed, 29 Sep 2010 16:38:09 -0500

https://datatracker.ietf.org/doc/draft-narten-radir-problem-statement/
I can't remember if it was on this list or V6Ops, but does it make a difference that this is an individual contribution that is expired? Should we perhaps do the same consensus check and push to full RFC status as we have been doing with the individual proposals?
Given the fact that it's fairly central to the discussion, I think that there's some value in this, assuming the author is willing to shepherd it.

Thanks,
Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Wednesday, September 29, 2010 11:43 AM
To: IRTF RRG
Subject: Re: [rrg] Consensus on inter/intra-domain routing separation

Folks,

Regards,
Tony

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

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Robin Whittle <[email-masked]>
Date: Fri, 01 Oct 2010 00:58:43 +1000

Short version:   Toni asked if I support the routing system
                 addressing nodes (complete hosts, via any of their
                 one or more interfaces) rather than the current
                 arrangement of each IP address referring to a
                 particular interface.

                 I answer in the context of retaining the existing
                 overloading of "Identifier" and "Locator" functions
                 on an IP address, which I support the continuation
                 of.  My answer is that I support the continuation of
                 the existing practice of these things referring to
                 interfaces, rather than nodes.

                 I did not attempt to discuss this in terms of Toni's
                 preferred architecture: Locator / Identifier
                 Separation.  However, ILNP does implement what he
                 wants, and I think the other CES architectures -
                 at least Name Based Sockets and RANGI - do.

Hi Toni,

On (2010-09-24 msg07379) you wrote, initially quoting
draft-rja-ilnp-intro-06:

>       anything, so virtually all Routing RG outputs are
>       considered controversial.
>
> network at different points. So, to name the node independently
> of its point of attachment, we need an identifier assigned to the

Then you quoted my reply (2010-09-21 msg07358 "Re: Consensus on
identity/location separation - Objections to Loc/ID Sep AKA CEE") to
your message that day (msg07356 "Consensus on identity/location
separation")

> OK. Half of us (who expressed opinion) are for, the other half are against location/identity separation.

Only you and I participated in the discussion.

You supported introducing Locator / Identifier Separation and I argued
against it - for retaining the current "overloaded" arrangements and
for introducing a CES architecture (Ivip, LISP or IRON) which would
continue to support these arrangements.

Then you asked another question:

> Now node reference.
>
> Endpoints of data communication in the general network are
> computers, i.e., nodes. Naming nodes is especially appropriate
> for path selection among nodes. It is the node that communicates
> with another node, so their location/identity needs to be
> expressed to the routing system.

> In today's Internet naming endpoints is actually of their
> interfaces to links. This leads to weird situations where
> communication with a correspondent at a remote part of the
> 'Net is conducted on a per interface basis; and a change in
> the local interfaces of communication (i.e., links of
> attachment) means to the remote party a connection with
>  different entity. (identity again) In path selection, naming
> interfaces designates the norm that a route in one direction
> is totally different from the same route in the reverse
> direction, instead of being seen as a reverse path.

OK.

> So, do you consent that nodes (instead of interfaces) have to be
> referenced with locators(addresses)/identifiers?

I am only discussing this in the context of retaining the current
overloading of identifier and locator functions onto the IP address -
that is, the current Internet protocols.  This would be retained by
the CES architectures.  I won't discuss what I think would be best for
what you prefer - Locator/Identifier Separation (CEE architectures) -
since I don't support such an architecture.

I don't nodes "have to be" referenced by rather than the specific
interfaces of a node, since the Internet today works with the
"IP-address = identity = routing locator" applying to a specific
interface, such as an Ethernet NIC or wireless interface, rather than
the "IP-address = identity = routing locator" applying to a particular
computer (i.e. "node" AKA host).

However, what you suggest can be done for applications which want to
do it, using existing protocols:

  1 - Application always references a remote node via its FQDN.

  2 - Lookup of the FQDN returns (round-robin result of multiple
      IP addresses in no particular order) the IP addresses of the
      one, two or more interfaces of a single physical node.

  3 - Application sets up sessions to each such interface (from its
      one or more interfaces) and uses them in some way for load
      sharing, other kinds of traffic engineering and most
      importantly for recovery from failure of one interface (or that
      interface becoming unreachable) with session survival - AKA
      "multihoming".

      To be able to add interfaces during the session would require
      extra protocols between the hosts, with requisite authentication
      guff, or the originating host periodically performing another
      DNS lookup of the FQDN in order to get the latest set of IP
      addresses.

      This won't provide mobility in any usable form.

This chews a global unicast IP address for each interface, but
applications can be written to do this today.  I can't think of any
which do, but that doesn't mean it isn't, can't or shouldn't be done.

I do not support the change you are suggesting, which I understand
involves changing the Internet protocols to coerce all nodes to
communicate only in terms of themselves, irrespective of what
interfaces they are using.

One reason is that a node might not want incoming traffic to arrive on
all its interfaces.  Another is that it might not want to send traffic
on all its interfaces.

Some interfaces may be slow, expensive or unreliable - or the node may
want to avoid using them so they are ready to accept some other stream
of packets.

Some interfaces might, for policy reasons, be unsuitable for
particular types of communication.  Some interfaces might use networks
with too high a latency, or too high a packet loss, or too small an MTU.

So, to make your idea workable, I think a given physical computer
would need to generate multiple Identities, with each such Identity
assigned a set of its Interfaces suitable for particular kinds of
communication.

This can already be done by any application which is suitably written,
as I just described.

I think your intention is to support multihoming, traffic engineering
and probably mobility on a host-by-host basis - as is the case for
instance with ILNP.  However, I think it is best to have the
multihoming done at the level of the border routers of an end-user
network, without bothering each host at all with anything to do with
multihoming.  CES architectures do this.  CEE architectures make each
host responsible for handling multihoming, TE and mobility - which I
think is the wrong division of labor and would be very hard to manage,
test and make robust compared to doing everything at the level of the
end-user network as a whole.

 - Robin

---

From: Robin Whittle <[email-masked]>
Date: Fri, 01 Oct 2010 01:36:16 +1000

Short version:  I disagree with Toni's suggestion that the interdomain
                routing system should operate according to ASes, and
                not be concerned with routing packets addressed to
                particular prefixes to particular border routers.

                This concept of "AS-based routing" or "route on ASN"
                has been discussed before.  I provide 3 strong
                objections to it, any one of which would be sufficient
                to rule the idea out of serious consideration.

                There are no-doubt other objections.

Hi Toni,

In your message (2010-09-29 msg07400), you wrote about my lack of
response (and lack of responses by anyone else) to your message:

   Consensus on node reference (was: Consensus on identity/location
   separation)  (2010-09-24)

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

However, I have now replied to this:

   Re: [rrg]Consensus on node reference
      http://www.ietf.org/mail-archive/web/rrg/current/msg07406.html

You quoted your msg7379 in full and then wrote:

> OK. Half of us (who expressed opinion) are for, the other half
> are against location/identity separation.

You and I expressed an opinion in that thread - you support it and I
am against it.  (BTW, each of your paragraphs is one long line in the
archives.)

> So, the easy part passed. Now the big mess and its even bigger

I don't understand this.

> Inter-domain path selection and intra-domain next-hop resolution
> are unnecessarily entangled with the use of intra-domain prefixes
> in inter-domain path selection.

Yes, in the current arrangements, each interface has an IP address and
that IP address (in the destination field) is used for deciding how to
forward the packet at each router, no matter whether the router is in
the local network or outside it (i.e. in the Interdomain routing system).

I support the continuation of these arrangements.

CES architectures such as LISP and Ivip (I don't know all the details
of the latest version of IRON) are additions to the routing system in
general (primarily or entirely the interdomain routing system), which
don't affect node (host) behavior at all.  These architectures
involve tunneling packets from ITRs to ETRs.  LISP and Ivip do this by
encapsulating the packet in an outer header, with the ETR's IP address
in the outer header's destination field.  So the ordinary local and
interdomain routers still work the same as they do today, but the
inner packet is actually being sent towards an ETR which will
decapsulate it, according to the outer destination address, without
reference to the destination address of the packet which is being
tunneled.

    (Ivip in the long-term would transition to a "Modified Header
     Forwarding" arrangement in which there is no encapsulation, but
     the header would contain sufficient bits for routers to forward
     the packet to, or most of the way to, the correct ETR.)

> So the inter-domain routing system has been filled up with
> routing domains' inner intelligence that is spilling all over.

Yes, the interdomain routing system (the BGP routers in the DFZ) need
to concern themselves with each prefix which is advertised by one or
more border routers of any AS.

CES architectures aim to provide very large numbers of multihomable,
portable, prefixes for end-user networks, which can support inbound TE
and ideally mobility, without adding much to the number of prefixes
advertised in the interdomain routing system (AKA "advertised in the
DFZ").

> But there are AS paths. They are the necessary and sufficient
> pointers for conducting inter-domain path selection; provided
> that routing domains start to convey inter-domain traffic as
> whole entities, acting similarly to nodes in intra-domain
> hop-by-hop forwarding.
>
> Thus, inter-domain path selection will be based on AS numbers
> (only) and intra-domain next-hop resolution – on locators
> (currently IP addresses).

This change to the behavior of routers would enable considerable
simplification of the interdomain routing system.

I understand your suggestion would involve something like:

   Every router would somehow obtain a list of all the prefixes
   currently handled by the system.  Each prefix would have a
   single ASN, indicating which ASN is advertising this prefix.

   Then, the routers would somehow (perhaps with a BGP-like protocol)
   decide how to forward packets based entirely on which ASN
   advertised the prefix the destination field best matches.

   Since the number of ASNs is a lot smaller than the number of
   prefixes, this would significantly reduce the workload of the
   route processors of all the interdomain routers.

This way, it would be relatively simple to add very large numbers of
prefixes, without the scaling difficulties which would occur if we
kept the current system and expected the BGP-based interdomain routing
system to cope with all those prefixes.

However, it is not necessarily our task to make life easier for the
routing system - especially if it involves placing extra processing,
packet number, packet size and/or delay burdens on some or all hosts.
I argue against CES (Locator/Identifier Separation) because it would
do all these things.

Your idea of routing on ASN alone has been discussed on the list
before.  As far as I know, the major objections to it include:

  1 - This would only be acceptable if, for all ASes, the AS would
      be happy to accept packets for any of its prefixes on any of
      its routers.

      This is most definitely not the case for most ASes, AFAIK.

      ASes want and need to be able to advertise particular prefixes
      on particular border routers.  This is how they share the load
      and achieve various other objectives.

  2 - Your proposal would only work if it could be assumed that each
      AS was actually a cohesive network with all its border routers
      (BRs) able to easily send packets anywhere inside the network.

      This is not a reasonable assumption.  I could be an AS and have
      routers at a dozen sites all around the world, with one or more
      BRs at each site - but no links between these sites.  I might
      want to advertise some of my prefixes at one site, or one BR at
      one site, and other prefixes at another.

      Your plan would compel me to accept incoming packets for any
      of my prefixes on any of my BRs at any of my sites.  But this
      would be completely at odds with what I want and need to do.

  3 - Your plan would mean that an AS would have no control
      whatsoever over where its traffic enters its network.  Let's
      say the AS has only 2 BRs.  There's nothing to prevent the rest
      of the routers deciding to send all the packets to BR-1 and
      none to BR-2.

      Likewise, an AS with 100 BRs couldn't prevent the rest of the
      routing system deciding to send all packets, addressed to any
      of its prefixes, to a single BR.

There are no-doubt other objections, but I think any one of these is
sufficient to rule out the possibility that "routing on ASN" is either
a good thing in principle, or has a hope of being accepted by networks.

> Do you agree that inter-domain and intra-domain routing have to be

They already are separated.  Between ASes BGP is used.  Inside ASes,
another routing protocol is used.

 - Robin

---

From: [email-masked]
Date: Thu, 30 Sep 2010 12:26:38 -0400

Consensus on this and  that:
I have expressed my favorite solution pretty clearly. So from my point of view it makes no sense to quarrel on terms and interpretations thereof.
Obviously I am against AS-(topological) routing

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Robin Whittle <[email-masked]>
An: RRG <[email-masked]>
Verschickt: Do., 30. Sept. 2010, 16:58
Thema: Re: [rrg] Consensus on node reference

Hi Toni,

OK.

 - Robin

---

From: Robin Whittle <[email-masked]>
Date: Fri, 01 Oct 2010 02:49:24 +1000

Short version:   I think Toni is asking some important high level
                 questions in a constructive manner.

                 I try to relate the answers to these questions to
                 the major bodies of opinion I think exist amongst
                 RRG participants.

Hi Toni,

In msg07402, you wrote in part:

> Ah, I see why the current recommendation "reflects the decision of
> the co-chairs", not the consesus of the group. 

Yes, but I and others support the publication, as an RFC, of
draft-irtf-rrg-recommendation-14 as a whole, with its summaries,
critiques, counterpoints and chairs' recommendation - in my case with
a note about problems with how ILNP is represented (msg07357).

> How about the chair
> checking the consensus on a set of documents, of which each
> contains the phrase "virtually all Routing RG outputs are
> considered controversial"?

I support the publication as RFCs of the ILNP I-Ds, but not because I
support ILNP or consider it uncontroversial.

> effects upon the entire architecture.

I understand you are asking a series of high-level questions:

  msg07356  [A] Consensus on identity/location separation

              Adopt Locator / Identity Separation vs. retaining
              existing overloading Locator = Identifier = IP address.

  msg07379  [B] Consensus on node reference

              Change the routing/addressing system to refer to nodes
              rather than (as present) specific interfaces of a node.

  msg07400  [C] Consensus on inter/intra-domain routing separation

              Have interdomain routers concern themselves with ASNs
              primarily, so they each figure out which of their
              interfaces should get packets addressed to any of the
              prefixes an AS advertises - as opposed to the current
              BGP arrangement of ignoring the ASN at the end of
              a route and forwarding packets according to their
              prefix, to the one or more border routers which
              advertise this prefix.

I think these are important questions and I tried to answer them
constructively.

I think there are three broad bodies of opinion in the RRG - not
counting those who are undecided:

  1 - Keep the existing overloaded arrangements and solve the
      routing scaling problem by adding a CES (Core Edge
      Separation) architectural enhancement: LISP, Ivip, TIDR or
      IRON.

      This retains all existing host functions and protocols
      unchanged, including the practice of the IP address
      specifying (as an Identifier and Locator) a specific
      interface of a node, rather than the node itself.

        [A] LOC/ID?                           No.
        [B] Node instead of interface?        No.
        [C] Route on ASN rather than prefix?  No.
            Change host protocols?            No.
            Change host stacks or apps?       No.
            Add work, delays etc. to hosts?   No.
            Add complexity to routing system? Yes.

  2 - Keep the routing system relatively unchanged, and solve
      the routing scaling problem with new protocols and
      functionality in all nodes, using the Locator / Identifier
      Separation (Core Edge Elimination CEE) approach, such as
      ILNP, Name Based Sockets, RANGI or GLI-Split.

      In these architectures, an Identifier refers to a node
      (host) and each node has one or more Locators, which are in
      practice IP addresses (IPv6 in all cases except ILNPv4,
      which is not practical since it requires upgrades to all
      IPv4 BGP routers).

      I think this involves new application protocols and adoption
      of IPv6 as a basis.  This is certainly the case for Name
      Based Sockets, and I argue that ILNP needs applications to be
      rewritten too.  No-one has shown how ILNP can work with
      existing applications.  I think the problems I encountered
      trying to figure out how ILNP would work with existing
      applications would also apply to RANGI, but the RANGI
      designers say this is not the case.  I intend to discuss
      this more.

        [A] LOC/ID?                           Yes.
        [B] Node instead of interface?        Yes.
        [C] Route on ASN rather than prefix?  No.
            Change host protocols?            Yes.
            Change host stacks or apps?       Stacks and apps
                                              (though ILNP and RANGI
                                              supposedly work with
                                              existing IPv6 apps)
            Add work, delays etc. to hosts?   Yes.
            Add complexity to routing system? No.

  3 - Replace the BGP interdomain routing system with something
      which uses different algorithms for each router to share
      information and decide how to route packets, either
      according to the prefix their destination address matches,
      or perhaps according to the ASN which advertises that prefix.

      These are TARA (draft-hummel-tara-00) which concerns geographic
      routing (I have partially read it and intend to comment on it)
      and the Hyperbolic Mapping proposal (papers in a Nature
      Communications and Physical Review E arxiv.org/abs/1006.5169).

      Like the CES proposals, I think these proposals involve no
      changes to host protocols, stacks or applications - and no new
      burdens on any hosts.

      (I think these are both completely impractical since they do
      not enable routers to serve the needs of networks, and because
      there's no way of introducing these changes.  I think there is
      little or no support for them beyond the proponents, but at
      least they have been described and discussed - and they are
      completely different from the CES and CEE approaches.)

        [A] LOC/ID?                           No.
        [B] Node instead of interface?        No.
        [C] Route on ASN rather than prefix?  Maybe?
            Change host protocols?            No.
            Change host stacks or apps?       No.
            Add work, delays etc. to hosts?   No.
            Add complexity to routing system? ...
                Supposedly simplify it compared to what a BGP-based
                system would need to do in order to achieve the
                same results - but I think neither could work.

Another approach might be to soup up BGP and/or BGP routers - but I
don't think anyone seriously suggests this will provide the
multihoming, TE, portability and mobility we need.

I think that outside the RRG, some or many folks may think there's
no real problem that can't be handled by BGP routers improving their
capabilities in the years to come (Moore's Law etc.) and so coping OK
with continued growth in the number of advertised prefixes.  However,
I think this ignores that fact that the current arrangements fail to
provide multihoming, portability and TE for many networks which want
and need it - and can't provide global mobility.

  - Robin