Subject: Re: IETF multihoming powder: just add IPv6 and stir

From: "J. Noel Chiappa" <[email-masked]>
Date: Sun, 4 May 2003 16:00:29 -0400

> From: Kurt Erik Lindqvist <[email-masked]>

    >> It might be good to get the word out that multi6 wants to recharter
    >> and work on the identifier/locator thing aka GSE++ aka 6+10. Then we
    >> can see if the pro mob is larger than the anti mob at the meeting.

    > I am not sure I want to say that we recharter to the GSE++ model.
    > ...
    > they want to present and make their case for their solution and against
    > a GSE based approach

When people start talking loosely about "GSE" I get nervous, because there
are a number of (to me) independent architectural and engineering points that
are involved in what I think of as "GSE".

(Indeed, there might be a danger that "GSE" means different things to
different people, but that's a *separate* problem from the one that I'm
talking about here.)

Anyway, I think we need to:

- keep each of these separate things clear in our mind - although of course a
	particular proposed solution will consist of a (hopefully :-)
	carefully selected set of detailed answers, one for each point.
- because if one proves problematic, that *doesn't* mean the other
	(independent) ideas are unworkable.

As I see them, the points in "GSE" are:

1 - The basic approach to multi-homing being use of more than one locator
	(I think we are approaching rough consensus on this for any
	solution, not just GSE, but list it for completeness)
2 - Separation of location and identity, using two separate and distinct
	labels, one for each function
	(Again, I think we are approaching rough consensus on this for
	any solution, but list it for completeness)
3 - Use of IPv6 addresses (or parts of them) as the namespaces for both of
	those two classes of identifiers
4 - Details of the identifier; two obvious options:
	A - Use of two complete IPv6 addresses, one for each kind of
	identifier, sometimes called "16+16"
	B - One IPv6 address, divided into two fields (the original being
	"8+8", but I now see mention of "6+10")
5 - Replacement of part or all of the location identifier by entities other
	than the endpoints of the end-end communication
	A - replacement involving the destination locator only
	B - replacement involving the source and destination locators

Some combinations have repercussions; e.g. 5 plus 4B means that either you
have to modify TCP6 (which I think we decided was unfeasible), or the
original contents of the location identifier part of the IPv6 address(es)
have to be placed back in the packet before the endpoint processes it.

Anyway, I hope this sort of framework for thinking about them is useful.

	Noel

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 5 May 2003 08:42:59 +0200

On söndag, maj 4, 2003, at 22:00 Europe/Stockholm, J. Noel Chiappa 

> are involved in what I think of as "GSE".

Actually. I would prefer that we

Stop talking about GSE - and start talking about a number of features 
included in a specific solution. If that is written down in a draft, 
even better.

I think that this will help us avoid the worst confusions and debates 
on non-issues.

> different people, but that's a *separate* problem from the one that I'm

Well, maybe. Unless we solve this we will be running in circles.

> 	solution, not just GSE, but list it for completeness)

Agreed.

> 	any solution, but list it for completeness)

I think that there might be some more work needed here before I would 
say that we are at consensus. At least that is what I take away from 
the last days discussions.

> 	B - replacement involving the source and destination locators

The above points are definitely not very clear so far, but that is also 
where we need more work done. Especially if we want to have something 
to discuss in Vienna.
> Anyway, I hope this sort of framework for thinking about them is 

It is. But it would be even better if we agreed on the characteristics 
on all solutions (not to mention which solutions have been taken to the 
IETF)...

- kurtis -

---

From: Xiaowei Yang <[email-masked]>
Date: Mon, 12 May 2003 16:15:06 -0400

Hi,

I am a graduate student working on the design of a new Internet
Routing architecture. I've sketched out the design in a short paper.
One reader pointed out that I might get some operational side comments
from this list.  If you are interested, you can find the paper at:

http://www.isi.edu/newarch/DOCUMENTS/anon2.routing.pdf

I'd appreciate your comments very much!

If this posting is against the policy of the list, I apology and
promise will not do it again.

Xiaowei

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 May 2003 06:36:36 +0859 ()

Noel;

> 	B - replacement involving the source and destination locators

The question, then, is that what are the endpoints.

IMHO, mobile (home) agents and PIM RPs are the end points,
just as DNS servers and mail relays are the end points.

And the rewriting of destination locators on mobile agents
and PIM RPs is useful to eliminate tunneling,

OTOH, rewriting of source locator is not so useful, though I have
no reason to forbid it.

> have to modify TCP6 (which I think we decided was unfeasible),

I showed it feasible. It is working and interoperating with leagacy
hosts without extra overhead of negotiation.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 May 2003 00:35:02 +0200

On dinsdag, mei 13, 2003, at 23:37 Europe/Amsterdam, Masataka Ohta 

> OTOH, rewriting of source locator is not so useful, though I have

Unless the source address is already a valid address assigned by the 
ISP you're forwarding the packet to (which can't by definition always 
be the case in a locator/identifier scheme), you need to rewrite it in 
order to get through ingress filtering and to be able to receive ICMP 
messages. Remember that path MTU discovery is pretty much mandatory in 
IPv6 so you need those ICMPs. Ingress filtering is important to keep 
denial of service attacks in check to at least some degree.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 14 May 2003 15:29:20 +0859 ()

Iljitsch;

> be the case in a locator/identifier scheme),

That's why I overviewed in draft-ohta-e2e-multihoming-03.txt:

   However, to enable source address filtering to discard packets with
   source addresses not belonging to an ISP, it is useful to enable a
   host, not some intelligent intermediate router, select a source
   address compatible with an outgoing ISP.  For that purpose, intra
   domain routing protocols should maintain routing table entries with
   not only preference values of an external routes, but also proper
   prefixes to be selected for source addresses, if the entries are
   chosen by a host.

The solutions should be end to end that complex functionality must
be performed only on hosts.

Hosts needs help from routing protocols.

Traditionally, when only a single address was usually assigned to each
interface and when hosts with multiple interfaces are routers, address
of outgoing interface was the source address.

However, with multiple addresses to an interface, selection of source
address/locator can be performed properly only with the help from
routing protocol, which is a reason why IPv6 is broken in
source address selection.

> you need to rewrite it in 
> messages.

No. See above.

> Remember that path MTU discovery is pretty much mandatory in 
> IPv6 so you need those ICMPs.

No. PMTUD is one, among many, of a useless feature of IPv6.

Worse, implementations are wrong to do it at IP layer, where there
can be no proper value of timeout.

Just send packets not loger than 1280B.

> Ingress filtering is important to keep 

Ingress? Do you mean egress?

You can't filter an ICMP packet generated for a packet with forged
source address, because the ICMP packet has valid source and
destination addresses.

Tony> A filter that is looking at a locator is probably a bug.

Maybe or may not be. But, my point is that it is harmless.

Or, do you, may be as a router designer, mind if some intermediate
routers are required to perform egress filtering on source locators?

Note that an alternative proposal is to let routers have complex
packet tracing functionality.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 May 2003 11:01:53 +0200

On woensdag, mei 14, 2003, at 08:30 Europe/Amsterdam, Masataka Ohta 

>    address compatible with an outgoing ISP.

Does it really matter who does it? This should be something we leave up 
to the implementers, if at all possible. However, if you want to get 
this deployed while the century is still young you'll have to make the 
hosts do it if the routers can't.

>    For that purpose, intra

No way. First of all having a routing table in each host is a huge 
waste of resources. Second, why use fifth hand information if a host 
can simply send some packets and see if they make it through? That's 
much more effective and light-weight at the expense of some only a few 
otherwise unnecessary end-to-end packets. Routing protocols seldom know 
which paths are good. They barely know how to avoid the very bad and 
non-functioning ones.

> be performed only on hosts.

I agree in principle. However, if we can give people the option to 
offload this to a middlebox if they so desire, that's a plus. (Which is 
a very different thing from requiring middleboxes or requiring routers 
or other non-middlebox boxes in the middle to do it.)

> Hosts needs help from routing protocols.

That's the same logic as suing a lawyer. At the surface it seems to 
make sense but you really don't want to do it if you can avoid it.

> source address selection.

The trouble with current transport protocols is that once you've 
selected your source address you can't change it. So we change it and 
then listen for ICMP messages to see when we have the wrong source 
address.

Or you can turn the whole thing around and decide if the host is going 
to use a source address that belongs to ISP A, well, then we have to 
send this packet out over ISP A. That way we don't even need routing 
tables in routers.  :-)

> No. See above.

Note that I was taking no position about where the rewriting happens: 
this may very well be done inside the source host.

> No. PMTUD is one, among many, of a useless feature of IPv6.

Why is it useless?

> Just send packets not loger than 1280B.

That's unacceptable.

In fact, we need to go even further and implement functionality in 
neighbor discovery to enable the use of jumboframes between two hosts 
that support them even though other hosts on the same subnet may not.

> Ingress? Do you mean egress?

No. I can't trust my neighbors to send me only good packets, so I have 
to make sure this is the case myself.

> source address, because the ICMP packet has valid source and

That's why we must filter the original packet with the forged source 
address. Then there is no trouble with ICMP messages generated for it.

> packet tracing functionality.

I assume you mean tracing forged sources? This done for only very few 
packets so it doesn't get in the way of regular operation.

---

From: "Michael H. Lambert" <[email-masked]>
Date: Wed, 14 May 2003 08:52:11 -0400

--On Wednesday, 14 May 2003 11:01 +0200 Iljitsch van Beijnum 
<[email-masked]> wrote:

> On woensdag, mei 14, 2003, at 08:30 Europe/Amsterdam, Masataka Ohta wrote:

[...]

>
> No way. First of all having a routing table in each host is a huge waste
> of resources. Second, why use fifth hand information if a host can simply
> send some packets and see if they make it through? That's much more
> effective and light-weight at the expense of some only a few otherwise
> unnecessary end-to-end packets. Routing protocols seldom know which paths
> are good. They barely know how to avoid the very bad and non-functioning
> ones.

Just because the path is valid (and perhaps "good" by a reasonable set of 
metrics) does not mean that it is even near-optimal.  A host sending a few 
packets to check a path will have no idea of the bandwidth along the path, 
for example.

> offload this to a middlebox if they so desire, that's a plus. (Which is a
> very different thing from requiring middleboxes or requiring routers or
> other non-middlebox boxes in the middle to do it.)

I think the right approach is to allow the functionality to be implemented 
hierarchically.

> That's the same logic as suing a lawyer. At the surface it seems to make
> sense but you really don't want to do it if you can avoid it.
>
> The trouble with current transport protocols is that once you've selected
> your source address you can't change it. So we change it and then listen
> for ICMP messages to see when we have the wrong source address.

I think the right way to think about this is that whatever device is 
responsible for making decisions about dynamic source address selection can 
usually benefit from hints from the routing protocols.

[...]

> that support them even though other hosts on the same subnet may not.

Exactly, although probably not important for small flows (< 100 Mb/s).

Ohta-san:  Please consider the loss requirements for a trans-Pacific 10 
Gb/s flow using the default Ethernet MTU.

Michael

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 May 2003 09:11:46 +0200

On woensdag, mei 14, 2003, at 14:52 Europe/Amsterdam, Michael H. 
Lambert wrote:

>> Second, why use fifth hand information if a host can simply

> Just because the path is valid (and perhaps "good" by a reasonable set 
> of metrics) does not mean that it is even near-optimal.  A host 
> sending a few packets to check a path will have no idea of the 
> bandwidth along the path, for example.

Note that in the commodity internet the bandwidth of a path is a 
non-issue: ISP connections are almost always of a much higher bandwidth 
than the part between the ISP edge and the end-host.

I agree that a few packets isn't enough to determine the bandwidth of a 
path but with a higher number of packets this shouldn't be much of a 
problem. But in these cases a partial routing table in the host would 
be ok, I guess.

Another approach is to use diffserv to signal packets should take the 
high-bandwidth path.

>> offload this to a middlebox if they so desire, that's a plus.

> I think the right approach is to allow the functionality to be 
> implemented hierarchically.

What does that mean?

> responsible for making decisions about dynamic source address 
> selection can usually benefit from hints from the routing protocols.

I'm not saying there are no benefits, just that the downsides are much 
bigger and that it would be unacceptable to mandate having a routing 
table in each host.

> Exactly, although probably not important for small flows (< 100 Mb/s).

I don't think setting the MTU based on the flow speed is useful: either 
you can do it so you do it or you can't so you don't. But I agree there 
isn't much point in having jumboframes in 10 or 100 Mbps equipment and 
it seems vendors feel the same way because I have yet to encounter a < 
1000 Mbps ethernet NIC that supports them.

---

From: "Michael H. Lambert" <[email-masked]>
Date: Thu, 15 May 2003 09:20:14 -0400

> problem. But in these cases a partial routing table in the host would be
> ok, I guess.
>

This doesn't scale well, but now I'm not sure how important that is.  As 
long as a "good" path can be determined with no manual host configuration, 
then we're probably okay requiring more work for an optimal path.

>> implemented hierarchically.

All I mean is that if we have an architecture which allows the use of 
middle boxes, then a site (perhaps defined broadly enough to include a 
local/metropolitan/regional aggregation point) could have a set of such 
middle boxes.  Those closer to the end host could ask those closer to the 
CE for path selection help.

> bigger and that it would be unacceptable to mandate having a routing

I agree, but it's equally unacceptable to prohibit it.  The cases where it 
matters are few, but generally important to funding agencies.

> isn't much point in having jumboframes in 10 or 100 Mbps equipment and it
> seems vendors feel the same way because I have yet to encounter a < 1000
> Mbps ethernet NIC that supports them.

The upshot is that discussion of MTU is off-topic for this WG, except as a 
metric for path selection.

Michael