[addr-select-dt] Fwd: updates from address selection design team

Arifumi Matsumoto <arifumi@nttv6.net> Fri, 16 July 2010 11:58 UTC

References: <7D78D21D-C0CF-4BCC-9B2C-ECC40976DE48@nttv6.net>
From: Arifumi Matsumoto <arifumi@nttv6.net>
Content-Type: text/plain; charset="us-ascii"
Message-Id: <C7CDB575-04F2-47F1-915F-77EA311EB480@nttv6.net>
Date: Fri, 16 Jul 2010 20:58:45 +0900
To: addr-select-dt@ietf.org
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: [addr-select-dt] Fwd: updates from address selection design team
Precedence: list

DT members,

I just sent the following e-mail to the 6man ML to start the
discussion about the big picture.
Please correct me either this list or the public list, if I'm wrong.

I want to continue discussion within this ML regarding every aspects
of our work, while seeking consensus about the big picture at 6man ML.

Best regards,

Begin forwarded message:
> 
> All,
> 
> I'm writing this e-mail representing the address selection design team.
> 
> We've worked and discussed much within the design team, and are
> about to make important choices to move forward.
> 
> Our main draft revised this week covers whole issues, so I'd like
> you to review it.
> draft-ietf-6man-addr-select-considerations-02.txt
> 
> I extracted the main changes and the choices below.
> 
> - separating policy merging issue from protocol work.
> 
> The biggest design choice is separation of policy merging
> issue from the policy updating protocol.
> 
> As we know it, policy table make sense as a whole.
> This is mainly because the precedence value is absolute.
> Thus, policy table merging always involve conflict.
> 
> We can merge policies by a heuristic approach.
> But, there is no distinct/established algorithm for merging.
> 
> So, we the design team thought we need experiences and time
> for merging process standardization, and we should move the base
> policy distribution work forward to meet the urgent needs from the
> field, while standardizing the merging algorithm as a experimental
> or informational RFC.
> 
> 
> - RFC 3484 default rule update
> 
>  Though, we the design team is not chartered for revising of
>  RFC 3484, this issue is closely related to our work of policy
>  updating.
> 
>  While analyzing the problem cases, we thought some of them 
>  should be solved by revising the default address selection rules
>  themselves.
> 
>  So the design team also discussed about the revision of RFC 3484.
>  The output was included in the existing revision proposal that
>  I had put together.  
>  draft-arifumi-6man-rfc3484-revise-03.txt
> 
> 
> We definitely need input from 6man people to move forward.
> 
>

[addr-select-dt] Fwd: updates from address select… Arifumi Matsumoto