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

Hi Darren,

Thanks for your reply. It seems like reasonable to pre-allocate space for IOAM. Also, PBT[1] based Telemetry can avoid this problem.

However, in Stateless SFC[2], the NSH TLV can be included in SRH to carry metadata. The length of metadata may be mutable and hard to be pre-computed when the MD type is 2.

Maybe we still can pre-allocate enough space for this scenarios, but I still think we should make HDR as mutable.

The fields that will not be changed en route will not affect the length of the SRH.

The mutable fields  will not count when compute ICV, and the changes of them are allowed, so why to limit  the change of length? There is no need to limit the length of these fields, because this does not help on Authentication but brings limitation.

It is a general problem for IOAM and SFC, which need to add metadata into data packets.

Thanks,

Cheng

[1] https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-03

[2] https://tools.ietf.org/html/draft-xuclad-spring-sr-service-programming-02#section-7.2.1

-----Original Message-----

From: Darren Dukes (ddukes) [mailto:ddukes@cisco.com]

Sent: Tuesday, May 28, 2019 1:22 AM

To: Chengli (Cheng Li) <chengli13@huawei.com>

Cc: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>

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

Hi Cheng, thanks for the support, I have a couple comments inline.

> On May 27, 2019, at 8:41 AM, Chengli (Cheng Li) <chengli13@huawei.com> wrote:

>

> Support. Many thanks to authors for their contributions! I agree that we should specify how the AH works with SRH in other drafts.

>

> But I can NOT find any text of describing Hdr Ext Len is not mutable in RFC8200.

> Hdr Ext Len SHOULD be mutable, otherwise, use cases like incremental SRv6 IOAM[1] can not work.

draft-ali-6man-spring-srv6-oam-01 actually reserves TLV at an SR Source node for use by segment endpoint nodes, so it doesn’t change the size of TLVs (see 4.4.2.1 and 4.4.2.2 of that draft).

> All the use cases of inserting or deleting new TLV, or updating TLV with new length value are not allowed if Hdr Ext Len is not mutable.

Use cases you’re thinking of should be able to use a method similar to that in draft-ali-6man-spring-srv6-oam, I would be interested to hear about them.

Thanks

  Darren

>

> I think it is a limitation to SRv6 that we should avoid it definitely.

>

>

> Best Regards,

> Cheng

>

> [1]. https://tools.ietf.org/html/draft-ali-6man-spring-srv6-oam-01#section-4.4.1

>

> -----Original Message-----

> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden

> Sent: Wednesday, May 22, 2019 9:40 PM

> To: IPv6 List <ipv6@ietf.org>

> Cc: Bob Hinden <bob.hinden@gmail.com>

> 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

> ipv6@ietf.org

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

> --------------------------------------------------------------------

>

> --------------------------------------------------------------------

> IETF IPv6 working group mailing list

> ipv6@ietf.org

> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

> --------------------------------------------------------------------