Darren,
Your comment, and the discussion that elicited it, are very helpful. They
remind us that draft-ietf-spring-network-programming are far from maturity. If
the END.B6.INSERT and END.B6.INSERT.RED SIDs are to survive,
draft-voyer-6man-extension-header-insertion must progress ahead of it.
And if neither END.B6.INSERT nor END.B6.INSERT.RED survive, one would wonder
the PSP and USP flavors of the END and END.X are still needed.
These are among the many issues that merit discussion.
Ron
"All who wander are not lost." - J.R.R. Tolkien
Juniper Business Use Only
-----Original Message-----
From: spring <spring-boun...@ietf.org> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, September 5, 2019 3:58 PM
To: Fernando Gont <fg...@si6networks.com>
Cc: spring@ietf.org; 6...@ietf.org
Subject: Re: [spring] Question about SRv6 Insert function
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 <fg...@si6networks.com> wrote:
>
> 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/i
>>>> pv6/4MevopH9_iQglUizhoT5Rl-TjRc__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0
>>>> hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzf2MV0sH$
>>>
>>> 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-sp
>> ring-srv6-network-programming-01*section-13.1__;Iw!8WoA6RjC81c!Q1FacH
>> EtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzWANflGD$
>>
>> 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: fg...@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
> ng__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDO
> HPUJzZjOoys5$
_______________________________________________
spring mailing list
spring@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!Q1FacHEtMFou8f-8Rus0hRzuStyHfpGcZ5AAJPoyFKA59fUR9rDOHPUJzZjOoys5$
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
