[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans
I'm not sure if I understand your problem/behaviour here.
I do not argue for or against using db in process automation for operation and maintenance. This is definitely not a topic for the standardization work inside this wg and every ISP should make its choice itself.
(My opinion is only that large ISPs will most likely use such instruments - nevertheless it is not a requirement.)
Thats all I want to say and please do'not interprete my emails in other directions.
Tnx and best regards
Olaf
> -----Ursprungliche Nachricht-----
> Von: bmanning@vacation.karoshi.com
> [mailto:bmanning@vacation.karoshi.com]
> Gesendet: Mittwoch, 1. Marz 2006 13:12
> An: Bonne?, Olaf
> Cc: bmanning@vacation.karoshi.com; tjc@ecs.soton.ac.uk;
> v6ops@ops.ietf.org
> Betreff: 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
> > > >
> > > >
> > > >
> >