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