Re: [v6ops] new draft: draft-sun-v6ops-semantic-usecase

On 2/18/13 11:50 PM, Owen DeLong wrote:
> On Feb 18, 2013, at 11:41 PM, joel jaeggli <joelja@bogus.com> wrote:
>
>> On 2/18/13 6:44 AM, Qiong wrote:
>>> Hi Joel,
>>>
>>> Thanks for your comments.
>>>
>>> I agree with you semantic prefix will have limitations in real world deployment. We will improve the limitation part and clearly clarify the scope for which operators should take in the next version.
>>>
>> I particular  I think it would be particularly undesirable but from a policy and address assignment perspective if providers were to up the size of their assignment requests using a justification of more semantic bits required. Where does that thought experiment end?
> I don't think the RIR communities are likely to go along with that in terms of adopting it into policy.
nor should they.
> Owen
>
>>> In designing the use case, we do need to carefully consider the tradeoff between the benefits and complexity. That's the current use case is relatively easy to deploy and have little impact on the current infrastructure. But of course, it will be evolved to reflect more requirements and feedback from the working group.
>>>
>>> Thanks !
>>>
>>> Best wishes
>>> Qiong
>>>
>>>
>>> On Mon, Feb 18, 2013 at 8:23 AM, joel jaeggli <joelja@bogus.com <mailto:joelja@bogus.com>> wrote:
>>>
>>>     On 2/17/13 5:45 AM, fred@cisco.com <mailto:fred@cisco.com> wrote:
>>>
>>>         A new draft has been posted, at
>>>         http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase.
>>>         Please take a look at it and comment.
>>>
>>>     I have some serious qualms about specifying something that that
>>>     you absolutely do not want to honor outside your own domain of
>>>     control. While this isn't too proscriptive both documents together
>>>     are headed in that direction.
>>>
>>>     As with draft-jiang-semantic-prefix the notion that host stacks
>>>     might be modified to treat particular masks of bits differently
>>>     within applications is an especially expensive form of application
>>>     network aware-signaling, flies completely in the face of the
>>>     uniform utility of ipv6 unicast  addressing.
>>>
>>>     Generically, the utility for an operator of ascribing meaning to a
>>>     particular bit mask outside of the host mask is relatively
>>>     straight forward and consistent with all sorts of addressing plans
>>>     (I can for example trivially identify all the router loopback(s)
>>>     in my network due the the addressing scheme, likewise internal
>>>     site versus external site assignments and so on within given /48
>>>     site assignement(s).
>>>
>>>     I think both of these drafts can be made useful but there are
>>>     limits clearly to the scope in which they can be applied.
>>>
>>>     thanks
>>>     joel
>>>
>>>         _______________________________________________ v6ops mailing
>>>         list v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>         https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>>     _______________________________________________
>>>     v6ops mailing list
>>>     v6ops@ietf.org <mailto:v6ops@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>>>
>>>
>>> -- 
>>> ==============================================
>>> Qiong Sun
>>> China Telecom Beijing Research Institude
>>>
>>>
>>> Open source code:
>>> lightweight 4over6: /http://sourceforge.net/projects/laft6//
>>> PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ /
>>> ===============================================
>>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>