merge Joels' PR in
This commit is contained in:
parent
ec41755f38
commit
d320cfedda
1 changed files with 21 additions and 13 deletions
|
|
@ -148,19 +148,27 @@ rate is low enough.
|
||||||
problems that motivated IPv4 CIDR allocation and later abundant IPv4
|
problems that motivated IPv4 CIDR allocation and later abundant IPv4
|
||||||
PAT, they include:
|
PAT, they include:
|
||||||
<list>
|
<list>
|
||||||
<t>Address allocation models for specific counts of fixed length
|
<t>
|
||||||
subnets to downstream networks or devices from /48 down to /64 are
|
Address allocation models for specific counts of fixed length subnets
|
||||||
based on our imagination of how subnets are or should be allocated
|
to downstream networks or devices from /48 down to /64 are based on
|
||||||
within ipv4 networks.</t>
|
design assumptions of how subnets are or should be allocated and
|
||||||
<t>Hierarchical allocation of fixed-length subnets requires
|
populated within ipv4 networks.
|
||||||
coordination between lower / intermediate / upper network elements
|
</t>
|
||||||
and has implict assumption that policies and size allocation at the
|
<t>
|
||||||
top of the hierarchy will accomidate all use cases with fixed lenth
|
Hierarchical allocation of fixed-length subnets requires coordination
|
||||||
subnet allocation.</t>
|
between lower / intermediate / upper network elementss. It has
|
||||||
<t>Coordination with upstream network elements for the allocation of
|
implict assumption that policies and size allocation allowed the top
|
||||||
fixed length subnets reveals topology and intent that may be private
|
of the hierarchy will accomodate present and future use cases with
|
||||||
in scope and which amounts to permission to build a particular
|
fixed lenth subnet allocation.
|
||||||
topology.</t>
|
</t>
|
||||||
|
<t>
|
||||||
|
Coordination with upstream networks across administrative domains for
|
||||||
|
the allocation of fixed length subnets reveals topology and intent that
|
||||||
|
may be private in scope. Policies for hierarchical allcation are applied
|
||||||
|
top-down and amount to permission to build a particular topology (for
|
||||||
|
example mobile device tethering, virtual machine instantiation, containers
|
||||||
|
and so on).
|
||||||
|
</t>
|
||||||
</list>
|
</list>
|
||||||
</t>
|
</t>
|
||||||
</section>
|
</section>
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue