Re: draft-ietf-v6ops-addcon WGLC

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

Hi Mark,

Thx for your reply. Just a few remarks inline. 

> -----Original Message-----
> From: Mark Smith 
> [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] 
> Sent: Wednesday, April 04, 2007 1:26 PM
> To: Bonneß, Olaf
> Cc: v6ops@ops.ietf.org; kurtis@kurtis.pp.se; 
> rbonica@juniper.net; fred@cisco.com
> Subject: Re: draft-ietf-v6ops-addcon WGLC
>
> ...
> 
> 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 :).
> > 
> 
> I'm sure that will do the trick.

Great :)

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

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.

> 
> * 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 :-) )

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.)

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?

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

Tnx again and best regards
	Olaf