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

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 experiemnt end?
> 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/ /
> ===============================================
>