Hi Andrew,
Yes, this is a great question.
After implementing compression, networks will have devices with both
compression and non-compression capabilities.
Therefore, compression and non-compression SIDs can appear in the same SRH
header.
This requires centralized path calculation by the
With RTGWG chair hat.
Hi Tal,
Thanks for the review and comments.
As an individual contributor:
Authors,
I have the same question about ti-lfa. Please provide more explanation
about why the use case in the draft can't be addressed using ti-lfa?
In section 3.1:
"
After PEA receives the in
On Fri, Aug 4, 2023 at 2:23 AM Tal Mizrahi wrote:
>
> Hi Tom,
>
> > This is a major problem with regards to L4 checksum computation in
> > deployment. RFC8200 and even IPv4 assume that the transport layer
> > checksum can be correctly calculated solely based on the contents of
> > the packet with
Hi Joel,
The authors’ resolution of issue 1 looks good to me, and I’d consider issue 1
as closed.
This document is currently in a stable and good shape to move forward. Thanks
for all the good work of the editors, authors and WG chairs.
Best regards,
Jie
From: spring On Behalf Of Joel Halper
Now,
Let me ask you this �C which vendor if vendors only support one of the options
�C is going to be pushing the sids for the other option? Where is the mixed sid
push going to happen if vendors only support one part of it?
Andrew
Internal All Employees
From: linchangwang
Date: Friday, 4
Andrew Alston has entered the following ballot position for
draft-ietf-spring-sr-replication-segment-16: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
Hi Joel,
Yes, I believe your suggestion is the best approach, i.e., to
integrate an adaptation of the text from
draft-mizrahi-spring-l4-checksum-srv6 into the compression draft.
I would be happy to help the authors with that.
Cheers,
Tal.
On Thu, Aug 3, 2023 at 6:50 PM Joel Halpern wrote:
>
>
Hi Joel, WG,
I wanted to share my perspective on the issue at hand. I am in agreement that
the issue has been satisfactorily resolved. The document
"draft-ietf-spring-srv6-srh-compression" clearly defines that all SIDs,
including Next-C-SID and Replace-C-SID, can co-exist in the same SRH. This
Hi Tom,
> This is a major problem with regards to L4 checksum computation in
> deployment. RFC8200 and even IPv4 assume that the transport layer
> checksum can be correctly calculated solely based on the contents of
> the packet without additional context. A compressed segment list in
> the DA wi
In my opinion the suggested approach is the most reasonable approach
at this point, and therefore the issue can be closed.
Cheers,
Tal.
On Tue, Aug 1, 2023 at 12:08 AM Joel Halpern wrote:
>
> As per the discussions on list and at IETF 117, the SPRING WG chairs (myself
> and Alvaro specifically)
Thanks for Changwang’s sharing. Yes, these are some typical examples like said.
As long as it follows the rules of C-SID encoding, a user can encode the
C-SIDs in any order he/she likes.
Following your example, another example which can provide better compression is
shown below.
SRH [0]: | r
Thomas, thank you for your review. I have entered a Discuss ballot for this
document based on my own review.
Lars
> On Jun 9, 2023, at 19:01, Thomas Fossati via Datatracker
> wrote:
>
> Reviewer: Thomas Fossati
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. Th
Lars Eggert has entered the following ballot position for
draft-ietf-spring-sr-replication-segment-16: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please re
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
14 matches
Mail list logo
