Subject: Re: one size doesn' fit all (was Re: other requirement? (was Re: [RAM] Traffic Engineering

From: Andrew McGregor <[email-masked]>
Date: Mon, 1 Jan 2007 22:50:54 +1300

It occurs to me that the principle difference between those two cases  
is that the home user is very unlikely to have more than one in-house  
link (or at least, isn't using IP routing).  Home networks are more  
likely to be doing link aggregation at the 802 level... I hope.

Andrew

On 01/01/2007, at 5:39 AM, Roland Dobbins wrote:

>
> On Dec 31, 2006, at 8:31 AM, marcelo bagnulo braun wrote:
>
>> That is why i am proposing to identify different type of  
>> multihomed sites and find different solutions for them
>
> This certainly makes sense, but how do we identify 'types' of  
> multihomed sites other than by some arbitrary criteria of scale  
> (and of which things - number of endpoints, number of PoPs, number  
> of transit links, etc.)?  Within the current IPv4 and IPv6  
> paradigms, can we identify *qualitative* differences between a home  
> user with a /24 and two T1s to different SPs and a large  
> multinational corporation with multiple PoPs/SPs on multiple  
> continents?
>
>
> ---------------------------------------------------------------------- 
> -
> Roland Dobbins <[email-masked]> // 408.527.6376 voice
>
> 		All battles are perpetual.
>
>     		   -- Milton Friedman
>
>
>
>
> _______________________________________________
> RAM mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ram
>

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Ted Seely <[email-masked]>
Date: Tue, 2 Jan 2007 11:05:09 -0500 (EST)

Hi Marcelo,

On Sun, 31 Dec 2006, marcelo bagnulo braun wrote:

>
> El 31/12/2006, a las 16:13, Roland Dobbins escribió:
>
> > I believe that 'the IPv6 mulithoming solution' ought to be
> > generalizable and scalable to sites of all sizes.
>
> This is exactly where we disagree. I think this is very hard because if
> you add up all the requirements of all type of potential multihomed
> sites, from a unmanaged lan with a couple of PCs to a highly managed
> huge corporation site, and you also add al the border constratints,
> like scalability of the routing system, then you have very very
> difficult problem
>
>
> That is why i am proposing to identify different type of multihomed
> sites and find different solutions for them

not that i'm disagreeing with you, but would this lead to multiple
solutions?  i think the last thing we all want is ala carte protocols
based on the criteria a site fits into.  i'm afraid this leads to
the sqaure peg protocol for the square peg sites, and round ones for round
sites.  do we really want to paint ouselves into this corner?  this sounds
less flexible to me than what we have today.

-ted

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Jan 2007 17:51:42 +0100

El 31/12/2006, a las 23:35, Roland Dobbins escribió:

>
> On Dec 31, 2006, at 1:51 PM, marcelo bagnulo braun wrote:
>
>> big sites have professional network admins that can configure complex 
>> protocols (e.g. bgp) Moreover, because of that they are likely to 
>> want some centralized way to enforce the configurations.
>
> One would think that larger enterprises would have these sorts of 
> folks available, but it isn't always true (not even predominantly 
> true, IMHO), and even when people with those skillsets are on staff, 
> there are generally only a few of them and this sort of thing may not 
> be their only responsibility, either.
>
> Larger enterprises typically do have configuration-management systems 
> of one sort or another, but (again, like most SPs), they're often 
> fairly basic systems in that they allow for automatic provisioning and 
> config versioning, but there's not a lot of logic present which 
> automates the development of the config itself, in most cases (this is 
> one of the main motivating factors behind the development of NETCONF). 
>  One partial exception to this observation is in the generation of 
> ACLs, but the automation for most ACL-generation systems in use today 
> is limited and somewhat brittle, at best, and often does not take into 
> differences in platform capabilities/performance/resources.
>
> [ Come to think of it, this all sounds remarkably similar to a lot of 
> SPs, doesn't it? ;> ]
>
>> A home network  does not have a network admin (ir the network admin 
>> is the user) and it is likely he is not able to do complex 
>> configurations.
>
> Most large enterprises don't handle complex configurations well, 
> either - see above.  They often end up building unnecessarily complex 
> networks for various reasons, but that's not the same thing, heh.
>

ok, i think we may have different definitions of complex here...

I have worked in network administration of two networks:
- the postal service network , with several hundreds of network 
geographcially distributed. they do have a net amdin staff and while i 
agree they don't like complex setups, they are able of doing what i 
call quite complex stuff, as oposed to the other network that i reffer 
next...
- my dad's home network. He doesn't even know what an IP address is, so 
he is not able to do any configuration at all. However, he is able to 
use his netwrok and it is likely he may become multihomed in some 
future, because the CATV guys may offer it for free, or the electricity 
company or some other commodity provider.

So, i can certainly see that the network admin staff of a company can 
deal with more "complex" configuration than normal home users and they 
are likely to have more requirements and they are likely to want to be 
in control of what is going on in the network. A home user normally 
doesn't even know the difference. I think this is a qualitative 
difference that should be taken into account. It may be perfectly ok to 
define that we will be defining a solution for users that have some 
basic knowledge and that won't work fully autoamtically.

Regards, marcelo

>> I think this is (may be) an important difference
>
> In my experience, the difference isn't as great as one would think, 
> IMHO.
>
> -----------------------------------------------------------------------

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Jan 2007 17:56:35 +0100

> less flexible to me than what we have today.

i agree that this is not the best possible outcome

my only concern is that if we try to find one solution that fits all 
the requirements of all possible scenario, the solution space may be 
nil

but we can try with Noel suggestion and see if we manage to do some 
progress with this strategy

Regards, marcelo

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 09:01:23 -0800

On Jan 2, 2007, at 8:51 AM, marcelo bagnulo braun wrote:

> So, i can certainly see that the network admin staff of a company  
> can deal with more "complex" configuration than normal home users  
> and they are likely to have more requirements and they are likely  
> to want to be in control of what is going on in the network.

The enterprise folks who're the most skilled at enterprise networking  
are mainly in the financial services sector along some tech companies  
and military, IMHO; again, they have skilled folks, but not many of  
them, and they're looking for ways to avoid complexity if at all  
possible.

So, we come back to the question - besides scale and internal  
complexity, what's the difference?  Is there some set of objective  
criteria we can come up with on which to predicate a split?

     		   -- Milton Friedman

---

From: Peter Sherbin <[email-masked]>
Date: Tue, 2 Jan 2007 09:58:46 -0800 (PST)

> complexity, what's the difference?

We could look at it from the market perspective where a household is an ultimate
consumption unit. Each housedhold needs addresses for millions of items down to a
body cell level (this was not possible with IPv4 but it is a clear opportunity with
IPv6). For redundancy households need multihoming. Hence by the magnitude of
required addressing space a household easily meets and / or exceeds an enterprise
requirement.

Thanks,

Peter

> criteria we can come up with on which to predicate a split?

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Ted Seely <[email-masked]>
Date: Tue, 2 Jan 2007 14:06:09 -0500 (EST)

Marcelo,

> call quite complex stuff, as oposed to the other network that i reffer

undeniably a very valid example of a large organization that is able to
support a large and complex network.  However, there is a distinct
difference in what commercial organizations can and want to support versus
government organizations.  one gets paid for regardless (called taxes and
being able to print your own money :), the other has to stay in business
and fund its own.  having done both in a previous life, it is a day and
night difference between the commercial sector and the government sector.
we have to keep in mind that the small to mid size company, which make up
the large majority of companies, do not have a lot of in house expertise,
nor are their networks a focus of their business.  sorry to continue to
beat that horse.

but... your dad sure sounds a lot like mine too.  :-)

> company or some other commodity provider.

and i sure hope that my dad isn't offerd a choice, because he won't know
what to do with it, nor does he care.  :)

-ted

k

---

From: [email-masked]
Date: Tue, 2 Jan 2007 14:14:24 -0500

> what to do with it, nor does he care.  :)

I'm a dad, and I care now -- will certainly care in the years to  
come, when the oldtimer references on this list are about us!
(i.e., when any of this might plausibly be implemented)

TV

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Jan 2007 02:49:24 +0100

El 02/01/2007, a las 18:01, Roland Dobbins escribió:

>> deal with more "complex" configuration than normal home users and 
>> they are likely to have more requirements and they are likely to want 
>> to be in control of what is going on in the network.
>

agree but they are willing to deal with the complexity if that is what 
it takes to tune their network wto make perform as they want (clear 
example of this is BGP TE setups) agree?

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Jan 2007 02:47:19 +0100

> nor are their networks a focus of their business.  sorry to continue to

but someone there do configure BGP today for multihoming, right?

BGP multihoming would be non starter in a home network imho do you 
agree?

So my only point is that these a qualitative different...

Regards, marcelo

---

From: Roland Dobbins <[email-masked]>
Date: Tue, 2 Jan 2007 18:07:50 -0800

On Jan 2, 2007, at 11:06 AM, Ted Seely wrote:

> However, there is a distinct
> and fund its own.

It's also worth noting that there's a wide variation in terms of  
capabilities and resources within the governmental sphere, as well.

     		   -- Milton Friedman

---

From: Tony Li <[email-masked]>
Date: Tue, 2 Jan 2007 18:56:12 -0800

>> The enterprise folks who're the most skilled at enterprise  
>> networking are mainly in the financial services sector along some  
>> tech companies and military, IMHO; again, they have skilled folks,  
>> but not many of them, and they're looking for ways to avoid  
>> complexity if at all possible.
>
> agree but they are willing to deal with the complexity if that is  
> what it takes to tune their network wto make perform as they want  
> (clear example of this is BGP TE setups) agree?

Largely, no.  It's an enormous burden on them.  Keeping a firewall up  
and running is about the peak of enterprise expertise today.  I think  
you're greatly overestimating what the average enterprise can and  
will be able to support.

Note that BGP TE is done mostly by ISPs today, not end user sites.   
There are, of course, exceptions, but they are very much in the noise.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 2 Jan 2007 18:59:34 -0800

> So my only point is that these a qualitative different...

Today, yes.  However, if we do the locator/identifier split properly,  
multihoming should be possible without any BGP configuration, for  
SOHO or a medium-to-large enterprise.

Again, I'm not finding ANY qualitative difference beyond what I  
suggested before:

a) 1 ASBR
b) more than one ASBR

Tony

---

From: Ted Seely <[email-masked]>
Date: Wed, 3 Jan 2007 10:00:24 -0500 (EST)

> but someone there do configure BGP today for multihoming, right?

yes, or they pay consultants to do it, and in either case they are
typically very rudimentary and not complex.  this may have changed, but
that was my observation from 10+ years ago.  now that being said, perhaps
the observation is not current enough to matter.  i leave that to others
still more involved in that space to provide input.

> BGP multihoming would be non starter in a home network imho do you

today yes, 10 years from now, for whatever this my evolve into, I don't
know.  as someone pointed out earlier in this thread, that will be us
eventually.  :)

> So my only point is that these a qualitative different...

agree based on today's requirements, and i use that term very loosely.

-ted

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 3 Jan 2007 10:10:03 -0500

On Jan 3, 2007, at 10:00 AM, Ted Seely wrote:

>>> government organizations.  one gets paid for regardless (called  
>>> taxes
>>> and
>>> we have to keep in mind that the small to mid size company, which  
>>> make
>>> up

I think that your observation is still correct.

> know.  as someone pointed out earlier in this thread, that will be us

ASNs 1880, 1881 and 1882 come to mind, for some reason.

Regards
Marshall

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Jan 2007 12:54:56 +0100

El 03/01/2007, a las 3:56, Tony Li escribió:

> you're greatly overestimating what the average enterprise can and will 
> be able to support.
>

every feedback i get seems to point in that direction....

So, are we concluding that any solution should work in any type of site 
without requiring configuration from the user? this seems quite a tough 
requirement to me...

Regards, marcelo

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 4 Jan 2007 06:58:28 -0800

On Jan 3, 2007, at 3:54 AM, marcelo bagnulo braun wrote:

> So, are we concluding that any solution should work in any type of  
> site without requiring configuration from the user? this seems  
> quite a tough requirement to me...

I wouldn't go that far, but it's important to understand that what to  
folks on this list may seem a reasonable amount of complexity in  
exchange for functionality may well prove an insurmountable obstacle  
for enterprises, even big, sophisticated ones.

[ Perhaps the points made earlier about OPEX and supportability now  
make more sense in light of this feedback. ]

		  Technology is legislation.

                     -- Karl Schroeder

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 07:28:36 -0800

> criteria we can come up with on which to predicate a split?

	So first, scale and internal (or other) complexity are
	intimately related. That being said, I'm really not sure
	what you mean by complexity, but what I can say is that
	if we build a system in which there are unbounded (e.g.,
	non-linear) effects (say, in the UPDATE stream, as I've
	been wanting to understand), then we will find ourselves
	with a network that isn't robust to exactly those
	situations in which we need robustness. 

	Remember that there is a (heavy-tailed) relationship
	between robustness and complexity (some complexity is
	needed to achieve robustness), and and if one goes to far
	down the complexity line the results can be, well, just
	avoid fires in train tunnels containing lots of fiber and
	the like.

	--dmm

---

From: David Meyer <[email-masked]>
Date: Thu, 4 Jan 2007 07:40:16 -0800

On Tue, Jan 02, 2007 at 02:06:09PM -0500, Ted Seely wrote:
> > El 31/12/2006, a las 23:35, Roland Dobbins escribi�:
> >
> > >

	Well, that and the fact that just because you can build
	something doesn't make it a good idea (tm). The fact that
	one can build something is almost irrelevant; we're an
 	industrious crew, and we build a lot of things. 

	Summary: The fact that one can build and/or deploy some
	         <X> isn't an indication that <X> is a good idea [0]. 

	--dmm

[0]	Where "good" might be scalable, efficient OPEX or CAPEX
	profile, reliable, ...
_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Tony Li <[email-masked]>
Date: Thu, 4 Jan 2007 09:51:53 -0800

> quite a tough requirement to me...

No, I wouldn't go that far.  I would say that we will need mechanisms  
that allow ASBRs to discover one another and exchange information.  I  
think that the most that we might get is a knob flipped on the ASBR  
that would both enable this mechanism and advertise the capability,  
presumably in the IGP.

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 4 Jan 2007 19:17:01 +0100

El 04/01/2007, a las 15:58, Roland Dobbins escribió:

>> site without requiring configuration from the user? this seems quite 
>> a tough requirement to me...
>

i agree with this indeed... i guess the difficulty is to understand 
what acceptable cost vs. unsurmountable obstacle is... from the 
discussion lately i think this is not an easy task...

Regards, marcelo

---

From: Tony Li <[email-masked]>
Date: Thu, 4 Jan 2007 11:29:34 -0800

> What about management of the solution?  does the solution must work  
> automatically or is it possible that it requires manual  
> configuration? i mean are we designing for the dentists office?
>
> from the feedback i got so far, it seems that the solution should  
> work in a non managed environment...

I'd have to agree with that.  The size of the unmanaged SOHO segment  
that we should address is quite large.  The juxtaposition of multiple  
access technologies and the near-ubiquity of wireless clearly makes  
multi-homing trivial in any urban or suburban environment.

Tony

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 5 Jan 2007 03:12:07 +0100

> multi-homing trivial in any urban or suburban environment.

i guess that there are a couple of comments to relax this requirement:
- First, it only applies to the basic support (basic features) and 
enhanced features may require additional (manual) tunning (i guess that 
the complex issue here would be to define which are basic features and 
which ones are enhanced, but as i see it, fault tolerance (in all its 
flavors) is a basic feature and TE is an enhanced feature
- Second, solutions may require expert configuration, but if this is 
the case, it must be possible that the ISP configures the device 
remotely (a currently available example of this approach would be 
address/prefix configuration through DHCP) or that the ISP provides the 
service for the customer (a currently available example of this would 
be the reverse mapping of delegated addresses). Note that different 
ISPs should not be required to cooperate

Do you think this describes the unmanaged network support requirement 
correctly?

Regards, marcelo

---

From: Tony Li <[email-masked]>
Date: Thu, 4 Jan 2007 18:20:31 -0800

> enhanced features may require additional (manual) tunning (i guess  
> that the complex issue here would be to define which are basic  
> features and which ones are enhanced, but as i see it, fault  
> tolerance (in all its flavors) is a basic feature and TE is an  
> enhanced feature
> - Second, solutions may require expert configuration, but if this  
> is the case, it must be possible that the ISP configures the device  
> address/prefix configuration through DHCP) or that the ISP provides  
> the service for the customer (a currently available example of this  
> would be the reverse mapping of delegated addresses). Note that  
> different ISPs should not be required to cooperate
>
> Do you think this describes the unmanaged network support  
> requirement correctly?

It's certainly adequate.  If you buy a SOHO box today, it pretty much  
has NAT and DHCP already enabled by default.  Certainly bells and  
whistles might get fancier, but that's not the real issue.  The point  
is to solve the 90% case simply.

Tony

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 4 Jan 2007 18:24:35 -0800

> Do you think this describes the unmanaged network support  

FWIW, I like 'unmanaged' much better than 'SOHO', as it can describe  
an easily-agreed-upon condition and a congruent set of base  
capabilities, rather than attempting to define a nebulous term like  
'SOHO'.  If there's going to be a split (something I still don't  
like, but can live with if it really seems necessary), it seems that  
capabilities would be the only objective way to predicate the split,  
since one customer's SOHO is another's colo, heh.

                     -- Karl Schroeder

---

From: Russ White <[email-masked]>
Date: Fri, 05 Jan 2007 08:48:38 -0500

> think that the most that we might get is a knob flipped on the ASBR that
> would both enable this mechanism and advertise the capability,
> presumably in the IGP.

While I think we need the autodiscovery, I would leave the IGP out of it
if possible. IMHO, IGPs themselves are being overloaded with
virtualization at a rate that's going to make them difficult to design
and manage. Overloading them with EGP discovery might not be the best
way of going about this.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone