[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-addcon WGLC
Hi Olaf,
On Wed, 4 Apr 2007 12:40:22 +0200
"Bonness, Olaf" <Olaf.Bonness@t-systems.com> 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:
> 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 :).
>
I'm sure that will do the trick.
> 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.
>
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 :-) )
> 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?
>
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
> Olaf
>
>
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.
>
> -----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.
>