Hi Gyan, Thanks again for sharing your perspective and I believe the points you make would certainly contribute in the analysis of different SR mechanisms and their pros/cons. So I definitely see the value of the points that you make and they seem to set the context for the use-cases and requirements for SRm6. May I suggest that the SRm6 authors incorporate your inputs into their draft for review?
Sadly, with this WG adoption call for just the CRH draft, we seem to be bypassing all of those very important analysis and discussions of SRm6 in Spring. Seems like the cart has been put before the horse in this case. Thanks, Ketan From: Gyan Mishra <hayabusa...@gmail.com> Sent: 28 May 2020 20:27 To: Ketan Talaulikar (ketant) <ket...@cisco.com> Cc: 6man <6...@ietf.org>; Joel M. Halpern <j...@joelhalpern.com>; Ron Bonica <rbon...@juniper.net>; rtg-...@ietf.org; spring@ietf.org Subject: Re: [spring] CRH is back to the SPRING Use-Case - Re: Size of CR in CRH On Thu, May 28, 2020 at 7:46 AM Ketan Talaulikar (ketant) <ketant=40cisco....@dmarc..ietf.org<mailto:40cisco....@dmarc.ietf.org>> wrote: 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 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. Gyan> Ketan - you are misunderstanding the CRH architecture. It uses the IPv6 data plane so is a variant of SRV6 and not SR-MPLS. SR-MPLS reused then MPLS data plane to create fec bindings and uses label stacking for steering cSPF static lsp using the MPLS forwarding plane. Operators that want CRH don’t want to go backwards and use SR-MPLS and have the baggage of MPLS data plane as in general these are green field operators use cases. SR-MPLS he it’s place and where it shines and works well is for brown field operators with existing MPLS LDPv4 deployments it’s a simple migration to SR-MPLS. For operators that already have an IPV6 core or are running MPLS LDPv6 brown field deployments, then then SRV6 or now CRH or SRM6 are the viable options. CRH introduces a new RH similar to RH0 or any of the other new RH introduces for simple source routing which has been around since IPv4. CRH does not use the segments in the RH to build the actual static hop by hop steered path as does SR-MPLS via SRGB block label stacking. Remember CRH is just another IPV6 Routing header. However now instead of copying the routing segment into the segment list to the IPv6 destination address as done with SRV6 their is one simple extra step. A CRH-FIB entry is created manually that is referenced by the routing segment and that entry is the IPv6 address that is copied to the next hop destination address to steer the packet hop by hop. By not storing the IPV6 address in the CRH RH you save all the problem with MSD(Maximum SID depth) issues that occur in with SRv6 which really makes SRV6 not viable for long strict SR-TE paths using adjacency sid that are more then a few hops due to MSD issue. SRV6 has its complex programming with end prefix sid and end.x adjacency sid instantiations overhead that makes SRV6 not viable for operators that don’t want to add in all the additional complexity of the many compression drafts 6+ that exist today to resolve the MSD issue. Speaking from an operator perspective, representing Verizon a Tier 1 carrier, we have use cases as other carriers for intra domain very very long static per VRF coloring of L3 vpn instantiated strict paths using SR-TE and flexalgo. However SRv6 by itself does not stack up and requires use of the compression techniques for SR-TE per VRF coloring. Unfortunately for SRV6 it failed to start out of the gate natively and could not deliver on per VRF coloring of long strict paths using SR-TE binding SID which is what the industry has been clamoring for. The major benefit for CRH is that natively it can have very very long strict hop by hop steered paths without requiring additional complexity component for compression techniques to make it work as does SRV6. SRv6 has its place in the industry and works well with short cSPF paths using prefix sid and staying away from hop by hop long strict explicit paths. And if you are willing to add the complexity of one of the many compression techniques then so be it and that makes SRV6 viable as well as an option for operators requiring long strict paths. For Verizon we would use SRM6 as it is the full blown version of CRH as it has the IGP extensions and supports SR-TE binding sid. For the many use cases where a very long strict hop by hop path is required and you want to use your existing IPv6 data plane, then CRH is the answer as it is a low overhead means of source routing and works plug-n-play out of the box using the IPv6 data plane. No need for any of the many compression techniques as required by SRv6 for building strict paths. CRH is no different then RFC 8138 RH used for 6lo devices. https://tools.ietf.org/html/rfc8138 The comments related to SR-MPLS over IPv6 RFC 8663 using tunneling techniques RFC 4023 MPLS over GRE in IPinIP w/o GRE using IPv6 outer header similar to Universal SID draft used for SRV6 to SR-MPLS interworking. There are use case for using RFC 8663 but that in my mind would be for Mirsky Universal SID interoperability use cases where you require interworking between SR-MPLS and SRv6 the tunneling of SR-MPLS in outer IPV6 header with RFC 8663. https://datatracker.ietf.org/doc/html/draft-mirsky-6man-unified-id-sr-06 This is completely different from CRH.. If you need interworking you use RFC 8663 with Mirsky draft or if you need a very simple low overhead technique for source routing capability that works right out of the box then CRH is the answer. Kind Regards Ketan -----Original Message----- From: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>> Sent: 25 May 2020 21:14 To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6...@ietf.org<mailto:6...@ietf.org>> 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=40cisco....@dmarc.ietf.org<mailto:ketant=40cisco....@dmarc.ietf.org>> Sent: Monday, May 25, 2020 5:21 AM To: Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>; Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6...@ietf.org<mailto:6...@ietf.org>> 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=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>> Sent: 25 May 2020 09:03 To: Ketan Talaulikar (ketant) <ket...@cisco.com<mailto:ket...@cisco.com>>; Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6...@ietf.org<mailto:6...@ietf.org>> 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 <ipv6-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>> On Behalf Of Ketan Talaulikar (ketant) Sent: Sunday, May 24, 2020 1:42 AM To: Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Cc: rtg-...@ietf.org<mailto:rtg-...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; 6man <6...@ietf.org<mailto:6...@ietf.org>> 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 i...@ietf.org<mailto:i...@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
