I second this - and I was extremely clear in my email to spring a few weeks ago
- I believe that there is place for both srv6+ and the alternatives -
especially since I point out that srv6+ solves an overhead problem that was not
solved by srh or the programming draft - and actually pre-dates the usid
mechanism.
Do I believe that the NP draft needs work to bring it inline with the consensus
agreed approach to rfc8200 and potentially an update to rfc4291 needs to be
done to sort out the semantic issues? Certainly - but that is not to say I want
the work to stop - on the contrary - I have said it before - and will say it
again - I believe we should work on both - and potentially have an interop
draft where necessary - and then - let the operators make the choice as to
which they wish to use.
There are people on this list who can attest to the fact that I broached the
subject of interop with several vendors - and even the authors of some of the
drafts under discussion - and I am more than happy to do the work on this if
people are willing to join the effort.
Andrew
Liquid Telecommunications - Group Head Of IP Strategy
________________________________
From: ipv6 <ipv6-boun...@ietf.org> on behalf of Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org>
Sent: Friday, September 6, 2019 18:50
To: Robert Raszuk
Cc: Fernando Gont; spring@ietf.org; 6...@ietf.org
Subject: RE: [spring] Question about SRv6 Insert function
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
