headers
Brian E Carpenter | 2 Apr 2007 10:14
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-nap-06.txt

James,

Thanks for your gracious comments. In turn, I'm sorry if my tone
was bit high. I've been living with this draft since 2004,
and it's hard to see it through other eyes.

    Brian

On 2007-03-29 19:25, james woodyatt wrote:
> On Mar 29, 2007, at 08:31, james woodyatt wrote:
>>
>> [...] I've had personal experience recently with exactly the sort of 
>> mistaken impression, which I mentioned in my first message, that I was 
>> concerned about.  That experience led me to take the very bold step of 
>> asking the authors to consider an editorial change to prevent what I 
>> thought were misunderstandings about the IETF consensus. [...]
> 
> I should explain that this experience was in the context of discussions 
> inside Apple about how best to respond to this:
> 
>     <http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1338>
> 
> Despite the referenced draft being informational, and despite the 
> caution in its introduction, and despite efforts to bring both these 
> facts to the attention of decision makers, the NAP draft has been 
> referenced as if it were an already published BCP.
> 
> I apologize again for not keeping up-to-date on the IETF consensus about 
> this issue.  When I last spent much time participating in IETF 
> discussions, this was the subject of a long-running and sometimes very
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ruri Hiromi | 3 Apr 2007 11:26
Favicon

ps & req in multi-prefix-env

Hello,

For WGLC, I would like to confirm the description about "multi- 
interface" issue.

In the documents(http://www1.tools.ietf.org/html/draft-ietf-v6ops- 
addr-select-req-01) at section4(3) and (4), we wrote about comments  
given at IETF67.

(1) should or must?
  In our original requirement, we thought multi-prefixes with single  
interface.  Now we inserted  the additional description about the  
problems(s) to be considered at the situation of multi-prefixes with  
multi-interfaces.  My question here is; which is better to declare  
"the multiple interface issue SHOULD be considered?" and "the  
multiple interface issue MUST be considered?"?   which phrase is  
suitable?

(2) how? any ideas? references?
  If you already have an idea to solve this, could you feed us details?

====
(current description)
3) Issues that need big RFC 3484 change.
     - Multiple Interfaces Issues

       Dave Thaler gave us comments that multiple-interface hosts may
       face policy collision and distribution of dst address selection
       policy and src address selection policy should be separated.
       Also, per-interface policy table was proposed.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mark Smith | 3 Apr 2007 14:50

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

* 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)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian E Carpenter | 3 Apr 2007 16:09
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

Some of my earlier comments haven't resulted in any text changes.
I'm not completely at ease about these points.

On 2006-06-13 09:25, Brian E Carpenter wrote:
...
>> 2.2.  Unique Local IPv6 Addresses
> ...
>>    Because a ULA and a global site prefix are both /48 length, an
>>    administrator can choose to use the same subnetting (and host
>>    addressing) plan for both prefixes.
> 
> The RIRs are moving away from a rigid /48 policy. It would be safer
> to start this sentence with "When" instead of "Because".
> And on the same topic...
> 
>> 2.4.  Network Level Design Considerations
> 
> I suggest adding a bullet at the end of this section along these
> lines:
> 
> o It is possible that as registry policies evolve, a small site
>   may experience an increase in prefix length when renumbering,
>   e.g. from /48 to /56. For this reason, the best practice is
>   number subnets compactly rather than sparsely, and to
>   use low-order bits as much as possible when numbering subnets.
>   In other words, even if a /48 is allocated, act as though
>   only a /56 is available. Clearly, this advice does not apply
>   to large sites and enterprises that have an intrinsic need
>   for a /48 prefix.
(Continue reading)

Permalink | Reply | 21 comments |
headers
Bonness, Olaf | 3 Apr 2007 18:32
Favicon

RE: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

Hi Brian,

Thank you very much for your remarks. I'll target in my answer only to your remarks regarding chapter 5
issues and leave the answers for the other points to my editor colleagues. Besides that I'll attach (parts
of) my email reply from 20th of July 2006 at the end of my email.

Section 5.2.1.2
Brian, if you compare the old section 5.2.1.2 from addcon_01 with the actualized section 5.2.1.2 from
addcon_v03 than you can observe several changes, we've injected based on our email discussion. 
For instance we've added the note within the third bullet point of 5.2.1.2 where it is stated that each
aggregation level brings down the efficiency of the addressing schema and that each ISP has to decide how
many levels of aggregation it wants to implement. For a better understanding I can extend this to a
statement where small ISPs may even implement a flat addressing architecture without any internal
aggregation level.
(But from my point of view the vast majority of ISPs will have to have at least one level of address
aggregation since it is no fun to have all the 100.000's / millions of customer routes inside your internal
routing tables. So flat routing will IMHO be the exception and not the rule.)

Section 5.2.1.3
Regarding your comments to section 5.2.1.3 we've modified the wording of (the first bullet point of) this
section and restructured chapter 5 of the ID by explicitely discussing "Changing Point of Network
Attachement" in section 5.2.3.4. Perhaps a pointer to this section in 5.2.1.3 would be helpful and I'll
insert it.

I hope that this will help to eliminate the obscurenesses you mentioned and will make the ID more readable.
Thanks again for your suggestions and best regards
	Olaf

====> Olaf Bonness wrote on 2006-07-20 <============================================
....
(Continue reading)

Permalink | Reply | 20 comments |
headers
John Spence | 3 Apr 2007 19:20
Favicon

RE: draft-ietf-v6ops-addcon WGLC


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.

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

> spence@...
Permalink | Reply | 0 comments |
headers
Fred Baker | 3 Apr 2007 20:44
Picon
Favicon

Re: ps & req in multi-prefix-env


On Apr 3, 2007, at 2:26 AM, Ruri Hiromi wrote:

> Hello,
>
> For WGLC, I would like to confirm the description about "multi- 
> interface" issue.
>
> In the documents(http://www1.tools.ietf.org/html/draft-ietf-v6ops- 
> addr-select-req-01) at section4(3) and (4), we wrote about comments  
> given at IETF67.
>
> (1) should or must?
>  In our original requirement, we thought multi-prefixes with single  
> interface.  Now we inserted  the additional description about the  
> problems(s) to be considered at the situation of multi-prefixes  
> with multi-interfaces.  My question here is; which is better to  
> declare "the multiple interface issue SHOULD be considered?" and  
> "the multiple interface issue MUST be considered?"?   which phrase  
> is suitable?

I'm a little uncomfortable with the distinction in this context. The  
way I use the terms, which dates from the development and editing of  
what we now call RFC 1812, "MUST" implies that something breaks if  
you don't do it, while "SHOULD" implies that there may be cases in  
which it is valid to not do the action - and the implementation that  
doesn't do the "should" is on the hook to make that case.

For example an IP router MUST apply a longest-match-first lookup to  
determine what route entry to use - if it doesn't, it will send
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bonness, Olaf | 4 Apr 2007 12:40
Favicon

RE: draft-ietf-v6ops-addcon WGLC

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Smith | 4 Apr 2007 13:25

Re: draft-ietf-v6ops-addcon WGLC

Hi Olaf,

On Wed, 4 Apr 2007 12:40:22 +0200
"Bonness, Olaf" <Olaf.Bonness@...> 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 :).
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian E Carpenter | 4 Apr 2007 13:48
Picon
Favicon

Re: I-D ACTION:draft-ietf-v6ops-addcon-03.txt

On 2007-04-03 18:32, Bonness, Olaf wrote:
> Hi Brian,
> 
> Thank you very much for your remarks. I'll target in my answer only to your remarks regarding chapter 5
issues and leave the answers for the other points to my editor colleagues. Besides that I'll attach (parts
of) my email reply from 20th of July 2006 at the end of my email.
> 
> Section 5.2.1.2
> Brian, if you compare the old section 5.2.1.2 from addcon_01 with the actualized section 5.2.1.2 from
addcon_v03 than you can observe several changes, we've injected based on our email discussion. 
> For instance we've added the note within the third bullet point of 5.2.1.2 where it is stated that each
aggregation level brings down the efficiency of the addressing schema and that each ISP has to decide how
many levels of aggregation it wants to implement. For a better understanding I can extend this to a
statement where small ISPs may even implement a flat addressing architecture without any internal
aggregation level.
> (But from my point of view the vast majority of ISPs will have to have at least one level of address
aggregation since it is no fun to have all the 100.000's / millions of customer routes inside your internal
routing tables. So flat routing will IMHO be the exception and not the rule.)

OK, somehow the diff I ran didn't make me look at that.
I agree it's better. I think it might be worth adding that since
IPv6 space is not as precious as IPv4 space, the tradeoff may
be different than it was for IPv4.

> 
> Section 5.2.1.3
> Regarding your comments to section 5.2.1.3 we've modified the wording of (the first bullet point of) this
section and restructured chapter 5 of the ID by explicitely discussing "Changing Point of Network
Attachement" in section 5.2.3.4. Perhaps a pointer to this section in 5.2.1.3 would be helpful and I'll
insert it.
(Continue reading)

Permalink | Reply | 19 comments |

Gmane