Hi Gyan,
It is possible to combine SIDs of different C-SID flavors and C-SID lengths in
the same SRH, along with those defined in RFC 8986 After all, they leverage the
same SRv6 data plane.
Let me give you an example.
Assume that an SR source node wants to send a packet onto an SR path through 10
SR segment endpoint nodes (nodes 1 through 10), and have a VPN termination for
a VRF 123 on a last SR segment endpoint node 11.
The SR source node selects the segments as follows:
* On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with K being the node
ID) bound to End with NEXT-C-SID flavor and 16-bit C-SID length.
* On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being the
node ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID length.
* On node 10, the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986).
* On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC 8986) for
VRF 123.
The SR source node then sends the packet onto the SR path by performing the
H.Encaps.Red behavior with:
* IPv6 Source Address = <an address of the SR source node>
* IPv6 Destination Address = 2001:db8:0:0101:0201:0301:0401:0501
* SRH =
* SegmentList[0] = 2001:db8:0:1100:d123::
* SegmentList[1] = 1000:0001:0900:0001:0800:0001:0700:0001
* SegmentList[2] = 2001:db8:0:0600:0001::
Therefore, there is no notion of lowest common denominator for C-SID length.
Based on the deployment requirements, an operator has the flexibility to select
the SRv6 SID flavor and C-SID lengths of their choice.
We can update the draft with this type of illustrations.
Thanks,
Francois
From: spring <[email protected]> on behalf of Gyan Mishra
<[email protected]>
Date: Sunday, 3 October 2021 at 21:01
To: Yisong Liu <[email protected]>
Cc: James Guichard <[email protected]>, SPRING WG
<[email protected]>, spring-chairs <[email protected]>
Subject: Re: [spring] RE： WG Adoption call for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Yisong
The main goal for operators is interoperability. As interoperability is the
key reason for a single SRv6 compression solution that we have WG consensus and
is desired.
Continued details of the interoperability study should be added to the draft
as the study progresses.
One key detail that is missing is forwarding efficiency and scalability using
NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID.
As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for ultra
scale SRv6 compression solution is recommended for 16 bit SID and
REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit
SID.
Of all the requirements as stated, the encapsulation header size is the primary
objective for operators to eliminate MSD issues with optimal forwarding and
state efficiencies.
At this time in order for Next and Replace solutions to be interoperable
keeping in mind requirements for optimal forwarding and state efficiency 32 bit
SID would be the lowest common denominator which should be stated as the
baseline result of the analysis draft on CSID overall 2 prong solution.
CSID draft:
https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-11
Bottom of section 11:
The interoperability was validated for the following scenario:
o Packet forwarding through a traffic engineering segment list
combining, in the same SRH
([RFC8754<https://datatracker.ietf.org/doc/html/rfc8754>]), SRv6 SIDs bound to
an
endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound
to an endpoint behavior with the REPLACE-C-SID flavor.
Further interoperability testing is ongoing and will be reported in
this document as the work progresses.
King Regards
Gyan
On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu
<[email protected]<mailto:[email protected]>> wrote:
Hi Chairs & WG,
I strongly support the adoption call. Regarding chair's note in the email, I
would like to point that the network programming model (RFC8996) by nature
defines multiple behaviors. CSID has a single SRv6 based data plane that
defines the next and replace behaviors consistent with the network programming
paradigm.
CSID's next and replace behaviors have been verified by interoperability test
in China mobile laboratory and there is no problem with the interworking of the
two behaviors on the CSID dataplane.
Best Regards
Yisong
发件人: James Guichard<mailto:[email protected]>
时间: 2021/10/01(星期五)22:04
收件人: SPRING WG<mailto:[email protected]>;
抄送人: spring-chairs<mailto:[email protected]>;
主题: [spring] WG Adoption call for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Dear WG:
The chairs would like to express their appreciation for all the responses
received to our emails with reference to how the working group wishes to move
forward with respect to a solution for SRv6 compression.
The apparent inclination of the working group is to use
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
as the basis for its compression standardization work. That is part of what
this email attempts to confirm.
Because of the above the chairs would like to issue a 2-week WG call for
adoption ending October 15th for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
but with some clear guidelines as follows. By expressing support for adoption
of this document you are fully aware of and are acknowledging that:
1. The SPRING working group is adopting a document that has multiple SRv6
Endpoint behaviors.
2. The document is a “living” document; it may change as it goes through
review and analysis by the SPRING working group.
3. All open discussion points raised on our mailing list MUST be addressed
BEFORE said document is allowed to progress from the working group to
publication. A list of these discussion points will be documented in the WG
document and maintained by the document editor in conjunction with the chairs.
4. If this document is adopted by the working group, the chairs specify as
part of the adoption call that the following text describing an open issue be
added to the document in the above-described open issues section:
* "Given that the working group has said that it wants to standardize
one data plane solution, and given that the document contains multiple SRv6
EndPoint behaviors that some WG members have stated are multiple data plane
solutions, the working group will address whether this is valid and coherent
with its one data plane solution objective.".
Please consider the above guidelines as you decide on whether to support or not
this WG adoption. Please express clearly your reasoning for support/non-support
as well as any open discussion points you would like addressed should the
document be adopted into the working group.
Thanks!
Jim, Bruno & Joel
_______________________________________________
spring mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
--
[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>
Gyan Mishra
Network Solutions Architect
Email [email protected]<mailto:[email protected]>
M 301 502-1347
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
