Subject: [RRG] What do we have consensus on?

From: Robin Whittle <[email-masked]>
Date: Thu, 22 May 2008 13:28:28 +1000

Hi Tony and Lixia,

Can you list what decisions the RRG has achieved consensus on?

I think clarity on these points would help us reach consensus on
whether to keep open discussions about solutions in the
"Translation" and "Transport" areas of the total possible solution
space.

For instance, is there broad consensus that will the RRG have done
its job if we propose a solution which only works with IPv6?

The RRG Design Goals only mention IPv4 once and do not mention IPv6
in the body of the text.  There is no IPv6 scaling problem and won't
be one for many years - until the adoption level rises well beyond
the current state, which would take a decade or more at current
growth rates.   I assumed we were trying to solve the IPv4 routing
scaling problem, with an eye to doing something similar for IPv6 -
although perhaps not with the same urgency.

Do we have consensus that it is acceptable for our solution to
require host changes to all hosts which participate in
communications which involve the new techniques?   For instance if a
host-based solution doesn't provide scaling benefits when
communicating with a non-upgraded host.

Do we have consensus that if the host-based solution by its very
nature makes it impossible for the network administrator to control
multihoming, portability etc. via central routers, that such an
approach provides suitable benefits to the routing system and to
those who must adopt it that is likely to be widely enough adopted
to make sufficient difference to the routing scaling problem?

  - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Tony Li" <[email-masked]>
Date: Thu, 22 May 2008 12:00:59 -0700

Hi Robin,

|Can you list what decisions the RRG has achieved consensus on?

There are a few things that we have consensus on and even then there are
contingencies on that consensus.  Specifically, for the mapping function, we
have consensus that we should support host specific identifiers, as well as
blocks.  We also have consensus that mapping systems that there should be
active mechanisms for dealing with overload situations.  

|For instance, is there broad consensus that will the RRG have done
|its job if we propose a solution which only works with IPv6?

No, not at all.  

|The RRG Design Goals only mention IPv4 once and do not mention IPv6
|in the body of the text.  There is no IPv6 scaling problem and won't
|be one for many years - until the adoption level rises well beyond
|the current state, which would take a decade or more at current
|growth rates.   I assumed we were trying to solve the IPv4 routing
|scaling problem, with an eye to doing something similar for IPv6 -
|although perhaps not with the same urgency.

Bad assumption.  We have the same problem in v6 that we do in v4 since the
architecture is identical.  Solving v4 without solving v6 is just a bandaid.
Hopefully, we can do better.  IMHO, it would be sufficient to fix just the
v6 side of things, but again, that's personal opinion.

|Do we have consensus that it is acceptable for our solution to
|require host changes to all hosts which participate in
|communications which involve the new techniques?   For instance if a
|host-based solution doesn't provide scaling benefits when
|communicating with a non-upgraded host.

No, we don't have consensus on that.  We don't have consensus that host
changes are prohibited either.

|Do we have consensus that if the host-based solution by its very
|nature makes it impossible for the network administrator to control
|multihoming, portability etc. via central routers, that such an
|approach provides suitable benefits to the routing system and to
|those who must adopt it that is likely to be widely enough adopted
|to make sufficient difference to the routing scaling problem?

Nope, we don't have consensus on that either.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Fri, 23 May 2008 20:58:26 +1000

Hi Tony,

Thanks for your reply:

> blocks.  

OK.

> We also have consensus that mapping systems that there should be

I don't understand this or recall the discussion.  Can you point me
to that discussion.

>> its job if we propose a solution which only works with IPv6?

Good.

> v6 side of things, but again, that's personal opinion.

I wasn't suggesting we only try to solve the IPv4 routing scaling
problem, or that the solution should only work for IPv4.  However, I
think the urgency of implementing the solution in IPv6 is less - so
we could probably afford to wait and learn from the IPv4 experience.

IPv6 mapping data is more voluminous, since the ETR address is 4
times as long as in IPv4, and if the micronet (EID) is specified
with 128 bit precision ("for the mapping function, we have consensus
that we should support host specific identifiers") then this is 4
times longer too.  These factors of 4 are significant, but are
unlikely to make any particular scheme completely impractical in
IPv6 if it is a good solution for IPv4.

> changes are prohibited either.

OK.

> Nope, we don't have consensus on that either.

That's not surprising since it was a badly written sentence.  It is
really a critique of any solution which requires host changes.

  - Robin

---

From: "Tony Li" <[email-masked]>
Date: Sun, 25 May 2008 12:54:07 -0700

Hi Robin,

|> We also have consensus that mapping systems that there should be
|> active mechanisms for dealing with overload situations.  
|
|I don't understand this or recall the discussion.  Can you point me
|to that discussion.

Ok, after a more careful look at the mailing list, I see that we started the
discussion and we haven't done a formal consensus check, so I'd like to
retract that.  We did discuss and I do have some proposed text that I think
captures where we are, but we haven't been formal about it.

|I wasn't suggesting we only try to solve the IPv4 routing scaling
|problem, or that the solution should only work for IPv4.  However, I
|think the urgency of implementing the solution in IPv6 is less - so
|we could probably afford to wait and learn from the IPv4 experience.

You are, of course, welcome to your opinion.  However, IMHO, it is
inappropriate to use IPv4 as a proving ground.  We cannot reasonably ask the
entire world to change routing architectures *as an experiment*.  We need to
perform experiments to be sure, and they may be done on v4, but by the time
that we reach the scale of the entire network, we should be extremely
certain of the outcome.

Thus, I feel that the real overriding requirement is that we have a solution
applicable to v6.  

Tony

---

From: Robin Whittle <[email-masked]>
Date: Mon, 26 May 2008 13:32:20 +1000

Hi Tony,

> Thus, I feel that the real overriding requirement is that we have a solution

I think we need a solution which works for both.  I wasn't
suggesting that IPv4 be used as any kind of test bed.

I am confident that Ivip could be implemented on a small scale for
both IPv4 and IPv6 to prove it works and that it is technically
feasible.  Then it could be implemented with confidence in both IPv4
and IPv6.  A major change such as this involves a bunch of
technical, administrative and business considerations which all
interact - but it looks feasible and promising to me.

I think the demand for the solution would be much stronger and more
urgent in IPv4 than in IPv6.

 - Robin

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 27 May 2008 00:54:14 -0700

Hi Robin,

instead of replying to each of your bullets below, here is what I  
thought where we are at this time: recall the discussions we started  
in April following the message on RRG process clarification:

     We need to first come to some agreement on the very highest
     level branches in the decision tree (e.g., do we do map-and-encap
     or translation or ???)

Towards the above goal, one step is to first reach a shared  
understanding of exactly how many branches we face at that highest  
level branching point.

I offered a strawman list of the branches: (really just 2 main branches)

> #1 Using only aggregatable addresses throughout in the Internet
> The essence of this approach is that a multihomed site will have  
> multiple address prefixes.
> Example approaches under this category:
> - SHIM6, with a shim layer between IP and transport to hide the  
> multiple
>  IP addresses from transport
> - A proposal by Mark Handley, which pushes all multiple IP addresses
>  all the way up to transport layer to handle
> (NOTE: I mention these examples for the sake of illustrating what  
> this branch means; by no means we should get into specific proposal  
> debate here)
>
> #2 Routing on aggregatable addresses only inside the global transit  
> core (the place that faces scalability challenges today), but do not  
> push these provider-based addresses into user sites.
> The essence of this approach is that a mapping layer must exist at  
> the interface between user sites and the transit core.
> (the word "layer" is meant an insulation boundary between parts of  
> the net; please do not confuse it with "protocol layer". I simply  
> could not find another word at the moment)
> Example approaches under this category:
> - map-n-encap, which uses IP-in-IP tunneling at the boundary
> - GSE, which uses IP address rewrite at the boundary

Tony suggested 3 branches:

- Transport:   this falls with #1 in the above
- Map-n-encap: this is #2 in the above
- Translation: I did not get exactly what this one is, if it is
                not the GSE rewrite.

there was a debate between Tony and Brian at the time about whether  
SHIM6 is translation. I dont think I fully understood Tony's argument  
on why SHIM6 is a translation; may be Tony could try one more time here.

Lixia

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 27 May 2008 10:05:27 -0400

Lixia Zhang wrote:
> thought where we are at this time: recall the discussions we started in 
> April following the message on RRG process clarification:
> 
> understanding of exactly how many branches we face at that highest level 
> branching point.

MY personal start on high level branches (something akin to facets, and 
the aspects of each top level facet, although probably not strictly a 
faceted taxonomy)), along with some suggested terminology is in
draft-halpern-rrg-taxonomy-00.txt.

While that document can definitely still use further clarifications, I 
would appreciate comments from other folks on its content before I 
produce -01.

Thank you,
Joel M. Halpern

---

From: "Tony Li" <[email-masked]>
Date: Wed, 28 May 2008 00:57:45 -0700

|Tony suggested 3 branches:
|
|- Transport:   this falls with #1 in the above
|- Map-n-encap: this is #2 in the above
|- Translation: I did not get exactly what this one is, if it is
|                not the GSE rewrite.
|
|there was a debate between Tony and Brian at the time about whether  
|SHIM6 is translation. I dont think I fully understood Tony's argument  
|on why SHIM6 is a translation; may be Tony could try one more 
|time here.

The way that I look at it, Shim6 establishes a set of 'identifiers' that the
transport protocols will use and then plays some games to determine the set
of 'locators' for network layer operations.  Since it is doing wholesale
swapping of the locators for the identifiers, I'd claim that it's mostly a
translation approach.  

I think that it's clear that it's not actually changing transport.  Further,
it's pretty clear that while it is piggybacking some information, it really
isn't going to the full-scale extent of a real encapsulation.  

That said, I recall thinking that there was some validity to Brian's
position and at the same time thinking that it wasn't yet worth worrying
about the specific details.  I am, of course, very happy to revisit this if
it becomes productive.

Tony

---

From: Christian Vogt <[email-masked]>
Date: Thu, 29 May 2008 02:37:41 +0300

Lixia, Tony,

I concur with Tony in characterizing Shim6 as performing address
translation.  Internet engineers tend to be skeptical about
translation based on experience with NAT boxes.  But the
(un)acceptableness of translation depends on whether it is stateful,
and if so, whether it takes place in hosts or in the network.

More specifically, in my view, the fundamental difference between
encapsulation and translation is where you store the information
needed to perform a packet transformation.  With classic tunneling,
this information is included in packets.  With classic translation,
the information takes the form of state at the entity performing
packet transformation.  The information carried in packets is then
reduced to a "state lookup key", which enables the receiver to find
the state it needs for the packet transformation.  In classic
translation, the state lookup key is a translated port number.

Accordingly, Shim6 performs translation.  Shim6 completely relies on
state in sender and receiver; the information in packets is limited to
a state lookup key, which in Shim6 terminology is a "context tag".

Classic translation is problematic when performed inside the network,
as NAT boxes do.  The network-side state then constraints the route of
a packet flow.  This limits rerouting flexibility -- a key feature of
IP.  Shim6 does not have this disadvantage because the translation
occurs in end hosts, and hence does not constrain any route.

1-to-1 translation differs from both encapsulation and classic
translation since it requires neither state nor in-packet information.
Due to its statelessness, it does not suffer from aforementioned
rerouting limitations, even if it is performed inside the network.

- Christian

---

From: Peter Sherbin <[email-masked]>
Date: Thu, 29 May 2008 07:30:38 -0700 (PDT)

> draft-halpern-rrg-taxonomy-00.txt.... I would appreciate comments

Good summary.
2. Terminology. Both a 'Core Aggregatable Address' and a 'Scoped Address' use an 'address' in their definition while the address itself remains undefined.
There are three Entity Identifiers. Would it be enough to have just one global identifier for a point of connection to the network (a node if there is only one interface, an interface if a node has more than one). Also a definition of a 'Communicating EI' equals to a 'Scoped EI' when binary is used for the later. Would it suffice to have a single global EI with the scope determined solely by the locator?

3. New Math or New Naming. Mapping combines split attempts separately from geo / AS aggregation. Why / how does aggregation prevents the splitting? E.g. in a split the network (locator) part still can be aggregated by geography or AS.

4. Divide and Conquer. Why consider 'Identification by name'? DNS is a limited subset of the Internet where a human-readable name is needed. The majority of network elements remain transparent to a human end-user of the application.

4.1. What mappings? Why mapping is needed is there is a split, i.e. an id part is added to a locator part to establish a routing end point?

5.3. Separate Identification. Why the oversimplified form is not good? If it is insufficient, what is lacking? If it works, what benefits are gained by adding complexity?

6. Scoping. The 3rd paragraph is confusing as it refers to the scope of identifiers. The scope is a property of a locator, right?

Thanks,

Peter

--- On Tue, 5/27/08, Joel M. Halpern <[email-masked]> wrote:

> From: Joel M. Halpern <[email-masked]>
> Subject: Re: [RRG] What do we have consensus on?
> To: "Routing Research Group" <[email-masked]>
> Date: Tuesday, May 27, 2008, 10:05 AM
> Lixia Zhang wrote:
> >

---

From: Scott Brim <[email-masked]>
Date: Thu, 29 May 2008 16:19:28 -0400

> translation, the state lookup key is a translated port number.

The primary intent in encapsulation is to preserve the original packet 
during an exchange between two intermediate hops.  The simple case is 
classic "layer networking", like IP over ATM or Ethernet.  A packet is 
encapsulated in total, and the "link" between encapsulation and 
decapsulation is seen as one IP hop.  In the case of IP-aware 
encapsulation, the TTL of the header may be deprecated.  So in that case 
there is no transformation whatever, by intent.

What you describe above one might call reversible translation.  But we 
need to differentiate between that and translations where there is no 
expectation of ever going back, e.g. IPv6->IPv4 or NAT, and just saying 
"classic translation" versus "reversible translation" gets awkward.

> rerouting limitations, even if it is performed inside the network.

What is 1-to-1 translation?

Scott

---

From: David R Oran <[email-masked]>
Date: Thu, 29 May 2008 17:34:49 -0400

> swapping of the locators for the identifiers, I'd claim that it's  
Except that translation approaches where the translation state is fate- 
shared with the transport above strike me as quite significantly  
different from approaches where it is not.

In fact, this may be an even higher level branch of the decision tree  
than map-n-encap vs. translation.

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 18 Jun 2008 22:24:29 -0700

> about the specific details.  I am, of course, very happy to revisit  

through a phone chat with Tony, I finally got what's the above tried  
to say.
It's all due to from which angle one looks at the picture.

I take the view of scaling routing by provider-aggregatable prefixes:  
for a multihomed site, both SHIM6 and Handley proposal take the  
multiple provider-based addresses all the way *into* each host.  As  
far as routing scalability is concerned, it makes no difference  
whether these multiple PA addresses stop at a shim layer, or go to  
transport layer (of course it can make a big difference as far as  
transport functions are concerned).
This is top-level branch#1 in my earlier msg http://psg.com/lists/rrg/2008/msg01220.html

Tony's above msg took the view from transport layer and *looking  
downward*: SHIM6 has this notion of EID, and the actual IP packets  
*may* be sent using IP addresses that are different from EID, hence  
"this is a translation" view, i.e. a translation from an "EID" to an  
"IP address".
(to be more precise, SHIM6's notion, as I understand it, is really a  
binding of a set of IP addresses to one transport session, so anyone  
in the set can be used. But lets not argue this semantic detail).

Lixia

---

From: "Tony Li" <[email-masked]>
Date: Wed, 18 Jun 2008 22:41:28 -0700

|through a phone chat with Tony, I finally got what's the above tried  
|to say.
|It's all due to from which angle one looks at the picture.
|
|I take the view of scaling routing by provider-aggregatable prefixes:  
|for a multihomed site, both SHIM6 and Handley proposal take the  
|multiple provider-based addresses all the way *into* each host.  As  
|far as routing scalability is concerned, it makes no difference  
|whether these multiple PA addresses stop at a shim layer, or go to  
|transport layer (of course it can make a big difference as far as  
|transport functions are concerned).
|This is top-level branch#1 in my earlier msg 
|http://psg.com/lists/rrg/2008/msg01220.html
|
|Tony's above msg took the view from transport layer and *looking  
|downward*: SHIM6 has this notion of EID, and the actual IP packets  
|*may* be sent using IP addresses that are different from EID, hence  
|"this is a translation" view, i.e. a translation from an "EID" to an  
|"IP address".
|(to be more precise, SHIM6's notion, as I understand it, is really a  
|binding of a set of IP addresses to one transport session, so anyone  
|in the set can be used. But lets not argue this semantic detail).

Agreed.  So if we look at things from the network side looking in, we have
the classes where:

- Locators propagate all the way to the host
- Locators are terminated at the site border

>From the feedback that we got from the SHIM6 discussion, there really aren't
enough tools today to deal with the case where locators propagate to the
host.  This isn't to say that it couldn't be fixed, just that there's an
(engineering?) issue to be dealt with.

Do we agree with this separation?  And is it useful?

Tony

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Jun 2008 08:31:52 -0400

> Do we agree with this separation?  And is it useful?
While I agree with the separation as a conceptually useful  
distinction, for me it isn't really the "top-level branch" in the  
architectural tree because one could always put a map-n-encap module  
in the routing layer of each host and then there would be three host- 
oriented approaches:
- topologically-aggregatable addresses and EIDs inside the routing  
layer of the host. Only EIDs visible to transport
- topologically-aggregatable addresses mapped to/from an EID in a shim  
layer between routing and transport layers of the host. Only EIDs  
visible to transport
- topologically-aggregatable addresses directly managed by the  
transport layer of the host

Others will of course see this differently, but for me the top level  
branch is in fact whether the solution *requires* code and state in  
the hosts, or conversely can be done by routers with the hosts totally  
oblivious. A consequence of this branching is that if you require new  
code in the hosts, you can exploit state in the hosts, which has  
benefits which have been articulated many times on this list.

In the taxonomy above, only the first approach shields the hosts from  
the mapping/translation/whatever. That's pretty fundamental in my book.

DaveO.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jun 2008 10:09:17 +1200

Dave,

If you look for a "top-level branch" we will never find
a view that everyone agrees with. Let's just say that this
is one important axis or facet, and there are others of
similar importance. Viewed that way, I agree with Tony's
summary.

   Brian

On 2008-06-20 00:31, David R Oran wrote:
> While I agree with the separation as a conceptually useful distinction,
> for me it isn't really the "top-level branch" in the architectural tree
> because one could always put a map-n-encap module in the routing layer
> of each host and then there would be three host-oriented approaches:
> - topologically-aggregatable addresses and EIDs inside the routing layer
> of the host. Only EIDs visible to transport
> - topologically-aggregatable addresses directly managed by the transport
> layer of the host
> 
> branch is in fact whether the solution *requires* code and state in the
> hosts, or conversely can be done by routers with the hosts totally

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Jun 2008 23:05:53 -0400

On Jun 19, 2008, at 6:09 PM, Brian E Carpenter wrote:

> a view that everyone agrees with.
I must have misunderstood the earlier messages that seemed to imply  
that was precisely what we were being asked to do.

> Let's just say that this
> similar importance.
I can buy that.

> Viewed that way, I agree with Tony's
> summary.
>
I agree with the part that there is a big difference between designs  
where the locators can't be guaranteed to reach the hosts and are  
handled in routers.

Whether those are visible inside the routing layer only, in a shim  
layer, or in the transport is secondary since by various  
implementation tricks and judicious layer violations, you can blur  
those distinctions. What you can't blur is whether we have a design  
that works when the hosts are oblivious to its existence.

Cheers, Dave.

>>> Agreed.  So if we look at things from the network side looking in,  
>>> we
>>> have
>>> the classes where:
>>>
>>> From the feedback that we got from the SHIM6 discussion, there  
>>> really
>>> aren't
>> distinction,
>> layer
>> the