Subject: requirements draft revision

From: Joe Abley <[email-masked]>
Date: Tue, 26 Jun 2001 08:13:17 -0400

Hi,

I've been sitting on this for a few days now, so I think it's time to
throw it out for discussion. Note that I haven't given Ben time to check
this over, so if there are gross errors they are mine and Vijay's, and
you shouldn't blame him.

I'm not happy with the requirements on transport-layer stability and
survivability, but I wasn't able to find clear consensus in the mail
archives on the issue. Perhaps we can put that issue to bed in -02.

I have split out the description of v4 multi-homing to a separate
document, as I think that makes things clearer. The v4 document is
somewhat green, and could do with some attention (it might be useful to
re-order the points as a compliance document against the reqs draft,
for example, so it is more clear where it is deficient and where it
exceeds the requirements).

Anyway, flame on.

  http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements-01.txt
  http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt

Joe

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 27 Jun 2001 01:14:42 +0900

thanks for the new document.

>  http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt

	the document does not currently describe how the IPv4 multihoming
	is achieved.  without describing it precisely, we cannot really
	go into discussions in section 4 and 5 (Features/Limitations of
	IPv4 Multihoming), as the features/limitations can change
	depending on how you set it up.

	i guess a section has to be added between 3 and 4, which describes
	the current practice (like "buy two circuit from two ISPs, get
	PI address space or PA from one of ISP, establish BGP with both,
	announce the address space to both).

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 26 Jun 2001 19:13:34 +0200 (West-Europa (zomertijd))

> Anyway, flame on.

Since you ask...

>   http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements-01.txt

"For purposes of redundancy and load sharing, the multihomed customer blocks,
which are almost always a longer prefix from the provider aggregate, are
announced, along with the larger aggregate by the provider."

This reads like customer blocks always fall within a provider aggregate,
which is not the case for PI address space.

I think the users of a multihoming solution will have a few requirements of
their own:

1. Multihoming should work even if the host on the other side of the
connection uses a current (June 2001) IPv6 implementation.

2. If the solution requires cooperation of the transit providers, it should
only require the cooperation between the customer and each of the transit
networks individually and not directly between the transit networks.

If these objectives aren't met it is likely that users will opt for
traditional IPv4-like multihoming.

>   http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt

"A multi-homed enterprise may influence routing decisions beyond its
immediate transit providers by advertising a strategic mixture of
carefully-aimed long prefixes and covering shorter-prefix routes."

This is one of the ways to accomplish inbound load balancing. Another widely
used mechanism is path prepending. And some transit networks allow their
customers to set communities for their routes that influence many things in
the transit network which can also have broader effects (like prepending the
path at certain exchange points).

Iljitsch van Beijnum

---

From: Joe Abley <[email-masked]>
Date: Tue, 26 Jun 2001 13:56:56 -0400

> 	announce the address space to both).

I agree, that would certainly be helpful. If you feel like contributing
some words, I'd be happy to paste them in.

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 26 Jun 2001 14:06:08 -0400

> On Tue, 26 Jun 2001, Joe Abley wrote:

Hooray! :)

> which is not the case for PI address space.

That's very true. I think these bits need to be removed from the
requirements documented, and described more accurately in the v4
draft, as itojun suggested.

> connection uses a current (June 2001) IPv6 implementation.

Is this required in addition to 2.2.2 and 2.2.3?

> networks individually and not directly between the transit networks.

How about this:

  A multihoming strategy may require coopreration between an enterprise
  and its transit providers, but must not require cooperation directly
  between the transit providers.

> traditional IPv4-like multihoming.

I agree.

> path at certain exchange points).

Very true, and worth mentioning. I will add words.

Thanks!

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Jun 2001 21:04:15 -0700

In multi6-multihoming-requirements requirement - 3.1.3 Performance -  is
simply bogus. The example given is managing traffic flows to avoid a
specific remote congestion point. As it is not possible for any organization
to reliably affect the routing policies of another organization (even the
first hop), this is basically an unrealistic expectation. Taken to the
limit, the requirement presented means every site has ultimate real-time
control of routing policy for every service provider as well as all the
remote sites they have active flows with. Even if each service provider
wanted to cede control, the mismatch of policy constrains between the
collections of end sites will assure this requirement can't be met because
it has to be true for each of them.

Since I assume you have some specific implementation in mind it might help
if there were an example provided. Without that this requirement simply
needs to be removed.

Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Joe Abley
Sent: Tuesday, June 26, 2001 5:13 AM
To: [email-masked]
Subject: requirements draft revision

Hi,

Anyway, flame on.

http://www.automagic.org/~jabley/draft-ietf-multi6-multihoming-requirements-
01.txt
  http://www.automagic.org/~jabley/draft-ietf-multi6-v4-multihoming-00.txt

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Jun 2001 13:26:12 +0200 (West-Europa (zomertijd))

> Is this required in addition to 2.2.2 and 2.2.3?

Don't you mean 3.2.3?

The current way of multihoming requires only the multihomed network and its
transit providers to take any action.

If the new way of multihoming requires action (upgrading software) by the
other end, obviously this will be less effective because the number of sites
that upgrade their software will always be less than 100%.

So "old" multihoming would be superior to "new" multihoming so it is very
likely that networks will continue to use the old way until this becomes less
attractive for some reason, such as cost or default-free networks filtering
their routes.

Basically, I'm saying the new way of multihoming should be at least as 
attractive to most users as the current way.

>   between the transit providers.

Excellent.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2001 11:11:52 -0500

Joe Abley wrote:
> 
> On Wed, Jun 27, 2001 at 09:50:20AM -0500, Brian E Carpenter wrote:
> > My comments on the -01 draft (presumably you will post it officially?)
> 
> It is coming.

Yes, in fact it came, thanks.

> 
> > You define the SHOULD/MUST/etc terminology but don't use it. I think this
> > is important - some of the requirements should be SHOULDs and some of
> > them must be MUSTs, but I don't think that is correct yet in the text.
> > For example, imho 3.1.1 should be MUST, but it starts with a "should".
> > I suggest a pass through the draft to clarify this everywhere.
> 
> Yes, thanks for reminding me. I will attempt to do that shortly.
> 
> > 3.1.1:
> >
> > >    The multihoming architecture must accommodate (in the general case,
> > >    issues of shared-fate notwithstanding) the following failure modes:
> >
> > I don't find the parenthesis very clear. Suggestion:
> >   (in general, disregarding the survival of individual sessions
> >   as covered by section 3.1.6)
> 
> That's not what I meant. An example of what I was trying to convey is
> that to protect against local-loop failure, it is reasonable to order
> two access circuits. However, if those two access circuits happen to
> run through the same building access, over the same fibre, through
> the same SONET mux, etc, etc, then in practice you may not be protecting
> yourself from many of the likely reasons for failure. Those two circuits
> have "shared fate".

OK, so your phrase does need clarifying.

> 
> > 3.1.6:
> >
> > >    Multihoming solutions must provide re-homing transparency for
> > >    transport-layer protocols;
> >
> > I think we have to be more precise. Firstly it isn't the protocol that
> > survives, it's the session. Secondly, does this include UDP? Suggestion:
> >
> >    Multihoming solutions must provide re-homing transparency for
> >    transport-layer sessions, including protocols such as
> >    TCP and SCTP, and purely stateless protocols built on UDP.
> 
> That certainly makes things clearer.
> 
> > [actually what about applications built on raw IP??]
> 
> If we put a re-homing transparency requirement in for those, aren't we
> mandating that end-point IP addresses must survive through a re-homing?
> Doesn't that bring us back to exactly where we are today?

I think so. So it should be stated as a non-requirement.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2001 09:35:43 -0500

> > Is this required in addition to 2.2.2 and 2.2.3?

I think he does. I think it is required (perhaps as an update to 3.2.3)
to make it clear that an updated host can communicate with a non-updated
host (without survivability).
> that upgrade their software will always be less than 100%.

And people still use Windows 3.1. We can't make this a killer argument
for host updates - that's exactly why I drafted 3.2.3.
> attractive for some reason, such as cost or default-free networks filtering

Exactly. That's why we're here - to find a strategic solution.

> attractive to most users as the current way.

In the long term.

   Brian

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 27 Jun 2001 12:16:16 -0400

>Doesn't that bring us back to exactly where we are today?

        Not necessarily.  One possible approach for transport-layer
protocols, one that seems reasonable to some folks, is that the 
Protocol Control Block for a given session would not contain an 
IP address, though it might contain some other identifier(s).  Also note 
that while UDP is characterised as stateless, all implementations 
that I'm familiar with have normal Protocol Control Blocks 
even for UDP sessions -- so as implemented and deployed there 
is some non-zero UDP state already.  For protocols built on raw IP, 
they could also use some other form of identifier in lieu of an 
IP address, if such an identifier were found and agreed upon.

        [Aside: it is in this respect that it would be nice if the
folks in the IRTF NSRG could focus on producing drafts on the
matter of alternate/additional namespaces.  Right now there's
some discussion, but few if any drafts over there, which seems
like a bug.]

Ran

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Jun 2001 11:41:02 -0400

It is coming.

Thanks for the feedback!

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Jun 2001 11:35:31 -0400

On Tue, Jun 26, 2001 at 09:04:15PM -0700, Tony Hain wrote:
> first hop), this is basically an unrealistic expectation.

In the current v4 architecture, it is overwhelmingly usual for an
operator to assign a higher local preference to prefixes received
from a customer than from a peer.

If I am a customer of T1, I can be very confident that the path from
T1 to me will follow the prefixes I advertise rather than a route
through a peer, for advertisements of the same mask length.

This absolutely happens today, and people absolutely multi-home today
in order to accomplish this.

> Taken to the

This requirement comes from the observed fact that this happens today,
and works very reliably.

Suppose for a second a large, popular on-line auction company obtained
transit through one particular provider, and that provider had a problem
of peering congestion to some other large promising regional ISP that
was taking months to sort out. An immediate solution for the auction
company was to purchase transit from the promising regional ISP, which
eliminates the congestion point that had been causing them such pain.

[note that the congestion condition hypothetically alluded to above
would surely no longer be an issue, if we consider the fabricated
example to be real in some way]

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Jun 2001 11:27:38 -0400

> > Is this required in addition to 2.2.2 and 2.2.3?

Yeah :)

> that upgrade their software will always be less than 100%.

Ah, I see -- I misunderstood what you meant by "other side of the
connection" -- you're talking about a remote endpoint of a transport-
layer session, right?

Perhaps we can generalise the paragraph I suggested (below) to include
this requirement, which seems very sensible to me.

> attractive to most users as the current way.

Absolutely. That is the crux of the matter.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2001 09:50:20 -0500

Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

"We shall need a number of efficient librarian types 
 to keep us in order." - Alan Turing, 1947.

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Jun 2001 13:53:56 -0400

On Wed, Jun 27, 2001 at 10:36:22AM -0700, Tony Hain wrote:
> You effectively proved my point. It is not possible to reliably affect the
> routing policy of an external organization (else the need to purchase access
> to the opposite side of the congestion point would not be necessary).

My point was that it is trivial to affect the routing policy of an
external organisation by buying transit from them.

> Also
> you appear to be targeting a relatively simple topology of managing the
> immediate providers, but the wording implies that any solution is required
> to work over an arbitrarily complex one.

The wording is:

3.1.3 Performance

   By multihoming, an enterprise should be able to protect itself from
   performance difficulties between transit providers.

   For example, suppose enterprise E obtains transit from transit
   providers T1 and T2, and there is long-term congestion between T1 and
   T2.  The multihoming architecture should allow E to ensure that in
   normal operation none of its traffic is carried over the congested
   interconnection T1-T2.

   A multi-homed enterprise must also be able to distribute inbound
   traffic particular multiple transit providers according to the
   particular network within their enterprise which is sourcing or
   sinking the traffic.

If I made the first paragraph "between its transit providers" rather
than "between transit providers" would thae make it clearer?

> [snip]
> 
>             /--ISP 1--><--ISP 2--><--ISP 3--\
> Remote Site<                                 >Popular site
>             \--ISP 4--> Congestion<--ISP 5--/

The requirement here is that "popular site" should be able to multi-home
between ISP4 and ISP5 in order to avoid congestion between ISP4 and
ISP5.

> The policy of 'remote site' is to always prefer its low-cost path to ISP 4.
> The wording requires that the multi-homing solution allow 'Popular site' to
> override the routing to ensure a bypass of the congestion. That can't happen
> because it violates the policy of the other end. Acquiring service from ISP
> 4 or coercing 4 to connect to 2 or 3 are about the only options here.

See above.

> There are current topologies where existing tools have an effect, but they
> have a limited scope. Tat needs to be recognized and they need to be added
> as examples, or the requirement is unobtainable and needs to be removed.

I still don't see what is unobtainable about the requirement, given that
it describes motivations for multi-homing that are achievable today
with v4/CIDR-abuse.

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Jun 2001 10:36:22 -0700

You effectively proved my point. It is not possible to reliably affect the
routing policy of an external organization (else the need to purchase access
to the opposite side of the congestion point would not be necessary). Also
you appear to be targeting a relatively simple topology of managing the
immediate providers, but the wording implies that any solution is required
to work over an arbitrarily complex one. If your intent was simply to say
that 'an enterprise must be able to acquire service from any provider', that
is very different. The open question in both cases is how many entities need
to know the topological details and preference, and how much can one
override the operational biases of the interconnection mesh. The implied
assertion is that it is sufficient for a site to inform the global set of
service providers what it wants and magic will happen. But if the routing
policy of said 'popular on-line auction house' was contradictory to the
outbound routing policy of an arbitrarily distant site where one of the
customers happened to be located, it is not possible for 'popular on-line
auction house' to do anything to directly affect the path of those packets.

Tony

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Joe Abley
Sent: Wednesday, June 27, 2001 8:36 AM
To: Tony Hain
Cc: [email-masked]
Subject: Re: requirements draft revision

Joe

---

From: Vijay Gill <[email-masked]>
Date: Wed, 27 Jun 2001 14:38:09 -0400

On Tue, 26 Jun 2001, Tony Hain wrote:

> In multi6-multihoming-requirements requirement - 3.1.3 Performance -
> is simply bogus. The example given is managing traffic flows to avoid
> a specific remote congestion point. As it is not possible for any
> organization to reliably affect the routing policies of another
> organization (even the first hop), this is basically an unrealistic
> expectation. Taken to the limit, the requirement presented means every
> site has ultimate real-time

Many organizations, including the networks I've worked on, have specific
communities that can be used to color prefixes, such that the routing
policy is changed for those prefixes.

/vijay

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Jun 2001 12:03:46 -0700

Vijay Gill wrote:

> Many organizations, including the networks I've worked on, have
> specific communities that can be used to color prefixes, such
> that the routing policy is changed for those prefixes.

This works within the scope of the community. As soon as it violates some
higher-level policy of an arbitrary third-party though it will be ignored.
My point was simply that multi6 requirements can't be setting us up to do
more than current technology allows. The wording needs to be precise so that
it requires continuing current practice without expanding the scope
unrealistically.

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Jun 2001 11:54:32 -0700

Joe Abley wrote:
> My point was that it is trivial to affect the routing policy of
> an external organisation by buying transit from them.
Then why couldn't 'popular site' trivially affect the routing policy of 'one
particular provider' to bypass the path? After all they bought transit from
them.
All that a site can hope to affect is the 'internal' routing policy of a
service provider, and then only because that is the service being bought.

> If I made the first paragraph "between its transit providers"
> rather than "between transit providers" would thae make it
> clearer?
It would certainly limit the scope of the statement to what is achievable
today.

> The requirement here is that "popular site" should be able
> to multi-home between ISP4 and ISP5 in order to avoid
> congestion between ISP4 and ISP5.
Basically what you are saying here is that 'any site should be able to
acquire services from an arbitrary set of providers'. But the statement in
the draft goes significantly further:
	"The multihoming architecture should allow E to ensure that
      in normal operation none of its traffic is carried over the
      congested interconnection T1-T2."
This implies that any multi-homed E has realtime control of global routing
policies of all other organizations. The best that E can hope for is that
traffic from direct customers of T1 & T2 not be carried over the congested
path. It may through selective announcements be able to affect some traffic
beyond the direct customers of T1 & T2, but it can't do that reliably on a
global scale.

> I still don't see what is unobtainable about the requirement,
> given that it describes motivations for multi-homing that are
> achievable today with v4/CIDR-abuse.
The words used are overly broad compared to actual practice. I don't have a
problem with requiring that current practice be continued, but make sure the
words are not setting us up to require something beyond reality.

Tony

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Jun 2001 15:19:21 -0400

> particular provider' to bypass the path? After all they bought transit from

They might be able to say to that one provider "don't propogate my
advertisements to the promising regional ISP with whom you have
peering congestion". However, the result of that is quite possibly
that they will become *completely* isolated from that regional ISP,
which is not their intention.

They want their prefixes to propogate there in a manner which does
not cause traffic following them to experience congestion.

> service provider, and then only because that is the service being bought.

Correct. That is my point.

> It would certainly limit the scope of the statement to what is achievable

I don't actually think it limits its scope at all, but if it lowers
the chance of misunderstanding, I'm happy to put it in.

> policies of all other organizations.

No it doesn't. It implies that E has a mechanism to influence the
way its traffic is carried within each of T1 and T2.

> The best that E can hope for is that
> path.

No. Traffic from beyond T1 and T2 ultimately has to be carried by T1
and T2 in order to reach E. Once in T1 or T2, the same forwarding
decisions will be made for all regardless of the source of the traffic.
If T1 never sends traffic to T2 in order to reach E, that holds for
all traffic sources.

> It may through selective announcements be able to affect some traffic

The TE requirements of T1 and T2 are not relevant.

> words are not setting us up to require something beyond reality.

I don't understand how you reach some of your conclusions (above), and
am really not seeing where the "words used are overly broad".

If you would like to point out the particular phrases that are causing
you to draw some of the conclusions above, that might be useful.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Jun 2001 22:58:09 +0200 (West-Europa (zomertijd))

> for host updates - that's exactly why I drafted 3.2.3.

Of course at some point some software has to change. But just look at the
speed at which IPv6 is being deployed: people DON'T want to update their
software if it doesn't benefit THEM immediately.

This is exactly the reason why I don't think GxSE is the way to go: it
requires software updates in just about everything to work at all. We need
something that at least works as a single homed system in every instance and
works well within the limits of the software/protocol version environment it
lives in.

So a current IPv6 host should benefit from newer routers rewriting
addresses. And newer IPv6 hosts should be able to survive outages by using
multiple IP addresses even if the routers aren't capable of rewriting.

Obviously, the optimal situation is reached when all the hosts and routers on
both ends are completely up-to-date on all the new protocols. 

So what we need for a GxSE-like solution would be something where either the
end host or a router does all the processing or they share, with every case
being a likely possibility. In the first case, a host would have multiple GR
addresses and transparently accept a change of destination of incoming
packets (the sending side has better information about what works because it
(hopefully) gets ICMP messages when a packet can't be delivered). On the
other hand, if the host doesn't support the new scheme a router has to act as
a "multihoming proxy agent" and mimic regular IP connectivity towards the
internal host.

Note that the permutations between source and destination addresses when two
multihomed sites communicate can grow quickly in such a solution: when both
ends have two addresses there are four possible paths, with three addresses
each nine. Selecting the best path will be very hard in this situation and
even selecting just a reasonable one can be a non-trivial problem.

> In the long term.

I'd say: intermediate term.

Iljitsch van Beijnum

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 27 Jun 2001 23:07:05 +0200 (West-Europa (zomertijd))

> it requires continuing current practice without expanding the scope

I think it is reasonable to require that connectivity to the rest of the
world over one transit provider should be unimpaired whatever the
connectivity status (good, degraded or non-existent) between two transit
providers. (But remember you need this line when your link to one of the
transit providers fails!)

This is what happens today because a network will prefer to send traffic
directly to a customer rather than over another network (because of the lower
administrative distance of IGPs and/or the shorter BGP path).

So a solution that depends on just one transit provider announcing an
aggregate and sending traffic to a second transit provider that doesn't
announce a more specific would break this requirement.

Iljitsch van Beijnum

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Jun 2001 14:09:24 -0700

Joe Abley wrote:
> If you would like to point out the particular phrases that
> are causing you to draw some of the conclusions above, that
> might be useful.

The multihoming architecture should allow E to ensure ...

  T1 ---- T2 ---- T3 --
  | \_     |    _/     \
  |   \_   |  _/        E
  |     \  | /         /
  T4 ---- T5 ---- T6 --

E met the requirement 'By multihoming', but there is nothing they can do to
protect themselves from an arbitrary set of 'performance difficulties
between transit providers'. Yes they can negotiate with T3 & T6 about what
gets announced and where, but that is not sufficient to 'ensure' that some
other organization like T5 doesn't override their intended policy. All E can
do is express a preference. If others choose to abide that preference so be
it, but there is nothing E can do to 'ensure' that outcome unless they have
real-time control of everyone else's policy. By requiring the multihoming
architecture to allow E to 'ensure' an outcome you are moving it well beyond
current practice.

Basically take the words you are using and apply them to an arbitrary
topology that is outside the scope you are intending to address. If the
words are germane but don't return the expected result, they are not precise
enough and need to be replaced or removed.

Again, I believe the actual requirement you are targeting is 'any site
should be able to acquire services from an arbitrary set of providers'. The
reasons may be to avoid congestion, or simply lowering latency to a pocket
of customers. The precise reason doesn't matter and is really out of scope
because that is a policy issue. What matters is that the architecture needs
to enable traffic between any site and the customers of a directly attached
service provider to be directed over the attachment to that service
provider.

Tony

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Jun 2001 19:32:52 -0400

> performance difficulties between transit providers.

... "between _its_ transit providers", I think we agreed.

> between transit providers'.

The only transit providers in that diagram are T3 and T6.

> Yes they can negotiate with T3 & T6 about what
> other organization like T5 doesn't override their intended policy.

T5 is not a transit provider of E.

> All E can
> real-time control of everyone else's policy.

I have already described how E can expect to have exit policy for E's
prefixes handled by T3 and T6.

> By requiring the multihoming

No.

> enough and need to be replaced or removed.

I am still not seeing why you think T[1245] are transit providers of E.

> should be able to acquire services from an arbitrary set of providers'.

No. The requirement is what is written in the draft, and I do not agree
that it reduces to that sentence. If a host within E communicates with
a host in T3 using a source address delegated from T6, and the multi-homing
scheme prohibits E advertising its T6-delegated prefix to T3, then this
requirement is not met, for example, since T3 will route to E via T6.

> The
> because that is a policy issue.

There is a particular capability here that is common in the network today
that we want to preserve. If people are unable to overcome peering
congestion between operators in this way, they will find another way,
and it will quite probably resemble what what is done today with v4.

> What matters is that the architecture needs

I think you're going to need to rephrase that paragraph, because I can't
parse it.

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Jun 2001 18:08:45 -0700

> The only transit providers in that diagram are T3 and T6.

According to the definition in the document, all the Tx organizations are
transit providers. The fact they don't happen to be attached to E makes no
difference to their status as transit providers.

> T5 is not a transit provider of E.

While E is not a direct customer of T5, that does not mean T5 is not
providing transit services for traffic to E, particularly for clients of
itself or T4. Revenue and customer/supplier relationship have no connection
with the service of connectivity and transiting bits beyond the provider's
network.

> I have already described how E can expect to have exit policy
> for E's prefixes handled by T3 and T6.

Yes, and I have described that all the exit policies mean nothing unless the
next party honors them. Since E is not a customer why should they?

> No. The requirement is what is written in the draft, and I do
> not agree that it reduces to that sentence. If a host within
> E communicates with a host in T3 using a source address
> delegated from T6, and the multi-homing scheme prohibits E
> advertising its T6-delegated prefix to T3, then this requirement
> is not met, for example, since T3 will route to E via T6.

Ah, the core of the problem ... applying an IPv4 mindset and constraints to
an IPv6 problem space. There is absolutely no reason for E to expect T3 or
T6 to accept and route a prefix from the other. They may be willing to do
so, but it is not a strict requirement for IPv6 multihoming to solve the
simple scenario you described. If a host within E is communicating with a
host in T3, longest-match source address selection rules will cause it to
use E's T3 prefix. If E chooses not to provide both prefixes to it's hosts,
that is not T3's problem.

Now if you are talking about a scenario where T3 & T6 are providing backup
for each other's prefix of E for the transit providers beyond, then we are
at the point of a substantive requirement and discussion.

> There is a particular capability here that is common in the
> network today that we want to preserve. If people are unable
> to overcome peering congestion between operators in this way,
> they will find another way, and it will quite probably resemble
> what what is done today with v4.

I have no problem with this. All I am looking for is a precise description
of current practice so we don't end up with an expectation that an IPv6
solution is required to do far more. Basically the current document reduces
to 'if E connects to more than one provider the multihoming architecture
will *ensure* that E is able to direct traffic the way it wants at a global
scale'. This is a far broader statement than the simple scenario you have
for the example, but there is nothing requiring the statement to be
restricted to that scenario.

> I think you're going to need to rephrase that paragraph, because
> I can't parse it.

If a host within E communicates with a host in T3 it will use the path
between E and T3, likewise for communication with a host within T6 it will
use the path between E and T6.

Tony

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Jun 2001 21:50:08 -0400

How about this:

  A "transit provider", T,  of enterprise E is an enterprise which provides
  connectivity to the Internet for E which extends beyond the part of the
  Internet operated by T. T and E are directly connected.

See above.

See above.

> an IPv6 problem space.

No -- illustrating how the requirement is not met by a particular
multihoming strategy.

> There is absolutely no reason for E to expect T3 or

We are not presupposing a routing solution. We are simply stating
a requirement.

> scale'.

Well, I don't think it does but it is clear you do :) Does the changed
definition above make things better?

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 27 Jun 2001 19:55:38 -0700

Joe Abley wrote:
> A "transit provider", T,  of enterprise E is an enterprise
> which provides connectivity to the Internet for E which
> extends beyond the part of the Internet operated by T. T
> and E are directly connected.

That solves the problem by restricting the definition to match that specific
example, but I thought one of the points of multi6 was to address the
general problem for all *transit* providers caused by multihomed sites. With
this approach there is no definition for the transit providers not connected
to E, so when we move on to the next example of things that need to work the
definition will no longer fit.

> We are not presupposing a routing solution. We are simply
> stating a requirement.

Oh but you are presupposing a routing solution in that you are expecting one
of the transit providers connected to E to provide routing for the site
prefix from the other one. While this is an IPv4 requirement, it is optional
for IPv6 when the goal is simply keeping the routes straight between the
attached providers.

Tony

---

From: Joe Abley <[email-masked]>
Date: Thu, 28 Jun 2001 02:26:58 -0400

On Wed, Jun 27, 2001 at 07:55:38PM -0700, Tony Hain wrote:
> example,

Actually, no -- that's what I always intended the definition to be.
Someone two hops away with whom you don't have a direct relationship
is not a transit provider, even though they might carry your traffic.
They might be a transit provider of your transit provider, however,
or a peer of your transit provider. Global transit works through
cascades of relationships.

> but I thought one of the points of multi6 was to address the

Transit providers not connected to E are not transit providers of E.

> prefix from the other one.

That is the mechanism by which this requirement is met in the current
multihoming practice with v4.

> While this is an IPv4 requirement, it is optional

There may be other mechanisms that meet that requirement in a new
v6 architecture.

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 28 Jun 2001 09:38:50 -0700

Joe Abley wrote:
> Someone two hops away with whom you don't have a direct
> relationship is not a transit provider, even though they
> might carry your traffic.

Somehow I don't think this is a globally recognized definition of the term
'transit provider'. It also unnecessarily focuses the discussion on one tiny
segment of the problem space. As I recall, the group's charter is to
minimize the impact to the entire routing system (read that all transit
providers), not just the ones directly attached to multihomed sites.

> > ... <snip>
> That is the mechanism by which this requirement is met in the
> current multihoming practice with v4.

And it is obvious you don't see the inconsistency between your statements.

> There may be other mechanisms that meet that requirement in
> a new v6 architecture.

How can there be? You keep insisting the requirement as 'the need for every
provider to accept and provide internal routing for the prefix of another
provider'. That is not the requirement, it is the current mechanism. If you
insist that carrying foreign prefixes is the requirement, there can't be any
other mechanism by definition.

The real requirement is that 'any enterprise is able to acquire services
from an arbitrary set of providers, and have a mechanism to keep the routing
straight between those providers such that traffic between the enterprise
and customers of any one provider will not transit another provider'.

Tony

---

From: Joe Abley <[email-masked]>
Date: Thu, 28 Jun 2001 13:00:49 -0400

On Thu, Jun 28, 2001 at 09:38:50AM -0700, Tony Hain wrote:
> 'transit provider'.

Well, it's the only definition I have ever heard of in the past six years
of working for transit providers. If my definition is not widely used, I'd
be happy to hear an alternative.

> It also unnecessarily focuses the discussion on one tiny

By imposing an architecture on just an enterprise and its transit providers,
a solution *is* proposed for the entire routing system, in a similar way
that an architecture for hop-by-hop routing semantics can facilitate
connectivity between hosts that are more than one hop apart.

> And it is obvious you don't see the inconsistency between your statements.

Good.

> provider'.

No. I keep insisting the requirement is as stated in the draft.

3.1.3 Performance

> That is not the requirement, it is the current mechanism.

Agreed.

> If you
> insist that carrying foreign prefixes is the requirement,

I don't.

> there can't be any

I don't see how we can require that any enterprise be able to acquire
services from any other enterprise. I also don't think we should be
presupposing a routing solution.

Joe

---

From: Ben Black <[email-masked]>
Date: Thu, 28 Jun 2001 21:16:37 -0700

> 'transit provider'. It also unnecessarily focuses the discussion on one tiny

This is absolutely the globally recognized definition.  What you might be
confusing is the concept of a transit provider with a transit network.  A
transit network is one which carries traffic which is neither originated
from nor destined to addresses within itself.  A transit provider is one
which maintains peering agreements with other providers to give access
from its customers to the customers of those providers.  Note that some
providers will use other providers for transit for a variety of reasons.

Two transit providers exchanging customer traffic does not mean they are
using each other "for transit", in the meaning used from a customer's
perspective, though they are certainly acting as transit networks.

> and customers of any one provider will not transit another provider'.

The real requirement is that customers be able to control, through 
whatever mechanism or mechanisms, the flow of traffic.  Your statement
above is one point in that space, but there are many others in use
everyday on the Internet.

Ben

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 29 Jun 2001 12:47:13 +0200 (West-Europa (zomertijd))

On Fri, 29 Jun 2001, Tony Li wrote:

> I submit, therefore, that the real, scalable, requirement for the routing
> architecture is somewhat different: that the destination domain NOT be able
> to technically inject any policy information into the transit domains
> whatsoever.

If you want a scalable architecture, your requirements should include
"scalable" and not "no injection of policy information".

Iljitsch

---

From: Tony Li <[email-masked]>
Date: Fri, 29 Jun 2001 02:52:59 -0700

| The real requirement is that customers be able to control, through 
 | whatever mechanism or mechanisms, the flow of traffic.  Your statement
 | above is one point in that space, but there are many others in use
 | everyday on the Internet.

Today's routing architecture provides policy control for inter-domain
traffic, but gives complete control over that policy to the source and
transit domains along the path.  Today's architecture gives NO direct,
technical control to the destination.  The way that the destination
influences transit policy is through the use of external motivation
(i.e. cash changing hands) or through the use of advisory information
injected into routing.  In this latter class, the mechanisms are simply
those that take advantage of some side effects in the normal policy
computations of the transit domains.  Specifically, by injecting a longer
prefix, their announcements take priority over aggregated announcements.
By padding the AS path, they can make one entry preferable to another.

If your real requirement is to extend the policy control of the
destination, then you must also accept the fact that there must be
distribution about the policy requests of the destination to the transit
domains.  However, distributing this information is exactly what is causing
the indigestion in the routing subsystem today.

Policy wonks will observe that this causes the destination domain to revert
to using cash to influence transit routing policy, thereby eliminating the
tragedy of the commons that we live with today.

Regards,
Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 29 Jun 2001 08:57:22 -0700

Ben Black wrote:
> A transit network is one which carries traffic which is
> neither originated from nor destined to addresses within
> itself.  A transit provider is one which maintains peering
> agreements with other providers to give access from its
> customers to the customers of those providers.

There is absolutely no distinction between those statements! You are mixing
the concept of customer with the technical detail of address space. A pair
of providers with customers in PI space would fit both of those statements.
A pair of providers connecting only dial customers using their space would
fit the last one. How does the term transit apply in that case?

What you appear to be trying to distinguish between is the network selling
dial-access from one selling policy-enabled leased-line services. In the old
days when the latter used PI address space, the address based definition
made sense, but now that customers are simply punching holes in the
provider's block, the address-based distinction is gone.

> Note that some providers will use other providers for
> transit for a variety of reasons.

Absolutely. The question is if the entire chain of providers is using a
chain of sub-delegated address space from one end, are they transit
providers by this definition?  A-B-C-D-E   The fact that E maintains peering
arrangements so its customers can reach customers of B would make it a
transit provider by your second statement, but E's address space came from
D, which came from C, which came from B, so according to your first bullet
these are transit networks in one direction but not the other.

From this and Joe's statements, I believe the intended distinction between
'transit network' and 'transit provider' is actually based on the actions of
the connecting enterprise. If that enterprise is further selling access
services to other enterprises (therefore it is assumed to be expressing
distinct routing policies), then the transit entity is termed a 'network';
when the enterprise simply terminates connections for internal purposes and
wants to express global routing policy through the transit entity, then the
transit entity is termed a 'provider'. This leaves an obvious missing case,
so I assume if the enterprise simply terminates connections for internal
purposes and doesn't express policy, then the transit entity is simply
called an 'access provider'. Note there is no distinction here about
customer relationship, or address space being used. If this is the case, the
definition in the document needs to be tightened up to define the actions of
the connecting enterprise.

Tony

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2001 09:54:49 -0700

> A transit network is one which carries traffic which is neither originated
> from nor destined to addresses within itself.

s/itself/its customers/

> A transit provider is one which maintains peering agreements with other
> providers to give access from its customers to the customers of those
> providers.

nope.  a transit provider might have no peering, and purely purchase.
e.g. savvis, internap, ...

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2001 11:00:55 -0700

>   and E are directly connected.

i have a more open notion

A "transit provider", T, to network N provides N with connectivity to the
global internet extending beyond that part of the internet operated by T.
T and N may be directly connected, or the relationship may be indirect.

randy

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 13:53:19 -0400

> e.g. savvis, internap, ...

The last definition I had was this:

Is this accurate/sufficient?

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 14:16:11 -0400

> T and N may be directly connected, or the relationship may be indirect.

We haven't defined a "network" in this context (I'm assuming
"enterprise" will do the trick; "network" hints at routing
solutions and we are trying to be general).

Also, a transit provider can usefully provide connectivity to some
subset of the global internet, as in the case of, uh, some friendly,
easy-to-deal-with ISP providing transit to just one soon-to-file-
chapter-11 ISP who is difficult to deal with directly.

What do you have in mind by the "or the relationship may be indirect"
phrase? What particular case are you trying to accommodate?

Joe

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2001 11:24:35 -0700

> ...

transit providers provide transit to other transit providers.  hence the
recursion.  hence the use of network, not enterprise.

randy

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 14:43:28 -0400

> recursion.  hence the use of network, not enterprise.

Is a transit provider not itself an enterprise? I was assuming it
was.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 15:20:00 -0400

On Fri, Jun 29, 2001 at 12:16:43PM -0700, Randy Bush wrote:
> >> i try not to use the same noun to refer to two different concepts
> >> within the same sentence.  intentional puns excepted, of course.
> > I don't mean "enterprise" to have the meaning "customer". I mean it
> > like "autonomous system", but without the routing/BGP connotations.
> 
> apologies.  my confusion.  i thought you were trying to communicate,
> but you seem to care more about being right.

I was just trying to make the definition clear. Seems there is
some confusion about what I meant.

*shrug*

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2001 11:45:29 -0700

randy

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 14:54:33 -0400

An "enterprise" is an entity autonomously operating a network using
  TCP/IP and, in particular, determining the addressing plan and
  address assignments within that network.

Consider:

  A --- B --- C
        |     |
        D     E

A, B, C, D are all enterprises. B, E are transit providers of C.
A, D are transit providers of B. Both C and B are multi-homed.

If C has customers, then C is a transit provider for those customers.

Joe

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2001 12:16:43 -0700

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 15:34:22 -0400

On Fri, Jun 29, 2001 at 12:20:03PM -0700, Tony Hain wrote:
> Joe Abley wrote:
> > An "enterprise" is an entity autonomously operating a
> > network using TCP/IP and, in particular, determining the
> > addressing plan and address assignments within that network.
> >
> > Consider:
> >
> >
> >   A --- B --- C
> >         |     |
> >         D     E
> >
> Is C a transit provider if the customer is receiving a /27, but simply
> defaulting to C's routing policies?

Yes. If a customer of C can reach the rest of the internet through C,
then C is a transit provider of that customer. Here's the updated
diagram:

   A --- B --- C --- F
         |     |
         D     E

F is the customer of C.

> What is the difference between that and
> using a dial-in NAT to map 10/8 through a single address received from C?

I don't understand the question. It's the fact that C is providing
connectivity to the internet beyond C that makes it a transit provider.
I don't understand what addressing and/or the presence of NAT has to
do with it in the general case.

> They both fit the definition of Enterprise here.

Yes. A, B, C, D, E and F are all enterprises, according to what I meant
to convey in the text. If we can make things clearer by introducing a
new term for "an enterprise which has a transit provider", as Randy
seemed to be saying, then that's cool. We can do that.

> In both cases the address
> space and routing policies presented to B & E belong to C, so what makes C a
> 'transit' provider?

The fact that C provides internet connectivity for F.

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 29 Jun 2001 12:20:03 -0700

Is C a transit provider if the customer is receiving a /27, but simply
defaulting to C's routing policies? What is the difference between that and
using a dial-in NAT to map 10/8 through a single address received from C?
They both fit the definition of Enterprise here. In both cases the address
space and routing policies presented to B & E belong to C, so what makes C a
'transit' provider?

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 17:10:53 -0400

On Fri, Jun 29, 2001 at 01:36:31PM -0700, Tony Hain wrote:
> The reason I have been hammering on this is there are some underlying
> assumptions everyone has about what these terms mean, and buried in those
> assumptions are mechanisms for what needs to happen to make things work.

I agree, if we're going to have definitions of the terms we use
in the requirements doc, we need to have them defined clearly. I have
been trying to make the definitions as solution-neutral as possible.

> The reason for the NAT question was trying to distinguish the difference
> between an individual dialing in vs. a larger organization. Basically, what
> does F managing address space have to do with the discussion of C being a
> transit or not?

The idea was to re-use an established term (that definition comes
from RFC1918) as a substitute for "autonomous system" which is the
term used in the previous draft, and which implies routing and BGP.
The reference to address space makes more sense in an RFC1918 context
than in this one, perhaps, but the kind of entity I wanted to use
the word "enterprise" to refer to is the same, I think.

> Does any collection of routed subnets constitute an
> 'Enterprise'?

No. "Any collection of routed subnets" could mean anything, from a
crossover cable to the entire Internet. The definition of "enterprise"
used in the draft is much narrower.

> If so do we care about all of them, or only the ones that are
> trying to punch a policy through C? Is there a way to distinguish those
> cases?

The word "enterprise" is only really being used to describe an
entity which is able to multi-home. We need to call those entities
something. That's not an adquate description, however, since we
need "enterprise" in order to defined "multi-home".

"transit provider" is a role that an enterprise may play in relation
to another enterprise: that of providing connectivity to the Internet.

> The fundamental point I was getting to with that last set of questions was
> trying to really nail the definition of 'transit'. The last line of your
> response implies single directionality. Why is C not a transit provider of
> B? (hint: the term 'customer' may not appear in the answer)

Heh :) I take your point. I guess C *is* a transit provider of B by the
definition in the draft. How about if we s/to the Internet/to the global
Internet/ as Randy suggested?

> If the Internet were a single rooted tree the single directionality
> definition would work, but the Internet is a mesh, so the definition is a
> mess. Are you really trying to identify a term for the set of transit
> networks where one of the attached parties is a stub?

The Internet is, in general a mesh, but in practice it's rarely difficult
to identify who is "upstream" and who is "downstream". If we insert the
word "global" as above, I think the definition will be very familiar
to most operators. To drill the concept home, we could always add some
diagrams.

On the other hand, if you have a better definition, let's hear it.

Joe

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Fri, 29 Jun 2001 19:13:15 -0500 (CDT)

> do with it in the general case.

No, it's the fact that C will route _any_ of its customers' traffic to
either its destination or to an egress point nearer (usually) its
destination that makes it a transit provider.  The word any is the key.  A
peer will route any traffic you send it that is destined for its own
network, and sometimes to other agreed upon networks.  A transit provider
routes you to EVERYTHING.

Is it clearer, now?

-Taz

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Fri, 29 Jun 2001 19:09:36 -0500 (CDT)

You mean administrative domain.  We call them networks, but you can call
it an administrative domain.  That means a portion of a network controlled
by the same body.

Mind you, everyone will just say, "Oh, you mean a network."  I find it
amusing that you're trying very hard to define something while avoiding
defining it as what it is.  It's like trying to describe a McIntosh apple
while avoiding calling in an apple entirely, and avoiding any correlation
to an apple.

-Taz

---

From: Ben Black <[email-masked]>
Date: Fri, 29 Jun 2001 16:44:24 -0700

> e.g. savvis, internap, ...

"Note that some providers will use other providers for transit for a 
variety of reasons."

Ben

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 21:13:06 -0400

> while avoiding calling in an apple entirely, and avoiding any correlation

We could call it a site, a network, an enterprise, a provider, a
subscriber, an autonomous system, a domain, an area, an organisation,
a node, a backbone, and probably lots of other things. All those terms
are heavily overloaded ("network", arguably, more than most).

The reason for choosing "enterprise" was that there was an existing
definition in RFC1918 that seemed to fit. I called it an "autonomous
system" to start with, and the reaction to that was that we needed to
drop the routing connotation. I'm not avoiding "network" for any
particular reason, although that's not what I'd call it in general
conversation.

I really don't think it matters what we call it, as long as we know what
we mean. If we call it a "network", we still have to define what we mean
by that in this context. "Enterprise" doesn't seem like such a bad name
to me, but like I say, I don't really care what we use :)

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2001 21:16:53 -0400

> No, it's the fact that C will route _any_ of its customers' traffic to

We were avoiding the use of "customer", I think, in the interests of finding
a technical description as opposed to a commercial one.

> routes you to EVERYTHING.

Right. Isn't this encapsulated in Randy's use of "global"?

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 29 Jun 2001 16:39:56 -0700

Joe Abley wrote:

> I have been trying to make the definitions as solution-neutral
> as possible.

This may not be possible because all the terms are already so overloaded in
different contexts. :)

> entity which is able to multi-home.

So the guy next door with ADSL and Cable modem is an enterprise?

I think the problem is assuming that there is any association between the
size of an attaching entity and the routing policies it will try to inflict.
Even if current operational experience shows a correlation between size and
a particular activity; five years from now the words used to describe the
activity will be the same but the size will be smaller, so the entity being
described by those words will be different.

> On the other hand, if you have a better definition, let's

I have been trying to understand what the intent of the distinctions is. If
the scope is limited to the example of an entity attaching to two (or more)
providers and having the traffic flow over those attachment points without
traversing another provider, then your current evolved definition is
sufficient. If the intent is to eventually describe a variety of routing
policies expressions beyond the attached providers of the entity, then
directionality becomes a problem. B might want to punch a policy through C
to E to influence a mutual customer of D & E, even though the 'global
Internet' is upstream through A. Does this make C a 'transit provider' for B
or E, or a 'transit network', or all of the above? If the definition
requires directionality toward A then does it become none of the above? If C
acquires its address space from B does this change anything?

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 29 Jun 2001 13:36:31 -0700

> > > addressing plan and address assignments within that network.
... snip ...
> I don't understand the question. It's the fact that C is
> providing connectivity to the internet beyond C that makes it
> a transit provider. I don't understand what addressing and/or
> the presence of NAT has to do with it in the general case.
>
> Yes. A, B, C, D, E and F are all enterprises, according to
> what I meant to convey in the text. If we can make things
> clearer by introducing a new term for "an enterprise which
> has a transit provider", as Randy seemed to be saying, then
> that's cool. We can do that.
>

The reason for the NAT question was trying to distinguish the difference
between an individual dialing in vs. a larger organization. Basically, what
does F managing address space have to do with the discussion of C being a
transit or not? Does any collection of routed subnets constitute an
'Enterprise'? If so do we care about all of them, or only the ones that are
trying to punch a policy through C? Is there a way to distinguish those
cases?

Tony

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Fri, 29 Jun 2001 20:35:31 -0500 (CDT)

> a technical description as opposed to a commercial one.

A transit provider can ONLY be described by its relationship to a
customer, as it is a term used to describe a commercial behavior.

> Right. Isn't this encapsulated in Randy's use of "global"?

Yes, I believe so.  I was just arguing with the latest round of
descriptions, because Randy's point seemed to have bounced off.

-Taz

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Sat, 30 Jun 2001 00:15:24 -0500 (CDT)

On Fri, 29 Jun 2001, Tony Hain wrote:

> Jon (Taz) Mischo wrote:
> No, transit is a technical function of bit delivery. There is no customer
> relationship implied or required.

No, TRANSPORT is a technical function, transit is a service.  You
transport a package across state lines, you don't transit it.  Same goes
for packets.  You do, however, use public transit (a pay service) to
transport you places in most big cities.

See the difference?

-Taz

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 29 Jun 2001 21:48:52 -0700

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 30 Jun 2001 12:49:58 +0200 (West-Europa (zomertijd))

> A, D are transit providers of B. Both C and B are multi-homed.

I don't like the implied definition of multihomed. I think it should be
something along the lines of:

An enterprise or network is multihomed if it connects to two or more transit
providers and is not a transit provider itself.

Today there is no real distinction between just being multihomed and also
providing transit services, but in a new system the two may be very
different.

Connecting to just a few peers is doesn't qualify as being multihomed in my
book because the routing information doesn't reach the default free zone.

Iljitsch

---

From: Tony Li <[email-masked]>
Date: Sat, 30 Jun 2001 12:11:23 -0700

| On the other hand, if you have a better definition, let's hear it.

Randy sent you a fine definition that matches common accepted usage of the
term.  Using that would be easier than trying to get the rest of the
industry to change their definition.

Tony