Re: [core] draft-ietf-core-sid-00, SID allocation

On Mon, Nov 14, 2016 at 12:47 PM, Michel Veillette <
Michel.Veillette@trilliantinc.com> wrote:

> Hi Andy
>
>
>
> === About the size of the SID range allocated to each YANG module
>
>
>
> The 20 bits range proposed is not incompatible with 'draft-ietf-core-sid'.
>
> Each entity allocating SIDs (e.g. SDOs, End users) is free to define the
> size of the SID range allocated to each YANG module.
>
>
>
> Do you propose to mandate a fixed range size (e.g. 20 bits / 1048576 IDs) ?
>

I prefer 1 range per module, not N

>
>
> 'draft-bierman-core-yid' (https://tools.ietf.org/html/
> draft-bierman-core-yid-00#section-2.1)
>
> supports this concept of flexible range size (field 'local-bits'),
>
> what will be the advantage to revert to a fixed rage size?
>
>
>
> == About the capability to add an extra SID range to a YANG module
>
>
>
> The solution can't impose a hard limit on the number of YANG items within
> a YANG module.
>
> The ability of adding an extra SID range removes this hard limit and
> remove any range anxiety.
>

Your previous solution allocated 10 bits for schema nodes within a module.
We already have modules with more than 1024 objects. Most modules
have less than 300 nodes, so a limit of 1M nodes will never  be a real
restriction.

The real issue is multiple ranges per module.
If this is removed the rest of the details cancel each other out.

>
> Regards,
>
> Michel
>
>
>

Andy

>
>
> *From:* core [mailto:core-bounces@ietf.org] *On Behalf Of *Andy Bierman
> *Sent:* Sunday, November 13, 2016 8:59 PM
> *To:* Alexander Pelov <a@ackl.io>
> *Cc:* Core <core@ietf.org>
> *Subject:* Re: [core] draft-ietf-core-sid-00, SID allocation
>
>
>
>
>
>
>
> On Sun, Nov 13, 2016 at 5:45 PM, Alexander Pelov <a@ackl.io> wrote:
>
> Dear Peter, Andy,
>
>
>
> Excellent points, thanks for bringing this up!
>
>
>
> A major difference between SIDs and MIBs is that we cannot allocate
> prefixes in SIDs (as is the case with MIB-OID). The system works perfectly
> well - it is just NOT feasible for IANA to allocate ranges to individual
> modules on a global scale. It’s also not feasible for developers/companies
> to ask IANA for individual allocations per module (and anything else boils
> down to what we’re currently doing).
>
>
>
>
>
> You want to manually manage ranges.  Why?
>
>
>
> Why not allocate module-ids with a fixed range of objects within a module?
>
>
>
> e.g.,32 bits for modules,  20 bits for objects --> module ID 1 has objects
> 0x100000 to 0x1fffff.
>
>
>
> What evidence do you have that we need more than 4 billion modules,
>
> each with up to 1 million objects?
>
>
>
> There is no operational experience with SIDs but there is plenty with
> managed objects
>
> in general.
>
>
>
> Andy
>
>
>
>
>
>
>
> The SID draft functions under a Two-tier registration system. IANA ->
> SDOs/Registrars -> Modules. IANA allocates chunks of IDs to other
> SDOs/registrars. A module is then registered by these third parties and the
> particular SIDs get assigned to the individual modules.
>
>
>
> Note, that IANA can also register SIDs for individual modules, e.g. for
> all YANG modules published by the IETF. I would suppose the same policy
> could apply to other SDOs.
>
>
>
> Hope that this clarifies the question.
>
>
>
> Best,
>
> Alexander
>
>
>
>
>
>
>
> Le 14 nov. 2016 à 10:17, Andy Bierman <andy@yumaworks.com> a écrit :
>
>
>
> Hi,
>
>
>
>
>
> One question to ask:  How many modules do we expect to have?
>
> How many objects do we expect to have?  In 30 years of writing MIB modules
>
> we have never even come close to a million objects. (Maybe 100,000?)
>
>
>
> A million modules, each with a million objects, would still be less than
> 40 bits.
>
> So why to we need complex range assignments and non-contiguous numbering
>
> within a module?  Presumably to preserve numbers and not waste them.
>
> But since the SID encoding is based on deltas, and the full SID is only
> used
>
> once per transaction, this does not seem to be a real concern.
>
>
>
>
>
> Andy
>
>
>
>
>
> On Sun, Nov 13, 2016 at 4:12 PM, peter van der Stok <stokcons@xs4all.nl>
> wrote:
>
> Dear YANG-SID authors,
>
> I want to propose a change to the allocation of SIDs.
> Currently, the SIDs are divided in ranges and prospective users can
> register a range with IANA.
> When the range is already assigned, they need to select a new not
> allocated range.
> I think that this will discourage many future SDOs who may want to use
> YANG + COMI. Many of these SDOs like to figure out the best number
> structure for their uses, and will be very disappointed when they cannot
> acquire the range. Actually, I believe, they will abandon the use of YANG +
> COMI.
>
> My proposal is to assign numbers to modules, and let IANA handle the
> module number registration as proposed for the SIDs. The assignment of SIDs
> to YANG identifiers, as proposed in the draft remains, the same. The
> difference is the complete freedom to choose the SIDs in any given module.
> The advantage is that all modules can pick their values from the small
> number range.
>
> The change is in the discovery and the structure of the resource path. In
> COMI I want to define another resource type called YANG module with name
> core.c.module. The discovery will return the path: /prefix/module-number-in-binary64.
> For example, with an empty prefix and for module 32, discovery will return
> /g. To retrieve a specific YANG instance with numeric identifier sid in
> module 32, the statement GET coap/example.com/g/sid will do. With two
> characters, modules with numbers < 4096 are covered; probably 3 characters
> will cover all modules.  Given that the SIDs are small, the total URI size
> will not increase due to this modification.
>
> When the full datastore is accessed, the path /c is currently used. We can
> reserve c, meaning module number 28 is already assigned. Another method is
> returning a long path name, such as /whole_store. The size of the related
> URI is not important in this case. However, the proposed module allocation
> necessitates a small modification to the CBOR representation of the
> contents of the full datastore. This is attained by representing the full
> datastore as a CBOR map containing (key, value) pairs, where key is the
> module number and value is the content of the module as specified in
> yang-cbor document.
>
> For the PATCH and the FETCH methods, this representation will also work,
> given the content-formats that are currently looked at.
>
> I hope you like my proposal. The advantage is a simpler IANA
> administration, SID allocation freedom within a module, and shorter SIDs.
> The disadvantage is a slight complexity increase in the CBOR representation
> of the full datastore.
>
> Hope this helps,
>
> Peter
>
>
> --
> Peter van der Stok
> vanderstok consultancy
> mailto: consultancy@vanderstok.org
> www: www.vanderstok.org
> tel NL: +31(0)492474673     F: +33(0)966015248
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>
>
>
>