On 5/9/19 23:26, Darren Dukes (ddukes) wrote: > inline. > >> On Sep 5, 2019, at 4:01 PM, Fernando Gont <fg...@si6networks.com> wrote: >> >> On 5/9/19 22:52, Darren Dukes (ddukes) wrote: >>> 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. >> >> I don't see how this changes the discussion here. > > Perhaps you should read the whole document Fernando.
I'm arguing that there is a document that relies on stuff that 6man never even wanted to adopt as wg item. You respond "but the document has other stuff". And I repeat: the document still assumes EH insertion is possible, when it's actually forbidden. >>> - 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. >> >> Among the possible options is that EH-insertion is never worked out. In >> which case, what's the point of basing something on EH insertion when >> the status quo is that EH insertion is not allowed, and there does not >> seem to be any indication that that will change anytime soon? > > Ah, an excellent reason to never work on anything: if its not easy then don’t > bother with the work! That's clearly not my point. My point is that you are putting the cart before the horse. Make your case for EH insertion, and try to update RFC8200 such that EH insertion is allowed (among other things, explain why you need it, and why you want to insert EHs instead of encap/decap -- which draft-voyer-6man-extension-header-insertion does not even mention). Then do the rest. Or pursue what you are doing in spring without any EH-insertion, and postpone anything that has to do with EH insertion for when/if it is actually allowed. I'm all for you trying any of these options. But not for the very curious interpretations of RFC2460 and/or RFC8200, or trying to avoid updating RFC8200 before doing EH insertion. Thanks, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
