Re: Comments on draft-morelli-v6ops-ipv6-ix-00.txt

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>   Internet Exchanges (IX) have played a key role in the development
> of
>>   Internet, organizing and coordinating the traffic interchange among
>>   Internet Service Providers (ISP).
>
> Actaully, I know of few, if any IXes that have coordinated the exchange
> of traffic. This is purely a business decision of the involved ISPs.
>
> [Mario] Well, what we did in our draft is a pure description of the
> general IX model studied inside the Euro6IX project trying to put in
> evidence the most innoovative aspects.
>
> I undersntand that all IXs organize and coordinate the exchange of
> traffic in the sense that they provide all the facilities the ISPs need
> to interchange traffic, although it could be true that they do not
> organize how the traffic is exchanged.

IXes provide a layer 2 fabric.

> In the case of IXs with route servers, I think it is very true that the
> IX organizes and coordinates the traffic interchange, as that is the 
> job
> of BGP peerings managed by the RS.

There is a slight distinction here. Route-servers will help the ISPs 
that want to peer and exchange traffic with everyone else present at 
the IX. But _ONLY_ then. I am still free to decide not to peer with 
anyone that is present.

>>   Traditionally, IXs have been based
>>   on layer 2 infrastructures, being the layer 3 services managed by
> the
>>   participant ISPs.
>
> I don't like the use of "services". IXes are based on layer 2 as that 
> is
> their business model. ISPs selling transit are dealing with Layer 3
> exchange of traffic.
>
> [Mario] It is true that today Layer 2 IX is the most frequent business
> model, but technically we see several reasons to move towards business
> models based on Layer 3. So in this sense, this business model could
> offer new  services from both the technical and business
> perspectives....if "services" is not the suitable wording, we may 
> agree,
> but we do not find any better description by now..

First, this goes kind of badly with your own statement that this is the 
IETF and we do not care about business models. I disagree that what you 
are proposing have any future as a business model, I also disagree that 
this would be a good business model. And I fail to see the technical 
reasons for doing this. Actually, I think it creates a lot of 
unnecessary complexity.

>>   However, IPv6 hierarchical and aggregatable routing and addressing
>>   model comes to enhance the IX functionalities by proposing to
>>   directly assign addresses to IX customer's networks.  The customers
>>   can connect with one or several upstream providers and have a
>>   separated addressing space, dependent on the IX instead of the
>>   providers, in order to facilitate multihoming or avoid renumbering
>>   procedures when changing the provider.
>
> I am not really following what you are saying here. IPv4 is also
> aggregatable, although not hierarchial. Hierarchy for IPv6 only comes
> into play as end-customers can only get addresses from their provider
> and there is no PI space.
>
> [Mario]In the model that we are proposing, we want to assign to the IX
> an IPv6 prefix (e.g. /32) that in its turn he could reassign to its
> connected cusomters. In our view, this is not related to PI. The IX
> Customer is not tied to any specific ISP on that IX.

No, but what I am saying is that there is hierarchy in IPv6, as opposed 
to in large parts of IPv4) as there is no PI IPv6 space. Further, you 
say that a customer is not tied to a particular ISP. The reason is that 
the IX has taken over the role as the ISP, and the customer in turn is 
tied to that particular IX. And the customer will required to use the 
upstreams and the polices of the choice of the IX. Depending on who the 
IX chooses as it upstream.

> [Mario] Moreover, in the model that we are proposing, IX is not a
> transit provider but the IX acts as a local/regional ISP for its
> customers.

So the IT IS a upstream for the customers. IT IS a competitor to it's 
own members. And the IX will need a upstream and all customers will 
have to follow the choice of the IX.

> [Mario] There are three different actors in the model: the providers,
> providing connectivity to Internet, the IX that provides addresses and
> coordinates all, and, optionally, another actor providing L2
> connectivity between clients and the IX. The aggregate route (IX 
> prefix)
> is announced by the IX itself (in particular, by the L3MF).

I still don't understand who would announce the covering aggregate and 
who transport that traffic. And how that party would get payed. AFAICS 
the other ISPs will be transit customers of the IX that will have ISP 
announce the coving route as their upstream.

>>   In addition, being an IX a central point where traffic is
>>   concentrated, several networks and application services benefit
> from
>>   the fact of being partial or totally offered from an IX, opening
> the
>>   IX to the world of new advanced services and functionalities like
>>   security, AAA, QoS, multicast, mobility, PKI, DNSSEC or policy
>>   provision, that could also facilitate the deployment of IPv6 and
>>   their required transition mechanisms.
>
> IXes have been providing common services for years. Netnod have 
> provided
> i.root-servers.net, the offical Swedish time through NTP, a RIPE whois
> copy etc since 1998. k.root-servers.net at Linx is another example. 
> Etc,
> etc.
>
> [Mario] I think that you caught the point. They offered "common"
> services, what we propose is to use the IX to provide for  a broader 
> set
> of services (like for example multicast, security, QoS and so on). Even
> if these services are already present in some IXes, this is not
> described until now.

Eh, Multicast has been on IXes since years, as have other services. The 
hardest part with doing intra-provider QoS is the commercial agreement. 
There is nothing in what you propose that you can not do at a IPv4 
based L2 exchange. If you are proposing "walled gardens" of for example 
connecting certain web-services etc to the IX, then that is just more 
customers moving from the ISPs to the IX.

>>   A NAP is basically an enhancement of the IX concept that, apart
> from
>>   a place to host bilateral peering arrangements between similar
>>   providers, it takes the role of a transit purchase venue, where
>>   regional ISPs can acquire transit services from long-haul or
> transit
>>   providers.
>
> I don't really agree. I see the two terms used interchangable.
>
>
> [Mario]  Even if you are righ from a practical point of view,
> theoretically our sentence has been taken from "Interconnection, 
> Peering
> and Settlements-Part I" by Geoff Huston, Telstra
> (http://www.cisco.com/warp/public/759/ipj_2-1/ipj_2-1_ps1.html). There
> was an historical distintion between IXs and NAPs, that maybe has
> dissapeared now.

There was, but I don't see that any more.

>>   On the other hand, IPv6 proposes a strictly hierarchical routing
> and
>>   addressing model that essentially follows the principles stated in
>>   CIDR [1]: hierarchical assignment of addresses and routing based on
>>   aggregation.  The addresses assigned to an organization depend on
> the
>>   point they connect to the Internet.  As a consequence, if the site
>>   changes its provider, its global prefix must be changed according
> to
>>   its new location in the global topology.
>
> ...which is more or less through also for IPv4.
>
> [Mario] So we agree?

Yes, but is not IPv6 specific at the moment.

>>   This new IPv6 IX based addressing model, as well as the advantages
> of
>>   locating network and application services inside the IXs, bring new
>>   possibilities for the design of new advanced IPv6 Internet
> Exchanges
>>   architectures, opening the providers market to new opportunities
> and
>>   actors.
>
> I think you will find that most ISPs see "new actors" as something
> negative :-)
>
> [Mario] We do not enter into business considerations in IETF, but in 
> our
> Euro6IX work we are already working on this issue. We believe that 
> there
> are valid reasons for this.

Then I suggest you remove the last statement from that text.

> First note. If Long-haul providers are to mean Tier-1 or transit
> providers, I have yet to find one that connects to an IX. I think
> KPNQwest's connections to Linx and AMS-IX where the last ones. Also 
> note
> that it's in the interest of Tier-1s NOT to connect to IXes. And if 
> they
> are present (and we can argue about the difference) they are for the
> sole purpose of selling transit.
>
> [Mario] In our model LHP is not equal to Tier1 provider. A LHP is just 
> a
> provider that wants to sell connectivity to Internet to the IX
> customers. In fact the difference between a LHP and Regional Provider 
> is
> not important for our model.

Ok, but if I an ISP, how do I know that I will only transport traffic 
to my own customers? I will need to announce the covering route, and 
will therefor potentially carry all traffic to the IX, also for all the 
other ISPs. How will I get paid for that?

> [Mario] ISP router is the router an ISP deploys on an IX to have
> presence there. The CER is the router that connects an IX customer to 
> an
> IX.

And with "IX customer" here you mean "a business connected to the IX 
that is not in the business of reselling connectivity to a third 
party"?

>>   2.  IX Remote Customers (IXRC), which are not directly connected to
>>       the IX but to a regional provider that is present on the IX.
>
> You mean transit customers of the reginal provider?
>
> [Mario] An IXRC is basically a customer of the regional provider with
> the only difference that it uses addresses from the IX range instead of
> the regional provider's range. The only purpose of an IXRC is to
> facilitate it the provider change without renumbering.

...as long as I change to a provider that is a customer of the IX. And 
as the IX is a direct competitor to the ISPs, I am not convinced that 
would be the case.

> This is not true. I would say the vast majority of connections to the
> worlds IXes are small ISPs. By far. Large ISPs in the form of Tier-1s 
> or
> "Tier-1 wanna bees" are extremely rare. Corporate networks vary. In
> Sweden there are none. In Norway they are plenty. In the rest of Europe
> they are some AFAIK.
>
> [Mario] We do not agree on this issue. We know about IXes where big
> companies/ISP are present. Probably is a geographical/cultural issue.

Ok, I only know of the +30 IXes that are members of Euro-IX and some of 
the IXes in Asia.

>>   To solve this problem, the advanced IX model presented in this
>>   document uses a different approach based on the possibility (new
> for
>>   an IX) to directly assign IPv6 addresses to the customers.
>>   Connectivity provision and IPv6 address assignment are now
> separated
>>   issues and they are no longer both linked to the LHP.
>
> Actually they wheren't in the past either. They where linked to who you
> choose to use as your LIR. In most IPv6 cases this is the same entity
> that announces the covering route for the block from where assignments
> are made.
>
> [Mario] What we said is that in this model, the IX becomes the LIR and
> the connectivity providion is done by one of the Providers connected to
> that IX.

But you do not describe routing, or how the ISPs guarantee that they 
are not carrying traffic for non-customers.


>>   group, for instance, in case of distributed IX).
>
> I only know of two distributed IXes. One in Japan and a Swedish 
> provider
> that sells something they call distributed IX, that I think most would
> call either Internet transit or simply Internetaccess. I
> might be
> wrong. Distributed IXes have the bad habit of competing directly with
> their customers transmission service revenues. Which ISPs normally tend
> to dislike even more than competing with the IP related sales.
>
> [Mario] This is a business issue and not IETF issue.

So where is the technical motivation for a distributed IX? Especially 
that would be superior to a "standard" non-distributed layer 2 
exchange?

>
>> 5.3  Server Farm
>>
>>   The new model here proposed foresees that services are placed
> inside
>>   an IX.  This is a revolutionary concept that permits the
>> development
>
> Hrm. It wasn't even very revolutionary in 1998....
>
> [Mario] Maybe you are right but it has not been documented until now.
> Moreover we are not aware about anything similar to L3MF even with 
> IPv4.
> The work of v6ops is to document operational issues and experiences 
> with
> IPv6 and this is what we are doing in this document.

That you are documenting an idea doesn't make it revolutionary. And I 
can remember seeing in your draft that this is documentation of issues 
and experiences from deployment? If it is that should go in there, and 
be made clear.

> It also assumes that the connected ISPs have a "open" peering policy 
> and
> are willing to peer with every other connected member. This might or
> might not be true. "Traditional" IXes are neutral to this and have
> (mostly) no view on member peering policy.
>
>
> [Mario] You are right but both options are possible.

I know you will say "this is a business issue and not for the IETF", 
but it hasn't proven to be a working method to make money so far.

>> 6.1.3  QoS
>
> Intra-provider QoS is hard to agree on a dedicated point-to-point link.
> Less alone a shared medium IX. And this has nothing to do with the IX
> architecture.
>
> [Mario] That is part of the innovation  :-)

I have quite a few years of experience in peering negotiations for a 
Tier-1 provider. I think I am safe to say that you haven't understood 
the problem. But maybe that is just me.


- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQQ6uHqarNKXTPFCVEQI+VwCgpATg7g24axWo06uZogbQOh1z/2gAmwaC
SV6dGFCHEn/FEWVf3nYbbR1+
=GNS9
-----END PGP SIGNATURE-----