On 29/05/2020 12:12, Gyan Mishra wrote:
On Fri, May 29, 2020 at 5:11 AM Peter Psenak
<ppsenak=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org>>
wrote:
Hi Ron,
On 28/05/2020 18:55, Ron Bonica wrote:
> Weibin,
>
> Inline…..
>
> Ron
>
> Juniper Business Use Only
>
> *From:* Wang, Weibin (NSB - CN/Shanghai)
<weibin.w...@nokia-sbell.com <mailto:weibin.w...@nokia-sbell.com>>
> *Sent:* Thursday, May 28, 2020 10:35 AM
> *To:* Ketan Talaulikar (ketant) <ket...@cisco.com
<mailto:ket...@cisco.com>>; 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,
>
> 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.
Gyan> Peter - You mentioned a key point which is is a major
difference.
I thank you for pointing out this critical point for everyone in both
Spring WG & 6MAN WG -now one big happy family🙏😀
With RFC 8663 SR-MPLS over
IPV6 using RFC 4023 w/o GRE with IPv6 encap here is what the end result
of the packet looks like:
SR-MPLS over IPv6 = Next header encapsulation
IPv6 | SR-MPLS |. Customer payload
Operators wanting CRH don’t want the MPLS Layer 2 1/2 MPLS data plane
insertion into the packet mucking up the packet and want to stay clear
of MPLS since they want a clean and pure IPV6 packet that follows RFC
8200 IPV6 specification.
you don't want MPLS, so you wrap the same data to a new extension header
and give it a new name. And you suddenly like it. Hmm, does not sound
like a solid technical argument to me.
thanks,
Peter
So the use case for RFC 8663 is very different as it is widely deployed
for interworking SR-MPLS with SRV6 - Outlined in Mirsky draft below:
https://datatracker.ietf.org/doc/html/draft-mirsky-6man-unified-id-sr-06
CRH is no different then using any other routing header proposal such as
6lo for RPL.
https://tools.ietf.org/html/rfc8138
CRH Packet format:
IPV6 CRH | Customer payload
The additional encapsulation makes a big difference and it’s really
apples versus oranges and not the same at all.
Why would any operator use SR-MPLS over IP to for steering traffic if
they have an existing IPV6 data plane they want to utilize.
They would use SRv6 or CRH and would pick CRH to avoid MSD (maximum sid
depth) issues for long strict paths and not have to deal with extra
complexity of all the compression variants.
Decision tree:
If an operator wanted an MPLS data plane variant they would go with
SR-MPLS but if they want IPV6 data plane variant they obviously would
pick an option that uses IPv6 data plane and that would be the SRV6 or CRH.
In order to even remotely justify from my point of view that SR-MPLS
over IPv6 would used for anything other than the obvious “interworking”
between SR-MPLS and SRV6, you would really have to prove that an
operator is willing to add MPLS into the mix when they want IPV6. Not
possible.
I can guarantee no operator would do that.
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 <ipv6-boun...@ietf.org <mailto:ipv6-boun...@ietf.org>
<mailto:ipv6-boun...@ietf.org <mailto:ipv6-boun...@ietf.org>>> *On
> Behalf Of *Ketan Talaulikar (ketant)
> *Sent:* 2020年5月28日19:46
> *To:* Ron Bonica <rbonica=40juniper....@dmarc.ietf.org
<mailto:40juniper....@dmarc.ietf.org>
> <mailto:rbonica <mailto:rbonica>=40juniper.....@dmarc.ietf.org
<mailto:40juniper....@dmarc.ietf.org>>>; Joel M. Halpern
> <j...@joelhalpern.com <mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>>
> *Cc:* rtg-...@ietf.org <mailto:rtg-...@ietf.org>
<mailto:rtg-...@ietf.org <mailto:rtg-...@ietf.org>>; spring@ietf.org
<mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>; 6man
<6...@ietf.org <mailto:6...@ietf.org> <mailto:6...@ietf.org
<mailto:6...@ietf.org>>>
> *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=40juniper....@dmarc.ietf.org
<mailto:40juniper....@dmarc.ietf.org>
> <mailto:rbonica <mailto:rbonica>=40juniper.....@dmarc.ietf.org
<mailto:40juniper....@dmarc.ietf.org>>>
>
> Sent: 25 May 2020 21:14
>
> To: Ketan Talaulikar (ketant) <ket...@cisco.com
<mailto:ket...@cisco.com>
> <mailto:ket...@cisco.com <mailto:ket...@cisco.com>>>; Joel M.
Halpern <j...@joelhalpern.com <mailto:j...@joelhalpern.com>
> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>>
>
> Cc: rtg-...@ietf..org <mailto:rtg-...@ietf.org>
<mailto:rtg-...@ietf.org <mailto:rtg-...@ietf.org>>; spring@ietf.org
<mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>; 6man
<6...@ietf.org <mailto:6...@ietf.org> <mailto: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:40cisco.....@dmarc.ietf.org>
> <mailto:ketant <mailto:ketant>=40cisco....@dmarc.ietf.org
<mailto:40cisco....@dmarc.ietf.org>>>
>
> Sent: Monday, May 25, 2020 5:21 AM
>
> To: Ron Bonica <rbon...@juniper.net <mailto:rbon...@juniper.net>
<mailto:rbon...@juniper.net <mailto:rbon...@juniper.net>>>; Joel
> M. Halpern <j...@joelhalpern.com <mailto:j...@joelhalpern.com>
<mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>>
>
> Cc: rtg-...@ietf..org <mailto:rtg-...@ietf.org>
<mailto:rtg-...@ietf.org <mailto:rtg-...@ietf.org>>; spring@ietf.org
<mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>; 6man
<6...@ietf.org <mailto:6...@ietf.org> <mailto: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:40juniper....@dmarc.ietf.org>
> <mailto:rbonica <mailto:rbonica>=40juniper.....@dmarc.ietf.org
<mailto:40juniper....@dmarc.ietf.org>>>
>
> Sent: 25 May 2020 09:03
>
> To: Ketan Talaulikar (ketant) <ket...@cisco.com
<mailto:ket...@cisco.com>
> <mailto:ket...@cisco.com <mailto:ket...@cisco.com>>>; Joel M.
Halpern <j...@joelhalpern.com <mailto:j...@joelhalpern.com>
> <mailto:j...@joelhalpern.com <mailto:j...@joelhalpern.com>>>
>
> Cc: rtg-...@ietf..org <mailto:rtg-...@ietf.org>
<mailto:rtg-...@ietf.org <mailto:rtg-...@ietf.org>>; spring@ietf.org
<mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>; 6man
<6...@ietf.org <mailto:6...@ietf.org> <mailto: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>
<mailto: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> <mailto:j...@joelhalpern.com
<mailto:j...@joelhalpern.com>>>
>
> Cc: rtg-...@ietf..org <mailto:rtg-...@ietf.org>
<mailto:rtg-...@ietf.org <mailto:rtg-...@ietf.org>>; spring@ietf.org
<mailto:spring@ietf.org>
> <mailto:spring@ietf.org <mailto:spring@ietf.org>>; 6man
<6...@ietf.org <mailto:6...@ietf.org> <mailto: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://www.verizon.com/>
*Gyan Mishra*
/Network Solutions A//rchitect /
/M 301 502-1347
13101 Columbia Pike
/Silver Spring, MD
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
