Re: [spring] Regaining Focus on SRv6 and SRv6+

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.net@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 <robert@raszuk.net>
> *Sent:* Saturday, September 7, 2019 1:54 PM
> *To:* Tom Herbert <tom@herbertland.com>
> *Cc:* Ron Bonica <rbonica@juniper.net>; spring@ietf.org; 6man@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 <tom@herbertland.com> wrote:
>
> On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica
> <rbonica=40juniper.net@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
> > ipv6@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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>