Hi,
I support this document moving forward.
As part of the WG LC I'd like to suggest a minor clarification. Document
explains the conditions the SID structure shall satisfy for compression
to be feasible, which, in my view should not be confused with Segment
List Validation (as per rfc9256). Please se a proposal below.
Thank you
-m
OLD:
===
6.1. Segment Validation
An SR source node MUST validate all SIDs defined in this document
that it uses as part of a segment list, regardless of whether the
segment list is explicitly configured, locally computed, or
advertised by a controller (e.g., via BGP
[I-D.ietf-idr-segment-routing-te-policy] or PCEP
[I-D.ietf-pce-segment-routing-ipv6]).
A SID of this document is valid if it is associated with a valid SID
structure.
The structure of a SID is valid if all the following conditions are
met.
* The Locator-Block length is not 0.
* The sum of the Locator-Node length and Function length is not 0.
* The Argument length is equal to 128-LBL-LNL-FL.
An SR source node MUST NOT include an invalid SID in a segment list.
If an explicitly configured or advertised segment list (e.g., from a
controller) contains an invalid SID, the segment list MUST be
declared invalid ([RFC9256]).
===
NEW:
===
6.1. Segment Validation for Compression
As part of the compression process or as a preliminary step, the SR
source node MUST validate the SID structure, if known, of each SID of
this document in the segment list. The SR source node does so
regardless of whether the segment list is explicitly configured,
locally computed, or advertised by a controller (e.g., via BGP
[I-D.ietf-idr-segment-routing-te-policy] or PCEP
[I-D.ietf-pce-segment-routing-ipv6]).
A SID structure is valid for compression if it meets all the
following conditions.
* The Locator-Block length is not 0.
* The sum of the Locator-Node length and Function length is not 0.
* The Argument length is equal to 128-LBL-LNL-FL.
When compressing a segment list, the SR source node MUST treat an
invalid SID structure as unknown, and treats the SID as
incompressible.
===
Le 2024-01-22 à 15:28, Joel Halpern a écrit :
CAUTION:This is an external email. Please be very careful when
clicking links or opening attachments. See the URL nok.it/ext for
additional information.
(One of the other chairs pointed out that this had not gone to the
list. So forwarding the announcement.)
This tarts the WG last call on the above document.
Thank you,
Joel
-------- Forwarded Message --------
Subject: IETF WG state changed for
draft-ietf-spring-srv6-srh-compression
Resent-Date: Sun, 21 Jan 2024 11:25:02 -0800 (PST)
Resent-From: alias-boun...@ietf.org
Resent-To: bruno.decra...@orange.com, aretana.i...@gmail.com,
j...@joelhalpern.com, pengshup...@huawei.com
Date: Sun, 21 Jan 2024 11:25:02 -0800
From: IETF Secretariat <ietf-secretariat-re...@ietf.org>
To: draft-ietf-spring-srv6-srh-compress...@ietf.org,
spring-cha...@ietf.org
The IETF WG state of draft-ietf-spring-srv6-srh-compression has been
changed
to "In WG Last Call" from "WG Document" by Joel Halpern:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
Comment:
This starts the WG last call for this document. Please comment with
support
or opposition, and explanation of your perspective. Silence is not
consent,
and just "support" or "oppose" is not helpful. This call will run through
the end of Feb 4, 2024. Yours, Joel Halpern - responsible Spring co-chair
PS: I would appreciate a document shepherd from the WG for the bnext
step. Email me if you are willing.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
