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