RE: draft-ietf-v6ops-addcon WGLC

["Bonness, Olaf" <Olaf.Bonness@t-systems.com>]

Hi Mark,

tnx a lot for taking the time, reading and commenting the addcon I-D. I'll try to provide some answers to your statements regarding chapter 5.2. "ISP case study".

5.2.2.1.2:
We got already a note from Marla in this direction stating that a 300% growing buffer would be to large. Thats why we've already changed this section to a 100-300% growing range (i.e. /47 or /46). At the end of section 5.2.2.1.2 it is stated:
  "If the actual observed growing rates show that the reserved growing
   zones are not needed than these growing areas can be freed and used
   for assignments for prefix pools to other devices at the same level
   of the network hierarchy."
This means that there will be no waste of address range if the growing buffer is not needed by the customer.
But I find your idea very good to reserve growing buffer only in the case that there is a likelihood that this buffer will be needed and I will add the following note after the 3rd sentence of section 5.2.2.1.2:
  "Note: If it is obvious that the likelyhood of needing a /47 or /46 
   in the future is very small for a "common" customer, than no growing
   buffer should be reserved for it and only a /48 will be assigned
   without any growing buffer."
Tnx for your hint :).

5.2.3.3: and 5.2.3.4
I'll try to explain what I meant here. Assuming the custumer has the /48 prefix 2001:db8:1::/48 and is attached (dual-homed) to LER A and LER B. Than both LERs have a route to 2001:db8:1::/48 in their BGP (I will change the IGP in the ID to BGP - tnx) routing tables and will hence need a label for that prefix. This (inner) label will be propagated with the prefix via BGP to all the other LERs.
If the other LERs receive a packet for network 2001:db8:1::/48 they will decide which BGP next hop to chose (LER A or LER B), will push the corresponding inner label (6PE label) and will than push the transport label for the choosen LER.

In this direction you are right. The number of (outer) transport labels that a LER needs will only change when new LERs are attached to the network. But the number of inner (6PE) labels changes with the number of (customer) routes a LER propagates. Thats why for dual-homing there will be needed 2 inner labels for one IPv6 prefix.

Regarding a change of the POP LER A -> LER B. In this case it happens that in the new point of network attachement (LER B) a new/additional (inner) label for the IPv6 prefix has to be assigned, also in the case that this IPv6 prefix 2001:db8:1::/8 was originaly aggregated e.g. in 2001:db8::/38 of the old POP / LER A.

Hope this helps little bit to illustrate the thoughts of the ID.
Do you find that there has to be some text added to 5.2.3.3 and 5.2.3.4 in order to make it more readable?

Thank you very much for your hints and your feedback and best regards
	Olaf



-----Original Message-----
From: Mark Smith [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] 
Sent: Tuesday, April 03, 2007 2:50 PM
To: Fred Baker
Cc: v6ops@ops.ietf.org; kurtis@kurtis.pp.se; rbonica@juniper.net
Subject: Re: draft-ietf-v6ops-addcon WGLC

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.