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
