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= 40juniper....@dmarc.ietf.org> 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=40cisco....@dmarc.ietf.org> > *Sent:* Thursday, May 28, 2020 7:46 AM > *To:* Ron Bonica <rbon...@juniper.net>; Joel M. Halpern < > j...@joelhalpern.com> > *Cc:* rtg-...@ietf.org; spring@ietf.org; 6man <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, > > > > 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=40juniper....@dmarc.ietf.org> > > Sent: 25 May 2020 21:14 > > To: Ketan Talaulikar (ketant) <ket...@cisco.com>; Joel M. Halpern < > j...@joelhalpern.com> > > Cc: rtg-...@ietf.org; spring@ietf.org; 6man <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> > > Sent: Monday, May 25, 2020 5:21 AM > > To: Ron Bonica <rbon...@juniper.net>; Joel M. Halpern <j...@joelhalpern.com > > > > Cc: rtg-...@ietf.org; spring@ietf.org; 6man <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> > > Sent: 25 May 2020 09:03 > > To: Ketan Talaulikar (ketant) <ket...@cisco.com>; Joel M. Halpern < > j...@joelhalpern.com> > > Cc: rtg-...@ietf.org; spring@ietf.org; 6man <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> On Behalf Of Ketan Talaulikar (ketant) > > Sent: Sunday, May 24, 2020 1:42 AM > > To: Joel M. Halpern <j...@joelhalpern.com> > > Cc: rtg-...@ietf.org; spring@ietf.org; 6man <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 > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
