Subject: WG last-call draft-ietf-multi6-multihoming-requirements-04.txt

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 2 May 2003 23:51:31 +0200

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Unless there are more comments on the above draft by Monday 12.00 CET 
we will send the above draft to the IESG.

Best regards,

- kurtis -

---

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

Ok, I sent this Friday but from the wrong mail-address. I was referring 
to noon today, but I agree that this is to short notice. My fault. 
Let's move this up to Wednesday 7th of May 12.00 CET.

Apologies again.

- kurtis -

On fredag, maj 2, 2003, at 23:51 Europe/Stockholm, Kurt Erik Lindqvist

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 May 2003 08:49:21 +0200

Hold it!!!

I sent several editorial comments on April 16, that Joe stated he would
include, and there was one substantive comment on the security considerations,
where I think there was an agreed change.

So at the minimum there has to be an -05 version.

Also, a last call that arrived 03:00 Monday and expires 12:00 Monday
seems a little short ;-)

   Brian

---

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

On måndag, maj 5, 2003, at 08:49 Europe/Stockholm, Brian E Carpenter 

> where I think there was an agreed change.

Hmm. Joe?

> Also, a last call that arrived 03:00 Monday and expires 12:00 Monday

See other mail.

- kurtis -

---

From: Joe Abley <[email-masked]>
Date: Mon, 5 May 2003 08:11:49 -0400

On Monday, May 5, 2003, at 02:55 Canada/Eastern, Kurt Erik Lindqvist  

>> where I think there was an agreed change.

Those changes were applied, as far as I know. At least, I sent diffs to  
the list at the time and received no feedback.

>> Also, a last call that arrived 03:00 Monday and expires 12:00 Monday

-05 is the current draft.

http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- 
requirements-05.txt

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 May 2003 15:51:58 +0200

Quite right. Kurt last-called the obsolete draft.

Could we restart the last call, on the basis of the -05 draft?
My answer on that is: ship it!

  Brian

---

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

On måndag, maj 5, 2003, at 15:51 Europe/Stockholm, Brian E Carpenter 

> Quite right. Kurt last-called the obsolete draft.

Grr. For some reason me posting to this mailinglist is under some form 
of spell...:-)

> My answer on that is: ship it!

Me and Sean have discussed around this last-call in private and we are 
both really in favor of getting this shipped ASAP. Unless anyone have 
come up with a really compelling reason not to ship it by Wen 12.00 CET 
we will ship it. The -05 draft that is.

- kurtis -

PS From my understanding there is actually nothing that require a WG 
last-call procedure-wise, and not all WGs use it either. Randy correct 
me if I am wrong.

---

From: David Conrad <[email-masked]>
Date: Mon, 5 May 2003 11:22:19 -0700

Just to be explicit:

Christian raised an issue regarding the ability for 'smart hosts' to be 
able to pick the return path.

Should this be added to the list of goals?

Rgds,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 May 2003 10:03:44 +0200

It sounds more like a "nice to have" than a major goal. I suspect
it's the sort of thing that might come in a Stage 2 solution,
with topology information being distributed to hosts - not something
I expect to see very soon. Stage 1 seems to be hard enough.

   Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 6 May 2003 10:14:11 +0200

I would say no for this version. We might want to publish a new version 
later on when we have a more clear picture.

- kurtis -

On måndag, maj 5, 2003, at 20:22 Europe/Stockholm, David Conrad wrote:

> Just to be explicit:
>
> Christian raised an issue regarding the ability for 'smart hosts' to 
> be able to pick the return path.
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 6 May 2003 09:15:16 -0400

On Tuesday, May 6, 2003, at 04:14 Canada/Eastern, Kurt Erik Lindqvist 
wrote:

> I would say no for this version. We might want to publish a new 
> version later on when we have a more clear picture.

Sections 3.1.4 and 3.2.4 kind of hint at this capability already. It's 
not very explicit, but since all the MUSTs and MUST NOTs have been 
stripped from the document, I don't think this should keep anybody 
awake at night.

So I also say "no for this version".

Joe

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 May 2003 00:11:05 +0300 (EEST)

> we will ship it. The -05 draft that is.

I've done a quick review on the document.

There are lots of things that should be clarified, but all should be
rather easily editable.  The document name should also be changed
(s/requirements/goals/) if that's possible.

substantial
-----------
1) the terminology should be improved to be more precise.

   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.

==> should be reworded to remove references to "transit provider is a
site" -concept, which is irrelevant and confusing in this context.

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

==> this also needs rewording.  In general, the term "transit provider" 
is applied to network service providers which are in the middle of the 
packet forwarding chain.  I do not call first-hop upstream providers 
transit providers.  The term "transit" here is also misleading because 
it IMO points to the difference between "transit" and "peering", 
which do not apply to end-sites.

==> therefore, I think the last three terms could be reworded a bit.
(I might be able to try to help with some text if needed and folks agree.)

==> similar consideration wrt. "transit" applies to the rest of the 
document.

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

Solutions will probably not be simple for all of these; stating these 
explicitly will make the solution designers aware of different aspects of 
simplicity which should be considered.

3) there are a few especially worrisome goals.

3.1.2 Load Sharing

   By multihoming, a site should be able to distribute both inbound and
   outbound traffic between multiple transit providers.

3.1.3 Performance

   [...]

   A multihomed site should be able to distribute inbound traffic from
   particular multiple transit providers according to the particular
   address range within their site which is sourcing or sinking the
   traffic.

==> typically "inbound traffic balancing", especially as made a very
specific and detailed goal by "performance", go a long way in the "very
potentially unscalable" territory.

Therefore, I'd like to add some disclaimers or a few additional words to 
these goals -- but I don't know how and what in particular.

Anyone else worried?

4) document assumes the Internet transit/ISP architecture is a single 
administrative entity

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

5) co-operation (non)goals are not explicit about third party ISP's and 
non-direct transit ISP's

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.

==> particularly if the "transit provider" terminology is not redefined,
this needs to be very much clarified.  I believe the above text is used to
refer to the direct first-hop upstream providers of the site only.  It
should also say that co-operation with any of the site's transit providers
and any of their peers or transits should not be required ("no requirement
for third parties", here transit of the transit being a 2 1/2 party)

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/

 This contributes to the rapidly-increasing size of the
   global routing table.

==> s/size/size and dynamicity/ (better word than dynamicity?!?!)

   By multihoming, a site should be able to distribute both inbound and
   outbound traffic between multiple transit providers. This requirement
   is for concurrent use of the multiple transit providers, not just the

==> s/requirement/goal/

3.2.2 Impact on Routers

   The solution may require changes to IPv6 router implementations, but

==> s/solution/solutions/ -- many more under section 3.2.x.  The text
seems to indicate that a single solution would fit the bill.

Normative References

==> references section should be numbered.

   [4]  Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable
        Global Unicast Address Format", RFC 2374, July 1998.

==> this ref is no longer used in the body, and good riddance.  Remove.

   [7]  Huston, G., "Analyzing the Internet's BGP Routing Table",
        January 2001.

==> especially for a *normative reference*, the reference should IMO be 
much 
more explicit (e.g. refer to a publication and give a URL or the like).

editorial
---------
   site-multihoming

==>s/site-multihoming/site multihoming/ (everywhere) ?  This seems a more 
common practice..?

   providers may share a single conduit from the street into a building;
   in this case backhoe-fade of both circuits may be experienced due to

==> "backhoe-fade" ?  No idea what that means, and couldn't find it 
in a dictionary either.

   demonstrate that the modified name resolution system required to
   support them are readily deployable.

==> s/are/is/

   The multihoming solution may allow host or application changes if
   that would enhance session survivability.

==> s/session/transport-layer/ (to make a more explicit reference to 
the goal presented earlier)

   It should be posssible for staff responsible for the operation of a

==> s/posssible/possible/

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

---

From: Joe Abley <[email-masked]>
Date: Tue, 6 May 2003 19:36:34 -0400

Hi,

> (s/requirements/goals/) if that's possible.

I don't think it's worth changing the name; if we do that we lose the 
version control of the document since we have to start again as -00. 
The name of the draft will become largely irrelevant if it is published 
as an RFC.

> substantial

Please explain.

> which do not apply to end-sites.

When I originally put forward these definitions, it was because lots of 
different people had widely differing opinions about what exactly the 
terms "transit", "site", "network", etc meant. It was not possible to 
produce definitions that suited the meanings entrenched in everybody's 
heads, so I settled on a set that seemed to work for the majority of 
people.

[The reason these definitions are there at all is to disambiguate the 
document, given the differing opinions of those terms].

I would prefer to leave those definitions alone, unless there are 
concepts which need to be understood in the text of the draft which are 
not accommodated by the definitions that are there.

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

> these goals -- but I don't know how and what in particular.

These two particular requirements (when they were being called 
requirements) were discussed at some length on this list. The reason 
they were in the document was that they are capabilities which are 
widely used by sites which multi-home today, and any replacement 
multihoming strategy probably needs to support them if it is going to 
be adopted by people in the real world.

The concern people had about whether any single solution would meet all 
of these requirements was what led us to replace the "requirements" 
word with "goals".

>     a homogenous single routing blob -- "once you're in, you're in for 

I'm not sure that additional sentiment is required, but I wouldn't 
object to it going in.

> refer to the direct first-hop upstream providers of the site only.

Your interpretation is correct. I think this is implicit in the way 
that "transit provider" is currently defined (it says "A transit 
provider's site is directly connected to the sites for which it 
provides transit.").

> It

I'm not sure what you're intending to say here; co-operation between 
whom and any of the site's transit providers? Who is "their" in "their 
peers or transits"?

> semi-editorial/substantial

No, I don't think there's any "independence" rationale there; these are 
covered prefixes describing PA assignments, not announcements of PI 
space.

> ==> s/size/size and dynamicity/ (better word than dynamicity?!?!)

complexity?

>    is for concurrent use of the multiple transit providers, not just 

Good catch.

> seems to indicate that a single solution would fit the bill.

Fair enough.

> ==> references section should be numbered.

It will do what xml2rfc decides is right. Unless there is tremendous 
breakage in xml2rfc's output (in which case let's tell Dr Rose) I'm 
inclined to leave these bits as they are.

> ==> this ref is no longer used in the body, and good riddance.  Remove.

Good catch.

> more explicit (e.g. refer to a publication and give a URL or the like).

I will find an URL.

> ==>s/site-multihoming/site multihoming/ (everywhere) ?  This seems a 

I have no opinion on this.

> ==> "backhoe-fade" ?  No idea what that means, and couldn't find it

http://www.net.oregonstate.edu/netvideo/dugout.html

>    support them are readily deployable.

Good catch,

> the goal presented earlier)

Good catch, and...

> ==> s/posssible/possible/

Good catch. Thanks :)

Joe

---

From: David Conrad <[email-masked]>
Date: Tue, 6 May 2003 19:57:25 -0700

In reviewing the draft, I see that it is more generic than simply site 
multihoming.  Specifically, the last paragraph of 3.1.3 and section 
3.1.4 imply an ability to multihome down to a specific host (address 
range of 1) and applications (e.g., nntp servers) respectively.

I am not sure if or how this should be clarified -- perhaps it was just 
me jumping to the wrong conclusion.

Rgds,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 May 2003 08:30:47 +0200

>> ==> especially for a *normative reference*, the reference should IMO 
>> be much

> I will find an URL.

Seems all of this is suffering from "broken-URL-itis". You can probably 
find something resembling the original in Cisco's Internet Protocol 
Journal, but it has since become an RFC unless I'm very much mistaken: 
http://www.ietf.org/rfc/rfc3221.txt

Also note that things have changed since then (only 8% growth), Geoff 
presented a different story at Apricot 2002: 
http://www.apricot2002.net/download/Conference/22/01.pdf "An 
Examination of the Internet's BGP Table Behaviour in 2001" but again 
the URL is broken. (There should be a law against that.)

Also, he unfairly blames multihomers, while not aggregating is the 
number one, two and three reason for the growth in the global routing 
table.

> http://www.net.oregonstate.edu/netvideo/dugout.html

So are you going to include the URL in the text or what???

Remember that RFCs are published by an international standards 
organization. As such, the text should be clear also for people who 
have English as their second or third language and are unfamiliar with 
American colloquialisms.

Iljitsch

---

From: Pekka Savola <[email-masked]>
Date: Wed, 7 May 2003 11:12:52 +0300 (EEST)

> The name of the draft will become largely irrelevant if it is published 

Indeed.  However, the misleading names have often caused confusion at IETF 
LC and IESG review time, from those who haven't read it properly.  
However, IETF LC is not necessary for this document, and it states rather 
clearly in the abstract that these are goals, not requirements -- so this 
seems ~OK.

> > site" -concept, which is irrelevant and confusing in this context.

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.
 
> not accommodated by the definitions that are there.

I'm not sure if these are OK.  In some cases in the document, 
at least, it is important to refer to the upstreams of the first-hop 
ISP's.  With the current terminology, that's difficult.

Also, the text may be rather ambiguous as it doesn't seem to match the 
common understanding of what "transit provider" typically is.

XXXX

> of people who do and don't deploy multihoming). Perhaps you could 

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

I was not sure how to reword that better, but I do believe there are 
differences here.

> be adopted by people in the real world.

Real world is not set in stone, the procedures can change.  I fear we'll
fail if they don't, and we have an attitude "something is done like this, 
so we must always be able to do the same thing, unchanged".

But..
 
> of these requirements was what led us to replace the "requirements" 

.. yes.

> I'm not sure that additional sentiment is required, but I wouldn't 

I feel it's important, but I'm willing to hear what others think.
 
> > It should also say that co-operation with any of the site's transit
> > providers and any of their peers or transits should not be required
> > ("no requirement for third parties", here transit of the transit being
> > a 2 1/2 party)
> 

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
- ISP A <-> Transit2
- Site S <-> [Internet] 
- ISP A <-> [Internet]
- Transit1 <-> [Internet]
 
> covered prefixes describing PA assignments, not announcements of PI 

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.

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.

In any case, the introduction is incomplete.  Multihoming is also done 
with PI addresses, without covering aggregates.  

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.
 
> > ==> s/size/size and dynamicity/ (better word than dynamicity?!?!)

Complexity is too generic a term unfortunately, it doesn't imply anything
about the advertise/withdraw cycles caused by site multihoming.

> inclined to leave these bits as they are.

Nothing major but:

http://www.rfc-editor.org/policy.html

states "s. Normative References" and "s+1. Informative References".

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 7 May 2003 10:21:42 -0400

On Wednesday, May 7, 2003, at 02:30 Canada/Eastern, Iljitsch van 
Beijnum wrote:

> Seems all of this is suffering from "broken-URL-itis". You can 
> probably find something resembling the original in Cisco's Internet 
> Protocol Journal, but it has since become an RFC unless I'm very much 
> mistaken: http://www.ietf.org/rfc/rfc3221.txt

Thanks.

> have English as their second or third language and are unfamiliar with 

Yep, good point. I think I am blaming Vijay or Ben for that phrase 
anyway :-) I will find something more straightforward.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 7 May 2003 10:49:03 -0400

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

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

> The second item separates "multihoming end-site" and "everyone else

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.

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

[...]

> This doesn't take a stance on even more non-goal co-operation, with 

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.

> direct ISP: as long as a covering aggregate (from somewhere else) 

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.

> ==> there is no "coverage" if it is not a longer prefix.

ok, how about "which are almost always covered by a provider 
aggregate,".

> with PI addresses, without covering aggregates.

OK. That's a fair point.

> about the advertise/withdraw cycles caused by site multihoming.

turbulence?

> say something to the same effect might be possible.

Yep, fair enough.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 May 2003 19:40:46 +0300 (EEST)

Sorry for a slight delay in answering.

> accepted amongst operators as we're likely to find.

I suggest replacing the definitions:

   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.

> happen at "end-sites" (assuming I'm understanding your terminology 

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.

> multi-homing but I'm not sure why the goals document should state it as 

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.
 
> paying that guy and continue to announce your long-prefix route to 

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.
 
> 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").
 
> ok, how about "which are almost always covered by a provider 

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.
 
> > about the advertise/withdraw cycles caused by site multihoming.

Sounds rather good, gives the right impression.

---

From: Joe Abley <[email-masked]>
Date: Fri, 9 May 2003 13:06:59 -0400

[...]

>    and Internet connectivity to the site.  The connectivity extends 

I don't see the reason for introducing a new term ("direct Internet 
services provider") which I have never heard used before in preference 
to one which I hear commonly used, in the exact sense in which it is 
defined in -05.

Does anybody else have an opinion about this?

>>>>> 2) simplicity for the internet and/or the site should be made

I'm going to think some more about your comments here, and see if I can 
distill something pithy to cover it.

>>>>>    A multihoming strategy may require cooperation between a site 
>>>>> and
>>>>> its

[...]

> to).  Co-operation must not be required there, I think.

Since these are goals, and not requirements, I'm not sure it's 
necessary or desirable (from the point of view of getting a message 
across) to enumerate every single possible case and permit, require or 
prohibit each in turn.

Maybe we could insert a comment like "The impact of any inter-provider 
cooperation that might be required to facilitate the multi-homing 
strategy should be examined and assessed from the point of view of 
operational practicality."

> specifics if you need to, and there's no one stopping you.

Similarly, there's nothing to stop you choosing any unadvertised space 
and using it as your own, but it does tend to make people upset and 
it's not something I would base a business on.

I will make some provisional edits to -05 and float them on the list 
today.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 9 May 2003 19:11:02 +0200

>> understanding of the phrase, which is why the definitions are there.

Really? Can you list some examples of conflicting use of the term 
"transit"? It seems like a reasonably well-defined word to me.

>    A "transit provider" operates a site

This is completely confusing. It seems we lack a definition for "site", 
and as a non-native speaker I might be missing something, but the word 
"site" makes me think along the lines of a building site: a single 
location. Transit providers tend to operate networks that span more 
than a single location.

If we're going to change wording, let's do away with "site" and replace 
it with "AS". This one is well-defined and used extensively in 
discussions about interdomain routing.

>    which directly provides
>    connectivity to the Internet to one or more external sites.

Or "the rest of the world" for short. I don't think we should consider 
the plight of those selling or buying partial transit as it leads to 
endless
problems with multi-address solutions.

And it doesn't have to be directly.

>    which it provides transit.

Nonsense.

>    and Internet connectivity to the site.  The connectivity extends 

Ok, now define the internet...

Logical connections work too.

> include a wireless connection, but I'm not a native speaker, so..

"connection" is even more generic.

> instead of "transit provider", but I'm not sure whether that's any

What's the thing with directness???

> specifics if you need to, and there's no one stopping you.

A quick message to the NOC of the remaining ISPs can do wonders in this 
regard. Many ISPs only accept more specifics out of other ISP's 
prefixes if that ISP is ok with it. Some don't accept them at all.

---

From: Joe Abley <[email-masked]>
Date: Fri, 9 May 2003 13:23:25 -0400

On Friday, May 9, 2003, at 13:11 Canada/Eastern, Iljitsch van Beijnum 
wrote:

> This is completely confusing. It seems we lack a definition for 
> "site", and as a non-native speaker I might be missing something, but 
> the word "site" makes me think along the lines of a building site: a 
> single location. Transit providers tend to operate networks that span 
> more than a single location.

The document includes a definition for "site":

    A "site" is an entity autonomously operating a network using IP and,
    in particular, determining the addressing plan and routing policy for
    that network. This definition is intended to be equivalent to
    "enterprise" as defined in [2].

> If we're going to change wording, let's do away with "site" and 
> replace it with "AS". This one is well-defined and used extensively in 

The original reason for not using "AS" was that we did not want to 
presuppose a routing solution to the problem (e.g. to the exclusion of 
solutions which involve address overloading on the edge).

>>    which it provides transit.

As I seem to be mentioning in every single message on this subject, the 
reason for the definitions being there at all is that different people 
have different ideas about what "transit provider" means.

At home, I buy transit from an ISP in Ontario called Sentex. They buy 
transit from Telus. According to some understandings of "transit 
provider", Sentex is a transit provider of Joe Abley, but Telus is not, 
since Telus have no direct provider relationship with Joe Abley.

According to other definitions, Telus and Sentex are both transit 
providers of Joe Abley.

To clear up this ambiguity, the document was modified to include 
definitions. To be clear, the purpose of the document is not to define 
the term "transit provider": the purpose is to describe a set of 
criteria which might be viewed as useful capabilities for a multihoming 
strategy. If the set of definitions in the document are (a) not 
completely off the wall and (b) cover the terms used in the document, 
then we are finished talking about definitions.

> Ok, now define the internet...

It's the "largest equivalence class in the reflexive transitive 
symmetric closure of the relationship "can be reached by an IP packet 
from" [Seth Breidbart]

> Logical connections work too.

Let's not introduce new exciting vague terminology for the sake of it.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Fri, 9 May 2003 20:48:48 +0300 (EEST)

> to one which I hear commonly used, in the exact sense in which it is 

Well, "first-hop provider" or "first-hop ISP" could be others.

But still, I think it's *better* to define a new term than redefine a
commonly used one.  That way people do not have prior expectations on what
the term refers to, and even though they would not read the terminology
with great care, it would still point to the right direction.

Even if you my proposition for a new definition is ignored, I think the 
"transit provider" term should be edited to remove stuff about its site.  
I think it would be possible to do so, in a similar fashion as with my 
terms.
 
> operational practicality."

Looks fine (in addition to other clarification on this subject, wrt. 
"transit provider").

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 9 May 2003 19:53:28 +0200

> The document includes a definition for "site":

Ok, I took Thierry Ernst's message as an indication there was no 
definition; my apologies.

>> replace it with "AS". This one is well-defined and used extensively 
>> in discussions about interdomain routing.

> solutions which involve address overloading on the edge).

Ok, we keep "site" then even though the definition seems identical to 
AS, but I do maintain that "transit site" is confusing and shouldn't be 
used.

> As I seem to be mentioning in every single message on this subject, 
> the reason for the definitions being there at all is that different 
> people have different ideas about what "transit provider" means.

When I was responding everything was pretty much out of context. I took 
"sites for which it provides transit" to mean "destinations reachable 
through the transit service" which would indeed be nonsense, but the 
context makes clear (or at least: clearer) that this means "sites that 
are customers of the transit provider". Maybe it's a good idea to spell 
this out in the definition.

> provider", Sentex is a transit provider of Joe Abley, but Telus is 
> not, since Telus have no direct provider relationship with Joe Abley.

> According to other definitions, Telus and Sentex are both transit 

Regardless of your personal circumstances, they are always "a transit 
provider", which is the term being defined. Things would be different 
if you were defining "a site's transit provider".

> criteria which might be viewed as useful capabilities for a 
> multihoming strategy. If the set of definitions in the document are 
> (a) not completely off the wall and (b) cover the terms used in the 
> document, then we are finished talking about definitions.

Nobody is ever finished talking about definitions.   :-)

> symmetric closure of the relationship "can be reached by an IP packet 

That's a good one.

> Let's not introduce new exciting vague terminology for the sake of it.

If I am connected to my ISP over ADSL, how is that a "physical" 
connection with the ADSL whole sale company's ATM network in the 
middle? If the connection isn't always physical, the word physical 
shouldn't be used.

Iljitsch

PS. I really do appreciate you doing a difficult job here.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 May 2003 12:58:44 +0200

> Does anybody else have an opinion about this?

My opinion is that we have spent *far* too long wordsmithing this
document, have as a result downgraded it from "requirements" to
"goals," and that we should now just publish it and move on.

The current text is good enough.

   Brian

---

From: S Woodside <[email-masked]>
Date: Mon, 12 May 2003 20:13:53 -0400

> independence ("PA address becomes de-facto PI").

Typically for large sites only though right?

simon

---

From: S Woodside <[email-masked]>
Date: Mon, 12 May 2003 21:03:26 -0400

On Friday, May 9, 2003, at 12:40  PM, Pekka Savola wrote:
>>> Complexity is too generic a term unfortunately, it doesn't imply
>>> anything about the advertise/withdraw cycles caused by site 
>>> multihoming.
>> turbulence?

turnover is used when there's a lot of change in the staff at a 
company. Or how about turmoil ? cycling could work too since it's 
cycles.  turbulence makes me think of airplanes ;-)

yes, I love playing with words ;-)

simon

---

From: Pekka Savola <[email-masked]>
Date: Tue, 13 May 2003 08:47:19 +0300 (EEST)

> Typically for large sites only though right?

Yes, but rather small ones have also paid for that.

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 May 2003 10:27:28 -0400

> I will make some provisional edits to -05 and float them on the list 

Sorry about the delay; various other things came up and conspired to 
keep me busy over the weekend and yesterday. I haven't forgotten about 
these.

Joe