Re: [spring] Question about SRv6 Insert function

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

Hi Fernando.

The takeaway I attempted to highlight is that there is in fact agreement between 6man and spring on how to proceed, and we are proceeding as agreed to work on the relevant documents.

Thanks!
  Darren

________________________________
From: Fernando Gont <[e-mail]>
Sent: Thursday, September 5, 2019 4:47 PM
To: Darren Dukes (ddukes)
Cc: [e-mail]; Fernando Gont; Ron Bonica; [e-mail]; [e-mail]; Suresh Krishnan; draft-voyer-6man-extension-header-insertion; li zhenqiang; draft-ietf-spring-srv6-network-programming
Subject: Re: [spring] Question about SRv6 Insert function

On 5/9/19 23:26, Darren Dukes (ddukes) wrote:
> inline.
>
>> On Sep 5, 2019, at 4:01 PM, Fernando Gont <[e-mail]> 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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492