[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-v6ops-addcon-03.txt



Some of my earlier comments haven't resulted in any text changes.
I'm not completely at ease about these points.

On 2006-06-13 09:25, Brian E Carpenter wrote:
...
2.2.  Unique Local IPv6 Addresses
...
   Because a ULA and a global site prefix are both /48 length, an
   administrator can choose to use the same subnetting (and host
   addressing) plan for both prefixes.

The RIRs are moving away from a rigid /48 policy. It would be safer
to start this sentence with "When" instead of "Because".
And on the same topic...

2.4.  Network Level Design Considerations

I suggest adding a bullet at the end of this section along these
lines:

o It is possible that as registry policies evolve, a small site
  may experience an increase in prefix length when renumbering,
  e.g. from /48 to /56. For this reason, the best practice is
  number subnets compactly rather than sparsely, and to
  use low-order bits as much as possible when numbering subnets.
  In other words, even if a /48 is allocated, act as though
  only a /56 is available. Clearly, this advice does not apply
  to large sites and enterprises that have an intrinsic need
  for a /48 prefix.

On 2006-07-19 17:37, Brian E Carpenter wrote:
...
2.4.2.  Address Space Conservation

   Despite the large IPv6 address space which enables easier subnetting,
   it still is important to ensure an efficient use of this resource.
   Some addressing schemes, while facilitating aggregation and
   management, could lead to significant numbers of addresses being
   unused.  Address conservation requirements are less stringent in IPv6
   but they should still be observed.

   The proposed HD [8] value for IPv6 is 0.94 compared to the current
   value of 0.96 for IPv4.  Note that for IPv6 HD is calculated for
   sites (i.e. on a basis of /48), instead of based on addresses like
   with IPv4.

Perhaps it would be wiser to make the parenthesis
     (e.g. on a basis of /48)

Thanks for adding the ISP case. Some comments...

5.2.1.2.  IPv6 addressing schema requirements from the ISP perspective
          of the Service Provider

   From ISP perspective the following basic requirements could be
   identified:
   o  The IPv6 address allocation schema must be able to realize a
      maximal aggregation of all IPv6 address delegations to customers
      into the /20 of the Service Provider.  Only this /20 will be
      routed and injected from the Service Provider into the global
      routing table (DFZ).  This strong aggregation keeps the routing
      tables of the DFZ small and eases filtering and access control
      very much.  (Note: A strong aggregation e.g. on POP or LER basis
      limits as well the numbers of customer routes that are visible
      within the ISP network.)

I'm quite concerned by this. Basically, why? Are we really expecting
ISPs to have so many customer sites that they can't simply flat-route
internally? Yes, that may be slightly less attractive for an MPLS
based ISP rather than for one using IP routing, but it has horrible
consequences because of the way it constrains address assignment.

5.2.1.3.  IPv6 addressing schema requirements from the Network Access
          provider perspective of the Service Provider

   As already done for the LIR and the ISP roles of the SP it is also
   necessary to identify requirements that come from its Network Access
   Provider role.  Some of the basic requirements are:
   o  The IPv6 addressing schema of the SP must be flexible enough to
      adapt changes that are injected from the customer side.  This
      covers changes that are based on the raising IPv6 address needs of
      the customer as well as changes that come from topological
      modifications (e.g. when the customer moves from one point of
      network attachment (POP) to another).

I don't understand "changes that are injected from the customer side."
Does this mean injected by a routing protocol? What sort of flexibility
do you mean? And when a customer changes POP, well, see my previous
comment. That should just be a routing change.

There was a little discussion following my comments, and I hoped for
a few clarifying sentences in the document.

    Brian