Re: RE:

no, it doesn't, for two reasons.

First, in a best effort network, it is invalid to presume that order  
will be preserved in the network.

Second, changing the identifier field in IPv4 from 16 bits to 10 and  
using the remaining bits to indicate something else is a change to  
the identifier field in IPv4. RFC 791 and RFC 1122 merely specify  
that the identifiers should be locally unique within a field of time,  
not that they have certain characteristics from which other  
functionality may be deduced.

I really not trying to be a pain here, but you really need to take  
this to a working group that does protocols, and specifically in this  
case, does changes to IPv4. v6ops can develop requirements for such a  
protocol if you like, but the protocol work needs to be done  
somewhere appropriate to the protocol.

On Aug 31, 2005, at 3:29 PM, Templin, Fred L wrote:

> Fred,
>
> What I suggested in my previous message was more dramatic
> (and complicated) than what is really needed. If the tunnel
> encapsulator simply defines for itself a coding for the
> 16-bit IPv4 Identification field such as the following:
>
>     0                   1
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposed Resolution of Issues [1-37]

The issue list available on http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm has
been updated and addresses the remainder of the issues from the WGLC.

The Consensus answers in marked in blue are the onces that were proposed
last week and have been considered as stable consensus. The proposed resolution
entries marked in red are the onces added today.

Groetjes,
G/

[draft-ietf-v6ops-nap-01.txt] Proposed Resolution of Issues [1-37]

The issue list available on http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm has
been updated and addresses the remainder of the issues from the WGLC.

The Consensus answers in marked in blue are the onces that were proposed
last week and have been considered as stable consensus. The proposed resolution
entries marked in red are the onces added today.

Groetjes,
G/ 

Re: I-D ACTION:draft-huston-hd-metric-01.txt

On Wed, Aug 31, 2005 at 03:50:01PM -0400, Internet-Drafts@... wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 	Title		: Considerations on the IPv6 Host density Metric
> 	Author(s)	: G. Huston
> 	Filename	: draft-huston-hd-metric-01.txt
> 	Pages		: 18
> 	Date		: 2005-8-31
> 	
> This memo provides an analysis of the Host Density metric as
>    currently used to guide registry allocations of IPv6 unicast address
>    blocks.  This document contrasts the address efficiency as currently
>    adopted in the allocation of IPv4 network addresses and that used by
>    the IPv6 protocol.  It is noted that for large allocations there are
>    very significant variations in the target efficiency metric between
>    the two approaches.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-huston-hd-metric-01.txt

A couple of observations.

I note from RFC3194 that it says "The examples suggest an HD-ratio value
on the order of 85% and above correspond to a high pain level, at which
operators are ready to make drastic decisions" and that "...this suggests
that values of 80% or less corresponds to comfortable trade-offs between
pain and efficiency."

So the argument here is that very large networks don't share the same
HD ratio property?  I think it would be nice to state the crux of the 'case'
of this draft in the intro section.

Re: I-D ACTION:draft-huston-hd-metric-01.txt

Are you of the opinion that we should take this, and perhaps Thomas'  
draft, up as a v6ops draft?

(I would question whether free advice on address allocation policy is  
actually an IPv6 WG topic as much as an operational topic anyway, and  
certainly comments on the HD ratio is an operational topic)

On Sep 1, 2005, at 8:39 AM, Tim Chown wrote:
> On Wed, Aug 31, 2005 at 03:50:01PM -0400, Internet-Drafts@...  
> wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>>     Title        : Considerations on the IPv6 Host density Metric
>>     Author(s)    : G. Huston
>>     Filename    : draft-huston-hd-metric-01.txt
>>     Pages        : 18
>>     Date        : 2005-8-31
>>
>> This memo provides an analysis of the Host Density metric as
>>    currently used to guide registry allocations of IPv6 unicast  
>> address
>>    blocks.  This document contrasts the address efficiency as  
>> currently
>>    adopted in the allocation of IPv4 network addresses and that  
>> used by
>>    the IPv6 protocol.  It is noted that for large allocations  
>> there are
>>    very significant variations in the target efficiency metric  
>> between

Re: I-D ACTION:draft-huston-hd-metric-01.txt

Hi Fred,

These sem to be very operational issues to me.  I think both are views
of the same overall issue, i.e. evolving the 'big picture' for BCP in
IPv6 address allocation and management.   Thomas cites the HD ratio
in his draft, for example, but not Geoff's draft (I think!).

I think an interesting bit of RFC3177 is the reasoning for a fixed /48
boundary in section 3.  Issues like multihoming and site-locals that
are discussed, but I don't think Thomas picks those up.  3177 talks of 
leaving the option to retrofit an 8+8 multihoming model, but I think 
we're now heading a different way with shim6.  3177 also talks about 
site locals, which would lead to the implication that we'll need to
modify ULAs to be /56 friendly if Thomas' suggestions are adopted.

Tim

On Thu, Sep 01, 2005 at 11:21:05AM -0700, Fred Baker wrote:
> Are you of the opinion that we should take this, and perhaps Thomas'  
> draft, up as a v6ops draft?
> 
> (I would question whether free advice on address allocation policy is  
> actually an IPv6 WG topic as much as an operational topic anyway, and  
> certainly comments on the HD ratio is an operational topic)
> 
> On Sep 1, 2005, at 8:39 AM, Tim Chown wrote:
> >On Wed, Aug 31, 2005 at 03:50:01PM -0400, Internet-Drafts@...  
> >wrote:
> >
> >>A New Internet-Draft is available from the on-line Internet-Drafts  

Re: Proposed Resolution of Issues [1-37]

On Thu, Sep 01, 2005 at 12:45:29PM +0200, Gunter Van de Velde (gvandeve) wrote:
> The issue list available on http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm 
> has
> been updated and addresses the remainder of the issues from the WGLC.
> 
> The Consensus answers in marked in blue are the onces that were proposed
> last week and have been considered as stable consensus. The proposed 
> resolution
> entries marked in red are the onces added today.

Looks good.

For issue 5, RFC3041 might hamper that.

On Issue 9, I suspect Kurtis has good figures on this, I recall he did 
back before multi6 reformed and we had multihoming discussions in Michel's
list.  

Issue 10, because admins pick 10.0.0.0/24 or 192.168.0.0/24.  I'll wager
they do the same with ULAs still, but hey :)

Issue 12 ULAs dont aggregate internally either, as each /48 is in effect
a random prefix.  May bug big organisations, who thus may not use 'proper'
ULAs?

Issue 14 - as Stig pointed out, if two remote sites use ULAs they may
prfer to use ULAs between them.   But that could be configured as 3484
policy too.   The key thing is that ULAs now have global scope, so are
by default treated as globals.

Re: Proposed Resolution of Issues [1-37]

On Sep 2, 2005, at 1:33 AM, Tim Chown wrote:
> Issues 32&33:  ULAs *may* help renumbering, not *will*.  There is  
> baggage
> with ULAs and as such their use is a tradeoff not a given, I feel.

I very much agree. I had the same debate with Pekka and Thomas when  
the renumbering procedure draft went in. Thomas filed a 'discuss'  
requiring me to say that ULAs would simplify renumbering, but without  
saying how. I told them:

On Jan 15, 2005, at 5:46 PM, Fred Baker wrote:
> Listen. If ULAs simplify the procedure of renumbering a network  
> without a flag day, then there should be several places in the  
> document where a few sentences of the following form can be added.
>
>   "if the old prefix..." or "if the new prefix..."
>   "is a ULA prefix then"
>   "...this step may be skipped" or "...this step may be simplified  
> <in this way>"
>   "and it still allows you to renumber a network without a flag day  
> for <this> reason."
>
> Present me with those sentences, and I will include them.

On Jan 15, 2005, at 9:34 AM, Fred Baker wrote:
>> This said, I think it's still good idea to _mention_ ULAs, but  
>> treat them with sufficient skepticism at this point.  The text you  
>> proposed, and which I modified, and suggested in the previous  
>> message:
>>

Re: Proposed Resolution of Issues [1-37]

On Fri, Sep 02, 2005 at 02:18:00PM -0700, Fred Baker wrote:
> 
> And by the way, if ULAs are global, they are global addresses... What  
> does the "L" stand for?

I've been wondering that too ;)

--

-- 
Tim/::1

Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt

Tim Chown wrote:

On Thu, Aug 18, 2005 at 02:54:16PM +0200, Rémi Després wrote:

Please don't hesitate to ask for more clarifications. I am aware they are needed, and it helps making progress.

The stumbling block to me digging deeply into your work is the terminology used. It's not using conventional language and terms.

I was trying to use new terminology only where it seemed useful.
But for the next step I will try to do better.
(In the mean time, if you could sindicate a few terms in particular I should replace, that would be helpful.)

Thanks,
Rémi
+33 6 72 74 94 88

PS: this answer comes late because I happen to have been on vacation not far from your university.
With my wife, we visited southern England, in particular Winchester, Salisbury, Sonehenge, Stourhead Garden, Wilton House etc.
It was a very pleasant experience .