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
