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

From: <[email-masked]>
Date: Sun, 17 Feb 2013 05:45:00 -0800 (PST)

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.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 17 Feb 2013 16:23:00 -0800

On 2/17/13 5:45 AM, [email-masked] 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 18 Feb 2013 09:27:44 +0000

Thanks Joel for your comments and support. Some replies in lines.

>From: joel jaeggli [mailto:[email-masked]]

We fully agree the assigned semantic for prefix should be only meaningful locally. In some use case, these semantic may also be useful information outside the domain. Do you think the leak of semantic information may cause secure issues? If so, we can add some consideration in the security section.

>aware-signaling, flies completely in the face of the uniform utility of

The application-aware is an extend use case. Yes, it is expensive and it is technical gap to make good use of it from the current network and user devices. The basic use case is only embedded user semantic, which is cheap and may be supported by current networks. This purpose informational framework document is only describe the concept framework and its possibilities.

>assignments and so on within given /48 site assignement(s).

There are many benefits for operator to do this. Actually, some operation may already apply such notion in their addressing plans one way or another.

>clearly to the scope in which they can be applied.

Fully agree. Actually it is one of the purpose of framework document to list and document these limitations and technical gaps.

Best regards,

Sheng

---

From: Qiong <[email-masked]>
Date: Mon, 18 Feb 2013 22:07:58 +0800

Dear Fred,

Thanks for invoking it.

This draft is a companion draft of I-D.jiang-v6ops-semantic-prefix. It
provides a use case and some guidelines from operator's point of view.
Semantic prefix can be quite useful in terms of user/device management,
high-priority service guarantee, etc. However, since some limitations and
implementation complexity still exist, careful considerations should be
taken into designing it.

Your comments/feedback are very much appreciated. Thanks in advance :)

From: internet-drafts
Date: 2013-02-17 15:52
To: sunqiong
CC: xiechf; jiangsheng
Subject: New Version Notification for
draft-sun-v6ops-semantic-usecase-00.txt

A new version of I-D, draft-sun-v6ops-semantic-usecase-00.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Filename:  draft-sun-v6ops-semantic-usecase
Revision:  00
Title:  Use case of IPv6 prefix semantics for operators
Creation date:  2013-02-17
Group:  Individual Submission
Number of pages: 11
URL:
http://www.ietf.org/internet-drafts/draft-sun-v6ops-semantic-usecase-00.txt
Status: http://datatracker.ietf.org/doc/draft-sun-v6ops-semantic-usecase
Htmlized: http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase-00

Abstract:
   Embedding certain semantics into IPv6 addresses will bring a lot of
   benifits for operators to simplify network management and apply
   operations accordingly[I-D.jiang-semantic-prefix].  This memo
   illustrates the use case of semantic bits from operator's point of
   view, and provides considerations on how to design the semantic bits
   in IPv6 address.

The IETF Secretariat

On Sun, Feb 17, 2013 at 9:45 PM, <[email-masked]> wrote:

> http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase. Please take
> a look at it and comment.
> [email-masked]
> 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/ *
===============================================

---

From: Qiong <[email-masked]>
Date: Mon, 18 Feb 2013 22:44:28 +0800

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.

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 <[email-masked]> wrote:

>> A new draft has been posted, at http://tools.ietf.org/html/**
>> draft-sun-v6ops-semantic-**usecase<http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase>.
>> Please take a look at it and comment.
>>
> 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.
>
> 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.
>
> 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).
>
>  ______________________________**_________________ v6ops mailing list
>> [email-masked] https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>>
>
> ______________________________**_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>

Open source code:

---

From: joel jaeggli <[email-masked]>
Date: Mon, 18 Feb 2013 23:41:28 -0800

On 2/18/13 6:44 AM, Qiong wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 2/17/13 5:45 AM, [email-masked] <mailto:[email-masked]> wrote:
>
>         http://tools.ietf.org/html/draft-sun-v6ops-semantic-usecase.
>     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.
>
>     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 [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> lightweight 4over6: /http://sourceforge.net/projects/laft6//
> PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ /

---

From: Owen DeLong <[email-masked]>
Date: Mon, 18 Feb 2013 23:50:04 -0800

On Feb 18, 2013, at 11:41 PM, joel jaeggli <[email-masked]> wrote:

>> 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.

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 <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: joel jaeggli <[email-masked]>
Date: Tue, 19 Feb 2013 07:02:55 -0800

> I don't think the RIR communities are likely to go along with that in terms of adopting it into policy.
nor should they.

---

From: Qiong <[email-masked]>
Date: Wed, 20 Feb 2013 17:59:17 +0800

Hi Joel,

Please see inline :)

On Tue, Feb 19, 2013 at 3:41 PM, joel jaeggli <[email-masked]> wrote:

> 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?
>
[Qiong] Sorry I do not quite understand your meaning. Do you mean operators
may ask more semantic bits from address assignment community ? Our major
purpose is to decide how to design the IPv6 prefix when the operator has
already get the IPv6 address pool. It is mainly used within a local region.
Would you please explain a bit more ?

Thanks in advance!

Best wishes
Qiong