Hello SPRING WG, Please find below some status on the main points of this WG LC.
=============== A) PSP [1] & RFC 8200 [2] =============== This point is whether SRH removal by the penultimate SR end point (aka PSP) is allowed by RFC 8200. More specifically " S14.4. Remove the SRH from the IPv6 extension header chain" Vs " Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." On this text, what is been discussed is "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." More specifically whether "Destination Address field of the IPv6 header" means the "final Destination Address" or the "Destination Address" as seen in the packet that the node received. [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-10#section-4.16.1 [2] https://tools.ietf.org/html/rfc8200#section-4 It's clear that two different opinions have been expressed, sometimes strongly, sometimes repeatedly. The literal reading of RFC 8200 wording ("the Destination Address field of the IPv6 header."), seem to allow PSP. At the very least, I don't find a basis to block this PSP behavior. Finally, the responsible AD has not accepted the related errata. https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/ Based on this, the plan is to flag this point of debate in the shepherd report, and leave this for the IESG to decide on how to read RFC 8200 (which represented 6MAN consensus and which the IESG approved). The threat to appeal will also be explicitly indicated (shepherd write up, point 10). Independently of RFC 8200, the question has been raised with regards to the benefit of PSP. My take is that PSP is an optional data plane optimization. Judging its level of usefulness is very hardware and implementation dependent. It may range anywhere from "not needed" to "required for my platform" (deployed if you are network operator, or been sold if you are a vendor), with possible intermediate points along "n% packet processing gain", or "required when combined with a specific other feature". I don't think that the SPRING WG can really evaluate this point (lack of hardware knowledge, lack of detailed information on the hardwares). The fact that this has been implemented by some platforms and deployed by some operators, is, to me, an indication that it is useful for those cases. (I believe that an English proverb is "the proof of the pudding is in the eating". Although I'm certainly missing part of its meaning and culture, in it's literal reading, it seems to apply). =============== B) confirmed WG interest and WG support to move forward =============== Multiple/many "support" and "+1" have been expressed. There is clearly an interest from the WG on this document, and to have it progressed. Note that there is no need for one to express his support multiple times. e..g., by sending another "+1" when one has already expressed his support. =============== C) clarifying/correcting the text in order to have common understanding and interoperable implementations. =============== WG is working on clarifying/correcting the text in order to have common understanding and interoperable implementations. We should finalize this. This is taking a bit more time than unusual (although it really depends compared to which document, e.g., SRH draft). I'd like everyone to consider the specifics of the SRv6 work and this document: there may be cultural differences between people from the spring/routing context and the 6man/Internet context. As such, someone coming from one context may believe that point "A" is obvious and hence doesn't understand why someone from another context seem to not understand it. I'd like everyone to make an effort on this. Let's remember that this point is about writing a technical specification which is well understood by everyone, and minimizing interoperability risks. --> Let's please focus on this aspect. =============== D) formal decision to advance this document =============== I'm listed as a contributor on this document (among 23 contributors). Even though I have zero specific write/modification privilege on the text in this document, and I'm not part of the authors email alias, this would not be ideal for me to take the decision to forward this document to the IESG.. I've discussed this with our AD (Martin) and he agreed to make the formal decision to send the document to the next level. Thank you Martin. As an element of context, I handled this WG LC not for the fun of it or because I believed it would easy, but because we needed to advance this document and that Rob was not available to take that role. --Bruno From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com Sent: Thursday, December 5, 2019 6:15 PM To: 'SPRING WG List' Cc: 6...@ietf.org; draft-ietf-spring-srv6-network-programming Subject: WGLC - draft-ietf-spring-srv6-network-programming Hello SPRING, This email starts a two weeks Working Group Last Call on draft-ietf-spring-srv6-network-programming [1]. Please read this document if you haven't read the most recent version, and send your comments to the SPRING WG list, no later than December 20. You may copy the 6MAN WG for IPv6 related comment, but consider not duplicating emails on the 6MAN mailing list for the comments which are only spring specifics. If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point. This may help avoiding that the thread become specific to this point and that other points get forgotten (or that the thread get converted into parallel independent discussions) Thank you, Bruno [1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-05 _________________________________________________________________________________________________________________________ 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
