Thx Jim ! Apologies - I spotted one typo in my mail: s/ as a new transport./ It is a new transport./
On Wed, Feb 26, 2020 at 2:44 PM James Guichard < james.n.guich...@futurewei.com> wrote: > +1 and well said! > > > > *From:* spring <spring-boun...@ietf.org> *On Behalf Of *Robert Raszuk > *Sent:* Wednesday, February 26, 2020 8:06 AM > *To:* Mark Smith <markzzzsm...@gmail.com> > *Cc:* Xiejingrong (Jingrong) <xiejingr...@huawei.com>; Ron Bonica < > rbon...@juniper.net>; spring@ietf.org; Joel M. Halpern < > j...@joelhalpern.com>; Pablo Camarillo (pcamaril) <pcama...@cisco.com> > *Subject:* Re: [spring] Is srv6 PSP a good idea > > > > > > > Somebody choosing not to use AH doesn't mean SPRING can ignore the IPv6 > specifications. > > > > I think it sure can and in fact it should. > > > > See there is perhaps key misunderstanding here. > > > > Regardless if folks agree or not with that SRv6 is a new data plane. SRv6 > != IPv6 that's obvious. > > > > It also does not attempt to *extend* IPv6. It reuses some IPv6 elements > and makes sure non SRv6 nodes can treat the packets as vanilla IPv6, but > that's it. With that in mind all of this going back and forth > between SPRING and 6MAN to me is triggered by wrong positioning of SRv6 as > a new transport. > > > > Sure if SRv6 would be extending IPv6 then updates to RFC8200 would be > needed - but here RFC8200 should at best be informative reference. I am not > even sure why SRH needs to be 6MAN RFC. IETF is designed to build and > improve prior art not be locked by it. > > > > Cheers, > > R. > > > > > > > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
