Robert,
I don't have slides, but it should be pretty easy to describe. Rather than
inserting a second Routing header between the IPv6 header and the existing
router, Arv6+ the following:
* Update SL and the IPv6 destination address, if required
* Prepend an IPv6 header with its own Routing header
Also, I don't understand your comment about a packet with two SRv6+ Destination
Options headers. I can't think of a situation where that ever happens.
Ron
From: Robert Raszuk <rras...@gmail.com>
Sent: Saturday, September 7, 2019 6:06 PM
To: Ron Bonica <rbon...@juniper.net>
Cc: Tom Herbert <t...@herbertland.com>; spring@ietf.org; 6...@ietf.org
Subject: 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....@dmarc.ietf.org<mailto: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<mailto:rob...@raszuk.net>>
Sent: Saturday, September 7, 2019 1:54 PM
To: Tom Herbert <t...@herbertland.com<mailto:t...@herbertland.com>>
Cc: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>;
spring@ietf.org<mailto:spring@ietf.org>; 6...@ietf.org<mailto: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<mailto:t...@herbertland.com>> wrote:
On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org<mailto: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<mailto: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<mailto: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<mailto:i...@ietf.org>
Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!SOWprbKRa0W6SRURXfpr9dxa4D5a-kglw9RZB_d_5dbCFgTF_OFbf2d0jVaRm6Jj$>
--------------------------------------------------------------------
Juniper Business Use Only
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
