Mark, Thanks for saying what we were all thinking.
Ron Sent from my phone On Sep 6, 2019, at 9:07 PM, Mark Smith <markzzzsm...@gmail.com<mailto:markzzzsm...@gmail.com>> wrote: On Sat, 7 Sep 2019, 09:00 Tom Herbert, <t...@herbertland.com<mailto:t...@herbertland.com>> wrote: On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk <rob...@raszuk.net<mailto:rob...@raszuk.net>> wrote: > > Sander, > > But this is exactly what both chairs of 6man did with the help of AD long > time back. You must have missed it ! > > And below is a link precisely written to address requirement of justifying > deviation: > > https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-06<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-06__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krfiJ6n4a$> > Yes, and that draft was discussed in depth in 6man, a number of issues were raised, and we haven't heard back from the authors. And this was not just a case of saying it violates RFC8200, there were specific reasons given why it isn't robust. So it's correct to say that current consensus in 6man is that extension header insertion is disallowed. I also have a nit about that draft. The very first line of the abstract is "The network operator and vendor community has clearly indicated that IPv6 header insertion is useful and required." The fact that somebody _really_ wants their protocol to be adopted by IETF is hardly going to influence anyone. Obviously, anyone writing a draft thinks that it is useful and required, it's up to the authors to show that. Frankly, I think this statement comes off as being condescending and sets a poor tone for reading the rest of the document. Yes, it's a appeal to authority. Earlier versions had 10 or more authors listed. That is also an appeal to authority. The draft doesn't say why insertion is considered necessary. There is no justification presented. There is no statement that says, "When using IPv6 tunnelling with 128 bit SIDs, the per packet overhead can become too high." That would be admitting what the real cause was, and make people question whether using 128 bit SIDs was really the right decision - as they should. Considering all that, I would describe this draft as trying to get its proposal approved through social engineering rather than technical engineering. Tom > And let me repeat one more and last time ... all other documents in progress > use two different insertions. Most of them does SRH insertion + new IPv6 > encapsulation which is allowed by all IPv6 related RFCs - so zero violation > of any consensus. > > Just NP document also adds two functions for insertion without encapsulation, > as additional tools which can be used for things like FRR if such application > will be approved in 6man WG. > > All SRv6 existing specs can progress just fine with that last mode of > insertion being removed if rough consensus in 6man would not get reached. > > Cheers, > Robert. > > > On Fri, Sep 6, 2019 at 11:58 PM Sander Steffann > <san...@steffann.nl<mailto:san...@steffann.nl>> wrote: >> >> Hi Ole, >> >> > I don’t see a need to continue this debate on meta issues, but since you >> > framed this as criticism of me in the chair role I found it required to >> > reply. >> >> I expect the chair to uphold a previously reached consensus and put the >> requirement of justifying deviating from it with the ones that want to go >> against said consensus. >> >> Cheers, >> Sander >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org<mailto:spring@ietf.org> >> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krR6VKe7s$> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org<mailto:i...@ietf.org> > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krbgSAl-0$> > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org<mailto:i...@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krbgSAl-0$> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list i...@ietf.org<mailto:i...@ietf.org> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!QCUnocXqhwmktJnIOEJVs_z0uIoC21MOFOVAR0vgcgeAgGzg9MirMP7krbgSAl-0$ --------------------------------------------------------------------
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
