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

On Mon, May 27, 2019 at 5:42 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.

Chengli,

Extension headers are not inserted or deleted by any node along a
packet's delivery path per RFC8200. Changing the length of an
extension header is equivalent to deleting an extension header and
inserting a new one in its place.

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

This topic has come up before in 6man list, in fact this is the
subject of draft-voyer-6man-extension-header-insertion-05. In those
discussions, issues in robustness, accountability and attribution
(both for operational and legal purposes), security, operations
(breaks ICMP for instance) have been brought up. The proponents of
extension header insertion have yet to adequately address those
issues.

> 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.

Adding and deleting TLVs is the topic in
"https://trac.ietf.org/trac/6man/ticket/69", please look at that. Note
that the ticket is closed, but it's pretty obvious that this it is not
resolved and the text in the latest draft seemingly creates a loophole
to do this by defining a "SID type" for that purpose.

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

Then it's also a general limitation in IPv6. For instance, IOAM is
useful networks that don't use segment routing. So if Adding/Deleting
TLVs is needed for SR TLVs then there's also needed for Hop-by-Hop
options. But, rather this is necessary and sufficient has yet to be
proven. There are two alternatives to adding TLVs: 1) Use IP
encapsulation which properly allows "EH insertion" in the outer header
since the encapsulator is sourcing an IPv6 packet 2) Use a mutable TLV
type (defined for HBH, DO, and SR options) that includes sufficient
scratch space for intermediate nodes to write their data.

Tom

>
>
> 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
> --------------------------------------------------------------------