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 <[email protected]>
Sent: Saturday, September 7, 2019 1:54 PM
To: Tom Herbert <[email protected]>
Cc: Ron Bonica <[email protected]>; [email protected]; [email protected]
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
<[email protected]<mailto:[email protected]>> wrote:
On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica
<[email protected]<mailto:[email protected]>>
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
> [email protected]<mailto:[email protected]>
> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!8WoA6RjC81c!XdaMALbhFo4TNFver8v6Zwv5qIQ2mxR2PiQiwPTEJ31TLT5m9oxN8yritAkWNZwq$>
Juniper Business Use Only
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
