Dear WG,
We have just submitted a new version of
draft-ietf-spring-srv6-srh-compression.
This revision adds a new subsection 9.3 “Upper Layer Checksum Verification
on Transit Nodes” under “Operational Considerations”. The new text
indicates that unaware middleboxes may fail to verify the upper l
Internet-Draft draft-ietf-spring-srv6-srh-compression-15.txt is now available.
It is a work item of the Source Packet Routing in Networking (SPRING) WG of
the IETF.
Title: Compressed SRv6 Segment List Encoding
Authors: Weiqiang Cheng
Clarence Filsfils
Zhenbin Li
Hi Joel,
One small clarification.
Knowledge of the SRv6 SID block (either by configuration or using the new
SRv6 block specified in draft-ietf-6man-sids as a default) is sufficient
for an “observer node” to identify SRv6 traffic and potentially skip
verifying the checksum.
An SRv6 and C-SID awa
Hi Alvaro & WG members,
As an operator, I think there will be no intermediate nodes performing SRv6
packet upper layer checksum in our network deployment. Currently, there is no
problem with C-SID deployment. I feel that there is no need to change the text
in Section 6.5.
Best Regards
Note as an observer of this discussion:
If we consider that the need for configuration of observer nodes is an
issue, I am pretty sure we need to remember that it is not just the SID
block that needs to be known. The compressed SID length and flavor also
need to be known.
Yours,
Joel
On 4
Hi Ketan,
On Tue, 9 Apr 2024, 01:55 Ketan Talaulikar, wrote:
> Hi Alvaro,
>
> I have some concerns about the second paragraph of your email. Compressed
> SRv6 SIDs (C-SID) are still SRv6 and therefore everything from existing
> SRv6 RFCs apply and those aspects are very much foundational to this
Hi Ketan,
> a) SR Source Node: the node originating the packet - it may have an SRH or
> may skip it (section 4.1)
> b) Transit Node: node doing IPv6 forwarding
> c) (Ultimate) Destination Node (from RFC8200): the final node to which the
> packet is destined
>
All you said seems true valid, but
Hi Alvaro and all,
I re-read section 6.5, it seems to be clear enough IMO, it also has link
towards section 9.2 (ICMP Error processing).I do agree with Ketan's email about
the methodology for splitting all nodes into those 3 categories (Source,
Transit, Destination). Indeed those concerns w
Hi Alvaro,
I find some level of confusion on the discussion threads and it might
perhaps be due to the inconsistent use of terminologies. It would help to
use the correct terminologies from RFC8754 (6man WG RFC) to bring clarity
on what is within the scope and what is beyond the scope of this docu
Hi Alvaro,
I have some concerns about the second paragraph of your email. Compressed
SRv6 SIDs (C-SID) are still SRv6 and therefore everything from existing
SRv6 RFCs apply and those aspects are very much foundational to this C-SID
document as well.
RFC8754 has introduced the omission of SRH (sec
10 matches
Mail list logo
