[spring] Re: Mohamed Boucadair's Discuss on draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-13: (with DISCUSS and COMMENT)

[[e-mail]]

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 <[e-mail]>
Envoyé : mardi 3 mars 2026 03:53
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; hanruibo <[e-mail]>
Cc : aretana.ietf <[e-mail]>; buraglio <[e-mail]>; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp <[e-mail]>; spring-chairs <[e-mail]>; spring <[e-mail]>; The IESG <[e-mail]>
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<mailto:[e-mail]>
Date: 2026-02-20 23:54
To: han<mailto:[e-mail]>
CC: 'aretana.ietf'<mailto:[e-mail]>; 'buraglio'<mailto:[e-mail]>; 'draft-ietf-spring-dhc-distribute-srv6-locator-dhcp'<mailto:[e-mail]>; 'spring-chairs'<mailto:[e-mail]>; 'spring'<mailto:[e-mail]>; 'The IESG'<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Envoyé : vendredi 13 février 2026 15:57
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc : 'aretana.ietf' <[e-mail]<mailto:[e-mail]>>; 'buraglio' <[e-mail]<mailto:[e-mail]>>; 'draft-ietf-spring-dhc-distribute-srv6-locator-dhcp' <[e-mail]<mailto:[e-mail]>>; 'spring-chairs' <[e-mail]<mailto:[e-mail]>>; 'spring' <[e-mail]<mailto:[e-mail]>>; 'The IESG' <[e-mail]<mailto:[e-mail]>>
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


发件人: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
发送时间: 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 <[e-mail]<mailto:[e-mail]>>
Envoyé : jeudi 22 janvier 2026 12:48
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
Cc : aretana.ietf <[e-mail]<mailto:[e-mail]>>; buraglio <[e-mail]<mailto:[e-mail]>>; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp <[e-mail]<mailto:[e-mail]>>; spring-chairs <[e-mail]<mailto:[e-mail]>>; spring <[e-mail]<mailto:[e-mail]>>
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<mailto:[e-mail]>
Date: 2026-01-16 23:46
To: The IESG<mailto:[e-mail]>
CC: aretana.ietf<mailto:[e-mail]>; buraglio<mailto:[e-mail]>; draft-ietf-spring-dhc-distribute-srv6-locator-dhcp<mailto:[e-mail]>; spring-chairs<mailto:[e-mail]>; spring<mailto:[e-mail]>
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.