Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

[Tom Herbert <[e-mail]>]

On Fri, May 24, 2019 at 8:41 AM Darren Dukes (ddukes) <[e-mail]> wrote:
>
> Tom, the action requested by the WG was to restore the text from rev 17. that was done.
>
> Now you appear to have an editorial comment to change that restored text to be something slightly different that you find more precise.  Is that correct?
>
Tom,

If this is just an editorial change to that text then that would be
fine, but this isn't the only change in -19 that discusses mutability.
The last paragraph in section 4.3.1 was added in -19,and not in -17 or
18, and I don't know that there was discussion in the WG about the
need for this. In particular, the sentence: "The remainder of the SRH
(Flags, Tag, Segment List, and TLVs that do not change en route) are
immutable while processing this SID type." seems to imply that the
mutbability requirements are depended on SID type (a term which AFAICT
isn't clearly defined). So to me, the mutability requirements are
still either ambiguous or conflicting in version -19 of the draft. I
would to proceed to write the draft on SR and AH, but without clear
unambiguous requirements on mutability that's hard.

Tom


> Darren
>
> On May 23, 2019, at 6:06 PM, Tom Herbert <[e-mail]> wrote:
>
> On Thu, May 23, 2019 at 1:55 PM Brian E Carpenter
> <[e-mail]> wrote:
>
>
> On 24-May-19 00:32, Bob Hinden wrote:
>
> Jingrong,
>
> On May 23, 2019, at 4:47 AM, Xiejingrong <[e-mail]> wrote:
>
> Support WGLC.
>
> Some minor/editorial nits:
> (1) Below text in section 2 is irrelevant and incorrect, because there is no 'mutable' or 'mutability' word in RFC8200.
>
>
> The w.g. chairs concluded that the consensus of the 6man w.g. was that the the mutability of the SRH fields be specified.  See:
>
>  https://mailarchive.ietf.org/arch/msg/ipv6/jBpmjGZd77ZRHKOKUF6Hsbcc0is
>
> That makes it both correct and relevant.
>
>
> To be even more clear, RFC8200 does not use the word mutable, but it
> does deal with the mutability of options:
> "The third-highest-order bit of the Option Type specifies whether or
> not the Option Data of that option can change en route to the
> packet's final destination."
>
>
> That makes one wonder why the text from RFC8200 wasn't directly
> adapted for use here. For instance, this could read:
>
> "The highest-order bit of the TLV type specifies whether or not the
> TLV data of that option can change en route to the packet's final
> destination.
>
>       0 - TLV data does not change en route
>
>       1 - TLV data may change en route"
>
> but the current text reads:
>
> "TLVs may change en route at each segment.  To identify when a TLV
> type may change en route the most significant bit of the Type has the
> following significance:
>
>      0: TLV data does not change en route
>
>      1: TLV data does change en route"
>
> I believe the intent here is that TLV data may change in route why the
> high order bit is set in the type, so the phrase " TLVs may change en
> route" is imprecise, only TLV data can change not type or length (if
> this is not the intent please let us know). The additional text about
> mutability in section 4.3.1 does nothing to bring clarity on this.
>
> Tom
>
> Regards
>   Brian
>
>
>
> Regards,
> Bob
>
>
>
>  In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are
>  defined in Section 4.4 of [RFC8200] as not mutable.  The Segments
>  Left field is defined as mutable in Section 4.4 of [RFC8200].
>
>  Some of the other fields of the SRH change en route (i.e. they are
>  mutable).  The SRH is processed as defined in Section 4.3 of this
>  document, and uniquely per SID type.  The mutability of the remaining
>  fields in the SRH (Flags, Tag, Segment List, Optional TLVs) are
>  defined in that section, in the context of segment processing.
>
> (2)the "or No Next Header" in the title of section 4.3.1.2 is irrelevant.
> 4.3.1.2.  Upper-layer Header or No Next Header
>
> Thanks,
> Jingrong
>
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Bob Hinden
> Sent: Wednesday, May 22, 2019 9:40 PM
> To: IPv6 List <[e-mail]>
> Cc: Bob Hinden <[e-mail]>
> Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>
>
> Hello,
>
> This message starts a new two week 6MAN Working Group Last Call on advancing:
>
>      Title           : IPv6 Segment Routing Header (SRH)
>      Authors         : Clarence Filsfils
>                        Darren Dukes
>                        Stefano Previdi
>                        John Leddy
>                        Satoru Matsushima
>                        Daniel Voyer
>     Filename        : draft-ietf-6man-segment-routing-header-19.txt
>     Pages           : 32
>     Date            : 2019-05-21
>
>   https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header
>
> as a Proposed Standard.
>
> This document was in an extended last call that started in March of 2018.   An issue tracker was set up, and eight new versions of the draft were produced and discussed on the list and at face to face 6man sessions.   All of the issues in the tracker have been closed.  The chairs believe it is ready to advance, but given the number of changes and the time that elapsed, a new w.g. last call is warranted.  Please review the new document.
>
> Our thanks to the authors/editors and the working group for the work on this document.
>
> Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author.  This last call will end on 5 June 2019.
>
> Thanks,
> Bob & Ole
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>