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

[Michel Veillette <[e-mail]>]

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) ?

'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.

Regards,
Michel


From: core [mailto:[e-mail]] On Behalf Of Andy Bierman
Sent: Sunday, November 13, 2016 8:59 PM
To: Alexander Pelov <[e-mail]>
Cc: Core <[e-mail]>
Subject: Re: [core] draft-ietf-core-sid-00, SID allocation



On Sun, Nov 13, 2016 at 5:45 PM, Alexander Pelov <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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<http://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: [e-mail]<mailto:[e-mail]>
www: www.vanderstok.org<http://www.vanderstok.org/>
tel NL: [phone]     F: [phone]

_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core