Dear WG,
I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression.
Based on my understanding, NEXT and REPLACE flavors defined in this draft can
meet with RFC8986. Also, there are multiple implementations today like Arrcus
and VPP as well. I really appreciate the huge efforts
Hi Chairs & WG,
I fully support the adoption of the draft.
From October to December 2020, I led the CSID multi-vendor interoperability
test in the China Mobile Lab. The joint team successfully verified that
different vendors implement data plane interoperability based on the CSID
draft. We
Hi John
Greg made an excellent point that as SRv6 uses the IPv6 data plane and as
IPv6 extended header routing header SRH RH type 4 is in fact part of the
“data plane”.
So as CSID containerization of the 128 bit SID entry in the SRH header RFC
8754, CSID is in fact a change of not only the SRV6
Hi John,
thank you for equipping your question with the definition of the data
plane. That helps a lot. I agree with Gyan that as the local function
processing the SID encoding in an SRH container must change, so the only
conclusion we can make is that the data plane that supports C-SID is
Hi John
CSID as it does supports SRv6 forwarding plane, it does require a change to
the existing SRv6 PGM RFC 8986 to support the CSID draft new flavors.
So yes definitely a software upgrade would be required.
Kind Regards
Gyan
On Wed, Oct 13, 2021 at 7:25 PM John Scudder wrote:
> Hi Robert,
Il 2021-10-14 01:24, John Scudder ha scritto:
Hi Robert,
My question doesn’t have anything to do with “classic ASIC design”.
Indeed if you look at the definitions I supplied they don’t say anything
at all about how the router is implemented, the nature of the control
plane including whether
Hi Robert,
My question doesn’t have anything to do with “classic ASIC design”. Indeed if
you look at the definitions I supplied they don’t say anything at all about how
the router is implemented, the nature of the control plane including whether
there is one, and indeed are very broad. I would
Hi John,
I think the crux of the matter is indeed in definition of "SRH data plane".
So let me present my own personal understanding of it.
Clearly SRH external format does not change so hardware's ability to read
SRH remains intact. IPv6 packet's header also can be read and processed by
network
Hi Folks,
I’m struggling with the claim repeated throughout the beginning of
draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, §1, §3) that
“this solution does not require any SRH data plane change”.
I’m not aware of a standardized formal definition of “data plane”, it seems to
Brian E Carpenter wrote:
> So I'm not concerned that srv6-srh-compression has any more fundamental
> impact than basic SRV6 or RFC8986. (However, this aspect of SRV6 was
> one of my primary motivations for RFC8799. What happens in SRV6 stays
> in SRV6.)
You said it better than
Joel,
On 13-Oct-21 20:37, Joel M. Halpern wrote:
>> 1) Does the placement of a list of sids in the IPv6 DA field change the
>> IPv6 architectural description of that field.
That's why I recently asked for a set of examples of the resulting
"addresses". I don't understand enough of SRV6 to
I support adoption. The document describes changes that are consistent with
existing SRv6-related RFCs, and I find the objection about multiple apparent
data plane solutions to be puzzling at best.
pdm
From: spring On Behalf Of James Guichard
Sent: Friday, October 1, 2021 9:05
Hi Gyan,
Sorry for the late reply. Thank you for reading the draft so carefully, really
appreciated. But I will recommend you to split the comments into small emails
so that we can discuss easily. LOL.
Regarding the illustrations, yes, it can be added later on. And also Francois
provides the
Hi All,
So - to understand the claims of compatibility between the behaviors within the
same domain - I decided the best way to test this was to write some actual code
to simulate it. I'm hoping to get the full simulation code out in the next 24
hours - but in the mean time I figured I'd add
I will consider this as we reach the current closure date.
Yours,
Joel
On 10/13/2021 8:04 AM, Weiqiang Cheng wrote:
Dear Chairs and WG,
As a co-author of this document, I would like to thank all participants
in the discussion. All those discussions, comments and suggestions are
of great
Hi SPRING，
Sorry for the late response due to the National days break. It seems like I
miss a lot of discussion, and it did cost me a lot of time to read all the
threads.
As a member of the design team, and a person who participates in IETF SR
standards for a long time, I know who how
Hi Dear WG,
We have deployed SRv6 in our national-wide large scale networks for a long
time to provide better Internet services for over 1 billion people.
Furthermore, almost one year ago, we had decided to use the mechanism defined
in this draft in our network in the near future.
I
Marvell silicon supports the SRv6 CSID flavors REPLACE-CSID and NEXT-CSID, and
Marvell has participated in multi-vendor interoperability testing of these CSID
flavors.
I support the WG adoption of the draft.
David
From: spring On Behalf Of James Guichard
Sent: Friday, October 1, 2021 5:05 PM
Dear Chairs and WG,
As a co-author of this document, I would like to thank all participants in
the discussion. All those discussions, comments and suggestions are of great
value to us.
It was unexpected that so many IETFers could join the discussion. It is
amazing. It also made me realize
Hi Greg,
Your understanding is correct. The C-SID flavors cannot be randomly mixed
within the same C-SID container.
We can clarify the details related to the combination of flavors in a C-SID
container in an upcoming version of the draft. For example, the last entry of a
C-SID container can
Hi Tarek,
Section 4.3 of RFC 8754 indicates that a locally instantiated SID is identified
based on the result of an LPM lookup on the packet’s destination address. That
SID has a behavior that determines how the endpoint node should process the
packet.
The C-SID draft does not change how the
Hi Gyan,
Thanks for your feedback. The authors will work on some more illustrations to
add in the draft.
In my previous email
(https://mailarchive.ietf.org/arch/msg/spring/ZfbHtQ1FTqWYqjXqcFuEf22I2L8/), I
provided an example of how the Next-C-SID and Replace-C-SID flavors could be
used
Dear WG,
I support the adoption call. CSID draft defines multiple SRv6 flavors, but
they present a single SRv6 data plane based solution.
Regards,
Yuexia Fu
发件人: spring [mailto:spring-boun...@ietf.org] 代表 Severin Dellsperger
发送时间: 2021年10月13日 16:00
收件人: James Guichard; SPRING WG
Dear SPRING Working Group,
I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression.
The SID compression mechanism described in the document will help adopting SRv6
more efficiently when having multiple SIDs with small payload, in a way
consistent with a single and already
Dear WG
I strongly support the WG adoption for the Compressed SRv6 Segment List
Encoding in SRH draft
(https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/).
In different projects, I have worked with SRv6 and used the NEXT-C-SID flavor
to enable Segment Routing
Dear WG
I want to express support for the WG adoption of the draft
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
(CSID).
In my research studies at the University of Applied Sciences, I have developed
a Segment Routing application capable of doing service
There is a typo in the below which if not understood as a typo would be
quite confusing. I wrote that I raised the issue with
"with the Internet ADs and SPRING chairs".
That should have read "with the Internet ADs and 6man chairs".
The SPRING co-chairs are recused, and the charter requirement
Hello Spring WG,
>From Intel, we are currently in the process of adding SRv6 feature in the open
>source NOS - SONiC.
In our discussions with our customers about SRv6 H.encaps.red, END.X, END.DT46
etc functions that we are implementing in SONiC, we also hear about the
importance of NEXT and
Hi WG，
After many interop and efficiency tests in our lab, I have to
say that CSID recommended by draft-filsfilscheng-spring-srv6-srh-compression/
is a good solution for the deployment of SRv6. Our judgements came frome
the following aspects:
- Under the circumstances of large
Dear WG, WG chairs,
I support the adoption of CSID draft
(draft-filsfilscheng-spring-srv6-srh-compression).
Over the past years, I have been working extensively on the SRv6 stack in the
Linux kernel.
I have contributed to the Linux kernel by introducing new SRv6 features as well
as optimizing
I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression.
I have been working together with my team at the university of Rome Tor Vergata
on SRv6 support in the Linux kernel.
The CSID draft builds on RFC8986 and defines two new flavors.
We supported these two flavors in the
Dear J. Guichard, Spring WG and Spring Chairs
we support the adoption of draft-filsfilscheng-spring-srv6-srh-compression. To
the best of our knowledge, CSID is single SRv6 based data plane that defines
next and replace flavors to End, End.X, and End.T SIDs and it is consistent
with RFC8996
32 matches
Mail list logo
