Re: [spring] Question about SRv6 Insert function

["Darren Dukes (ddukes)" <[e-mail]>]

Hey Fernando, since you’re lost, here are some more waypoints to help you find your way ;)

- draft-ietf-spring-srv6-network-programming mentions SRH insertion in only 2 of 39 SID behaviors - i.e. it’s a small part of the draft, and all insert variants have an encapsulation variant defined.

- At IETF 101, the 6man WG confirmed that SRH insertion must be worked on before draft-ietf-spring-srv6-network-programming can progress to RFC - i.e. there are not surprises anywhere.

- draft-ietf-spring-srv6-network-programming added a normative reference to draft-voyer-6man-extension-header-insertion to document that fact.

Darren

On Sep 5, 2019, at 10:55 AM, Fernando Gont <[e-mail]<mailto:[e-mail]>> wrote:

On 5/9/19 17:46, [e-mail]<mailto:[e-mail]> wrote:
Fernando,


From: spring [mailto:[e-mail]] 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?

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.

--
Fernando Gont
SI6 Networks
e-mail: [e-mail]<mailto:[e-mail]>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




_______________________________________________
spring mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spring