Hi Joel,We've submitted the new version as following
link:https://www.ietf.org/archive/id/draft-cheng-spring-distribute-srv6-locator-by-dhcp-02.txtPlease
review it.Best Regards,Weiqiang
---原始邮件---
发件人: Joel Halpern <[email protected]>
发送时间: 2023-08-09 20:30:49
收件人: Weiqiang Cheng <[email protected]>
spring <[email protected]>
主题: Re: [spring] FW: New Version Notification
fordraft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt
I look forward to seeing a draft with these changes.
Yours,
Joel
On 8/9/2023 2:43 AM, Weiqiang Cheng wrote:
Dear Joel,
Thank you for sharing your comments. We would like to address each of your
points as follows:
Firstly, we will explicitly state that the CPE must be operator-managed in the
text.
Secondly, we understand your reservations about the assumption of
multi-operator trust domains. We will only cover the situations where different
arms of the same company operate their portions of the network separately but
trust each other.
Lastly, we appreciate your suggestion to rephrase the text accompanying Figure
1 to make it an active statement about the requirement for all relevant
components to be part of a single trust domain. We will update the text
accordingly.
Once again, thank you for bringing these comments.
Best regards,
Weiqiang
From: Joel Halpern
Date: 2023-08-08 22:27
To: Weiqiang Cheng spring
Subject: Re: [spring] FW: New Version Notification for
draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt
I have three concerns with this. The first concern is that I do not see where
the text is explicit that the CPE MUST be operator-managed. That seems to me
to be necessary no matter what one assumes about operator relationships.
The second concern is about the assumption of multi-operator trust domains. If
by that you mean a situation where multiple arms of the same company operate
their portions of the network separately, but trust each other, then yes, I
understand how that can be a single trust domain. However, that is a single
operator, not multi-operator. I have never seen any siutation in which
actually distinct operators trust each other and trust each other's security
mechanisms enough to be treated as a single trust domain. And what little
text we have defining trust domains does not suggest such an interpretation. I
am not comfortable with that, and I would expect pushback when we as a WG tried
to publish the document if we made such an assertion.
Third, as a lesser matter, I would prefer if the text that went with figure one
started with "This deployment assumes that all of the relevvent componenbts in
figure one are part of a single trust domain". That is an active statement
about a requirement by this document, not a passive observation.
Yours,
Joel
On 8/7/2023 10:01 PM, Weiqiang Cheng wrote:
Hi Joel,
Thank you very much for your comments.
I agree that all network elements, such as BRAS, CRx, Backbone, and CPE,
belong to the same operator, and this scenario indeed constitutes a trusted
domain. However, a trusted domain can indeed extend beyond a single operator.
In cases where multiple operators authenticate and trust each other's network
infrastructure, they can form a collective trusted domain. This allows them to
collaborate and leverage the resources of multiple trusted operators when
providing services. It is important to consider such scenarios and ensure that
the concept of a trusted domain is flexible enough to accommodate diverse
network environments.
How about if the author were to include text similar to the following:
"While in this document we describe a trusted domain consisting of network
elements from the same operator, it is important to note that a trusted domain
is not necessarily limited to a single operator. In the real world, multiple
operators can establish mutual trust, authenticate each other's network
infrastructure, and form a collective trusted domain. In such cases, they can
collaborate and leverage the resources of multiple trusted operators to provide
services. Therefore, we encourage readers to maintain flexibility in
understanding the concept of a trusted domain and consider the possibilities of
cooperation and trust among different operators."
Including such text would provide a clearer expression of the author's
understanding of the concept of a trusted domain and remind readers to consider
the potential for cooperation and trust among multiple operators in practical
applications.
B.R.
Weiqiang
From: Joel Halpern
Date: 2023-08-07 22:10
To: Weiqiang Cheng spring
Subject: Re: [spring] FW: New Version Notification for
draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt
For now speaking personally, although this may require chairs' intervention, I
do not find the trust domain text to be sufficient. While I am not sure it
would suffice, I would expect the text that goes with figure 1 to explicitly
state both that the CPE are under operator control and that the BRAS, CRx, and
Backbone devices are all run by a single operator that is the same as the
operator managing the CPE. And that they form a trust domain or are all part
of a single larger trust domain.
Yours,
Joel
On 8/7/2023 3:08 AM, Weiqiang Cheng wrote:
Dear Chairs and Group,
We have updated the draft and addressed the comments received during the
adoption call.
The main updates include:
1) Adding a detailed description of the trusted domain in the Security
Considerations section. 2) Optimizing the text based on the received comments.
For a detailed overview of the changes, please refer to the following diff
link:
https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-distribute-srv6-locator-by-dhcp-01
If you have any further comments or feedback, please feel free to share.
B.R.
Weiqiang Cheng
From: internet-drafts
Date: 2023-08-07 14:46
To: Changwang Lin Geng Zhang Ruibo Han Weiqiang Cheng Yuanxiang Qiu
Subject: New Version Notification for
draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt
A new version of I-D, draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt
has been successfully submitted by Ruibo Han and posted to the
IETF repository.
Name: draft-cheng-spring-distribute-srv6-locator-by-dhcp
Revision: 01
Title: Distribute SRv6 Locator by DHCP
Document date: 2023-08-07
Group: Individual Submission
Pages: 16
URL:
https://www.ietf.org/archive/id/draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt
Status:
https://datatracker.ietf.org/doc/draft-cheng-spring-distribute-srv6-locator-by-dhcp/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-cheng-spring-distribute-srv6-locator-by-dhcp
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-distribute-srv6-locator-by-dhcp-01
Abstract:
In a SRv6 network, each SRv6 Segment Endpoint Node must be assigned
a locator, and segment IDs are generated within the address space of
this locator. This document describes a method for assigning
locators to SRv6 Segment Endpoint Nodes through DHCPv6.
The IETF Secretariat
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
