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

From: "Tony Li" <[email-masked]>
Date: Sat, 3 May 2003 19:55:18 -0700

Noel,

The architecture that you describe is no longer the Internet
architecture.  Yes, ok, it's sorta vaguely like it, but it is
NOT the architecture that folks have in mind when they say that
they want to preserve host path selection.  Or have 'smart'
hosts.

Putting a source route in the header (or deeper) in the packet
has been tried and firmly rejected.  People want the ability
to select paths, but are unwilling to pay for it.

Tony

|    -----Original Message-----
|    From: J. Noel Chiappa [mailto:[email-masked]] 
|    Sent: Saturday, May 03, 2003 6:53 PM
|    To: [email-masked]
|    Cc: [email-masked]
|    Subject: RE: IETF multihoming powder: just add IPv6 and stir
|    
|    
|        > From: "Tony Li" <[email-masked]>
|    
|        > If you follow this argument a bit further, the 
|    number of possible paths
|        > internal to the core explodes.
|        > ...
|        > Frankly, there's no way to reasonably support a host 
|    path selection
|        > feature in the Internet architecture.
|    
|    Sorry, but this assertion is not correct.
|    
|    It's true that one cannot support separate state for each 
|    individual flow in
|    the core of the network. Hoever, this does not mean that 
|    one cannot support
|    host path selection, both setup and non-setup (i.e. 
|    completely done by the
|    header of each individual packet).
|    
|    The problems involved in some of the simplistic approaches 
|    to doing host path
|    selection were brought to my attention many years ago; the 
|    first being the one
|    that you actually (if my memory serves at this great 
|    distance) introduced me
|    to, the necessity to scale router state, as explained in this note:
|    
|        http://users.exis.net/~jnc/tech/state_growth.html
|    
|    There's another related problem with flow setup even with 
|    aggregated flows,
|    which Vadim Antonov first explained to me, which is more 
|    of an O(N) problem at
|    the edges, related to the growth of the overall network.
|    
|    
|    In any event, after much thought, I've come up with a 
|    number of mechanisms
|    that allow you to provide host path selection in a feasible manner.
|    
|    One can do a certain amount with address selection - 
|    there'a grad student at
|    MIT called Xiaowei Yang who's doing a PhD on that. I don't 
|    happen to like
|    that approach, I'm not really sure sure why - probably 
|    because it feels like
|    a kludge.
|    
|    However, with a certain amount of cleverness, and also 
|    trading off per-packet
|    header overhead to reduce per-flow state in the switches, 
|    one can do an
|    amazing amount.
|    
|    I don't want to bore everyone with a long explanation, and 
|    sorry, no it's not
|    written down, but very briefly, it all depends on having 
|    virtual links in the
|    topology map which correspond to instantiated aggregated flows (and
|    recursively so). You can either do an end-end flow setup 
|    which uses those
|    virtual links (and the flow stack in the packet header), 
|    or you can play all
|    sorts of interesting tricks with the flow stack to cause 
|    packets to take paths
|    composed of those virtual links, or you can do a mixture 
|    of the two.
|    
|    I not sure if I have that problem Vadim identified with 
|    the full-blown
|    flow-setup case completely licked, but I have some ideas 
|    which I think will
|    do it.
|    
|    
|        > There is no way to completely specify the path of a 
|    packet without a
|        > connection oriented setup protocol.
|    
|    Source route in the header?
|    
|    	Noel
|    
|

---

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

> From: "Tony Li" <[email-masked]>

    >>> Frankly, there's no way to reasonably support a host path selection
    >>> feature in the Internet architecture. 

    > architecture.

Doing much of anything interesting within the current architecture, exactly
as it stands, in many cases isn't really possible. (E.g. the many people
who'd like to separate location and identity to make multi-homing easier.)

Hence I didn't realize that when you said "in the Internet architecture" you
really meant "in the Internet architecture as it currently stands", since
that latter case is a relatively sterile and pointless one.

    > People want the ability to select paths, but are unwilling to pay for
    > it.
                                                    
I have been aware for some decades now that people want filet mignon from the
network, and expect to get it for the price they've previously been paying
for hamburger. That has been painfully demonstrated in the routing area -
which is a good part of why I never bothered to write down how to do all this.

They seem to have forgotten the common principle of TANSTAAFL - one which
they are only now slowly accepting in the area of multi-homing (and even in
that sphere there are still lots of people who don't get it).

	Noel

---

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

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

    >> it all depends on having virtual links in the topology map which
    >> correspond to instantiated aggregated flows (and recursively so). You
    >> can either do an end-end flow setup which uses those virtual links
    >> .. or you can play all sorts of interesting tricks with the flow stack
    >> to cause packets to take paths composed of those virtual links, or you
    >> can do a mixture of the two.

    > isn't what you are describing MPLS?

Well, they both forward packets based on a flow label, and there's a stack of
flow labels, but that's about the only similarity. In other words, it's like
saying that because a SPARC and a Pentium are both stored-program machines
they are the same thing.

MPLS is a lot more than the hardware (which I kind of like); it's also a
whole bunch of sofware and protocols (all of which I think is bletcherous
junk, and horrible "bag on the side of the architecture").

If you examine just my text above, you will find a number of major
differences: e.g. the use of a map-based routing system in which some
previously-set-up flows are actually shown (as virtual links); the fact that
packets can be created with a whole bunch of labels in the flow stack, and
that this feature is available to users, etc, etc.

But this is all kind of irrelevant to Multi6; as Tony correctly points out,
I'm talking about an alternate reality in which the complete piece of
nonfunctional junk masquerading as our routing architecture has been put out
of our misery.

	Noel

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Sun, 11 May 2003 12:37:58 -0400

> From: Iljitsch van Beijnum <[email-masked]>

    > At the same time we have to be careful that we don't go through this
    > list and pick the option we like best for each item.

Do note that my list is not a complete list of all possible design
questions; it's simply the list that I thought of (in increasing order of
specificity) on the way to the solution called "GSE".

It would be interesting to try the same exercise on some others sketch
designs and see if there are some other ones that aren't in that list.

	Noel

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 13 May 2003 06:20:20 -0400

I don't agree.  But do what you want.
/jim

> -----Original Message-----
> From: Kurt Erik Lindqvist [mailto:[email-masked]] 
> Sent: Tuesday, May 13, 2003 4:38 AM
> To: Bound, Jim
> Cc: Iljitsch van Beijnum; J. Noel Chiappa; [email-masked]
> Subject: Re: IETF multihoming powder: just add IPv6 and stir
> 
> 
> 
> 
> But Noels list for me is more criteria for a specific 
> solution (loc/id 
> separation) rather than a general list?
> 
> - kurtis -
> 
> On söndag, maj 11, 2003, at 11:24 Europe/Stockholm, Bound, Jim wrote:
> 
> > I agree but Noel's list is a good list for the community to 
> see.  We 
> > cannot not put good stuff out because people will do bad 
> things with 
> > it and also that is far to political of a viewpoint to ever achieve 
> > progress for our efforts here.
> >
> > /jim
> >
> >
> >
> >> -----Original Message-----
> >> From: Iljitsch van Beijnum [mailto:[email-masked]]
> >> Sent: Sunday, May 11, 2003 5:21 AM
> >> To: Bound, Jim
> >> Cc: J. Noel Chiappa; [email-masked]
> >> Subject: Re: IETF multihoming powder: just add IPv6 and stir
> >>
> >>
> >> On zondag, mei 11, 2003, at 11:02 Europe/Amsterdam, Bound, 
> Jim wrote:
> >>
> >>> we need to capture what Noel listed here for sure.
> >>
> >> list and pick the option we like best for each item. It's pretty 
> >> clear that any solution will include some parts that aren't great. 
> >> The only way to judge the "not great" part is by evaluating the 
> >> solution as a whole and compare it to other fleshed out solutions.
> >>
> >>
> >
> 
>

---

From: "Tony Li" <[email-masked]>
Date: Wed, 14 May 2003 15:58:42 -0700

IMHO, firewall type filtering should be on "who" you are, not 
on "where" you are.

The only filtering on location that makes sense to me is to simply
ensure that the source locator is not spoofed.

Tony

|    > A filter that is looking at a locator is probably a bug.
|    
|    The need to filter is an operational reality.
|    
|    So how do we filter on an identifier? Put them into the 
|    routing tables 
|    and then uRPF? And if the identifiers are in the routing 
|    tables, who 
|    needs a locator?
|    
|    To me, identifiers belong at layer 4 and up. Locators 
|    belong at layer 
|    3. So any filtering on layer 3 must be on locators.
|    
|