Re: [rrg] Solution space summary comments

[Stefanos Harhalakis <[e-mail]>]

Thanks for your explanations!

See inline comments:

On Saturday 27 December 2008, William Herrin wrote:
> On Fri, Dec 26, 2008 at 6:07 PM, Stefanos Harhalakis <[e-mail]> 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.
>
> 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.

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.

> 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.

(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?).

> Our focus though, is multihoming. You'll note that the words "mobile"
> 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).
> >
> > 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.

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?)

> > 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.

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

> > 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.

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
[e-mail]
https://www.irtf.org/mailman/listinfo/rrg