Hi,
It appears that some may have misunderstood the SRv6 solution and invented CRH.
It is good to clarify these points.
SRv6 offers the possibility to combine underlay and overlay instructions in a
single SRH.
However,
* This is entirely optional
* If one would like to spread the source routed policy between multiple
extension headers, one can use SRv6 to do this
* SRH to hold the topological endpoints
* Any combination of other extension headers to hold VPN and/or Service
information. For example, SRH works seamlessly with NSH as documented in a WG
document https://tools.ietf.org/html/draft-ietf-spring-nsh-sr-02.
Claiming that a new data plane is needed to achieve this separation is false.
Claiming that CRH is needed to decrease the overhead of source-routed policy in
IPv6 is incorrect, too. Many members of the SPRING working group have produced
documents to extend the SRv6 solution for the specific purpose of minimizing
the MTU overhead and/or supporting very long SID-lists on legacy hardware.
Also, CRH is just a re-engineering of SR-MPLS Data Plane with IPv6 Control
Plane [RFC8663] and RFC8663 is an already productized, deployed, proven, and
standardized solution.
6man took 6 years to define SRH. The 6man WG spent a lot of efforts (1000s of
email, dozens of document revision, dozens of IETF presentations, control plan
work that is adopted by multiple workgroups, etc.).
There is no need to define a new data plane, new control plane and associated
management plane for the same purpose the IETF across multiple areas has worked
for years.
Thanks
Regards … Zafar
From: ipv6 <ipv6-boun...@ietf.org> on behalf of Ron Bonica
<rbonica=40juniper....@dmarc.ietf.org>
Date: Friday, May 22, 2020 at 10:17 AM
To: "Chengli (Cheng Li)" <c...@huawei.com>, 6man <6...@ietf.org>,
"spring@ietf.org" <spring@ietf.org>
Cc: "spring@ietf.org" <spring@ietf.org>
Subject: RE: How CRH support SFC/Segment Endpoint option?
Cheng,
The sole purpose of a Routing header is to steer a packet along a specified
path to its destination. It shouldn’t attempt to do any more than that.
The CRH does not attempt to deliver service function information to service
function instances. However, it is compatible with:
* The Network Service Header (NSH)
* The Destination Options header that precedes the Routing header
Both of these can be used to deliver service function information to service
function instances.
Ron
Juniper Business Use Only
From: Chengli (Cheng Li) <c...@huawei.com>
Sent: Friday, May 22, 2020 2:56 AM
To: 6man <6...@ietf.org>; spring@ietf.org; Ron Bonica <rbon...@juniper.net>
Cc: spring@ietf.org
Subject: How CRH support SFC/Segment Endpoint option?
[External Email. Be cautious of content]
Hi Ron,
When reading the CRH draft, I have a question about how CRH support SFC?
For example, we have a SID List [S1, S2, S3, S4, S5], and S3 is a SFC related
SID, how to indicate that? By PSSI? [1]
But how to know which segment endpoint node/egress node should process this
PSSI? At the beginning of the SRm6 design, this is described in [2]. But you
deleted the containers [2].
Without that, I don’t really understand how SFC can be supported.
Best,
Cheng
[1].
https://tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01#section-4.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-bonica-spring-sr-mapped-six-01*section-4.1__;Iw!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwP15i-Xa$>
[2].
https://tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt<https://urldefense.com/v3/__https:/tools.ietf.org/rfcdiff?url2=draft-bonica-6man-seg-end-opt-04.txt__;!!NEt6yMaO-gk!UD4vf0darQ9cskFhH1fJ9jwZJ-nIciQxgVnf1219YuyyaNcgvNdRUdkjwNmXwyHT$>.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
