[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-morelli-v6ops-ipv6-ix-00.txt
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I guess/hope it's ok to send comments on this draft to v6ops.
> 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.
> 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.
> 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.
I _think_ that what you are saying is that the IX would act as the
LIR for the end-customers and that the membership ISPs agree to
accept address assignment out of the IX address block from the
various members. To me it's not clear who would announce the covering
aggregate route? The IX? Then the IX is a transit provider competing
with it's own members...
> 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.
> 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.
> 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.
> 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 :-)
>3. Reference Scenario
>
> The following figure describes the main reference scenario of the
> advanced IPv6 Internet Exchange model defined in this document.
>
> Long Haul Providers
> +------+ +------+
> | LHP1 |...| LHPm |
> +------+ +------+
> | |
> +------------------|--------|----------------+
> | +----+ +----+ |
> | IX | R1 |...| Rm | |
> | +----+ +----+ |
> | | | | IX Customers
> |+----------+ +-----------------+ +------+ | +-------+
> || | | |--| CER1 |-|-| IXLC1 |
> || Value | | Layer Three | +------+ | +-------+
> || Added |--| Mediation | : | :
> || Services | | Function | +------+ | +-------+
> || | | |--| CERn |-|-| IXLCn |
> |+----------+ +-----------------+ +------+ | +-------+
> | | | |
> | +----+ +----+ |
> | | R1 |...| Rk | |
> | +----+ +----+ |
> +------------------|-------|-----------------+
> | |
> +--------+ +--------+
> | RP1 | | RPk |
> | | | |
> | +-----+|...| +-----+|
> | |IXRC1|| | |IXRCk||
> | +-----+| | +-----+|
> +--------+ +--------+
> Regional Providers
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.
> The IX is made of:
>
> o A classical L2 infrastructure (i.e, a high speed LAN), not
> represented on the figure.
> o ISP routers (R), that connect ISP networks to the IX.
>
> o Customer Exchange Routers (CER), that connect local customer
> networks to the IX.
I am not following this. What is the difference betweek a ISP router
and a CER?
> 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?
>5. Overview of the new advanced IPv6 IX model
>
> In a classical model, an IX is not normally opened to the direct
> connection of customers (i.e. large corporate networks or small
ISPs
> or whatever). Instead of that, customers are connected to ISP
> networks, which are present on the IXs.
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.
I think you are using the term "ISP" in very varying roles through
out the document BTW.
> In those cases where customers are directly connected to an IX, they
> typically subscribe an agreement with one or several Long Haul
> Providers present on the IX to route their traffic and announce
their
> prefix addresses.
Well, then they are not really directly connected, are they? :-)
Actaully following the next paragraph, I would simply call them
"customers".
> 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.
> In this way, if an IX customer wants to change its service provider
> (e.g. because it gets a better service or price from another LHP),
> it does not need to change its own addresses, as they have been
> assigned by the IX and not by the service provider.
....as long as the new provider is a customer of that IX.
> 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.
>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....
> In order to keep routing scalability, IX prefix/es must be announced
> aggregated to the IPv6 Internet through the ISPs peering on the IX.
> In principle, unaggregated prefixes assigned to IX customers must
not
> be redistributed outside the IX (only to routers present on the IX).
> This fact imposes the limitation that all incoming traffic (that is,
> traffic destined to IX addresses) will follow the same path,
> independently of the IX customer it is directed to.
Who will pay/select that/those provider(s)? If it is the IX, then
what is the difference between the IX and a ISP?
> As presented in section 3, two types of IX customers are defined:
>
> 1. IX Local Customers (IXLC), which have a direct layer 3
connection
> to a router in the IX (named CER), either managed by the
customer
> or by the IX administrator. These customers can be connected to
> the IX using different technologies like point to point links,
> Frame relay, MPLS VPNs, etc. Customer routers (CER) can be
> dedicated to a customer or can be shared between several.
> However, in the shared case, all the preferences and routing
> policies will be common to all customers sharing the router.
>
> 2. IX Remote Customers (IXRC), which have not direct layer 3
> connection with any router in the IX. They are customers of one
> of the providers present on the IX and so they are connected to
> the ISP network at some place different from the IX, but they
use
> addresses form the IX prefix. In this case, the ISP has to cope
> with the distribution of the prefix assigned to the customer
> through its routing system, in order to have the customer
> accessible from the IX.
I fail to see the interest in direct vs remote "layer 3"
connectivity.
> By using a route server the scalability of the IX is greatly
> improved, because, being "n" the number of ISPs present in the IX,
> the number of BGP peering is O(n) and not O(n2) as it is with a mesh
> topology. Moreover, the addition of new members to the IX is
> simplified, as only a new peering between new ISP router and the
> route server has to be configured.
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.
>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.
Summary, I think that you describe a transit ISP that would allocate
addresses to it's downstreams. Which if I remember correctly was the
original TLA meaning in the address architecture.
- - kurtis -
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3
iQA/AwUBQQN5vaarNKXTPFCVEQIIvgCfQ4mzfutIAub1nY9r3WXrfGylzv0AnRUY
khW42Ln9mdz4nu1BtqmtBmK8
=pJq8
-----END PGP SIGNATURE-----