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

[Jon Mitchell <[e-mail]>]

Jeff / Brian -

yes, there are a million combinations, I've put one in the draft that
seems to be relatively machine and human friendly (but only when looking
at it in asdot notation).  I'm not willing to consider 8 other options
with the draft in WGLC unless there appears to be a widespread concensus
in the WG to change to one specific other option.  I think overall, we
can say things like 4,000,000,000 are not easy to make human friendly in
the CLI when you remove the commas, so I'm not as convinced that these
are less opertionally error prone or human consumable.  Seems more
likely everyone re-uses that number if we decided on it (not that
uniqueness is an attribute that is useful in private ASNs) and
misconfigures it half the time to be 400M.

Jon

On Mon, Dec 10, 2012 at 04:58:16PM -0500, Brian Dickson wrote:
> The as-dot/bit-boundary style typically uses a lot less space, and there
> are several "nice" candidates:
> 
> 64512.0 = 4227858432 (same start, shifted 16 bits left)
> 64850.0 = 4250009600 (the 4250000000 and up range is more human-friendly
> without eating too much)
> 65000.0 = 4259840000 (has a bunch of zeros at the end, more
> asplain-obvious?)
> 65280.0 = 4278190080 (currently in the draft)
> 
> Of course, it may also be reasonable to set aside a third range:
> 4000000000 through TBD2 as Reserved (not part of new range, nor part of
> Public range, just "off limits", as a kind of DMZ).
> 
> That range can be freed up if need be later, e.g. once we have colonized
> the galaxy. :-)
> 
> Brian
> 
> On Mon, Dec 10, 2012 at 4:18 PM, Jeff Wheeler <[e-mail]> wrote:
> 
> > On Mon, Dec 10, 2012 at 1:40 PM, Jon Mitchell <[e-mail]>
> > wrote:
> > > The draft originally was more human/decimal boundary friendly before it
> > > was a WG doc.  There has been some on list, some on meeting (Vancouver)
> > > and some out of meeting discussions I did before we moved from nice
> > > decimal boundary to nice bit or asplain friendly boundary).  Here is one
> > > of the emails:
> >
> > I read the mail thread you linked, but it did not give me any
> > understanding why folks prefer a bit-boundary instead of a
> > human-readable boundary.  I will ask some more operator colleagues to
> > give their opinions.  I am surprised anyone would think bit-boundary
> > is the smartest choice if one of the alternatives looks nicer in the
> > CLI/NMS.
> >
> > I understand what you mean if the CLI/NMS allows you to customize and
> > create multiple prefixes like PRIVATEn and this might be nice for some
> > applications.  However, VPLS has clearly figured this out with label
> > blocks.  The applications for making numerous PRIVATEn prefixes within
> > a network are likely to have conceptually similar demands, in so far
> > as the management of number ranges is concerned.  Even if they aren't,
> > though, it seems clear that router software developers have mastery of
> > subtraction and addition, along with the bit-wise operators.
> > --
> > Jeff S Wheeler <[e-mail]>
> > Sr Network Operator  /  Innovative Network Concepts
> > _______________________________________________
> > Idr mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/idr
> >