Re: [spring] Question about SRv6 Insert function

[Robert Raszuk <[e-mail]>]

Well the term "*shut* *down"* is not precise here. IETF can not shut any
work .. you can keep working on anything you like and keep submitting
individual drafts for it. If you are nice to an AD he me even sponsor it
for publication.

SPRING WG however already has spectrum of mature solutions which address
the problem space - so adopting new proposal now would be more of
distraction then anything else. Also note that SPRING WG adoption will have
an avalanche effect as number of WGs are waiting for SPRING to consider
SRv6+ related drafts to be adopted or not.

Thank you,
R.


On Fri, Sep 6, 2019 at 5:47 PM Ron Bonica <[e-mail]> wrote:

> Robert,
>
>
>
> Your comment about killing innovation in the IETF strikes me as being odd.
> I never recommended shutting down SRv6 work. In fact, I support it.
>
>
>
> It is you who are asking to shut down SRv6+ work.
>
>
>
> So, who is looking to kill innovation in the IETF?
>
>
>
>                                                      Ron
>
>
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Friday, September 6, 2019 4:18 AM
> *To:* Ron Bonica <[e-mail]>
> *Cc:* Darren Dukes (ddukes) <[e-mail]>; Fernando Gont <
> [e-mail]>; [e-mail]; [e-mail]
> *Subject:* Re: [spring] Question about SRv6 Insert function
>
>
>
> Ron,
>
>
>
> > They remind us that draft-ietf-spring-network-programming are far from
> maturity.
>
>
>
> To me it actually highlights something quite contrary. It is that some
> folks are pretty far from appreciating or even grasping the value of the
> proposal.
>
>
>
> In your other note you have extensively elaborated well on how to
> effectively kill innovation in IETF. If we would be following your advice
> there would be almost non documents which build on former work and update
> former work.
>
>
>
> But most importantly documenting something does not force anyone to
> actually use it if they choose so. This entire smoke about header insertion
> from what I have been told has some technical concerns about real source
> awareness about say MTU issues. Well for one if I am doing insertion in my
> network I better make sure I do not drop the packet based on the MTU. It is
> so basic ... of course I must clean up when I fwd the packet to other
> domain but this is basic network hygiene.
>
>
>
> In the same time folks are happy to encap + add EHs, DOs etc ... on the
> grounds that src of the encap will be in the packet. Is this sufficient ..
> even if ICMP is sent to such src (domian ingress) I bet such domain ingress
> will not notify the original packet src anyway. And with encap the packet
> gets much bigger anyway.
>
>
>
> But I was not part of v6 creators and I think I will keep it that way
> based on that little thread we had here :)
>
>
>
> Best,
>
> R.
>
>
>
>
>
> Juniper Business Use Only
>