Re: [spring] Progressing draft-ietf-spring-network-programming: Finding a compromise

Dear Ron,

IMO current version of RFC8200 is very clear - node which is identified in
DA of the packet can modify or delete EHs.

I see no reason to spend time updating it.

Indeed insertion of new EH by any node in the path was at odds with the
RFC8200 text hence I suggested that it is removed to a separate draft. But
here there is no reason to remove anything as the current version of the
NPG is compliant with it as is.

Regards,
R.

On Fri, Feb 28, 2020 at 5:22 PM Ron Bonica <rbonica@juniper.net> wrote:

> Robert,
>
>
>
> This is not an attempt to buy time until an undefined future. I sincerely
> believe that:
>
>
>
>    - I can produce a draft that updates RFC 8200 before IETF 107
>    - The community can progress it by IETF 109
>    - The vendors can ship what they want until then
>
>
>
> If you want to make sure that this happens, you can work with me on the
> draft……
>
>
>
>
> Ron
>
>
>
>
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Friday, February 28, 2020 11:04 AM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* SPRING WG List <spring@ietf.org>; 6man WG <ipv6@ietf.org>
> *Subject:* Re: [spring] Progressing
> draft-ietf-spring-network-programming: Finding a compromise
>
>
>
> Dear Ron,
>
>
>
> I love your definition of "compromise": "You do what we tell you to do".
>
>
>
> Is this PSP removal crusade targeted to buy more time by making PSP
> illegal till undefined future ?
>
>
>
> Compromise in my books here would be to make PSP optional - but wait as
> stated already this is already optional today ! Node signals zero SIDs for
> PSP and it is no longer the problem for the node.
>
>
>
> Can you please at least one admit what real technical problem we are
> facing here with PSP ?
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
> On Fri, Feb 28, 2020 at 4:43 PM Ron Bonica <rbonica=
> 40juniper.net@dmarc..ietf.org <40juniper.net@dmarc.ietf.org>> wrote:
>
> Folks,
>
>
>
> I think that it is time to find a compromised regarding
>  draft-ietf-spring-network-programming. How does the following sound:
>
>
>
>    - Pablo removes Section 4.16 and all references to PSP from
>     draft-ietf-spring-network-programming and puts all of that content into
>    another draft
>    - The WG progresses  draft-ietf-spring-network-programming
>    - I will produce a document that updates The Devil’s Paragraph, as
>    described in
>    https://mailarchive.ietf.org/arch/msg/ipv6/Xm2RTBm-Hh_ZVUa5El4To1zopSg/
>    <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/Xm2RTBm-Hh_ZVUa5El4To1zopSg/__;!!NEt6yMaO-gk!W2xefXaqF7bCEvwwJzYm50yERn2CAwXiLDnW35LOPI-svSvs6VkVrAAuRJ97tLTn$>...
>    The draft will allow removal of the RH, but only when Segments Left equals
>    zero and when that action was requested by the source node as in
>    https://mailarchive.ietf.org/arch/msg/ipv6/cXpzCLOVQ1OOUPGU13ZNnQWDVIA/
>    <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/cXpzCLOVQ1OOUPGU13ZNnQWDVIA/__;!!NEt6yMaO-gk!W2xefXaqF7bCEvwwJzYm50yERn2CAwXiLDnW35LOPI-svSvs6VkVrAAuRMGNWUzC$>
>    ...
>    - When that draft progresses, Pablo’s PSP draft can progress
>    - Until then, vendors can ship whatever they want (since they are
>    shipping already).
>
>
>
> I would by happy to produce a first draft of the document that updates
> 8200.
>
>
>
>
>                                                                                                               Ron
>
>
>
>
>
> Juniper Business Use Only
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!W2xefXaqF7bCEvwwJzYm50yERn2CAwXiLDnW35LOPI-svSvs6VkVrAAuRPsBaDm0$>
>
>
>
> Juniper Business Use Only
>
>