Subject: RE: v6 multihoming and route filters

From: "Azinger, Marla" <[email-masked]>
Date: Wed, 5 Jul 2006 09:02:42 -0700

I urge everyone to seriously consider that silence is not a good answer.  This internet community needs, wants and is asking for direction.  Whatever comes out of this discussion, verbalizing a plan (be it with flaws or not) is better than no plan at all.  Silence has been a large part of this issue for some time now (with various internet conference venues) and all this has done is create confusion and finger pointing and thus total feeling of lost and confused routing for developing V6 networks.  

Also, correct me if I'm wrong...but I didn't think the global routing table should be seeing the "metropolitan aggregation" setup.  So /48 filter shouldn't interfere with that kind of setup.

Marla Azinger
Frontier Communications

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Christian Huitema
Sent: Tuesday, July 04, 2006 6:13 PM
To: Iljitsch van Beijnum; Marc Blanchet
Cc: [email-masked]
Subject: RE: v6 multihoming and route filters

> What would be the purpose of filtering at /48?
> 
> That allows for 2^45 = 351 trillion prefixes in the routing table,
> which I suspect won't work too well on current routers. And it only
> takes a handful of /32s deaggregated into /48s to inflate the IPv6
> global routing table to a size larger than the current IPv4 routing
> table.

But then, filtering at /32 allows for 2^30 = 1 billion prefixes, which I
suspect also won't work too well on current routers. Setting filtering
constraints at /32 is not sufficient to ensure small tables.

Setting narrow filtering constraints is also counter-productive, as it
encourage a rush on the short prefixes. An organization that could have
done just fine with a /48 or maybe a /40 will request a /32 just in
case, so that organization can eventually multi-home. 

In the end, the size of the routing table will equal the number of
entities that want multi-homing hard enough. Playing around with prefix
sizes will not change that, and will probably generate undesirable
counter effects.

Besides, there are networks in which advertizing /48 or even /64 in BGP
makes perfect sense. Take for example the "metropolitan aggregation" in
which all users in an area get numbered from the same long prefix. The
local ISP will have to exchange the short prefixes with each other. The
will use BGP. Do we want to have a rule cast in stone that prevents
them?

We should really think twice before asking the IETF to publish a
position on this subject. Silence may well be the right approach.

-- Christian Huitema

---

From: [email-masked]
Date: Wed, 5 Jul 2006 16:47:45 +0000

actually, i think that Christian is dead-on.  the IETF should not presume to know
or dictate "best practices" for routing - esp. when they have no idea what may be
my drivers.  the best/only thing they should do is describe -HOW- it is done and
-WHAT- are the boundaries for the choices ...  Making value judgements in standards
is nearly never a good idea.  

--bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Jul 2006 20:55:19 +0200

On 5-jul-2006, at 18:47, [email-masked] wrote:

> actually, i think that Christian is dead-on.  the IETF should not  
> presume to know or dictate "best practices" for routing - esp. when  
> they have no idea what may be my drivers.  the best/only thing they  
> should do is describe -HOW- it is done and -WHAT- are the  
> boundaries for the choices ...

This argument would be considerably more persuasive if there was some  
other group picking up the slack. The RIRs explicitly reject any  
responsibility for routing, although by creating address policies  
they impose important limits on what can be done here. Groups like  
NANOG, APRICOT and RIPE (as opposed to the RIPE NCC) are in the  
business of spreading best practices, but not in the business of  
creating them.

And since the IETF is (hopefully) the place where internet routing is  
best understood an the IETF has historically always had an  
operational component (hence the existence of this very working  
group), I think the IETF can't shy away from at the very least  
discouraging harmful practices, and preferably also pointing out  
tradeoffs that exist between different choices and recommend best  
practices if such can be identified.

> Making value judgements in standards is nearly never a good idea.

What is a standard other than a big fat value judgement?

---

From: [email-masked]
Date: Wed, 5 Jul 2006 19:23:22 +0000

> business of spreading best practices, but not in the business of  

	ah, but there are other groups picking up the slack...
	e.g. your ISP and their peers.
 
> practices if such can be identified.

	er, not clear that the IETF is the place where internet
	routing is best understood... except from a theory standpoint.
	there is a distinct difference between a specification (IETF),
	an implementation (ZEBRA), and operation (your ISP)...  IMHO
	it is none of the IETF's business to tell me or your ISP how
	it can and can not run its business.  That said, I have no
	problem with the IETF telling implementors that there is a 
	possibility of creating a potentially unmanageable number of 
	potential routing entries.  Such advice might also mention the
	fallicy of a "global routing table" and suggest that operators
	may need the tools to manage the number of route entries based
	on the current limits of their particular implementations.
	The SPEC's (IMHO) should not be hostage to current implementation
	limitations. and the SPEC designers should not attempt to dictate
	or police how i operate my network... Their influence should 
	extend as far as the implementors.   
> What is a standard other than a big fat value judgement?

	your view of standards is apparently different than mine.

	i guess that in the end, if the IETF codifies this, we are 
	back to classfull routing and hardcoding address boundaries...
	which turns back years of attempts to  remove arbitrary bounds
	checking that was implemented in IPv4 in the early days ... 

	those who refuse to learn from history are doomed to repeat it.

--bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Jul 2006 13:40:08 +0200

On 5-jul-2006, at 21:23, [email-masked] wrote:

>> other group picking up the slack.

> 	e.g. your ISP and their peers.

There is a big difference between individual entities doing  
individual things that make sense for them, and agreeing on something  
that's good for everyone.

>> best understood

> 	an implementation (ZEBRA), and operation (your ISP)...

You make it sound like there is no overlap between the different  
groups. Unlike other standards organizations, anyone can participate  
in the IETF and even though the balance between different groups  
could be better, the IETF still enjoys a wide variety of people and  
occupations in its constituency.

>   IMHO
> 	it can and can not run its business.

There is a big difference between providing information about what's  
a good idea and creating/enforcing rules. The former should be part  
of the IETF's business, the latter probably shouldn't.

> Such advice might also mention the
> 	fallicy of a "global routing table"

What fallicy?

> 	checking that was implemented in IPv4 in the early days ...

The lesson was poorly learned because through some back doors we're  
now in the situation where having /64 subnets is pretty much mandatory.

But we were talking about inter-domain routing. Filtering on prefix  
size is a very useful technique that does indeed have unfortunate  
side effects. But if you want to get rid of this technique you'll  
have to come up with something to replace it... Not filtering is not  
a reasonable long-term strategy.

---

From: [email-masked]
Date: Thu, 6 Jul 2006 12:36:08 +0000

> >	fallicy of a "global routing table"

	where is the "global routing table"?  How is it defined?
	In zero cases that I am aware of, can any given node running
	IP reach any other arbitrary node running IP.

	I posit that this "global routing table" is a myth.  The -ONLY- 
	thing that matters to me are are the entries in -MY- routers memory.  
	How they get there is -MY- choice and I get to dictate what is placed 
	there.  What you have in -YOUR- routers is your business.

> a reasonable long-term strategy.

	I never said not filtering was an option.  Proxy aggregation is viable
	as well.

	IF this draft is to have any credibility, the only choice will be to
	describe what prefix size filtering is, what the ramifications are, and
	what the "unfortunate side effects" are.  As an ION, one might indicate
	that given the implementation constraints of 2006, an operator might 
	consider the merits of selecting certain prefix sizes, if they choose
	to use prefix-sized filters in their routers.  Two distinct documents.

	IMHO of course.  The IETF will do what/as it pleases. 

--bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 7 Jul 2006 00:29:12 +0200

> 	where is the "global routing table"?  How is it defined?

Either as a particular instance (i.e., taken from one router) of the  
set of routes that allow connectivity to the internet at large or the  
set of prefixes that make up the address space used on the internet.  
Obviously this can be made as complex as desired.

> 	IP reach any other arbitrary node running IP.

What does that prove?

> 	there.  What you have in -YOUR- routers is your business.

That's nice for you but I'm glad that you're not my ISP because I  
don't think personal preference has an important place in running a  
global network. Not only because different people have different  
preferences, but also because it doesn't scale.

> 	I never said not filtering was an option.  Proxy aggregation is  

Not with BGP as it exists today, and security issues are quite  
problematic with this.

> 	to use prefix-sized filters in their routers.  Two distinct  

I disagree. Having a prefix that works in 98% of all cases is not  
nearly as useful as one that works in 99.98% of all cases. Having a  
free-for-all with regard to prefix filtering is suboptimal. And I  
think now we're back to the original issue so this is a nice point to  
have a go at letting the discussion rest.  :-)

> 	IMHO of course.  The IETF will do what/as it pleases.

Given rough consensus, yes.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 7 Jul 2006 23:14:39 +0200

On 5 jul 2006, at 18.02, Azinger, Marla wrote:

> I urge everyone to seriously consider that silence is not a good  
> answer.  This internet community needs, wants and is asking for  
> direction.  Whatever comes out of this discussion, verbalizing a  
> plan (be it with flaws or not) is better than no plan at all.   
> Silence has been a large part of this issue for some time now (with  
> various internet conference venues) and all this has done is create  
> confusion and finger pointing and thus total feeling of lost and  
> confused routing for developing V6 networks.
>
> Also, correct me if I'm wrong...but I didn't think the global  
> routing table should be seeing the "metropolitan aggregation"  
> setup.  So /48 filter shouldn't interfere with that kind of setup.

Where Is Sean Doran when you need him....

Sean (I think), was the first to start advocating string filtering on  
RIR allocation boundaries in IPv4. Randy at Verio followed and there  
where other Tier-1s as well. And life was good. Until downstreams  
started to move to Tier-1s that was receptacle for a) Money b) more  
specific prefixes. Sean at the IEPG meeting in Dec 2000 noted that  
the only scaleable solution to this is charging per prefix.

Randy and Sean had left, filtering fell away, money in the hand  
carried the day.

Route filtering is a policy set by the receiving provider. I don't  
believe there is anything here that the IETF ca say that will make a  
lasting impression.

- kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 7 Jul 2006 19:20:03 +0200

On 5 jul 2006, at 20.55, Iljitsch van Beijnum wrote:

>
> And since the IETF is (hopefully) the place where internet routing  
> is best understood an the IETF has historically always had an  

But the IETF have no understanding of the underlying financial  
motives. I certainly agree that it's bad practice but there is no way  
that the IETF in practice can enforce a policy of /48 multihoming OR  
filtering at /32 - except to present alternative technologies.

- kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 9 Jul 2006 20:21:30 -0400

Probably stuck at some airport...  :-(  (-:

> Sean (I think), was the first to start advocating string filtering  
> on RIR allocation boundaries in IPv4. Randy at Verio followed and  
> there where other Tier-1s as well. And life was good.

Except for the people who were now filtered with no prior warning and  
no recourse. The IETF can't and shouldn't want to mandate how people  
run their networks, but things work a lot better if there is  
consensus about the parameters within which everyone applies their  
own judgement.

> Sean at the IEPG meeting in Dec 2000 noted that the only scaleable  
> solution to this is charging per prefix.

Actually, this doesn't scale at all. I don't know how many networks  
that run defaultless there are, and how many of those do so out of  
necessity, but tracking all of them down and paying all of them some  
money (how do you decide how much each one gets?) is certainly NOT  
scalable.

> believe there is anything here that the IETF ca say that will make  
> a lasting impression.

You may be right, but my reasoning is: the most common IPv4 practice  
(filter at /24) doesn't translate to IPv6, everyone doing their own  
thing is suboptimal, and there doesn't seem to be another forum to  
decide on this, ergo the IETF should step up.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Jul 2006 13:52:39 +0300 (EEST)

On Sun, 9 Jul 2006, Iljitsch van Beijnum wrote:
> Except for the people who were now filtered with no prior warning and no 
> recourse. The IETF can't and shouldn't want to mandate how people run their 
> networks, but things work a lot better if there is consensus about the 
> parameters within which everyone applies their own judgement.

You seem to have the assumption that it is possible to come to a 
consensus (with a reasonable time and energy investment) that 
satisfies the stakeholders.

I'm almost certain it won't be possible, hence I'm rather skeptical 
about wasting time in trying.  So, I'm advocating that we should aim 
for a trade-off document instead if we really want to do something 
here and if we by some miracle happen to get to consensus, even 
better.. :-)

> You may be right, but my reasoning is: the most common IPv4 practice (filter 
> at /24) doesn't translate to IPv6, everyone doing their own thing is 
> suboptimal, and there doesn't seem to be another forum to decide on this, 
> ergo the IETF should step up.

Yes, the IETF has been known of its exercises in futility in the 
past so one more time won't hurt... ;-(

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 10 Jul 2006 19:42:13 +0200

On 10 jul 2006, at 02.21, Iljitsch van Beijnum wrote:

> Except for the people who were now filtered with no prior warning  
> and no recourse. The IETF can't and shouldn't want to mandate how  
> people run their networks, but things work a lot better if there is  

Problem is that one size does not fit all here. I might want to  
filter some /48s and others not, depending on who I might think I  
could push to become a down-stream as well.

> necessity, but tracking all of them down and paying all of them  
> some money (how do you decide how much each one gets?) is certainly  
> NOT scalable.

Money in this case will "flow-upwards".

> You may be right, but my reasoning is: the most common IPv4  
> practice (filter at /24) doesn't translate to IPv6, everyone doing  
> their own thing is suboptimal, and there doesn't seem to be another  
> forum to decide on this, ergo the IETF should step up.

But there is no way to ensure this is followed, actually it's most  
likely not followed. You can't put 2119 keywords in, so at best you  
get to document the trade-offs and at the end of the day people will  
take the approach that will maximise their revenue stream...

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Jul 2006 23:36:45 +0200

Pekka Savola wrote:
>> run their networks, but things work a lot better if there is consensus 
>> about the parameters within which everyone applies their own judgement.
> 
> 
> consensus (with a reasonable time and energy investment) that satisfies 
> the stakeholders.
> 
> about wasting time in trying.  So, I'm advocating that we should aim for 
> a trade-off document instead if we really want to do something here and 
> if we by some miracle happen to get to consensus, even better.. :-)
> 
> Yes, the IETF has been known of its exercises in futility in the past so 
> one more time won't hurt... ;-(

I suspect that the IETF could conceivably produce a document
saying "if you build a network of size X and with a range of filtering
policies between Y and Z, we think the following might be the impact
on route table growth and convergence times." But that might make
a better SIGCOMM paper than an RFC.

     Brian