Re: draft-ietf-v6ops-addcon WGLC

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

Hi,

Some feedback on this (good) draft.

On Sat, 24 Mar 2007 22:37:16 +0100
Fred Baker <fred@cisco.com> wrote:

> This is to initiate a two week working group last call of draft-ietf- 
> v6ops-addcon. Please read it now. If you find nits (spelling errors,  
> minor suggested wording changes, etc), comment to the authors; if you  
> find greater issues, such as disagreeing with a statement or finding  
> additional issues that need to be addressed, please post your  
> comments to the list.
> 

* 5.2.2.1.2.  'Common' customers

I'm a believer in all common customers receiving /48s, including home
users, however, it seems to me that by default reserving a /47 or /46
growth for all common customers seems a bit excessive. I'd suggest not
recommending a /47 or /46 for each /48 reservation as a default, and
instead having some text that suggests that either a pool be allocated
for /48s that might need to be expanded, or at least suggest that for
each /48 allocated, a consideration is made at that time as to the
likelyhood of needing a /47 or /46 in the future, and if it is likely,
then reserving the parent /47 or /46.

(At the smaller SP I work for, I can't ever see any of our customers
needing more than a /48, yet if we reserved /47s or /46s for all /48s
we'd allocate, we'd chew up a lot of address space needlessly)

* 5.2.3.3.  POP Multi-homing

I'm a bit confused as to what is being described here :

   "The second solution has the disadvantage that in every LER where the
   customer is attached this prefix will appear inside the IGP routing
   table requiring an explicit MPLS label."

I've understood that with an MPLS/BGP network, pretty much all the
prefixes, excepting BGP NEXT_HOP loopback /32s (v4) or /128s, are
carried within BGP, meaning that there would only be a single MPLS LSP,
and therefore an unchanging number of labels towards the announcing
LER, regardless of the prefixes originating at it.

I've understood that to move a prefix, you'd configure it
on a different LER, it would then be pushed into BGP, and delivered to
the other LERs by the BGP infrastructure. Each of those would then
assign that prefix to the LSP that each of the remote LERs already have
towards the prefix originating LER. IOW, there'd only be new prefixes
added into the IGP, and new MPLS LSPs, when new LERs are added to the
network.

While moving a prefix might announce a more specific route into BGP, if
BGP prefix aggregation was being used, I'm not sure I see why a prefix
would be injected into an IGP in this style of SP MPLS network. Have I
misunderstood this text (or maybe misunderstood an SP BGP/MPLS
architecture) ?

* 5.2.3.4.  Changing Point of Network Attachement

Same as previous.

That is it I think.

> We are looking specifically for comments on the importance of the  
> document as well as its content. If you have read the document and  
> believe it to be of operational utility, that is also an important  
> comment to make.
> 

I think this document is important. I don't remember coming across any
thorough IPv4 addressing considerations and example documents when I
was learning that, so it would be good to have an IPv6 addressing
considerations document, with both Enterprise and SP network examples,
available early in IPv6's deployment. I'd like to see it published as
an RFC for that reason.

Regards,
Mark.