[6bone] Fw: [IETF55] 6bone meeting
itojun@iijlab.net
itojun@iijlab.net
Wed, 20 Nov 2002 12:50:25 +0900 (JST)
--NextPart-20021120125017-1146400
Content-Type: Message/Rfc822
Return-Path: itojun@itojun.org
Delivery-Date: Wed Nov 20 03:27:06 2002
Return-Path: <itojun@itojun.org>
Delivered-To: itojun@coconut.itojun.org
To: wide@wide.ad.jp
Subject: [IETF55] 6bone meeting
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Wed, 20 Nov 2002 03:00:25 +0900
Sender: itojun@itojun.org
Message-Id: <20021119180025.9D2667B1@starfruit.itojun.org>
X-Filter: mailagent [version 3.0 PL73] for itojun@itojun.org
pekka - 6bone mess
scope of the document, background
introduction to problems in 6bone
focus to routing problem
required reading for any 6bone/sTLA sit
informational/bcp-like document
some thoughts on solutions
not perfect or fine-tuned, but enough to give some ideas
does not give any final advaice
background
ipv6 is globally useless due to bad connectivity
problems with 6bone
large number of BGP peers
scaling problems, arms race
you can only get good connectivity through 50+ peers?
long tunnels
instability
AS path length as a metric loses its meaning
old hardware, buggy software
route withdrawal
running transit service on old hardwrae or slow connection
pTLA a sa hobby (non-ISP's having pTLAs
pTLA's having not enough experience with "big ISP business"
want to try bigger shoes than they're capable of
full transit to everybody
traffic does not go via sane paths
worst problem
reqeuirements for obtaining a pTLA
too easy to get a pTLA and start toying
alternatives how to reach
wait for real ipv6 transit providers/isps
could take long
big problem of "walled gardens"
devise some hacks to bgp apth selection mechanisms
to take tunnels etc. into account
doesn't seem like the right solution
create some (partial) hierarchy and control transit
no automatic transit-for-all
try to create islands bigger than one as to be significant
continue as before
forces everyone to participate in the "arms race"
narten: clarify "islands" and "need transit providers"
?: US, it's all about money so big ISPs do not start ipv6 services...
pTLA/sTLA are single network
should we separate them or not?
pekka: transit should only made by real "transit" provider
?: which is worse, long tunnel, or transit everywhere?
both
long tunnel is worse
it is difficult to restrict bad tunnels from coming up
it is too easy to become pTLA
it's all about money, serious operation = money
BGP policies should fix it?
cmetz: generic problem for overlayed network.
chicken-and-egg situation
6bone was started as playground, production network should be separated
need content
amount of non-diagnostic traffic
we need to use it daily
we need to shout if there's problem, to get things fixed
tag routes with BGP attributes?
people using BGP without BGP knowledge
guidelines for connecting organizations
end-sites
ask your isp for v6 "create the market demand"
connect as close topologically as you can
small/medium-sized isp w/ stla/ptla
too small to be globally significant, only in a region
lots of tunnels for just them is a waste
create some "islands" and connect these globally
try to find transit providers
change from full transit to mostly pure peering
kill "long tunnels" especially if used for full transit
real transit providers
support v6, if not in every router, at least partially
connect to other real transit networks
relationship with rfc2772, how to go forward
quick summary
create hierarchy to be globally significant
transit should work together to connect only proper sites
prefer local connections, disallow transit
how to go forward?
aim for bcp/informational, for both 6bone/RIR space owners?
develop rules further, or is that for 2772bis?
2772bis
rules for 6bone address space owners only
could be useful for rir space owners too, of course
should not go too deep into the background - only reference 6bone-mess?
===
2772 additions
how should we change pTLA requirements?
who got pTLAs JUSt to get around multi-homing problem?
should we revoke bad pTLAs?
how can we motivate better performance of 6bone?
need to make this draft as explicit as possible, so the newbie can make this work
general comment: not trying to make 6bone "production" but to try to get pepole to limit the scope of how they break it
scope of document extended to rir space
prefix-based multicast more defined
increase required registry information
better wording on confusing parts
more explicit text surrounding filtering of 6bone prefix
must provide isp-like service - must be isp?
must have valid public ASN
must actually advertise the pTLA
creation of 6bone stereering group that can enforce rules specified with pTLAs
add SLA-like parameters
our must try to actually fix a problem that one has
keep latency down, response time to problem, ...
should this draft go to a working group?
pekka: should check current pTLA holders as well.
kessens: important to see what we can do to raise quality of applicants
rockell: how many of you are IPv6 full-time?
kessens: interpretation of rules - part of trouble.
pekka: need clear policy and implement it
classify by bandwidth?
(1) be more strict, like registry? (2) to emulate realworld problem, we need 6bone
narten: hierarchical model is a pipe dream
pekka: hierarchy in connectivity, not address allocation
kessens: be realistic.
===
LIR
what is default free zone?
ipv4 dfz:
subset of routers that do not have a default route and do not receive a full routing table from a single peer
assembly of tier-1 isp
dfz and dfz's routing table
routing table beyond the dfz's boundaries
what is ipv6 dfz? - no transit provider, no tier 1, so no ipv6 dfz
three possible scenarios
1. centralized backbone, arpanet/nsfnet style, unlikely
2. competing but interconnected backbones. this is the current tier-1 system. likely.
3. no major backbone but large scale direct interconnection between smaller networks. is this a realistic possibility?
(timeout)
--NextPart-20021120125017-1146400--