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 <mailto:wangai...@tsinghua.org.cn>
*发送时间：* 2023-07-14 11:19
*收件人：* 'Alvaro Retana' <mailto: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
<mailto: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 list
spring@ietf.org
https://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
