Re: comments on requirements-05

[Pekka Savola <pekkas@netcore.fi>]

Sorry for a slight delay in answering.

On Wed, 7 May 2003, Joe Abley wrote:
> 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.

I suggest replacing the definitions:

   A "transit provider" operates a site which directly provides
   connectivity to the Internet to one or more external sites. The
   connectivity provided extends beyond the transit provider's own site.
   A transit provider's site is directly connected to the sites for
   which it provides transit.

   A "multihomed" site is one with more than one transit provider.
   "Site-multihoming" is the practice of arranging a site to be
   multihomed.

   The term "re-homing" denotes a transition of a site between two
   states of connectedness, due to a change in the connectivity between
   the site and its transit providers' sites.

with:

   A "direct Internet services provider" (ISP) provides a physical connection
   and Internet connectivity to the site.  The connectivity extends beyond
   the ISP's own network.

   A "multihomed" site is one with more than one ISP.
   "Site-multihoming" is the practice of arranging a site to be
   multihomed.

   The term "re-homing" denotes a transition of a site between two
   states of connectedness, due to a change in the connectivity between
   the site and its ISPs.

(of course, this would require changes where the terms are being used.)

note: I believe the term "physical connection" is generic enough to 
include a wireless connection, but I'm not a native speaker, so..

note 2: one could also use NSP, not ISP.

An alternative would be to define a "direct transit provider" and use that
instead of "transit provider", but I'm not sure whether that's any 
better.

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

But note that these do not necessarily use the same set of solutions.  

Some might choose a simpler mechanism for the network, while others want 
simplicity for the end-site.  Those transits or folks in the Internet 
which value the simplicity for the network (and are willing to "pay" for 
it by requiring different solutions for their customers) should be 
considered.

On the other hand, for business reasons, a direct upstream may be
practically forced to accept bad practices. Therefore, interest in the
overall health is more important.

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

There is nothing to prevent that, if the solution supports it, but IMO 
it's better if the solution does not require co-operation with further 
upstream transit providers.

Also note that there was another case: Site S interacting with the
Internet (ie. with folks it is not directly or indirectly paying money
to).  Co-operation must not be required there, I think.
 
> >>> 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.

Can't stop paying?  Why can't?  You just keep advertising the route, more 
specifics if you need to, and there's no one stopping you.

Of course, I guess there is typically some smallish, nominal fee for not 
allocating the address space again to some poor sucker.
 
> "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.

Yes, I agree independence is typically a factor in PI-based BGP use, but 
that is also used for site multihoming -- which should be in scope too.

With the current state of *being typically able* to punch a hole in the 
aggregate and steal the address space (perhaps by paying some small sum to 
the original party), you end up with rather a close approximation of 
independence ("PA address becomes de-facto PI").
 
> > 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,".

That covers it, but I'm confused why you like to fade away the PI-address 
case -- which seems rather typical for biggest sites, at least.
 
> > 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?

Sounds rather good, gives the right impression.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings