RE: [spring] Regaining Focus on SRv6 and SRv6+ - Service Chaining

[Ron Bonica <[e-mail]>]

+1


Juniper Business Use Only

-----Original Message-----
From: ipv6 <[e-mail]> On Behalf Of Joel M. Halpern
Sent: Saturday, September 7, 2019 7:01 PM
To: Robert Raszuk <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [spring] Regaining Focus on SRv6 and SRv6+ - Service Chaining

With regard to service chaining, with either SRv6 or SRv6+, the interoperable mechanism for service function chaining is to carry NSH. 
Carrying the content of the NSH header in SRv6 SRH PDUs, while technically doable, is complexity that is not needed.

Yours,
Joel

On 9/7/2019 6:54 PM, Robert Raszuk wrote:
> Hey Ron,
> 
>     You may need to rethink your argument. (That is, except for the part
>     where you said that I was smart!)
> 
> 
> ;-)
> 
>     ____
> 
>     The SRv6+ PPSI does replaces something int SRv6. But it does not
>     replace the SRH’s tags, flags or TLVs. It replaces the low order
>     bits in the last SID. More specially, it identifies a function to be
>     executed by SR egress node. It replaces functions like END.DT4,
>     END.DT6, END.DX4, END.DX6, etc.)____
> 
>     __ __
> 
>     As Tom says,  the CRH is much simpler to parse that the SRH. It
>     contains only five fields, four of which are mandated by RFC 8200.
>     (The other is the SID list.)
> 
> 
> 
> The point is that CRH alone is not enough to make any jugement about
> SRv6+ complexity.
> 
> 
>     ____
> 
>     Unlike TLVs, the PPSI is fixed length (32 bits). It identifies an
>     instruction to be executed on the SR egress node. Carries the same
>     information as an MPLS service label or the low order bits of the
>     final SID in as SRv6 SID list.
> 
> 
> When you can provide pointer to SFC document describing how it would 
> work with SRv6+ similar to 
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-xuclad-s
> pring-sr-service-chaining-00__;!8WoA6RjC81c!WOcr-ODRlejYVFb3cQeWtWE2yCWadubHStL7Tseto4hBUS9BwX-5S91En356M2wC$  which does require many elements from SRH we will resume the discussion.
> 
> 
>     What you say about the IPv6 Option registry being nearly full may be
>     a bit of an exaggeration. This is because the CHG bit is meaningful
>     of hop-by-hop options, but is totally meaningless for Destination
>     options. So, for destination options, the IPv6 option registry is
>     actually 6 bits wide.
> 
> 
> Are you proposing to split this registry into two ? to get 32 more 
> values for your destination options types ? And then what ?
> 
> Best,
> R.
> 
> PS from your last mail ...
> 
>  > Prepend an IPv6 header with its own Routing header
> 
> So this is exactly what I was concluding. The packet under TI-LFA 
> protection in SRv6+ will end up with three IPv6 fixed headers, min two 
> CRH headers, and anywhere from zero to two (depending on the functions
> required) Dest Options header before Routing Header.
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> __;!8WoA6RjC81c!WOcr-ODRlejYVFb3cQeWtWE2yCWadubHStL7Tseto4hBUS9BwX-5S9
> 1En06Jp28j$
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!WOcr-ODRlejYVFb3cQeWtWE2yCWadubHStL7Tseto4hBUS9BwX-5S91En06Jp28j$
--------------------------------------------------------------------