[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://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-yang-spring-sid-as-source-address-11.txt<https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-yang-spring-sid-as-source-address-11.txt> - §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" - §2 "* User traffic. » may be "*" was intended to be a new bullet item. If so, rendering failed. *2 - §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? * §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. * §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. * 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. * Implementation section. Although not mandatory, adding one would probably be better (to share implementation status & maturity with the WG, and not to forget it) * "security consideration" is currently empty. Would be better to have a real one. 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]
