Subject: Re: draft-ietf-v6ops-addcon WGLC

From: Mark Smith <[email-masked]>
Date: Tue, 3 Apr 2007 22:20:10 +0930

Hi,

Some feedback on this (good) draft.

On Sat, 24 Mar 2007 22:37:16 +0100
Fred Baker <[email-masked]> 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.

---

From: "John Spence" <[email-masked]>
Date: Tue, 3 Apr 2007 13:20:37 -0400

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.

> Overall, the document has had good discussion, and covers an
appropriate 
> scope.  I think it is complete.

> I think it is ready to go, and provides excellent insight to IPv6 
> deployment teams - especially where they prepare for their first 
> deployment without the deep skills of someone involved with IPv6 over
the > years.

> [email-masked]

---

From: "Bonness, Olaf" <[email-masked]>
Date: Wed, 4 Apr 2007 12:40:22 +0200

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:[email-masked]] 
Sent: Tuesday, April 03, 2007 2:50 PM
To: Fred Baker
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: draft-ietf-v6ops-addcon WGLC

Hi,

Same as previous.

That is it I think.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 4 Apr 2007 20:55:35 +0930

Hi Olaf,

On Wed, 4 Apr 2007 12:40:22 +0200
"Bonness, Olaf" <[email-masked]> wrote:

> Hi Mark,
> 
> tnx a lot for taking the time, reading and commenting the addcon I-D.

My pleasure.

> I'll try to provide some answers to your statements regarding chapter 5.2. "ISP case study".
> 
> 5.2.2.1.2:

I'm sure that will do the trick.

> 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 wit…

That makes complete sense now - I'd forgotten this was a 6PE
environment. Following on from me being an example of somebody
forgetting this while reading the document, maybe it could be worth
mentioning a couple of clarifying points, if they're valid :

* If the SP moves to "native" IPv6 over MPLS support, when it becomes
available, the additional label consumption issue disappears.

* I understand (and I'm getting to the boundary of my MPLS
understanding) that allocating labels to 6PE (or VPNv4) prefixes on the
PE is to allow penultimate-hop popping of the outer label to occur at
the upstream LSR. If PHP can be switched off, then I'd think the label
consumption problem also goes away, at the cost of a double label pop
and an IPv6 lookup at the PE (although now I'm wondering if two labels
are necessary at all if the LER/PE is going to perform an IPv6 lookup
anyway - I don't think so, but I'll have to go back to my books on this
topic I think to refresh my memory and understanding :-) )

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

As above, if useful - it's probably getting a bit nit-picky I'll admit
for the broader intention and scope of this document though.

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

No worries. I'll be glad to have a document around like this to be able
to reference and point other people towards when planning IPv6 addressing.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Apr 2007 09:47:48 +0930

Hi Olaf,

On Thu, 5 Apr 2007 09:26:37 +0200
"Bonness, Olaf" <[email-masked]> wrote:

> Hi Mark,
> 
> Thx for your reply. Just a few remarks inline. 
> 
> > From: Mark Smith 
> > [mailto:[email-masked]] 
> > Sent: Wednesday, April 04, 2007 1:26 PM
> > To: Bonneß, Olaf
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
<snip>

> 
> Thats completely right, but I don't know if we should detail this within this ID since the use case scenario speaks explicitely about a 6PE provider.
> 

Agree.

> IMO MPLS Label stacking is not only because of PHP, since for instance in the VPN case the inner label is used to identify the correct VPN (VRF) where the packet should be delivered to at the egress PE.
> (Yes you are theoretically right - you could distribute for each VPN between ingress and egress PE a dedicated / unique label and could send your packet with only this transport MPLS label [assuming that you don't use PHP], but this approach would not scale since you would have to do a complete LSP setup within your provider core [{including all P routers] when a new VPN is attached in your PE and you would have (at least) N parallel LSPs between ingress and egress PE. Thats why the label stacking is a very flexible and efficient way to keep away topological changes in the customer area from your core network.)
> 

Thanks for the clarification, it's clearer now.

> But again IMO this does not directly relate to an IPv6 addressing schema of an ISP and I woul like to keep this discussion out of the addcon ID. Would this be ok to you, Mark?
> 

Also agree.

Regards,
Mark.