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

[Bob Hinden <[e-mail]>]

Darren,

> On May 25, 2019, at 7:27 AM, Darren Dukes (ddukes) <[e-mail]> wrote:
> 
> Bob. This text is functionally identical to the current text. This editorial change can be made but we would replace the word option with type.

Looking back at the doc, that sounds right to me.  The T in TLV, is of course "Type".  So it would be:

  The highest-order bit of the TLV type specifies whether or not the
  TLV data of that type 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”

Thanks,
Bob


> 
> Darren
> 
>> On May 24, 2019, at 7:38 PM, Bob Hinden <[e-mail]> wrote:
>> 
>> Tom,
>> 
>>> 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.
>> 
>> To my read, I think I prefer that text you are proposing.  That is:
>> 
>> 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”
>> 
>> Any objections to making this change?
>> 
>> Bob
>> 
>> 
>> 
>>> 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
>> --------------------------------------------------------------------