Re: comments on requirements-05

[Joe Abley <jabley@isc.org>]

On Wednesday, May 7, 2003, at 04:12 Canada/Eastern, Pekka Savola wrote:

> On Tue, 6 May 2003, Joe Abley wrote:
>
> > > ==> should be reworded to remove references to "transit provider is a
> > > site" -concept, which is irrelevant and confusing in this context.
> > Please explain.
> Typically "site" is considered to be an "end-site", in the transit
> provider's case, the NOC of the transit provider.  The backbone of the
> transit provider, possibly spanning contininents, seems to stretch the
> definition and the mental picture of a "site" pretty far.
I think in practice "typically" is in the eye of the beholder, which is 
why I was careful to define what I meant by site.

> Also, the text may be rather ambiguous as it doesn't seem to match the
> common understanding of what "transit provider" typically is.
Again, this came up when the draft was originally published with 
definitions. There is no common understanding of what "transit 
provider" is; different people add different nuances to their 
understanding of the phrase, which is why the definitions are there.

I think the current set of definitions are sufficient to cover the 
concepts used in the draft, and I think they're about as commonly 
accepted amongst operators as we're likely to find.

> > > 2) simplicity for the internet and/or the site should be made 
> > > explicit.
> > >
> > > 3.1.5 Simplicity
> > >
> > >    As any proposed multihoming solution must be deployed in real
> > >    networks with real customers, simplicity is paramount. The current
> > >    multihoming solution is quite straightforward to deploy and
> > > maintain.
> > >    A new IPv6 multihoming proposal should not be substantially more
> > >    complex to deploy and operate than current IPv4 multihoming
> > >    practices.
> > >
> > > ==> there are two aspects to the simplicity, with two different axes:
> > > - simplicity to those who deploy it, and to those that don't
> > > - simplicity to the Big Internet as a whole and the end-site itself
> > I don't see those as orthogonal; your second line looks to me like a
> > rewording of the first line (taking the Big Internet to be a 
> > collection
> > of people who do and don't deploy multihoming). Perhaps you could
> > explain that further.
> There is a slight difference there, in my eyes.
>
> The first item separates "multihomed site and its ISP(s) and possibly
> their transits" and "everyone else".
>
> The second item separates "multihoming end-site" and "everyone else
> (including their ISPs)".
All of "its ISPs" and "their transits" and a good chunk of "everybody 
else" are potentially multi-homed sites; multi-homing doesn't only 
happen at "end-sites" (assuming I'm understanding your terminology 
correctly).

The topology is a richly connected graph. Your use of "site" and 
"transit" seem to imply a more rigid hiererarchy which is not the case, 
in general.

> > > 3.1.8 Packet Filtering
> > >
> > >    Multihoming solutions should not preclude filtering packets with
> > >    forged or otherwise inappropriate source IP addresses at the
> > >    administrative boundary of the multihomed site.
> > >
> > > ==> replace from the end (remove the period):
> > >
> > >                                                  , or administrative
> > >    boundaries between any transit providers in the Internet.
> > >
> > >    (this is done to facilitate for the fact that the Internet is 
> > > *not*
> > > just
> > >     a homogenous single routing blob -- "once you're in, you're in 
> > > for
> > > good").
> > I'm not sure that additional sentiment is required, but I wouldn't
> > object to it going in.
> I feel it's important, but I'm willing to hear what others think.
>
> > > 3.2.6 Cooperation between Transit Providers
> > >
> > >    A multihoming strategy may require cooperation between a site and
> > > its
> > >    transit providers, but should not require cooperation (relating
> > >    specifically to the multihomed site) directly between the transit
> > >    providers.
[...]

> Let's try to illustrate:
>
>       Site S
>     /      \
> ISP A  --  ISP B
>  |          |
> Transit1 - Transit2  -- [ Internet ]
>  |           \
> [Internet]   [Internet]
>
> Co-operation is currently a goal with Site S <-> ISP A and Site S <-> 
> ISP
> B.  It is not with ISP A <-> ISP B.
>
> This doesn't take a stance on even more non-goal co-operation, with 
> e.g.
> - Site S <-> Transit1
> - ISP A <-> Transit1
Ah, ok, I see what you mean.

I'm not sure it's reasonable to take a stance on that. If site S wants 
to come to an arrangement with Transit1 to handle its traffic or 
routing in a certain way, why shouldn't it? With v4 CIDR abuse, for 
example, why shouldn't I be able to call up Sprint and say "hey, let me 
pay you money to relax your assignment-boundary filters in my 
particular case, so you'll accept my long-prefix route"?

This in general does not sound like a recipe for simple, pervasive 
multi-homing but I'm not sure why the goals document should state it as 
a non-goal.

> > > semi-editorial/substantial
> > > --------------------------
> > > For purposes of
> > >    redundancy and load-sharing, the multihomed address blocks, which
> > > are
> > >    almost always a longer prefix than the provider aggregate, are
> > >    announced along with the larger, covering aggregate originated by
> > > the
> > >    provider.
> > >
> > > ==> s/redundancy/redundancy, independence/
> > No, I don't think there's any "independence" rationale there; these 
> > are
> > covered prefixes describing PA assignments, not announcements of PI
> > space.
> There certainly is, if you can, and in practice do, take the portion of
> the PA with you, to another provider.  The text in the introduction 
> does
> not require the site to advertise the more specific from the behind the
> direct ISP: as long as a covering aggregate (from somewhere else) 
> exists,
> you're fine.
I mean, there's no independence in the sense that you are still 
dependent on the provider who allocated you the numbers. You can't stop 
paying that guy and continue to announce your long-prefix route to 
other transit providers.

"Independence", when mentioned in the context of v4 multihoming, is 
invariably to do with PI addressing I have noticed. Hence I think 
introducing that word here would add confusion rather than clarity.

> But why do you then say:
>
>  the multihomed address blocks, which are
>    almost always a longer prefix than the provider aggregate,
>
> ==> there is no "coverage" if it is not a longer prefix.
ok, how about "which are almost always covered by a provider 
aggregate,".

> In any case, the introduction is incomplete.  Multihoming is also done
> with PI addresses, without covering aggregates.
OK. That's a fair point.

> The introduction should be either modified to be a bit more descriptive
> (or generic), or make a reference to the v4 multihoming draft (which 
> would
> require us to start working on it again) -- which should be there 
> anyway,
> at least as an informational ref.
>
> > >  This contributes to the rapidly-increasing size of the
> > >    global routing table.
> > >
> > > ==> s/size/size and dynamicity/ (better word than dynamicity?!?!)
> > complexity?
> Complexity is too generic a term unfortunately, it doesn't imply 
> anything
> about the advertise/withdraw cycles caused by site multihoming.
turbulence?

> > > ==> "backhoe-fade" ?  No idea what that means, and couldn't find it
> > > in a dictionary either.
> > http://www.net.oregonstate.edu/netvideo/dugout.html
> A bit too technical term, when a simpler, generally understandable way 
> to
> say something to the same effect might be possible.
Yep, fair enough.


Joe