[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-v6ops-v6inixp-04.txt WGLC



Hi Mark,

This text when to several revision, I like the text you are proposing.

Roque


On Jan 18, 2010, at 11:00 PM, Mark Smith wrote:

> Hi,
> 
> On Mon, 18 Jan 2010 08:00:11 -0800
> Fred Baker <fred@cisco.com> wrote:
> 
>> This is to initiate a two week working group last call of draft-ietf- 
>> v6ops-v6inixp-04.txt. 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.
>> 
> 
> I think this text needs to be changed in Section 3, Addressing Plan.
> 
> "IXPs will normally use manual address configuration.  Address prefix
>   between /64 and /127 are technically feasible [RFC4291]."
> 
> RFC4291 says 
> 
> " For all unicast addresses, except those that start with the binary
>   value 000, Interface IDs are required to be 64 bits long and to be
>   constructed in Modified EUI-64 format."
> 
> If people wish to use longer than /64s, that is up to them. However I
> think that the text in this draft implies, by referring to RFC4291 the
> way it does, that this is supported in the IPv6 Addressing Archtecture.
> I'd suggest something like the following:
> 
> "IXPs will normally use manual address configuration. The IPv6
> ADdressing Architecture [RFC4291] requires that interface identifiers
> are 64 bits in size for prefixes starting with binary 000, resulting in
> a maximum prefix length of /64. Longer prefix lengths up to /127 have
> been used operationally. If prefix lengths longer than 64 bits are
> chosen, the implications described in [RFC3627] need to be considered."
> 
> 
>> 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 a good document. Anything that helps people avoid
> duplicating the effort of working out how to deploy IPv6 is important.