Hi Andrew,WG,
Let me add my understanding of interoperability.
If all devices support NEXT-C-SID, the encapsulation is as follows:
SRH [0]: block-1 | next-c-sid-21 | next-c-sid-22 | ….| next-c-sid-2n |
SRH [1]: block-1 | next-c-sid-11 | next-c-sid-12 | ….| next-c-sid-1n |
If all devices
Hi Joel, WG
Speaking strictly as a spring participant and wearing no other hats.
I cannot call this one solution �C yes �C what Changwang said below is correct
that they can potentially co-exist �C however the question of one solution
comes down to this:
If there is an implementation done
Tom, so moving SRv6 into NAT equivalent space is an interesting take,
granted (and sure better than bis'ing STD).
Thinking along those lines
a) SRv6 becomes L4 aware and goes chasing all the checksums in all L4s to
inc adjust them and gets silicon rev'ed up on every new L4 in the future.
b)
On Thu, Aug 3, 2023 at 9:30 AM Tony Przygienda wrote:
>
> well, turns out using a destination address to piggy back some computation
> semantics and especially changing it in mid-flite is not a great idea. Who
> knew ...
Tony,
We already have a working example on how to change destination
If the proposed change is a non-backwards compatible modification right
down at the bottom of the IP stack, that's a pretty big ask. Has there
been any assessment of what this is going to change or break?
Nick
Tony Przygienda wrote on 03/08/2023 17:29:
well, turns out using a destination
well, turns out using a destination address to piggy back some computation
semantics and especially changing it in mid-flite is not a great idea. Who
knew ...
as to bis'ing STD86 I was quickly thinking "it's not April yet" ...
-- tony
On Thu, Aug 3, 2023 at 9:43 AM wrote:
> Hi Tal,
>
>
>
You make a good point about SRH already being covered but the corner
case with compression not being covered.
Speaking personally, I would expect that to be dealt with by including
the relevant text in the compression draft, and noting that it updates
8200 (which probably means the last call
Tal, Tom and all,
IMHO and FWIW Tal has exposed a real and critical issue with compressed lists
of SRv6 SIDs.
I wonder if this issue could be addressed by explicitly stating that compressed
lists of SIDs can only appear in the SRv6 header but not in the Destination
Address of an IPv6 packet.
Tal,
>From the draft: "Compressed segment lists can be used in the
Destination Address without the presence of a Routing header, and in
this case the IPv6 Destination address can be modified along the path.
This is another case in which the checksum is computed based on the
Destination Address
Hi Bruno,
Many thanks for your reply. I think most of your comments have been addressed.
Please check.
I copy the only one left here for better discussion.
-
§2
"The value of the TTL field in the MPLS label stack entry containing the PSID
MUST be set to the same value as the TTL of the
Hi Authors and SPRINGers,
As required by SPRING WG policy, we need to add a section of implementation
status in this draft.
As far as I know, some vendors have implemented the feature of this draft
already, please free feel to share the info to me or to the list, I will
collect it into the
Hi @bruno.decra...@orange.com ,
I am not aware of any undisclosed IPR related to this document.
Thanks,
Sorry for the late reply
On Wed, Aug 2, 2023 at 6:50 PM wrote:
> Hi Royi Zigler, Han Li, authors,
>
>
>
>
>
> Regarding authors replies to the IPR polls, I could find the following
> ones,
Hi Tal,
Please note that there is an existing draft:
https://datatracker.ietf.org/doc/draft-xiao-spring-srv6-checksum/
which attempts to address the problem you found and another one described in
the penultimate paragraph of the Introduction section, in a different way not
requiring
Hi,
This new draft introduces a proposed update to [RFC8200], which is
intended to address compressed segment lists in SRv6
[draft-ietf-spring-srv6-srh-compression].
Link to the new draft:
https://datatracker.ietf.org/doc/draft-mizrahi-spring-l4-checksum-srv6/
There was some discussion in the
Hi Joel,
I agree that this may be a corner case, but it still needs to be covered.
As you pointed out, the compression document should certainly mention
how the checksum computation is affected by the compression.
There are two main issues with the text in [RFC8200]. The first is
that the
15 matches
Mail list logo
