Re: [IPv6] [Technical Errata Reported] RFC8754 (7102)

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Greg and Joel, I’m happy with:

Segments Left:  Defined in [RFC8200], Section 4.4.
Specifically, for the SRH, the number of unprocessed
128-bit entries in the Segment List.

It’s the more precise description. Now “Segment List field” or “Segment List”?

Thanks!
Darren

On 2023-05-29, 10:46 PM, "ipv6" <[e-mail]> wrote:


Good point.  That works for me.  That wording seems better than simply relying on people understanding "remaining".

Yours,

Joel
On 5/29/2023 10:17 PM, Greg Mirsky wrote:
Hi, Joel et al.,
as I understand it, segments are not removed from the Segment List. If that is correct, then, according to the proposed definition, the value of the Segments Left field is constant throughout the lifetime of a given SRH. But that is not how it is supposed to be used, Right? I think that the following might better reflect the use of the field:
NEW TEXT:
Segments Left:  Defined in [RFC8200], Section 4.4.
Specifically, for the SRH, the number of unprocessed
segments in the Segment List.
Similarly, following up on your point about the need to use more general terminology:
NEW TEXT:
Segments Left:  Defined in [RFC8200], Section 4.4.
Specifically, for the SRH, the number of unprocessed
128-bit entries in the Segment List.

WDYT?

Regards,
Greg

On Mon, May 29, 2023 at 6:59 PM Joel Halpern <[e-mail]<mailto:[e-mail]>> wrote:
I think there are two issues, both easily resolved.

Given that different people may have been reading the existing text
differently, I think that we need to make sure 6man agrees on what it
should have meant.   To solve this, we "merely" need folks to speak up.

The second issue is that we want the wording to end up correct even when
we add compressed SID containers, without introducing a normative
dependence on a WG I-D.

The proposed clarifying text currently reads:

Segments Left:  Defined in [RFC8200], Section 4.4.
Specifically, for the SRH, the number of segments
remaining in the Segment List.

If I try to interpret that looking forward to compressed SID containers, I end up confused as to what is intended.  (I know what the various pieces of pseudo-code add up to, but the definition should be clear.)  I think the following may help:

Segments Left:  Defined in [RFC8200], Section 4.4.
Specifically, for the SRH, the number of 1228 bit entries
remaining in the Segment List.

I had earlier thought that maybe we could say "the number of 128 bit SIDs or SID containers", but I fear that would produce an improper dependence since we don't have containers defined anywhere.

Thoughts?
Joel

On 5/29/2023 6:40 PM, Erik Kline wrote:
> There has been a request to engage in some word-smithing before
> returning this to Verified.
>
> May I ask that it be put back into Reported state while this is discussed?
>
> On Tue, Aug 23, 2022 at 12:38 PM RFC Errata System
> <[e-mail]<mailto:[e-mail]>> wrote:
>> The following errata report has been submitted for RFC8754,
>> "IPv6 Segment Routing Header (SRH)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> https://www.rfc-editor.org/errata/eid7102
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Darren Dukes <[e-mail]<mailto:[e-mail]>>
>>
>> Section: 2
>>
>> Original Text
>> -------------
>> Segments Left:  Defined in [RFC8200], Section 4.4.
>>
>> Corrected Text
>> --------------
>> Segments Left:  Defined in [RFC8200], Section 4.4.
>> Specifically, for the SRH, the number of segments
>> remaining in the Segment List.
>>
>> Notes
>> -----
>> RFC8754 describes “The encoding of IPv6 segments in the SRH” where IPv6 segments are defined in RFC8402.  RFC8402 describes binding SIDs and adjacency SIDs for SRv6. Both these SID types identify more than a single explicitly listed intermediate node to be visited.
>> The current definition of Segments Left only indicates it is defined in RFC8200, and RFC8200 defines it as “Number of route  segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination”.
>>
>> Previous versions of draft-ietf-6man-segment-routing-header (0-11) referenced RFC2460/RFC8200 and described the Segments Left field by use in the SRH; as an index into the Segment List. This was removed in later versions (12/13) to consolidate the use of segments left to be specific to the segment processed (now section 4.3.1).  However, that removed the definition of its meaning in the SRH which led to the current issue.
>>
>> The corrected text restores the meaning of Segments Left for the SRH in relation to Segment List (which is not defined in RFC8200), while still leaving its use during segment processing to the segment definition (section 4.3.1 or future documents).
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC8754 (draft-ietf-6man-segment-routing-header-26)
>> --------------------------------------
>> Title               : IPv6 Segment Routing Header (SRH)
>> Publication Date    : March 2020
>> Author(s)           : C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer
>> Category            : PROPOSED STANDARD
>> Source              : IPv6 Maintenance
>> Area                : Internet
>> Stream              : IETF
>> Verifying Party     : IESG
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------