Re: Notes From Monday Nights Meeting

[David Meyer]

        [cc'ing architecture-discuss@... in an attempt to
        get that going...]
On Tue, Oct 24, 2006 at 02:46:14PM -0400, Dorian Kim wrote:
> On Tue, Oct 24, 2006 at 07:32:21AM -0700, David Meyer wrote:
> > > > There was also talk on WG being chartered to attack the problem right
> > > > away, etc... but it is still too early for that IMO.
> >
> > Totally too early. I'm not even sure a WG is the right
> > thing (other options include design teams, etc).
>
> It seems to me that process queestion of IETF are orthogonal to what
> we should be doing.

        Agreed.

> We should proceed IMO with working on a solution disregarding the
> standards track issues for now. From that perspective, forming a
> design team, and/or exploring the boundaries of the solution space
> amongst the interested parties here seems like the next step.

        Makes sense.

        --dmm


_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Jari Arkko-2]

Dave,
> [cc'ing architecture-discuss@... in an attempt to
> get that going...]
>  
People on this list probably need more context
to figure out what problem you are trying
to solve.

--Jari


_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[David Meyer]

On Wed, Oct 25, 2006 at 12:57:05AM +0300, Jari Arkko wrote:
> Dave,
> > [cc'ing architecture-discuss@... in an attempt to
> > get that going...]
> >  
> People on this list probably need more context
> to figure out what problem you are trying
> to solve.

        Yeah, my mistake (and I've had a few private emails to
        that effect).

        So just to try to clear that up: I'm hoping we can use
        this list for discussion of ideas that came out of the
        IAB workshop on routing and addressing last week, in the
        hope that we will be reaching a wider and more inclusive
        audience.

` --dmm
 



_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Xiaodong Lee]

Dear Dvaid,

Can you show more about the ideas from the workshop?
I am very interested on such kind of things, especially on routing
issues.

Regards!

--
-- Xiaodong LEE [The best answer is doing]
   [phone]
   mailto:lee@...
   http://www.lixiaodong.cn



David Meyer wrote:

> On Wed, Oct 25, 2006 at 12:57:05AM +0300, Jari Arkko wrote:
>  
>> Dave,
>>    
>>> [cc'ing architecture-discuss@... in an attempt to
>>> get that going...]
>>>  
>>>      
>> People on this list probably need more context
>> to figure out what problem you are trying
>> to solve.
>>    
>
> Yeah, my mistake (and I've had a few private emails to
> that effect).
>
> So just to try to clear that up: I'm hoping we can use
> this list for discussion of ideas that came out of the
> IAB workshop on routing and addressing last week, in the
> hope that we will be reaching a wider and more inclusive
> audience.
>
> ` --dmm
>  
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@...
> https://www1.ietf.org/mailman/listinfo/architecture-discuss
>  

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Fergie-2]

Lee,

I think most of the issues in question came out during the
v6ops meeting today here in San Diego. It was a composite of
issues which have emerged in various operational forums (namely,
NANOG) and also (from what I understand), the IAB architecture
meeting a couple of weeks ago in Amsterdam

Instead of me going into any detail on the data points which
were presented this morning (and which should eventually end
up being posted somewhere?), I'll just say that perhaps the most
controversial (?) issue(s) that came up was w.r.t. how v6 actually
complicates operational aspects of the global routing system -- or
in other words: it doesn't help, it actually contributes to the
existing problem.

If someone else could provide a pointer to the slides/presentation
from this morning's meeting...

- ferg



-- Xiaodong Lee <lee@...> wrote:

Dear Dvaid,

Can you show more about the ideas from the workshop?
I am very interested on such kind of things, especially on routing
issues.

Regards!

--
-- Xiaodong LEE [The best answer is doing]
   [phone]
   mailto:lee@...
   http://www.lixiaodong.cn



David Meyer wrote:

> On Wed, Oct 25, 2006 at 12:57:05AM +0300, Jari Arkko wrote:
>  
>> Dave,
>>    
>>> [cc'ing architecture-discuss@... in an attempt to
>>> get that going...]
>>>  
>>>      
>> People on this list probably need more context
>> to figure out what problem you are trying
>> to solve.
>>    
>
> Yeah, my mistake (and I've had a few private emails to
> that effect).
>
> So just to try to clear that up: I'm hoping we can use
> this list for discussion of ideas that came out of the
> IAB workshop on routing and addressing last week, in the
> hope that we will be reaching a wider and more inclusive
> audience.
>
> ` --dmm
>  
>

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/


_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Noel Chiappa]

    > From: "Fergie" <fergdawg@...>

    > perhaps the most controversial (?) issue(s) that came up was w.r.t. how
    > v6 actually complicates operational aspects of the global routing
    > system ... it actually contributes to the existing problem.

Just briefly, since this is the point that's relevant here (not the rest of
the v6Ops stuff), what are the things about v6 that make the routing problem
worse? The nitwitted Provider-Independent addresses, of course, but that's
obvious. Other than that, I thought v6 was pretty similar to v4 (from the
point of view of the routing), so I'm curious as to what else makes it
worse.

        Noel

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[David Meyer]

        All,

        We have a draft workshop report almost done, and we'll
        post it here when its in reasonable shape.

        --dmm

On Tue, Nov 07, 2006 at 06:58:21AM +0000, Fergie wrote:

> Lee,
>
> I think most of the issues in question came out during the
> v6ops meeting today here in San Diego. It was a composite of
> issues which have emerged in various operational forums (namely,
> NANOG) and also (from what I understand), the IAB architecture
> meeting a couple of weeks ago in Amsterdam
>
> Instead of me going into any detail on the data points which
> were presented this morning (and which should eventually end
> up being posted somewhere?), I'll just say that perhaps the most
> controversial (?) issue(s) that came up was w.r.t. how v6 actually
> complicates operational aspects of the global routing system -- or
> in other words: it doesn't help, it actually contributes to the
> existing problem.
>
> If someone else could provide a pointer to the slides/presentation
> from this morning's meeting...
>
> - ferg
>
>
>
> -- Xiaodong Lee <lee@...> wrote:
>
> Dear Dvaid,
>
> Can you show more about the ideas from the workshop?
> I am very interested on such kind of things, especially on routing
> issues.
>
> Regards!
>
> --
> -- Xiaodong LEE [The best answer is doing]
>    [phone]
>    mailto:lee@...
>    http://www.lixiaodong.cn
>
>
>
> David Meyer wrote:
> > On Wed, Oct 25, 2006 at 12:57:05AM +0300, Jari Arkko wrote:
> >  
> >> Dave,
> >>    
> >>> [cc'ing architecture-discuss@... in an attempt to
> >>> get that going...]
> >>>  
> >>>      
> >> People on this list probably need more context
> >> to figure out what problem you are trying
> >> to solve.
> >>    
> >
> > Yeah, my mistake (and I've had a few private emails to
> > that effect).
> >
> > So just to try to clear that up: I'm hoping we can use
> > this list for discussion of ideas that came out of the
> > IAB workshop on routing and addressing last week, in the
> > hope that we will be reaching a wider and more inclusive
> > audience.
> >
> > ` --dmm
> >  
> >
>
>
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  fergdawg(at)netzero.net
>  ferg's tech blog: http://fergdawg.blogspot.com/
>

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Fergie-2]

That's pretty much it in a nutshell.

- ferg



-- jnc@... (Noel Chiappa) wrote:
 
    > perhaps the most controversial (?) issue(s) that came up was
w.r.t. how
    > v6 actually complicates operational aspects of the global routing
    > system ... it actually contributes to the existing problem.

Just briefly, since this is the point that's relevant here (not the rest of
the v6Ops stuff), what are the things about v6 that make the routing
problem
worse? The nitwitted Provider-Independent addresses, of course, but that's
obvious. Other than that, I thought v6 was pretty similar to v4 (from the
point of view of the routing), so I'm curious as to what else makes it
worse.

        Noel


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/


_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Fred Baker]

On Nov 7, 2006, at 5:52 AM, Noel Chiappa wrote:
> Just briefly, since this is the point that's relevant here (not the  
> rest of the v6Ops stuff), what are the things about v6 that make  
> the routing problem worse?

the PI address is just as PI as the IPv4 PI address. No change. There  
is a ringer in PA space - there are some issues that can arise if one  
gets a PA prefix from one provider and advertises it to another. That  
provider or its upstream may not accept the prefix in routing, and  
the original ISP is forced to advertise it into the backbone in order  
to not have a working alternate path get all the traffic. PA in that  
sense becomes PI.

The big thing that makes routing screwey is ingress filtering - BCP  
38. If the prefix in use is supposed to be the one delegated by the  
ISP, then the enterprise is nominally on the hook to ensure that the  
source address that crosses its DMZ is for the right ISP. But the  
host has no idea which DMZ the routing system will use or what  
prefixes are sited there. So it essentially selects a source address  
at random and the routing system is nominally on the hook to tunnel  
the packet to the right DMZ. The other side of that is the fact that  
a multihomed destination also has multiple addresses and there isn't  
necessarily real good guidance on which to use. The cross product of  
the two sets of addresses is essentially a random selector among M*N  
routes (which DMZ will it go out of my network, through which pair-or-
more of ISPs, and which DMZ will provide the ingress to the peer  
network?), which may have very different characteristics.

There is a mechanism to configure policy of this kind, in RFC 3484.  
The discussion in v6ops yesterday was to the effect that we wanted to  
look at this, though, as it may not be a adequate solution. SCTP and  
shim6 also have ways to mitigate the M*N routes, through some  
combination of cached history and probing during the session.

There is renewed discussion of GSE and an ID/Locator split. GSE  
solves the above issue, at least for the source address, by allowing  
the egress DMZ to write its prefix into the IPv6 header, eliminating  
the question of tunneling to a randomly selected DMZ. There is some  
possibility that a bad choice of destination address on the SYN-or-
equivalent can be fixed by GSE on the SYN-ACK path - if the routing  
in the remote system picks a different DMZ, it will pick a different  
prefix according to it. So GSE actively helps, although it doesn't  
fully optimize the solution and Mike's initial ID is best described  
as an initial ID.

The discussion of GSE is couched in language related to the ID/
Locator split. As you discussed in 1993 and earlier, this would be a  
good thing for various architectural reasons. I can't say that it  
automatically improves routing, or the scaling of addressing though.  
To my small mind, it enables the address overwrite done in GSE to be  
done safely, and it is the address overwrite that actually helps.

There is a wrinkle with the address overwrite, but it is solvable. It  
makes AH not work as specified - one has to restrict the "immutable  
or predictable" fields to the locator as opposed to the address. It  
also has some issues with IKEv2 in setting up ESP sessions (although  
ESP is not itself affected). Steve Bellovin tells me that both are  
fixable and has offered to help.

I will have the presentations that were given posted in the v6ops  
IETF67 proceedings site later today. I'll post the URL at the time.

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Tim Chown]

On Tue, Nov 07, 2006 at 06:58:21AM +0000, Fergie wrote:

>
> Instead of me going into any detail on the data points which
> were presented this morning (and which should eventually end
> up being posted somewhere?), I'll just say that perhaps the most
> controversial (?) issue(s) that came up was w.r.t. how v6 actually
> complicates operational aspects of the global routing system -- or
> in other words: it doesn't help, it actually contributes to the
> existing problem.
>
> If someone else could provide a pointer to the slides/presentation
> from this morning's meeting...

For those asking for Vince's slides, they are here:
http://www.vaf.net/~vaf/iepg.pdf

These were presented in v6ops and IEPG.

I think one of the aspects of 'contribbuting to the problem' was simply that
if v6 is turned on where v4 already exists today the routing tables would
grow bigger than many FIBs can handle.   The numbers are in the slides,
from around slide 16 onwards.   But there are also comments on difference
on IPv6 TE etc.

--
Tim

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Fred Baker]

On Nov 7, 2006, at 6:58 AM, Fergie wrote:

> If someone else could provide a pointer to the slides/presentation
> from this morning's meeting...

OK, our proceedings are all uploaded, but not the minutes, which I  
haven't received yet from the guy who was taking them. It turns out  
that there is some delay in making them visible; I guess that might  
be tomorrow. The minutes of this part of the meeting are "Dave Meyer,  
Vince Fuller, and Marla Azinger talked. They all think we have a  
scaling problem with every approach that is on the table. They also  
think maybe it should be fixed."

Some files are PDF, and at this point some are powerpoint. The  
proceedings people will turn them all into PDF later on.

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Fred Baker]

On Nov 7, 2006, at 8:07 AM, Fred Baker wrote:

> There is a wrinkle with the address overwrite, but it is solvable.  
> It makes AH not work as specified - one has to restrict the  
> "immutable or predictable" fields to the locator as opposed to the  
> address. It also has some issues with IKEv2 in setting up ESP  
> sessions (although ESP is not itself affected). Steve Bellovin  
> tells me that both are fixable and has offered to help.

for completeness, I should note that there is another ringer in the  
address overwrite. SCTP has the ability for one end to announce  
alternative addresses to its peer, and in shim6 a similar capability  
is added to TCP and UDP. The mutability of addresses makes  
recognizing packets in the session depend on this. GSE, in proposing  
a locator, allows the endpoint transport to look only at the locator.  
That means, however, changing every transport implementation running  
atop IPv6.

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Schliesser, Benson]

> Just briefly, since this is the point that's relevant here (not the
rest
> of the v6Ops stuff), what are the things about v6 that make the
routing
> problem worse? The nitwitted Provider-Independent addresses, of
course,
> but that's obvious. Other than that, I thought v6 was pretty similar
to v4
> (from the point of view of the routing), so I'm curious as to what
else
> makes it worse.

I'm also curious about what makes it worse. I wasn't able to attend
v6ops yesterday, but from past discussions I've gathered that the
scaling complaints against v6 can be summarized as "it scales like v4,
but with a higher limit on table size". Would somebody making this
argument view v4 address-exhaustion as a feature?

It seems to me that, leaving traffic-engineering aside, v6 can scale
better than v4 with proper allocation rules. That is, if each AS gets a
single prefix large enough to satisfy all of their current and future
needs (pretend that we can perfectly predict future needs for a moment)
then table size should be much smaller than today.

What am I missing?

Cheers,
-Benson




_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Chris Morrow]

On Tue, 7 Nov 2006, Fred Baker wrote:
> this. GSE, in proposing a locator, allows the endpoint transport to look only
> at the locator. That means, however, changing every transport implementation
> running atop IPv6.

which, with ipv6 'infancy' might still be a decent idea... doing it
'right' this time could lead to a better long term solution?

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Chris Morrow]

On Tue, 7 Nov 2006, Schliesser, Benson wrote:

> It seems to me that, leaving traffic-engineering aside, v6 can scale
> better than v4 with proper allocation rules. That is, if each AS gets a

I can't really scale 'better' if you want multihoming... If you think of
multihoming as you would today in the current v4 world. It scales about
the same in that case, which with a higher top end means more trouble :(

> single prefix large enough to satisfy all of their current and future
> needs (pretend that we can perfectly predict future needs for a moment)
> then table size should be much smaller than today.
>

table size will grow... I'm not sure you can say it'll be smaller than
today, since tomorrow there are likely many, many more things being
connected to the Internet.

Also, keep in mind that the 'global table' isn't all that is the problem
here, there are internal routes for ISP/NSP folks to carry, and overlay
routes for 'services'...

> What am I missing?


_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[John Day-2]

At 18:27 +0000 2006/11/07, Chris Morrow wrote:

>On Tue, 7 Nov 2006, Schliesser, Benson wrote:
>
>>It seems to me that, leaving traffic-engineering aside, v6 can scale
>>better than v4 with proper allocation rules. That is, if each AS gets a
>
>I can't really scale 'better' if you want multihoming... If you
>think of multihoming as you would today in the current v4 world. It
>scales about the same in that case, which with a higher top end
>means more trouble :(
>
>>single prefix large enough to satisfy all of their current and future
>>needs (pretend that we can perfectly predict future needs for a moment)
>>then table size should be much smaller than today.
>>
>
>table size will grow... I'm not sure you can say it'll be smaller
>than today, since tomorrow there are likely many, many more things
>being connected to the Internet.
>
>Also, keep in mind that the 'global table' isn't all that is the
>problem here, there are internal routes for ISP/NSP folks to carry,
>and overlay routes for 'services'...
>
>>What am I missing?
>
>

A complete architecture.  ;-)  Sorry I couldn't resist.

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Fred Baker]

I would agree, and agreed ten years ago. But if we're going to do it  
now, there is no time to waste.

On Nov 7, 2006, at 10:20 AM, Chris Morrow wrote:

>
> On Tue, 7 Nov 2006, Fred Baker wrote:
>> this. GSE, in proposing a locator, allows the endpoint transport  
>> to look only at the locator. That means, however, changing every  
>> transport implementation running atop IPv6.
>
> which, with ipv6 'infancy' might still be a decent idea... doing it  
> 'right' this time could lead to a better long term solution?

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[David Meyer]

On Tue, Nov 07, 2006 at 08:52:03AM -0500, Noel Chiappa wrote:

>     > From: "Fergie" <fergdawg@...>
>
>     > perhaps the most controversial (?) issue(s) that came up was w.r.t. how
>     > v6 actually complicates operational aspects of the global routing
>     > system ... it actually contributes to the existing problem.
>
> Just briefly, since this is the point that's relevant here (not the rest of
> the v6Ops stuff), what are the things about v6 that make the routing problem
> worse? The nitwitted Provider-Independent addresses, of course, but that's
> obvious. Other than that, I thought v6 was pretty similar to v4 (from the
> point of view of the routing), so I'm curious as to what else makes it
> worse.

        More rope (address space).

        --dmm


_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[Vince Fuller]

On Tue, Nov 07, 2006 at 05:30:57PM +0000, Tim Chown wrote:

> On Tue, Nov 07, 2006 at 06:58:21AM +0000, Fergie wrote:
> >
> > Instead of me going into any detail on the data points which
> > were presented this morning (and which should eventually end
> > up being posted somewhere?), I'll just say that perhaps the most
> > controversial (?) issue(s) that came up was w.r.t. how v6 actually
> > complicates operational aspects of the global routing system -- or
> > in other words: it doesn't help, it actually contributes to the
> > existing problem.
> >
> > If someone else could provide a pointer to the slides/presentation
> > from this morning's meeting...
>
> For those asking for Vince's slides, they are here:
> http://www.vaf.net/~vaf/iepg.pdf
>
> These were presented in v6ops and IEPG.

Those are the slides from IEPG - the "long" version.

The "short" version was presented in v6ops:

    http://www.vaf.net/~vaf/v6ops.pdf

As for what makes ipv6 scaling "worse" - the presentations talk about this
but to summarize: multihoming is implemented in the same way in ipv6 as in
IPv4; there is reason to believe that the biggest driver for routing state
growth is multihoming and that the trend is for more multihoming as time
goes by (in other words, the amount of state is not only growing but the
rate that it is growing is also increasing; the growth curve approximates
something like a polynomial or exponential).

In addition, IPv4 is going to be around for the indefinite future even if
everyone cuts over to ipv6 today. That means that projections of routing
state need to *add* ipv6 prefixes to the growing total for IPv4.

As for one prefix per AS for ipv6 (replying to another message) - the
projections in my presentation actually assume that though it that is almost
certainly an unreasonably low assumption. While, in priciple, most AS's
should be able to satisfy all of their address space needs out of a single
prefix, there quite a few reasons to expect that reality will not be so
clean (consider sites/providers that want to deploy one ipv6 prefix to
replace each IPv4 prefix for simplicity of management, those that span
multiple geographic areas that would like to assign one prefix to each,
etc, etc.)

        --Vince

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss

[jarno.rajahalme]

David Meyer [mailto:dmm@...] wrote:

>Subject: Re: [arch-d] Re: Notes From Monday Nights Meeting
>
>> Just briefly, since this is the point that's relevant here (not the
>> rest of the v6Ops stuff), what are the things about v6 that make the
>> routing problem worse? The nitwitted Provider-Independent addresses,
>> of course, but that's obvious. Other than that, I thought v6 was
>> pretty similar to v4 (from the point of view of the routing), so I'm
>> curious as to what else makes it worse.
>
> More rope (address space).
>

Or "more tunnel" :-?

        Jarno Rajahalme

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@...
https://www1.ietf.org/mailman/listinfo/architecture-discuss