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

[Ron Bonica <[e-mail]>]

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 <[e-mail]>
Sent: Saturday, September 7, 2019 6:06 PM
To: Ron Bonica <[e-mail]>
Cc: Tom Herbert <[e-mail]>; [e-mail]; [e-mail]
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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, September 7, 2019 1:54 PM
To: Tom Herbert <[e-mail]<mailto:[e-mail]>>
Cc: Ron Bonica <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Sep 6, 2019 at 6:08 AM Ron Bonica
<rbonica=[e-mail]<mailto:[e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> 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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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