> From: Fernando Gont [mailto:fg...@si6networks.com] > Sent: Thursday, September 5, 2019 4:56 PM > > On 5/9/19 17:46, bruno.decra...@orange.com wrote: > > Fernando, > > > > > >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont > >> Sent: Tuesday, September 3, 2019 1:18 PM > >> > >> Hello, Suresh, > >> > >> On 2/9/19 19:07, Suresh Krishnan wrote: > >> [....] > >>>>> So, we should probably explore the motivation for Option 2). If the > >>>>> motivation is not sufficient, we should probably standardize on Option > >>>>> 1. > >>>> > >>>> My argument would be: > >>>> Folks would do whatever they please with 1). If somehow they feel the > >>>> need to do 2), they should *refrain from even suggesting it*, post an > >>>> internet draft that proposes to update RFC8200 to allow for the > >>>> insertion of EHs, wait for that to be adopted and published, and only > >>>> then suggest to do EH insertion. > >>> > >>> I have put down my thoughts on the future of header insertion work in a > >>> mail to the 6man list in May 2017. The mail can be found below > >>> > >>> https://mailarchive.ietf.org/arch/msg/ipv6/4MevopH9_iQglUizhoT5Rl-TjRc > >> > >> This seems e bit misleading. What I would expect is that before any work > >> is published on EH-insertion, the IPv6 standard is updated to allow for > >> EH insertion. (plese see bellow) > >> > >> > >> > >> > >>>> P.S.: Given the amount of discussion there has been on this topic in the > >>>> context of RFC8200, I'd like to hope that there's no draft-ietf document > >>>> suggesting EH-insertion or, if there is, the relevant ADs and chairs > >>>> make sure that's not the case anymore. > >>> > >>> Yes. If a draft violates RFC8200 and it hits the IESG for evaluation, I > >>> will certainly hold a DISCUSS position until the violations are fixed. > >> > >> Since there have been plenty of attempts to do EH insertion or leave the > >> IPv6 standard ambiguous in this respect, and the IETF has had consensus > >> that EH insertion is not allowed, I think it would be bad, wastefull, > >> tricky, and even dangerous to let a document go through the whole > >> publication process, and just rely on the AD to keep the "DISCUSS" > >> button pressed. > > > > draft-ietf-spring-srv6-network-programming has a normative reference to > > [I-D.voyer-6man-extension-header-insertion] > > > > https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01#section-13.1 > > > > As such, from a process standpoint, it would not going to be published > > before [I-D.voyer-6man-extension-header-insertion] be itself published as > > RFC. And from its name, the latter is intended to be discussed and within > > control of the 6MAN WG. So I don't think that we can say that it "just rely > > on the AD to keep the "DISCUSS" button pressed." > > > > In my mind, this should also be a clear indication that the question of > > header insertion is (to be) within the control of the 6MAN WG. But you may > > have a different opinion. > > Maybe my mental algorithm has a bug, but: what's the point of spring > working on a document that relies on something that 6man has so far > rejected?
I take your point that 6MAN has rejected, in the past, general header insertion. (under the control of the 6MAN WG as I feel some nuances depending on the speakers) I don't know about the future 6MAN position with regards to SRH insertion specifically for SRv6, possibly restricted to a specific usage (e.g. TI-LFA) or context (e.g. source, transit and destinations nodes are within a single control domain). As of today, I'm expecting [I-D.voyer-6man-extension-header-insertion] to reflect this and I'm using it as a coordination and gating tooling between 2 IETF WGs. I'm open to considering others tools. But if your point is that the SPRING WG cannot discuss, envisage and document the usage of SRH insertion in the SPRING context, that is not my reading of the SPRING charter. As part of this discussion, you are very welcome to contribute. Finally, let me remind that draft-ietf-spring-srv6-network-programming is NOT updating RFC8200, and is NOT meant to update RFC8200. This has been explicitly stated "this document is not intended to update RFC 8200. If a behavior needs to update RFC 8200, it should be defined in a 6MAN draft in the 6MAN WG and normatively referenced." https://mailarchive.ietf.org/arch/msg/spring/GyYapMbWJdv95hoDMjZNKl5WHG4 > You spend energy on the document and then... just sit on the I-D to see > if 6man adopts voyer-6man-extension-header-insertion? Ship the document > to the IESG for them to review? -- I'm lost, sorry. draft-ietf-spring-srv6-network-programming is not primarily about header insertion. Its scope is much wider. So SPRING WG is working on the whole text of draft-ietf-spring-srv6-network-programming. If at some point the normative reference to [I-D.voyer-6man-extension-header-insertion] is holding the progression of the document, as of today I could see two paths: wait some more time/forever (i.e. never publish that document as RFC); remove the text blocking the progression. Personally, I would assume the latter. There could be others options, but I'd rather consider this when/if we face the problem. In the meantime, would you have an issue with any of those two/three hypothetic paths (wait, never publish, remove SRH insertion)? Thank you. --Bruno > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > _________________________________________________________________________________________________________________________ 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
