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

[Peter Psenak <[e-mail]>]

Hi Ron,

On 28/05/2020 18:55, Ron Bonica wrote:
> Weibin,
> 
> Inline…..
> 
>                       Ron
> 
> Juniper Business Use Only
> 
> *From:* Wang, Weibin (NSB - CN/Shanghai) <[e-mail]>
> *Sent:* Thursday, May 28, 2020 10:35 AM
> *To:* Ketan Talaulikar (ketant) <[e-mail]>; 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,
> 
> After reading through many mails related to CRH in list, I found all 
> CRH-SIDs (allocated to prefix-sid <loosely forwarding>and Adj-sid<strict 
> forwarding>) are of local significance in fact, its operation actually 
> is not same as MPLS Label nor SR-MPLS label (such as domain-wide prefix 
> SID/label), all CRH-SIDs are locally allocated by node itself based on 
> local FIB6, independent of other CRH-SID allocated by other nodes in CRH 
> domain; so every node (Maybe except  ingress PE of CRH domain)  has no 
> useful to learn other SIDs allocated by other nodes by IGP-extension 
> advertising. Its deployment must have controller (considering dynamic 
> mechanism), the controller learn all CRH-SIDs from each node to program 
> the source path under path calculation requirement from ingress PE.
> 
> [RB] Absolutely correct !!

if CRH-SIDs are of local significance how is the loose source routing 
going to be supported?

Or is CRH only supposed to be used for strict hop-by-hop source routing? 
If so, the use case would be quite limited.

Honestly, strictly technically, I do not see much difference between CRH 
and RFC8663 & RFC4023 combo. Former uses an extra extension header, the 
latter uses the next-header. Rest looks same.


thanks,
Peter



> 
> I suggested you should describe more detail about how to create CRH-SID 
> entry (in CRH-FIB) in this CRH draft, is it based on local FIB6, if it 
> is, how to do synchronization between CRH-FIB and FIB6?
> 
> [RB] In some deployment scenarios, the IPv6 FIB and the CRH-FIB are 
> populated by an IGP. Please review and comment on the IS-IS CRH document 
> <https://datatracker.ietf.org/doc/draft-bonica-lsr-crh-isis-extensions/>. I 
> am excited to collaborate with you on that .
> 
> [RB] In other deployment scenarios, the IPv6 FIB and / or the CRH-FIB 
> are populated by a controller. If you are interested in that scenario, 
> again, we would be excited to collaborate with you.
> 
>                                                     Ron
> 
> Above is my understanding, if not right,pls correct me.
> 
> Wang Weibin
> 
> *From:*ipv6 <[e-mail] <mailto:[e-mail]>> *On 
> Behalf Of *Ketan Talaulikar (ketant)
> *Sent:* 2020年5月28日19:46
> *To:* Ron Bonica <rbonica=[e-mail] 
> <mailto:rbonica=[e-mail]>>; Joel M. Halpern 
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 6man <[e-mail] <mailto:[e-mail]>>
> *Subject:* RE: [spring] CRH is back to the SPRING Use-Case - Re: Size of 
> CR in CRH
> 
> 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!VMgRZ_fS_8pBN886aeeU1sFZpteVAkwQNu6xqWRsR27VhEn_wpAuXmcCngHDrhN8$>
> 
>     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] 
> <mailto:rbonica=[e-mail]>>
> 
> Sent: 25 May 2020 21:14
> 
> To: Ketan Talaulikar (ketant) <[e-mail] 
> <mailto:[e-mail]>>; Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>>
> 
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 6man <[e-mail] <mailto:[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] 
> <mailto:ketant=[e-mail]>>
> 
> Sent: Monday, May 25, 2020 5:21 AM
> 
> To: Ron Bonica <[e-mail] <mailto:[e-mail]>>; Joel 
> M. Halpern <[e-mail] <mailto:[e-mail]>>
> 
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 6man <[e-mail] <mailto:[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] 
> <mailto:rbonica=[e-mail]>>
> 
> Sent: 25 May 2020 09:03
> 
> To: Ketan Talaulikar (ketant) <[e-mail] 
> <mailto:[e-mail]>>; Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>>
> 
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 6man <[e-mail] <mailto:[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] <mailto:[e-mail]>> On 
> Behalf Of Ketan Talaulikar (ketant)
> 
> Sent: Sunday, May 24, 2020 1:42 AM
> 
> To: Joel M. Halpern <[e-mail] <mailto:[e-mail]>>
> 
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] 
> <mailto:[e-mail]>; 6man <[e-mail] <mailto:[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]
> 
> ------------------------------------------------------
>