Hi Bruno,
Thanks for many good suggestions. We have made substantial revisions to the document and believe that most of the issues raised here have been addressed. Please see inline responses (with [fyang]) below. The updated version can be found here: https://datatracker.ietf.org/doc/html/draft-yang-spring-sid-as-source-addres s-12 BR, Feng 发件人: [email protected] <[email protected]> 发送时间: 2026年6月18日 19:32 收件人: [email protected] 抄送: spring <[email protected]> 主题: draft-yang-spring-sid-as-source-address [speaking as individual contributor] Hi authors, Following your request for adoption call, I’ve reviewed -11 (and -10). Please find below some minor comments and questions. -Idnits is not fully happy https:// <https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/i d/draft-yang-spring-sid-as-source-address-11.txt> author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-y ang-spring-sid-as-source-address-11.txt [fyang] Fixed. - §2 “There are several cases SHOULD be considered for using SRv6 SID”. May be a typo coming from an edit introduced in -11. May be : “Several cases SHOULD be considered for using SRv6 SID” [fyang] Fixed. - §2 “* User traffic. ? may be “*” was intended to be a new bullet item. If so, rendering failed. *2 [fyang] Fixed. - §2.1 “For SRv6 VPN-based services, the user traffic SHOULD use the SRv6 service SID as source address.” Thanks for adding clarifications in -11 with regards to the SID to use. It’s not completely clear to me whether this is specified enough: in principle, I guess that the ingress PE could advertise a different SID on a per VPN route basis. I’d guess typically for End.DX, when multiple CEs/link are in the VRF, or when advertising a route connected to the PE. In such cases, for your firewall issue to be solved, I would assume that you would need to use the “right” VPN SID: the one from the VPN route matching the source address of the customer packet. But this would imply an additional cost (lookup on the source IP address). Then, assuming a per CE/link SID assignment, may be only looking at the received interface would be enough. You may want to clarify that point. (e.g., describing the case, possibly proposing options to implementations, and recommendations (e.g., per link SID allocation for DT, or DX). “The service SIDs are locally allocated by the PE per VPN/AC”. Not sure this is currently mandatory. May be you meant to recommend such allocations strategy for DT? [fyang] 2 sub-section added for vpn and non-vpn case, respectively. For vpn case, 3 options (per-route/per-ac/per-vpn) are discussed, and we recommend to consider more specific granularity SID for source address to align with address in reverse traffic. * §2.1 “For VPN-less IP forwarding over SRv6 tunnels, the tunnels SHOULD use End SID as source address.” Not sure about this. A priori you would want to use the SID advertised with the BGP route that the egress PE would use to return the traffic, no? RFC 9252 section 5.3 & 5.4 recommends a specific DT or DX SID. [fyang] Here I mean the non-vpn case, e.g., internet traffic engineering w/o VPN. Section 2.1.2 is added. * §2.2 “For ping or the ICMP response generated by head or tail end of SRv6 tunnel, it SHOULD use the SRv6 SID as source address, such as ping, trace.” Please details which SID you are referring to. [fyang] Fixed. More specific on SID selection for SRv6 Ping, PE handling of ICMP error message trigged by the SRv6 transit node. * Draft does not seem to talk about SRv6 compression (RFC9800) and in particular the NEXT-CSID flavor. It’s not clear that it would work if the firewall is located before the last CSID EndPoint). Personally, I’d like this point covered, even if just to raise the issue. [fyang] Section 4 is added for C-SID consideration * Implementation section. Although not mandatory, adding one would probably be better (to share implementation status & maturity with the WG, and not to forget it) [fyang] Section 5 is added for implementation status. * “security consideration” is currently empty. Would be better to have a real one. [fyang] A few considerations are added. Thanks, BR --Bruno ____________________________________________________________________________ ________________________________ 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]
