Hi,
I am not aware of any undisclosed IPR to this draft as a contributor.
Best regards,
Aihua Liu
Original
From：chengweiqiang ;
To：fclad.ietf ; spring ; jmh
;
Date：2024-02-02 07:09:16
Subject：Re: [spring] IPR call and
Shepherdingdraft-ietf-spring-srv6-srh-compression
___
Dear all,
I support the publication of this draft.
This draft is very helpful and has been implemented with the devices of my
company.
Best regards,
Aihua Liu
Original
From：chengweiqiang ;
To：jmh ; spring ;
Date：2024-01-22 22:46:27
Subject：Re: [spring] Fwd: IETF WG state changed t
Thanks for your work.
With Errata 7102 for RFC 8754, I think issue #3 has closed. According to my
understanding, the others include 4, 5, are also closable.
Regards,
Aihua Liu
Original
From: JoelHalpern
To: SPRING WG List ;
Date: 2023年08月08日 23:00
Subject: [spring] Confim
I think we can close issue 1.
I agree the editors said that "All SIDs of the SRv6 dataplane can co-exist in
the same SRH. This make SRv6 a single, consistent dataplane solution". There
were some interop tests in the document.
Regards,
Aihua Liu
Original
From: JoelHalpern
Hi Weiqiang,
This draft proposed an interesting solution for dynamic SRv6 deployment,
especially with centralized management of SRv6 locator prefix. As the draft
descripted, it is valuable to simplify the CPEs to join in the SRv6 domain. I
wonder whether if this could be done by current exist
Hi Ron，
For your questions, from my point of view, might be a little deviation with
purpose of the C-SID solution. As I understand, the SRv6 header compression
depends on the redundencies of SID information, and the C-SID solution provides
2 flavors for compression, how to use them also depend
Hi Chaires and WG,
I support to adoption this draft. As we known, the draft has been discussed in
the DT for more than 2 years. The requirement draft has been accepted and
adopted by WG. The solution compatible with the standard SRv6 is preferred for
the SRv6 compression, that is the solution
Hi Ron,
You raised an interesting question, but I think it might be already discussed
in the DT. In my understanding, this question is just more related the usecases
and requirements but the solutions. In a SRv6 domain, the header compression
effection depends on the SID informaion redundencie
Dear Chairs & Weiqiang,
As I presented before, the CSID draft is just only one solution with two
different flavors. Even there are some others, the CSID has the most supporters
and has finished multi-vendor interworking test and field test, including my
company ZTE. Especially, CSID is the mos
In my opinion, C-SID just presents 1 solution in dataplane, even it has 2
flavors, but they share the same framework and process. Before we accept it it
is not important to prefer which flavor.
Best regards，
Aihua
原始邮件
发件人：Henderickx,Wim(Nokia-BE/Antwerp)
收件人：Joel M. Halpern
Thanks for DT's hard work completing SRv6 header compression requirements and
solutions comparion.
I agree that it's better for industry if we all accept only 1 standard solution
for SRv6. The different solutions compared by DT might originate from different
main scenarios, such as C-SID main
Hi Stewart & Weiqiang,
Thanks for Mr Stewart's comments, which are valuable for understanding the Path
Segment.
And I agree Weiqiang's responses. One more thing I want to notice that Path
Segment could balance the philosophy of SR and MPLS for Path capabilities, such
as Path Policy or PM. T
Hi Weiqiang,
Thanks for your new version draft and hard work on DT.
I think the SRv6 compression is very important especially for SRv6-TE with
heavy overhead.
As one of the authors of G-SRv6 draft, I think we should focus on this SRv6
requirements for consensus ASAP. That will be very hel
I support WG adoption this draft since it enables the use of BFD Demand mode
that reduces amount of BFD control messages received by the ingress BFD system.
Regards,
Aihua
原始邮件
发件人：GregMirsky
收件人：IETF Secretariat ;
抄送人：spring ;spring-cha...@ietf.org
;draft-mirsky-spring-...@iet
14 matches
Mail list logo
