4 Apr 2007 12:40
RE: draft-ietf-v6ops-addcon WGLC
Bonness, Olaf <Olaf.Bonness@...>
2007-04-04 10:40:22 GMT
2007-04-04 10:40:22 GMT
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". 184.108.40.206.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 220.127.116.11.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 18.104.22.168.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 :). 22.214.171.124: and 126.96.36.199 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 188.8.131.52 and 184.108.40.206 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@...] Sent: Tuesday, April 03, 2007 2:50 PM To: Fred Baker Cc: v6ops@...; kurtis@...; rbonica@... 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@...> 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. > * 220.127.116.11.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) * 18.104.22.168. 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) ? * 22.214.171.124. 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.