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<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]
------------------------------------------------------
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
