Hi Zhenqiang, On 10-Sep-19 22:14, li zhenqiang wrote: > Hi Bruno, > > Thank you very much for your response and clarification. > I agree with you that as of today RFC8200 rejects EH insertion. Since > draft-ietf-spring-srv6-network-programming is NOT updating RFC8200, it should > not contain texts or mechanisms that contradict with RFC8200. > Of course, Internet Standards can be updated to reflect technical progress > and satisfy new requirements following the updating procedure. Before an > Internet Standard under update reaches new rough consensus, we have to follow > the rules specified in the old one. > > BTW, EH insertion was intensively discussed alot when we did RFC2460bis. Two > years passed after RFC8200 was published. Is it time for us to reopen the > discussion based on the requirement raised in > I-D.voyer-6man-extension-header-insertion?
I don't believe that is the first discussion. IMHO, the first discussion should be whether we (as a community) believe we should standardise features that only work within a specified domain, or continue with the assumption that standardised features must work across the open Internet. Regards Brian Carpenter > > Best Regards, > Zhenqiang Li > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > li_zhenqi...@hotmail.com > > > *From:* bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> > *Date:* 2019-09-06 00:25 > *To:* Fernando Gont <mailto:fg...@si6networks.com>; Fernando Gont > <mailto:ferna...@gont.com.ar> > *CC:* Ron Bonica <mailto:rbonica=40juniper....@dmarc.ietf.org>; > spring@ietf.org <mailto:spring@ietf.org>; 6...@ietf.org > <mailto:6...@ietf.org>; Suresh Krishnan <mailto:suresh.krish...@gmail.com>; > draft-voyer-6man-extension-header-insertion > <mailto:draft-voyer-6man-extension-header-insert...@ietf.org>; > draft-ietf-spring-srv6-network-programming > <mailto:draft-ietf-spring-srv6-network-programm...@ietf.org>; li zhenqiang > <mailto:li_zhenqi...@hotmail.com> > *Subject:* RE: [spring] Question about SRv6 Insert function > > 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. > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
