Why would you expect this to always unconditionally use "secure tunnels" ?
For lot's of applications basic encapsulation is sufficient. Note that I
mentioned the case where my sites are connected over ISP not the Internet.
Besides if there is concern about data protection or data integrity lot's
of applications use app level encryption so asking for transport tunnel
security would be redundant at best.
Thx,
R.
On Fri, Jul 14, 2023 at 5:42 PM Joel Halpern <j...@joelhalpern.com> wrote:
> If they want to specify in the draft that the CPE are operator managed by
> a single operator, and that they use secure tunnels (not just arbitrary
> overlay) between the BRAS then we can as a WG see if that suffices. But
> the draft doesn't currently say that.
>
> Yours,
>
> Joel
> On 7/14/2023 11:40 AM, Robert Raszuk wrote:
>
> Joel,
>
> Limited domain (if you will) can be also build in the overlay - unless you
> point me to any standards track RFC which says otherwise. If I connect over
> ISP with v6 I can run my own limited domain over such ISP between hosts in
> my sites.
>
> Of course ISP may recognize that I am actually sending v6 packets with
> extension headers and drop those ... but this is not a concern for this
> thread nor for IETF. In such a case I will would switch an ISP :)
>
> Cheers,
> R.
>
>
>
>
>
> On Fri, Jul 14, 2023 at 5:33 PM Joel Halpern <j...@joelhalpern.com> wrote:
>
>> Nope.
>>
>> The host case for SRv6 is for hosts run by the operator within their
>> domain. 8986 explicitly requires that SRv6 be used only within a limited
>> domain.
>>
>> It is clear from other comments that you do not like this restriction.
>> That is your priviledge as an individual. But IETF work has to respect the
>> restriction.
>>
>> Yours,
>>
>> Joel
>> On 7/14/2023 11:28 AM, Robert Raszuk wrote:
>>
>> Joel,
>>
>> *Point 1: *
>>
>> Reading RFC8986 I see in section 4.16.2 clear definition of SRv6 running
>> on user hosts.
>>
>> *One of the applications of the USP flavor is when a packet with an SRH
>> is destined to an *
>> *application on hosts with smartNICs ("Smart Network Interface Cards")
>> implementing *
>> *SRv6. The USP flavor is used to remove the consumed SRH from the
>> extension header *
>>
>> *chain before sending the packet to the host. *
>> *Point 2: *
>>
>> If two hosts want for whatever reason to use SRv6 over the provider's
>> IPv6 underlay (and they may possibly benefit from DHCP allocation of
>> locators) they can happily do so and I see nowhere in any SRv6 spec any
>> mandate which would state a word against such deployment model.
>>
>> Thx,
>> Robert
>>
>> PS, This entire notion of "limited domain" is as you very well know
>> the history is not a very technical thing ...
>>
>>
>> On Fri, Jul 14, 2023 at 5:08 PM Joel Halpern <j...@joelhalpern.com> wrote:
>>
>>> Speaking as an individual participant, it seems to me that the
>>> description of using CPE as SRv6 endpoints needs to state explicitly and
>>> clearly that this assumes that the CPE are managed by the access operator,
>>> and that all of the relevant endpoints are part of a single operator /
>>> domain. Otherwise, this usage violates the base rules for SRv6.
>>>
>>> Personally, I would like to see this fixed before adoption completes.
>>>
>>> Yours,
>>>
>>> Joel
>>> On 7/14/2023 9:44 AM, Joel Halpern wrote:
>>>
>>> I probably need to re-read the draft. Does the draft assume the CPE is
>>> part of the operator domain? Remember that SRv6 MUST be used ONLY within a
>>> limited domain?
>>>
>>> Yours,
>>>
>>> Joel
>>> On 7/14/2023 2:22 AM, Weiqiang Cheng wrote:
>>>
>>> Hi Aijun,
>>> Thank you very much for your comments.
>>> We will add some text to describe that the CPE utilizes locators
>>> obtained through DHCP to provide differentiated services.
>>>
>>> Best Regards
>>> Weiqiang Cheng
>>>
>>>
>>> *发件人：* Aijun Wang <wangai...@tsinghua.org.cn>
>>> *发送时间：* 2023-07-14 11:19
>>> *收件人：* 'Alvaro Retana' <aretana.i...@gmail.com>; spring@ietf.org
>>> *抄送：* draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org;
>>> spring-cha...@ietf.org
>>> *主题：* 答复: [spring] spring WG Adoption Call for
>>> draft-cheng-dhc-distribute-srv6-locator-by-dhcp
>>> Support its adoption.
>>>
>>> It will be more convincible to add some descriptions in the document
>>> that the CPE itself needs to obtain different IPv6 address that can
>>> differentiate the services that it can provide.
>>>
>>>
>>> Best Regards
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> -----邮件原件-----
>>> 发件人: spring-boun...@ietf.org [mailto:spring-boun...@ietf.org
>>> <spring-boun...@ietf.org>] 代表 Alvaro Retana
>>> 发送时间: 2023年7月5日 20:00
>>> 收件人: spring@ietf.org
>>> 抄送: draft-cheng-spring-distribute-srv6-locator-by-d...@ietf.org;
>>> spring-cha...@ietf.org
>>> 主题: [spring] spring WG Adoption Call for
>>> draft-cheng-dhc-distribute-srv6-locator-by-dhcp
>>>
>>> Dear WG:
>>>
>>> This message starts a two-week adoption call for
>>> draft-cheng-dhc-distribute-srv6-locator-by-dhcp, ending on July/19.
>>> It "describes the method of assigning locators to SRv6 Endpoints through
>>> DHCPv6".
>>>
>>>
>>> https://datatracker.ietf.org/doc/draft-cheng-spring-distribute-srv6-locator-by-dhcp/
>>>
>>>
>>> Please review the draft and consider whether you support its adoption by
>>> the WG. Please share any thoughts with the list to indicate support or
>>> opposition -- this is not a vote.
>>>
>>> If you are willing to provide a more in-depth review, please state it
>>> explicitly to give the chairs an indication of the energy level in the
>>> working group willing to work on the document.
>>>
>>> WG adoption is the start of the process. The fundamental question is
>>> whether you agree the proposal is worth the WG's time to work on and
>>> whether this draft represents a good starting point. The chairs are
>>> particularly interested in hearing the opinion of people who are not
>>> authors of the document.
>>>
>>> Thanks!
>>>
>>> Alvaro (for the Chairs)
>>>
>>> _______________________________________________
>>> spring mailing list
>>> spring@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>>
>>>
>>> _______________________________________________
>>> spring mailing
>>> listspring@ietf.orghttps://www.ietf.org/mailman/listinfo/spring
>>>
>>> _______________________________________________
>>> spring mailing list
>>> spring@ietf.org
>>> https://www.ietf.org/mailman/listinfo/spring
>>>
>>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
