[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans



 ah, i see. existing "mega" ISP/access providers, which emerged primarily from the 
merger/sale of the many smaller, local ISPs of the 1980/1990 era are:

	a) given permanent "first mover" advantage in address delegations
	   because of their size, (and requirement to have automated systems
	   in play) over smaller, nimble, startup ISPs who have no such 
	   requirement.
	b) have protocol and operational recommendations formed that bias
	   address assignments and delegation options to those who can't operate
	   without a "working db"...

there are whole countries who do not have the capital or expertise to run such
back-end systems.  i remain sceptical of the presumption of a minimal capability
set that involves excessive (for most) support structures.  YMMV.

--bill


On Wed, Mar 01, 2006 at 12:58:09PM +0100, Bonness, Olaf wrote:
> Sorry, if I was a little bit unclear. My assumption is, that large ISPs/access providers with millions of customers will simply have automated processes (and hence data bases) for their network operation. Otherwise it is not possible to react successful and in  time if any errors occure.
> And this db's bring additional complexity to the process, thats right. 
> (But if you are not able to make your db working than you should not act as ISP :-), or am I wrong at this point?)
> 
> Of course this is a decission that every ISP has to made by its own ...
> 
> Olaf
> 
> > -----Ursprungliche Nachricht-----
> > Von: bmanning@vacation.karoshi.com
> > [mailto:bmanning@vacation.karoshi.com]
> > Gesendet: Mittwoch, 1. Marz 2006 12:32
> > An: Bonne?, Olaf
> > Cc: tjc@ecs.soton.ac.uk; v6ops@ops.ietf.org
> > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point Links and
> > Easing the Addressing Plans
> > 
> > 
> > 
> > 	so, the presumption is that unless you automate the process and 
> > put a db behind the assignments, that other processes are 
> > superfuluous?
> > not everyone has or wants to have yet another dependency in the loop.
> > (... sorry, can't get routing to work since the db is down... 
> > and its behind
> > a router ... er... sorry...)
> > 
> > --bill
> > 
> > 
> > On Wed, Mar 01, 2006 at 12:21:16PM +0100, Bonness, Olaf wrote:
> > > Yes, this  could be one nice approach - but is normally not 
> > necessary since the operation and maintenance procedures are 
> > mostly automated and db based.
> > > 
> > > Olaf
> > > 
> > > > -----Ursprungliche Nachricht-----
> > > > Von: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]Im
> > > > Auftrag von Tim Chown
> > > > Gesendet: Mittwoch, 1. Marz 2006 12:02
> > > > An: v6ops@ops.ietf.org
> > > > Betreff: Re: Guidelines for Numbering IPv6 Point-to-Point 
> > Links and
> > > > Easing the Addressing Plans
> > > > 
> > > > 
> > > > On Wed, Mar 01, 2006 at 11:41:59AM +0100, Bonness, Olaf wrote:
> > > > > > 
> > > > > >    4.  Routing Aggregation of the Point-to-Point Links
> > > > > > 
> > > > > >    Following this approach and assuming that a 
> > shorter prefix is
> > > > > >    typically delegated to a customer, in general a 
> > /48 [4], it is
> > > > > >    possible to simplify the routing aggregation of the 
> > > > point-to-point
> > > > > >    links.  Towards this, the point-to-point link may be 
> > > > numbered using
> > > > > >    the first /64 of a given /48.
> > > > > > 
> > > > > > using the first (or any) subnet of a larger prefix, breaks the
> > > > > > conceptual model of DHCP prefix delegation. the prefix is 
> > > > delegated to
> > > > > > the requesting router and cannot be used to number the 
> > > > link between
> > > > > > the delegating and requesting router.
> > > > > 
> > > > > My assumption from a service provider point of view would 
> > > > be to use a dedicated sub-preaefix (e.g. /48)of my own 
> > > > aggregate to address the point-to-point links (e.g. /64)  to 
> > > > the custumers (in the case I have to do this).
> > > > 
> > > > And if the customer prefix being 'easy' to relate to the 
> > > > point-to-point
> > > > link address is important (though one assumes this is all 
> > tucked away
> > > > nicely in some db :) you could presumably look at doing 
> > something like
> > > > using the 16 bits assigned for the customer /48 as the 16 
> > bits used 
> > > > to identify the /64 under your carved out /48 for 
> > > > point-to-point links?
> > > > 
> > > > -- 
> > > > Tim/::1
> > > > 
> > > > 
> > > > 
> >