Ron, > SRv6+ relies on prepending
Interesting ... can you elaborate how you will do TI-LFA with SRv6+ ? If you have slides showing packet format when TI-LFA is performed in the middle of SRv6+ domain please just kindly fell free to share a pointer to it. > I don’t understand your comment about two destination headers And I do not understand what you may not understand. Is your "prepending" the same what some may consider "insertion" then ? Thx, R. On Sat, Sep 7, 2019 at 11:52 PM Ron Bonica <rbonica= 40juniper....@dmarc.ietf.org> wrote: > Robert, > > > > Tom is correct. In SRv6+, there is never any need for one packet to > contain two routing headers. SRv6+ relies on prepending, in all cases, > including TI-LFA. > > > > Because the CRH is short, this works just fine. > > > > I don’t understand your comment about two destination headers. You might > want to rethink that. > > > > Ron > > > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Saturday, September 7, 2019 1:54 PM > *To:* Tom Herbert <t...@herbertland.com> > *Cc:* Ron Bonica <rbon...@juniper.net>; spring@ietf.org; 6...@ietf.org > *Subject:* Re: [spring] Regaining Focus on SRv6 and SRv6+ > > > > > > > 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 > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!XdaMALbhFo4TNFver8v6Zwv5qIQ2mxR2PiQiwPTEJ31TLT5m9oxN8yritKT7Pxrp$> > > -------------------------------------------------------------------- > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!XdaMALbhFo4TNFver8v6Zwv5qIQ2mxR2PiQiwPTEJ31TLT5m9oxN8yritAkWNZwq$> > > > > 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
