Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

[Jakob Heitz <[e-mail]>]

FWIW, I support a human readable range.
There is absolutely no advantage to any binary
boundary from the software point of view.

--
Jakob Heitz.
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Jon Mitchell
> Sent: Friday, December 14, 2012 9:40 AM
> To: Nick Hilliard
> Cc: IETF IDR Working Group
> Subject: Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00
> 
> 
> Nick -
> 
> I don't think there seems to be much concensus around any of the
> discussions to change the range in the draft but there are a number of
> people supporting in it's current state w/o these reservations, there
> are literally billions of options we could choose from, 
> especially when
> we consider David is now suggesting two ranges (the only 
> other person on
> the list who has commented).
> 
> The only obvious solution to using a very low number range 
> that doesn't
> put the private ASN range right in the middle of public ASN's some
> number of years from now is to lower significantly the size of the
> allocation (which we have already debated and said we wanted to not
> re-visit this issue again).  I appreciate that you say you may have a
> motivation that is different than a large number of sites for 
> using the
> new range, but this is not the motivation of the current draft.
> 
> This also leaves open the idea (not which I'm suggesting or 
> planning on
> writing drafts about) to re-structure what happens with the vasty
> majority of the space in between for some future undefined purpose.
> 
> As for private ASNs being secluded to the end of the range... this has
> historical precedence and seems to be much more identifiable as
> something different than other options (even if you typo it, it's
> unlikely to conflict with anyone!).  Why should private ASN's being
> favored over current ARIN Public assignments?  Should they gripe they
> have a 6 digit number while others are proposing the new 
> range only be 5
> digits?
> 
> As for 10 digits.. is it really that many (you can add some structure
> internally.. i.e. some zeros in the middle if you only need a 
> subset of
> the total available number)?
> 
> Jon
> 
> On Fri, Dec 14, 2012 at 04:25:04PM +0000, Nick Hilliard wrote:
> > On 13/12/2012 14:41, Jon Mitchell wrote:
> > > This is a long email, revisiting almost everyone of the numbering
> > > discussions in the draft, but I'll try to respond inline 
> mostly to the
> > > nice summary you have at bottom.
> > 
> > thanks for considering these points.  Just one issue:
> > 
> > >> 	- the numbers are large enough that they will attract typos
> > >> 	- complete mouthful and impossible to transmit down 
> e.g. phone, across the
> > >> room, etc (yes, we shout ASNs across the room, and 
> sometimes even talk to
> > >> customers).
> > > 
> > > I encourage your drafts to deprecate 4B ASN, MAC 
> addresses and IPv6.
> > 
> > I don't think this is a viable argument to justify a 
> 10-digit range -
> > instead it's a straw man.  There are many potential ranges 
> which will not
> > interfere with the RIR ranges and the lower ranges have an explicit
> > tangible benefit to me and others on this mailing list.
> > 
> > Turning it around, why didn't IANA start AS32 allocations 
> at 2^32 and work
> > their way down from there?  I'd argue that it's because the 
> larger numbers
> > are a pain to deal with and if they had done so, people 
> would have jumped
> > up and down and shouted at them for doing something 
> unnecessarily pathological.
> > 
> > On this basis I genuinely don't see why a private range should be
> > considered any differently.  Why should private ASN users 
> be committed to
> > use ridiculously large numbers forever more? (and what did 
> they do to
> > deserve this??? :-)
> > 
> > > My general feeling is that if you are configuring a small 
> number of
> > > sites and your operations is confined to a single room and voice
> > > communication is your primary method still, you are 
> likely to be happy
> > > with just using ASN 65000 (meets all of your criteria).
> > 
> > There may also be reasons for using ASN32s instead of 
> ASN16s, or perhaps
> > including ASN16s.  The two have different operational 
> characteristics.
> > 
> > Nick
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>