Sounds good for a intra-AS solution. Dino
> On Apr 12, 2019, at 7:38 AM, Ron Bonica <[email protected]> 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 <[email protected]> On Behalf Of Dino Farinacci >> Sent: Thursday, April 11, 2019 11:21 PM >> To: Mark Smith <[email protected]> >> Cc: [email protected]; SPRING WG <[email protected]>; [email protected]; Robert >> Raszuk <[email protected]> >> 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 <[email protected]> >> wrote: >>> >>> Hi Robert, >>> >>> Sorry not to get back to you sooner. >>> >>>> On Mon, 1 Apr 2019 at 01:40, Robert Raszuk <[email protected]> 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 >> [email protected] >> 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= >> -------------------------------------------------------------------- _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
