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

["Chengli (Cheng Li)" <[e-mail]>]

Hi Brian,


-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: Thursday, June 06, 2019 4:48 AM
To: Chengli (Cheng Li) <[e-mail]>; Tom Herbert <[e-mail]>
Cc: IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

Hi Cheng,
On 05-Jun-19 19:03, Chengli (Cheng Li) wrote:
> Hi Tom,
> 
> Please see inline.
> 
> Cheng
> 
> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Monday, May 27, 2019 11:41 PM
> To: Chengli (Cheng Li) <[e-mail]>
> Cc: Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
> Subject: 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) <[e-mail]> 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.
> 
> [Cheng] Then we should updated the RFC8200? Otherwise, TI-LFA, Binding SID and Insertion mode can not work. But this is not related to SRH drafts. We need another draft maybe to describe that if needed.

No, this was debated at length during the development of RFC8200 and was clearly excluded. I will not repeat the arguments here, but it is all in the list archive.

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

Exactly. (And this is one of the motivations for draft-carpenter-limited-domains. There might be scenarios where we could deviate from the current rules, but they are not scenarios involving the open Internet.)

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

Exactly. And it isn't mutable. Hence the need for the encapsulation model for SRH or IOAM in general. None of this discussion is new.
[Cheng] Agree with the Hdr Ext Len is immutable, and the encapsulation model is needed. Many thanks!

   Brian

> 
> 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.
> 
> [Cheng] Regarding IOAM, I can not see how incremental  IOAM can work 
> if adding TLV is forbidden. Luckily, we can use PBT based Telemetry to 
> avoid this limitation:  
> https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-0
> 3
> 
> 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:[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
> --------------------------------------------------------------------
> .
>