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

[Ron Bonica <[e-mail]>]

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=
> --------------------------------------------------------------------