> 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
