Robert, You've chosen to selectively comment on only parts of what I wrote, not the main thesis which is that SRV6 packet format is more complex than SRV6+.
The most obvious difference, besides SID size, is that SRV6 contains TLVs and SRV6+ doesn't. I don't believe that this was ever needed, HBH and destination already exist in RC8200 and could have been used as they will be in SRV6+. Similarly, AH could have been used instead of defining SR specific HMAC. Furthermore, several implementations of SRV6 are listed in draft-ietf-6man-segment-routing-header-22; all except one have the words "no TLV processing". The exception is Linux, which doesn't not implement SR TLVs per the standard and wouldn't interoperate with an implementation that is conformant (I have looked at the Linux code and in fact have suggested a fix). So the claim that SRV6 is mature and deployed is suspect considering there doesn't seem to be proper support for TLVs which is a major part of the protocol. Based on this analysis, I believe my statement that SRV6 format is more complex than SRV6+ is factual. It's my opinion that SRV6, particularly because of TLVs, is overly complex. Tom On Sat, Sep 7, 2019 at 10:54 AM Robert Raszuk <rob...@raszuk.net> wrote: > > > > It doesn't depend on extension header insertion > > Nothing depends on extension header insertion ... SRH insertion is an > optional optimization. > > > and there's no need to have multiple routing headers in the same packet. > > Really ? > > If I am doing SRv6+ in my network for TE and want to to do TI-LFA how would I > not end up with 3 IPv6 fixed headers and two Dest Option EHs and two CRH EHs > in the packet under protection ? > > But this is just tip of the ugliness iceberg ... > > All required extensions to protocols developed in to name just a few already > proposed by SRv6+ authors: IDR, LSR, BESS and 6MAN WG to support the new > mapping (which is other then nomenclature close to SR-MPLS mapping) will > require real development resources. > > OAM in spite of few claims from Ron that "just works" is not addressed and > does require even more extensions. > > Then last I will not be able to use SRv6+ for my deployment needs in the > global IPv6 overlay I am running simply that within my overlay I do not plan > to run any control plane. Underlay basic reachability provided by third > parties is all I need to construct optimal paths. So any protocol which > requires new signalling to distribute mapping is non starter. > > At the end we should learn from others ... (hint SDWANs) and avoid mistakes > of the past (hint: LDP). > > Many thx, > R. > > > > > > > > > On Sat, Sep 7, 2019 at 6:41 PM Tom Herbert <t...@herbertland.com> wrote: >> >> On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica >> <rbonica=40juniper....@dmarc.ietf.org> wrote: >> > >> > Folks, >> > >> > >> > >> > We have explored many facets of SRv6 and SRv6, sometime passionately. I >> > think that this exploration is a good thing. In the words of Tolkien, “All >> > who wander are not lost.” >> > >> > >> > >> > But it may be time to refocus on the following: >> > >> > >> > >> > For many operators, SRv6 is not deployable unless the problem of header >> > length is addressed >> > Many objections the uSID proposal remain unanswered >> > SRv6+ offers an alternative solution >> > >> > >> > >> > Given these three facts, I think that it would be a mistake to discontinue >> > work on SRv6+. >> > >> + 1 >> >> I'd suggest a fourth fact. The packet format of SRv6+ is much simpler >> than SRv6 and the protocol works better with existing mechanisms and >> protocols of IPv6 like Destination and HBH options, as well as AH. It >> doesn't depend on extension header insertion and there's no need to >> have multiple routing headers in the same packet. >> >> Tom >> >> >> > >> > >> > >> > Ron >> > >> > >> > >> > >> > Juniper Business Use Only >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > i...@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
