Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH

[Tony Przygienda <[e-mail]>]

I can beat that ;-) AFAIR, my first job in IBM in the 80s was to remove
loose source routing code from token ring bridges since it was causing
operationally too many problems ...

-- tony

On Thu, May 28, 2020 at 8:13 AM Ron Bonica <rbonica=
[e-mail]> wrote:

> Ketan,
>
>
>
> Neither of these forwarding methods are unique to SR.. In Section 3.1 of
> RFC 791, you will see that IPv4 had a Strict Source Route Option and a
> Loose Source Route Option. These predate SR by roughly twenty-five years.
>
>
>
>
> Ron
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Ketan Talaulikar (ketant) <ketant=[e-mail]>
> *Sent:* Thursday, May 28, 2020 7:46 AM
> *To:* Ron Bonica <[e-mail]>; Joel M. Halpern <
> [e-mail]>
> *Cc:* [e-mail]; [e-mail]; 6man <[e-mail]>
> *Subject:* RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of
> CR in CRH
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Ron,
>
>
>
> Some of the operators may not care about the SR name, but it is clear to
> me that the proposal in the CRH draft is a subset of Segment Routing (i.e.
> a reduced portion of Spring Architecture) that only supports prefix and
> adjacency SIDs as indicated by the two "forwarding methods".
>
>
>
> https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22#section-4
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-22*section-4__;Iw!!NEt6yMaO-gk!WUUoiYhNiQq44bqITjU9p16KKdON00tbtfOIgQoDmKHLycmNLLtVobJe9BtxN6V1$>
>
>
>
>    o  Forward the packet to the next-hop along the least-cost path to *>>>
> Prefix SID*
>
>       the next segment endpoint.
>
>
>
>    o  Forward the packet through a specified interface to the next *>>>
> Adjacency SID*
>
>       segment endpoint.
>
>
>
> Given the use of mapping IDs and mapping FIB, the proposal is comparable
> more to SR-MPLS than SRv6. It is better to do a holistic analysis of any
> proposal such as CRH that is introducing an MPLS label like mapping
> construct into IPv6 architecture - doing so should be considered as a
> significant change to IPv6.
>
>
>
> Thanks,
>
> Ketan
>
>
>
> -----Original Message-----
>
> From: Ron Bonica <rbonica=[e-mail]>
>
> Sent: 25 May 2020 21:14
>
> To: Ketan Talaulikar (ketant) <[e-mail]>; Joel M. Halpern <
> [e-mail]>
>
> Cc: [e-mail]; [e-mail]; 6man <[e-mail]>
>
> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR
> in CRH
>
>
>
> Ketan,
>
>
>
> It would not be fair to say that these operators  "wish to deploy a
> Traffic Engineering solution using a subset of Segment Routing".
>
>
>
> It would be fair to say that these operators  "wish to deploy IPv6 Traffic
> Engineering".  Some of these operators don't care about SR. Some are
> actively averse to SRv6. All they want is a Routing header.
>
>
>
>                                                                  Ron
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
>
>
> -----Original Message-----
>
> From: Ketan Talaulikar (ketant) <ketant=[e-mail]>
>
> Sent: Monday, May 25, 2020 5:21 AM
>
> To: Ron Bonica <[e-mail]>; Joel M. Halpern <[e-mail]
> >
>
> Cc: [e-mail]; [e-mail]; 6man <[e-mail]>
>
> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR
> in CRH
>
>
>
> [External Email. Be cautious of content]
>
>
>
>
>
> Hi Ron,
>
>
>
> Thanks for that clarification.
>
>
>
> I note that you are not anymore saying "Are not interested in SR" like you
> had mentioned before the WG adoption call :
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$
> <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ipv6/LheyFD_uwuHp7tiG8Y1CwKngDYI/__;!!NEt6yMaO-gk!X2qW2zTZEbZRfBSE6c_KM-k7aIvZTIT9bycp3jyFJ3sTbf8MtGo4E_uGX7zYZ7lk$>
>
>
>
> So, would it be fair to say that the operator that you are referring to
> below, wishes to deploy a Traffic Engineering solution using a subset of
> Segment Routing (i.e. a reduced portion of Spring Architecture) that only
> supports prefix and adjacency SIDs as indicated by the two "forwarding
> methods" that are referred to in draft-bonica-6man-comp-rtg-hdr?
>
>
>
> Thanks,
>
> Ketan
>
>
>
> -----Original Message-----
>
> From: Ron Bonica <rbonica=[e-mail]>
>
> Sent: 25 May 2020 09:03
>
> To: Ketan Talaulikar (ketant) <[e-mail]>; Joel M. Halpern <
> [e-mail]>
>
> Cc: [e-mail]; [e-mail]; 6man <[e-mail]>
>
> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR
> in CRH
>
>
>
> Ketan,
>
>
>
> Please consider an operator who:
>
>
>
> - Wants a way to steer IPv6 packets through a specified path that includes
> many nodes (>8)
>
> - Does not want any of the following:
>
>         - A new VPN encapsulation technique
>
>         - A new service function chaining technique
>
>         - Network programming
>
>         - MPLS and uSID
>
>         - To encoding instructions in IPv6 addresses.
>
>
>
> These operators want a compact routing header, nothing more.
>
>
>
>
> Ron
>
>
>
>
>
> Juniper Business Use Only
>
>
>
> -----Original Message-----
>
> From: ipv6 <[e-mail]> On Behalf Of Ketan Talaulikar (ketant)
>
> Sent: Sunday, May 24, 2020 1:42 AM
>
> To: Joel M. Halpern <[e-mail]>
>
> Cc: [e-mail]; [e-mail]; 6man <[e-mail]>
>
> Subject: RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR
> in CRH
>
>
>
> [SNIP]
>
>
>
> I am looking for explanation of the "other ways" that CRH can be used
> (i.e. those outside the Spring architecture). I am trying to understand
> from the authors what would be the applicability of that solution, it's
> use-cases and it's requirements. That is what, I believe, will help us
> evaluate the CRH proposal in the context of this working call. That will
> help us answer these questions like the scope of the SID, 32-bit or 16-bit
> or something else and what the CRH-FIB is going to turn out like.
>
>
>
>
>
> [SNIP]
>
> ------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>