Re: [lisp] [spring] IPv6-compressed-routing-header-crh

[Dino Farinacci <[e-mail]>]

Sounds good for a intra-AS solution.

Dino

> On Apr 12, 2019, at 7:38 AM, Ron Bonica <[e-mail]> wrote:
> 
> Dino,
> 
> Please stand by for ISIS Extensions To Support the CRH. At the moment, it is ten pages long, including two pages of boilerplate and two pages of references.
> 
>                                                                                                                         Ron
> 
> 
> 
> Juniper Internal
> 
>> -----Original Message-----
>> From: ipv6 <[e-mail]> On Behalf Of Dino Farinacci
>> Sent: Thursday, April 11, 2019 11:21 PM
>> To: Mark Smith <[e-mail]>
>> Cc: [e-mail]; SPRING WG <[e-mail]>; [e-mail]; Robert
>> Raszuk <[e-mail]>
>> Subject: Re: [spring] IPv6-compressed-routing-header-crh
>> 
>> So it looks like SR is either turning out to be like LISP or BIER, or both. So
>> where is the unique value?
>> 
>> The next step is you’ll need a control plane (where discussions have begun)
>> where it makes SR even more like LISP and support for multicast (where
>> discussions have begun) where it makes SR even more like BIER.
>> 
>> Dino
>> 
>>> On Apr 11, 2019, at 7:59 PM, Mark Smith <[e-mail]>
>> wrote:
>>> 
>>> Hi Robert,
>>> 
>>> Sorry not to get back to you sooner.
>>> 
>>>> On Mon, 1 Apr 2019 at 01:40, Robert Raszuk <[e-mail]> wrote:
>>>> 
>>>> Hi Mark,
>>>> 
>>> <snip>
>>>> 
>>>> Since you correctly observed that now SID can be 32 bit and that is similar
>> to the size of IPv4 my fundamental question is why not use something which
>> already exists instead of defining some sort of new  from scratch ?
>>>> 
>>>> It will be perfectly fine to have full proper SRv6 with SRH and LISP or
>> Vector Routing as an alternative options. I really do not see a room or need for
>> yet one more mapping plane. What problem does it solve which would not be
>> already solved elsewhere ?
>>>> 
>>> 
>>> Well, there seems to be or have been concerns about the overhead of
>>> using 128 bit SIDs in IPv6. That seemed to be the motivation for EH
>>> insertion.
>>> 
>>> I sympathise with the overhead concern, although I'd be quite happy to
>>> put up with the overhead and bandwidth costs of full IPv6-in-IPv6
>>> tunnelling in comparison to non-commodity operations like inserting
>>> the SRH EH into existing IPv6 packets to avoid that overhead.
>>> Bandwidth is always getting cheaper.
>>> 
>>> I think the value in using IPv6 as the transport for SR is that IPv6
>>> is becoming and will be the future the commodity layer 3 protocol.
>>> MPLS may be fairly commodity, however IPv6 will be more so, and I
>>> think the reason is that it is an end-to-end protocol that hosts use
>>> (I think this is also why Ethernet has become the dominant link-layer
>>> protocol, even for WAN links).
>>> 
>>> So if SR wants to benefit from and leverage IPv6's commodification,
>>> then it needs to be limited to commodity IPv6 operations. If it
>>> deviates, then it isn't commodity IPv6 any more.
>>> 
>>> So my motivation for suggesting 32 bit SIDs in IPv6, and I'm guessing
>>> Ron's too for his smaller variable SIDs proposal including 32 bits, is
>>> to try to reduce the overhead of SR over IPv6, while also retaining
>>> commodity IPv6 operation.
>>> 
>>> Regards,
>>> Mark.
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://urldefense.proofpoint.com/v2/url?u=https-
>> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
>> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
>> AWF2EfpHcAwrDThKP8&m=dnxJ4ZzYGvZ8uKFytr8PMMHi5uD35z5ACAx67
>> WEngXc&s=83q1T8NObaNS1omQoJRKsQ-b3a-x-_vIbE_LZmviPJ4&e=
>> --------------------------------------------------------------------