Subject: Re: [rrg] Solution space summary comments

From: "William Herrin" <[email-masked]>
Date: Fri, 26 Dec 2008 19:08:06 -0500

On Fri, Dec 26, 2008 at 6:07 PM, Stefanos Harhalakis <[email-masked]> wrote:
> On Wednesday 24 December 2008, William Herrin wrote:
>> http://bill.herrin.us/network/rrgarchitectures.html
>
> I'm new to this list/area (so be gentle :-) and I've just read the above page.

Sure, but let me push it off into a different subject line.

> I find it weird that while the title is "Routing table size problem" there is
> a lot of talk about mobility (plus other things like PMTUD (?)). Even though
> those are real-world problems, I see that you're trying to address them at
> the same time. AFAICT from the document, this complicates things a lot.

That's actually a big question. Let me offer the direct answers and
ask you to tell me how to expand on them from there.

PMTUD: Strategy A describes a range of architectures which could
replace the routing system we have now. One common characteristic of
most of the strategy A architectures is that they add information to
the packets in transit, increasing the packet length. Where the
endpoints are still speaking normal TCP/IP, this creates an issue with
Path MTU discovery. The endpoints don't know what to do when an ICMP
message comes back that the modified packet is now too large... unless
you somehow intercept and translate that too.

The other solution strategies don't appear to impact path MTU discovery.

Mobility: The need to multihome drives the routing scalability
problem. As we look at different ways of multihoming than what we do
now, some kinds of mobility look a lot like multihoming. If we're
disconnecting and reconnecting links in the topology graph, it might
not matter that the reconnected links are in a different location than
the disconnected ones.

Our focus though, is multihoming. You'll note that the words "mobile"
and "mobility" do not appear in the architectures summary.

> For example, criticism #1 for strategy B seems only related to mobility and I
> see it as a problem no matter how routing works (except perhaps from an
> unknown-yet very-special case).
>
> From what I understand from the document, if there is ever a GUID/SID/LOC
> breakup, the core routing will only deal with LOC, while the TCP (strategy B,
> criticism 1) will have to do with SID.

Hence criticism #1: TCP does not deal with a SID divorced from the
GUID and locator, nor is it clear that there is an reasonable
evolutionary change to TCP where it can construct a SID that doesn't
borrow from the GUID or Locator. So, if we want to correct the design
defect in the protocol suite and separate out the GUID, SID and LOC,
it may not be possible to preserve compatibility with the old TCP,
UDP, and the applications which use them.

Compare that to most of the strategy A approaches. The GUID, SID and
LOC are not separated out at all, so TCP continues to function. A new
remote LOC (RLOC) is introduced that's only valid within the network
core and the scalability issue is left untouched in local routing
where it seems to be more tractable. By mitigating the design defect
instead of correcting it, the strategy A systems preserve backwards
compatibility. Most everything that uses TCP now should still work.

> Also, shouldn't firewalls have to work
> with GUIDs instead of LOCs ? (strategy B, criticism 2)

I would think so, yes. But that's not the only way firewalls are used
today. They're also used to block "spoofing" and similar attacks on
the IP address that are more closely associated with the IP address's
locator semantics.

> for Strategy E: Assuming that managers, politics and economy will efficiently
> solve a technical issue that IETF and technicians can't, seems somehow...
> well... wrong... :-)

We're in the rejection phase. Ask for a consensus call that we reject
strategy E.

> for Strategy F: 6000$ per year per prefix seems like a small amount.

Then I respectfully ask you to mail me $6000. :)

The premise of strategy E is that if you can bill for it, that $6k is
perhaps not unreasonable as the entry fee for multihoming. The premise
behind strategy F is that as an Internet user with two ISP's, I can
remove $6000 from your pocket any time it pleases me to do so and you
just have to deal with that as a cost of being online.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Stefanos Harhalakis <[email-masked]>
Date: Sat, 27 Dec 2008 16:50:43 +0200

Thanks for your explanations!

See inline comments:

On Saturday 27 December 2008, William Herrin wrote:
> > I find it weird that while the title is "Routing table size problem"
> > there is a lot of talk about mobility (plus other things like PMTUD (?)).
> > Even though those are real-world problems, I see that you're trying to
> > address them at the same time. AFAICT from the document, this complicates
> > things a lot.
>

There is always the possibility to add PMTU information to the routing 
protocol (or something like that) like EIGRP does. As mentioned in the page, 
the approach looks like a "tunneling method", so the "tunnel endpoints" can 
reply with an ICMP fragm. needed when a packet of size S would be sent to a 
"tunnel destination" with PMTU P with P<S (and DF bit set). This way, no 
intermediate core router will ever return such an ICMP message to the end 
nodes.

> not matter that the reconnected links are in a different location than

(Here I may repeat some of your words, just to make clear we see it the same 
way)

Let me split the problem to:

a) GUID/LOC/SID separation
b) Mobility/Multihoming
c) Routing table size

(b) depends on (a) and (c) can be greatly helped by (a), but (b) has nothing 
to do with (c). As long as the separation happens, mobility will be feasible. 
I strongly believe that it would be better if each issue was seen
separately.

I always thought mobility as something that is layered "above the IP layer". 
For example, while using the IP (or GUID or LOC+GUID) to deliver packets, use 
something else (SID) to uniquely identify endpoints. This makes (b) and (c) 
completely different problems as long as (a) is solved.

Perhaps even (a) should be seen as 2 different problems (which is what some 
parts of the document indirectly say):
a1) LOC - IP separation
a2) IP -> SID/GUID separation

Isn't (a1) all that is needed for solving (c) and (a2) all that is needed for 
solving (b) ?

If yes, then the problem comes to:

a) Add LOC to Internet (core only?) to reduce routing table size
b) Add SID support to IP (either directly to the protocol or indirectly to the 
TCP/IP suite) to support mobility

Those are two different problems that can be solved in parallel. Solving them 
as one seems to me like living 35 years ago and and trying to implement TCP 
and IP as one (wrong?).

> and "mobility" do not appear in the architectures summary.

As you said eariler, most probably multihoming (for nodes) and mobility mean 
the same thing. I was referring to something like this quote:

"Link state changes in the coreward path are satisfied by renumbering instead 
of rerouting".

which I interpret as "address (GUID) change" (a.k.a. mobility)

> > For example, criticism #1 for strategy B seems only related to mobility
> > and I see it as a problem no matter how routing works (except perhaps
> > from an unknown-yet very-special case).
> >
> > breakup, the core routing will only deal with LOC, while the TCP
> > (strategy B, criticism 1) will have to do with SID.
>

TCP can always be extended in different ways. There is a draft [1] for 
providing extra options space for TCP segments and this space may be used to 
store SID. Of course TCP seems to need to be modified but we may come up with 
a better solution. As you're saying, even this way, UDP will still have 
problems and a solution may be incompatible with SCTP.

There is always the possibility to be able to do the separation while keeping 
backwards compatibility. I don't have something to propose, but (and I 
believe that you'll agree) history and experience shows that at the beginning 
of something like this the implementation should follow the theory and not 
the reverse. (Shouldn't we think abstract?)

> the IP address that are more closely associated with the IP address's

Isn't this almost impossible by definition when having multihomed nodes?

> just have to deal with that as a cost of being online.

You assume here that each user / ip address will have a different route 
(multihoiming+mobility ?)?. If not, then when my ISP gets a /20 IPv4 block, 
those 4k addresses will mean about 2$ per person per year. Far less than what 
I pay. The number becomes a lot smaller for much larger IPv6 blocks (an ISP 
can have just one (lets say) /96 block).

Again, thanks for the introduction :-)

[1] http://tools.ietf.org/html/draft-eddy-tcp-loo-04
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: "William Herrin" <[email-masked]>
Date: Sun, 28 Dec 2008 13:14:37 -0500

> intermediate core router will ever return such an ICMP message to the end

Hi Stefanos,

That could work. It sets constraints on the placement of ITRs and
ETRs... The origin of the core route can only advertise an MTU that is
the smallest supported betweeen the route origin and the ETR. On the
other end, the ITR would have to consult the core routing table for
each ETR and it would need a routing table feed to know when the path
MTU changes. It wouldn't be possible to divorce the ITR's operation
from what's happening in the core.

Do you think it's important to add this variant? Since I didn't hear
it in the months the document was open to casual additions, I'm
inclined to ask you to collect a consensus to add it late.

> to do with (c).

I don't agree with that last statement. I believe the relationship is
this: (c) is a harsh technical and economic problem that impedes the
growth and improvement of the Internet. Because we didn't do (a), (b)
drives (c).

One approach to solving (c) is to go back and do (a). If we do (a)
then (b) will no longer drive (c) so (c) will cease to be a problem.
This is strategy B in a nutshell.

The other six strategies recognize that going back and doing (a) at
this late date will break things. So, they do a partial job of (a)
(strategy A), they muck with (b) directly (strategy C) or they try to
suppress (c) directly (strategy E).

> Isn't (a1) all that is needed for solving (c) and (a2) all that is needed for

Yeah, that's more or less right.

> as one seems to me like living 35 years ago and and trying to implement TCP

They don't quite solve in parallel. The LOC and SID already exist;
they're not new. TCP and UDP tangle the LOC in the SID. You have to
untangle that in order to do something useful in either problem space.

> which I interpret as "address (GUID) change" (a.k.a. mobility)

Not quite. In that case, the node's GUID is something external,
another number or a DNS name. The LOC change gets pushed into the GUID
map but the GUID itself remains static. The next client that tries to
originate communications with the GUID finds the new LOC numbers.

> problems and a solution may be incompatible with SCTP.

Also bear in mind that TCP already has a SID, composed of the source
and destination ports and IP addresses. If you add a SID to the
options, it has to supercede the existing SID. That creates a heck of
a mess with devices like firewalls which expect the original SID to be
valid.

What do you do when extending TCP? Drop both ports to 0 to signal that
the SID is contained in the options? What then becomes the GUID and
how do you map it to the LOCs? The API only has a spot for "IP
address." Do you change the underlying API semantics so that the
32-bit or 128-bit number the application passes gets looked up in a
GUID to LOC map instead of being used directly as the LOC?

> the reverse. (Shouldn't we think abstract?)

If you don't think about compatibility at the start and you don't keep
thinking about compatibility throughout the process, you rarely get
compatibility at the end. If compatibility is a desirable output, you
have to keep it front and center throughout.

> Isn't this almost impossible by definition when having multihomed nodes?

With the current semantics on the IP address, yes it is. Doesn't that
mean that left unaddressed, an explosion of multihoming aggravates the
spoofing problem?

> can have just one (lets say) /96 block).

It isn't an assumption. Each time I introduce a multihomed system into
the backbone, I consume at least $6000/year of router resources
worldwide. That's not $6000 of my money; it's $6000 of your money. I'm
taking it right out of your pocket. If you don't want me to take your
money today, you have to discourage or prevent me from introducing my
own multihomed system. Which is precisely what the RIRs do, and they
do it so well that despite the Internet's size there are less than
30,000 multihomed systems.

> Again, thanks for the introduction :-)

You're welcome.

Regards,
Bill Herrin