Thanks a lot.
Weiqiang
---原始邮件---
发件人: "mohamed.boucadair" <[email protected]>
发送时间: 2026-03-04 23:02:09
收件人: chengweiqiang <[email protected]>
hanruibo <[email protected]>
抄送: "aretana.ietf " <[email protected]>
buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]>
spring-chairs <[email protected]>
spring <[email protected]>
iesg <[email protected]>
主题: RE: [spring] Re: Mohamed Boucadair's
Discussondraft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with
DISCUSSandCOMMENT)
Hi Weiqiang, authors,
The proposed changes work for me.
With that, I consider that all my points are closed. I will update my ballot as
soon as the new version is out.
Thank you for your patience with me. Appreciated.
Cheers,
Med
De : chengweiqiang <[email protected]> Envoyé : mercredi 4 mars
2026 15:57 À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
hanruibo <[email protected]> Cc : aretana.ietf <[email protected]>
buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]> spring-chairs
<[email protected]> spring <[email protected]> iesg <[email protected]> Objet :
RE: [spring] Re: Mohamed Boucadair's Discuss
ondraft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS
andCOMMENT)
Dear Med,
Thank you very much for your valuable comment and guidance. We completely agree
with your point regarding the ambiguity of using multiple locators and the
importance of following RFC7227.
To address this, the authors will add the following clarification in the next
version of the draft:
---
DHCP allows a client to obtain multiple addresses as specified in Section 6.5
of <xref format="default" target="RFC9915"></xref>. The same principle applies
to SRv6 locator assignment. In scenarios requiring multiple allocations (e.g.,
when multiple SRv6 locators are needed for distinct services, such as
best-effort and low-latency traffic, each with a different algorithm), the
allocation policy between the DHCPv6 client and DHCPv6 server MUST remain
consistent. After obtaining the SRv6 Locator assigned by the DHCPv6 server, how
to assign local SRv6 SIDs based on this SRv6 Locator, how to use multiple
assigned SRv6 Locators, and how to advertise these SRv6 SIDs to the rest of the
network are not within the scope of this document. However, and consistent with
the guidance in Section 16 of <xref format="default" target="RFC7227"></xref>,
the client MUST NOT make any assumption about the locators ordering or infer
any service logic from these locators.
---
The text makes the document more precise and fully aligns with RFC7227.
Let us know your comments.
Best regards,
Weiqiang
---原始邮件---
发件人: chengweiqiang <[email protected]> 发送时间: 2026-03-04
00:24:34 收件人: "mohamed.boucadair" <[email protected]> hanruibo
<[email protected]> 抄送: "aretana.ietf" <[email protected]>
buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]> spring-chairs
<[email protected]> spring <[email protected]> iesg <[email protected]> 主题:
回复:RE: [spring] Re: Mohamed Boucadair's Discuss
ondraft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS
andCOMMENT)
Hi Med,
Thanks for your comment.
DHCPv6 provides the capability to request multiple addresses simultaneously,
and we have inherited this capability in our extension for SRv6 Locator
allocation.
We hope this potential feature offers greater flexibility for future design. As
co-authors suggested, each locator could be bound to a given VPN service Ketan
also provided another example where multiple SRv6 locators might be needed for,
say, best-effort and low-latency services with different algorithms.
Regarding how clients actually use this capability, that remains open and is
outside this draft's scope. Going forward, operators may define private uses
for different locators, or a future RFC could specify a standardized mechanism
for mapping services to specific locators.
Best regards,
Weiqiang
---原始邮件---
发件人: "mohamed.boucadair" <[email protected]> 发送时间: 2026-03-03
19:15:02 收件人: Weiqiang Cheng <[email protected]> hanruibo
<[email protected]> 抄送: "aretana.ietf " <[email protected]>
buraglio <[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]> spring-chairs
<[email protected]> spring <[email protected]> The IESG <[email protected]>
主题: RE: [spring] Re: Mohamed Boucadair's Discuss
ondraft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS
andCOMMENT)
Hi Weiqiang, all,
Thank you for adding these scenarios. That’s an improvement.
However, how the client is supposed to handle those? For example, each locator
can be bound to a given VPN service (that you cited as an example). How the
client will disambiguate those from the received list? Would any random
association be OK from the service perspective? Else?
I’m still concerned with this part as the behavior is not clear.
Cheers,
Med
De : Weiqiang Cheng <[email protected]> Envoyé : mardi 3 mars 2026
03:53 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> hanruibo
<[email protected]> Cc : aretana.ietf <[email protected]> buraglio
<[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]> spring-chairs
<[email protected]> spring <[email protected]> The IESG <[email protected]>
Objet : Re: [spring] Re: Mohamed Boucadair's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and
COMMENT)
Hi Med,
Thanks for your comments.
As your suggestion, we have added the scenario of allocating multiple SRv6
locators in the version -15.
B.R.
Weiqiang Cheng
From: mohamed.boucadair
Date: 2026-02-20 23:54
To: han
CC: 'aretana.ietf' 'buraglio'
'draft-ietf-spring-dhc-distribute-srv6-locator-dhcp' 'spring-chairs' 'spring'
'The IESG'
Subject: [spring] Re: Mohamed Boucadair's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and
COMMENT)
Hi Ruibo,
Thank you for preparing this updated version. I still think this is providing a
partial solution, but I think that I can live with most of the resolutions you
made so far.
The only main pending point is that I still don’t see how do you comply with
this MUST in RFC7227:
“If multiple instances are allowed, the document MUST explain how to use
them.”
As you still say:
After obtaining the SRv6 Locator assigned by the DHCPv6 server, how
to assign local SRv6 SIDs based on this SRv6 Locator, how to use
^^^^^^^^^^^^
multiple assigned SRv6 Locators, and how to advertise these SRv6 SIDs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
to the rest of the network are not within the scope of this document.
Do you have a case where you need multiple locators at the first place?
Given that an operator would control the allocation policy, why that operator
would prefix shrinking prefixes rather than returning one single prefix?
# (nit) please make this change as this is example of the parent SHOULD
behavior:
CURRENT:
Note that the configuration behavior of the
server and client SHOULD be consistent (e.g., "Clients and Servers
SHOULD assign a single locator unless explicitly configured").
NEW:
Note that the configuration behavior of the
server and client SHOULD be consistent (e.g., "Clients and Servers
new assign a single locator unless explicitly configured").
Thank you.
Cheers,
Med
De : han <[email protected]> Envoyé : vendredi 13 février 2026 15:57 À :
BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : 'aretana.ietf'
<[email protected]> 'buraglio' <[email protected]>
'draft-ietf-spring-dhc-distribute-srv6-locator-dhcp'
<[email protected]> 'spring-chairs'
<[email protected]> 'spring' <[email protected]> 'The IESG' <[email protected]>
Objet : Re: [spring] Mohamed Boucadair's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and
COMMENT)
Dear Mohamed,
Thank you for your insightful suggestions.
We have carefully considered your comments and uploaded version 14, please find
our inline replies below for details.
Please let us know if you have any further comments.
B.R.
Ruibo
发件人: [email protected] [mailto:[email protected]] 发送时间:
2026年2月3日 19:13 收件人: Weiqiang Cheng 抄送: aretana.ietf buraglio
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp spring-chairs spring The
IESG 主题: RE: [spring] Mohamed Boucadair's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and
COMMENT)
Hi Weiqiang,
Thank you for the follow-up.
Apologies for the delay to replay as I was out last week.
Please see inline.
Cheers,
Med
De : Weiqiang Cheng <[email protected]> Envoyé : jeudi 22 janvier
2026 12:48 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> The
IESG <[email protected]> Cc : aretana.ietf <[email protected]> buraglio
<[email protected]>
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
<[email protected]> spring-chairs
<[email protected]> spring <[email protected]> Objet : Re: [spring] Mohamed
Boucadair's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13:
(with DISCUSS and COMMENT)
Dear Mohamed,
Thank you very much for your thorough review and insightful comments on our
draft.
We have carefully considered all of your comments and please see our inline
replies below for details.
Please let us know if you have any further thoughts or comments.
B.R.
Weiqiang
From: Mohamed Boucadair via Datatracker
Date: 2026-01-16 23:46
To: The IESG
CC: aretana.ietf buraglio draft-ietf-spring-dhc-distribute-srv6-locator-dhcp
spring-chairs spring
Subject: [spring] Mohamed Boucadair's Discuss on
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and
COMMENT)
Mohamed Boucadair has entered the following ballot position for
draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi Weiqiang, Ruibo, Changwang, Daniel, and Geng,
Thank you for the effort put into this specification.
Thanks to Ran Chen for the OPSDIR review. I would appreciate a reply from the
authors.
Please find below some DISCUSSion points:
# Deployment Assumptions, Pre-requisites: Clarity
Other than the need to make it clear this is a sample topology, and not
questioning which CPE class will support SR and that many statements here do
not apply for Enterprise CEs, Section 3 has several issues that are
problematic. Specifically:
## Administrative domains boundaries
CURRENT:
This
deployment assumes that all of the relevant components in Figure 1
are part of a single trusted SR domain.
It is not clear where the CPE is located (is it within the customer premises or
is it within the provider network).
There are several deployments out there for the location of CE/CPE. Note that
there might be cases where a managed CE can even be used to service multiple
customers (see rfc9889#section-3.3).
If this is within the customer premises, how is this considered as “single
trusted SR domain” given the attachment circuit between the Customer and
Provider is co-managed and do not technically belong to a single domain?
[Co-authors] The term 'Trusted Domain' has been discussed many times without a
final clear definition. Based on previous discussions, at least one consensus
is that all devices within the same operator's administrative domain are
considered to be in the 'trusted domain,' where all devices and ports can be
monitored and managed by the network management system.
Even if the CPE is located within the customer premises, as long as the device
itself and its ports are under the operator's administration, the risks remain
manageable. However, it is indeed necessary to highlight potential risks. The
co-author will add a risk statement regarding 'the attachment circuit between
the Customer and Provider' in the new version.
[Med] OK. Please add some text to call out these assumptions. You may consider
delimiting the administration perimeters (customer, provider) in your figure as
well.
[Co-authors][v2]thanks, we updated it in chapter 3 of version 14.
## If the managed CPE is within the network provider, then what operational
issues are solved by mimicking DHCP-PD for SR here?
[Co-authors] There are two issues we hope to address:
First, the number of customer-side devices may be substantial, making manual
configuration inefficient.
[Med] This one can be achieved with automation.
[Co-authors] [v2] Yes, the basic resources like IPv4/IPv6 address/locators
needs to be allocated firstly, then the customer-side devices could be
connected remotely, then other configurations could be achieved with
automation.
Second, on the BRAS side, SRv6 Locator routes cannot be dynamically distributed
to WAN.
[Med] Do you mean at the routing level?
[Co-authors] [v2] Yes.
## Are Locators the only needed provisioning task to CPEs to have intra-access
SR service?
[Co-authors] While SRv6 Locator configuration is a key element, a complete
provisioning solution encompasses more. It should be noted that this document
focuses specifically on the configuration of SRv6 Locators other aspects of
provisioning are outside its current scope.
[Med] Noted. My comment was whether we have an operational solution if only the
DHCP extension is in place? There is a dependency that I think we need to
clarify in this spec.
[Co-authors] [v2]Yes, if only the DHCP extension is in place for locators,
an operational solution is to add other configurations via CLI, NETCONF/YANG,
APIs, etc. We added some descriptions in chapter 3 of version 14.
CURRENT:
In this network, operators hope to achieve interconnection between
access users through End-to-End SRv6 tunnels. Taking the service
traffic from Host1 to Host2 as an example, CPE1 is the SRv6 ingress
node and CPE2 is the SRv6 egress node.
Unless I’m missing something, extra configuration is needed so that SR source
nodes (CPE in this case) can place “End-to-End SRv6 tunnels”. If my
understanding is correct, then there will be a need of a mix set of mechanisms
to provision the CPE. Is it justified from an operational standpoint to have
several mechanisms here instead of using a common provisioning mechanism?
[Co-authors] As mentioned above, additional configuration is indeed required.
However, considering that customer-side devices are often low-cost boxes that
may not even support IGP, using DHCP is an economical and straightforward
approach.
[Med] I still see a tension here between the part where we say that “additional
configuration is indeed required” and argument here. A way to close this is to
have some text that says that there are deployment cases where having a mix of
solutions to supply portions of required SR configuration may (or may not) be
operationally viable. Such assessment is out of scope of this document.
[Co-authors] [v2] Thanks, we updated it in chapter 3 of version 14 about
adding configurations via CLI, NETCONF/YANG, APIs, etc.
## Mobility Requirements
CURRENT:
Moreover, the mobility requirements
of CPEs are relatively high, and the access location of the same
CPE often changes, so its IPv6 address cannot be fixed.
I fail to understand this.
I don’t see from where we have this “high” requirement for CPE mobility. At
least, I don’t see how we can claim that as a general assumption, “access
location” of CPEs “often changes”.
## BTW, I don’t see how the use of DHCP solves this issues, especially given
the discussion in RFC7225 about “Additional States Considered Harmful”.
[Co-authors] The frequent changes in the access location of the same CPE is
indeed not the primary issue to be addressed in this document. As suggested, we
will revise the relevant descriptions.
[Med] Thanks.
## Some of these issues can be fixed by having less words in Section 3.
[Co-authors] We will optimize the text of section 3.
[Med] ACK
# Multiple instances and RFC7227 Guidance
CURRENT:
A client can explicitly request multiple SRv6 Locator prefixes by
sending multiple IA_SRV6_LOCATOR options.
and
A DHCP message may contain multiple IA_SRV6_LOCATOR
Options (though each must have a unique IAID).
and
After receiving a DHCP message with multiple IA_SRV6_LOCATOR options
at the same time, whether the server can assign multiple SRv6
Locators to the client depends on the server policy, which is out of
scope for this document.
This seems to conflict with this RFC 7227 guidance:
“If multiple instances are allowed, the document MUST explain how to use
them.”
[Co-authors] This document does not change the original DHCPv6 mechanism,
please refer to the description in
https://datatracker.ietf.org/doc/html/draft-ietf-dhc-rfc8415bis-12#name-multiple-addresses-and-pref.
[Med] Thanks, but my comment is about the new option defined in this spec.
[Co-authors] [v2] Thanks, we updated it in chapter 4 and chapter 5 of version
14 based on the ietf-dhc-rfc8415bis(now it is RFC9915.
## BTW, other guidance from RFC 7227 seems not followed here such as: template
for the defining the option (rfc7227#section-21), etc. Please check that
guidance, if not done. Thanks
[Co-authors] We will update the text to ensure it is fully aligned with the
guidance from RFC 7227.
[Med] Thanks
# "Automatic" behaviors are problematic
CURRENT:
Upon receiving the Release message, the server MUST remove the lease
and free the locator, making it available for allocation to other
clients.
This MUST is problematic as it assumes that the message will always be valid
and that there is no policy to discard the release.
There are other similar constructs in the document that I think need to be
fixed.
[Co-authors] We will revise all similar statements as suggested.
[Med] ACK.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# General: please update all DHCP occurrences to DHCPv6.
[Co-authors] Got it.
[Med] Thanks.
# You may cite RFC 7084 for considerations related to PD support.
[Co-authors] Will update.
[Med] ACK
# Several of the considerations in RFC 8987 can be leveraged here are well
[Co-authors] Will update.
[Med] Thanks.
Specifically, I would mirror the following Operational ones from RFC 8987
(replace delegated prefix with locator):
[Co-authors] Will update.
[Med] Thanks
O-1: The relay SHOULD implement an interface allowing the operator
to view the active delegated prefixes. This SHOULD provide
information about the delegated lease and client details such
as the client identifier, next-hop address, connected
interface, and remaining lifetimes.
O-2: The relay SHOULD provide a method for the operator to clear
active bindings for an individual lease, client, or all
bindings on a port.
O-3: To facilitate troubleshooting of operational problems between
the delegating relay and other elements, it is RECOMMENDED that
a time synchronization protocol be used by the delegating
relays and DHCP servers.
# Routing stability as an additional Operational Considerations
In some setups, an aggregate is announced instead of individual prefixes for
the sake of optimized RIBs. Withdrawal of specific routes triggered by releases
may have lead to shrink announcements. An alternative behavior is to have a
policy that governs that behavior. In such cases, the delegating routers will
drop packets sent to specific prefix not “delegated” on the customer-facing
interface.
# Nits
## What is the purpose of the following?
CURRENT:
Telecom providers can use their IP Metro and Backbone networks to
establish connectivity between access users who are located in
different regions.
Isn’t obvious that a network provider uses its network to provided intra-domain
connectivity?
[Co-authors] Got it. We will update.
[Med] ACK/
## Paradigm and “any program”
CURRENT:
The network programming paradigm for SRv6 is specified in [RFC8986].
It describes how any behavior can be bound to a SID and how any
network program can be expressed as a combination of SIDs. It also
describes several well-known behaviors that can be bound to SRv6
SIDs.
I suggest to simply state what that spec is about
NEW:
[RFC8986] introduces the SRv6 Network Programming concept
and specifies the base set of SRv6 behaviors.
[Co-authors] Got it.
[Med] ACK.
Cheers,
Med
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This
message and its attachments may contain confidential or privileged information
that may be protected by law they should not be distributed, used or copied
without authorisation. If you have received this email in error, please notify
the sender and delete this message and its attachments. As emails may be
altered, Orange is not liable for messages that have been modified, changed or
falsified. Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This
message and its attachments may contain confidential or privileged information
that may be protected by law they should not be distributed, used or copied
without authorisation. If you have received this email in error, please notify
the sender and delete this message and its attachments. As emails may be
altered, Orange is not liable for messages that have been modified, changed or
falsified. Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This
message and its attachments may contain confidential or privileged information
that may be protected by law they should not be distributed, used or copied
without authorisation. If you have received this email in error, please notify
the sender and delete this message and its attachments. As emails may be
altered, Orange is not liable for messages that have been modified, changed or
falsified. Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you._______________________________________________
spring mailing list -- [email protected]
To unsubscribe send an email to [email protected]
