Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

[Tom Herbert <[e-mail]>]

On Mon, Nov 27, 2017 at 2:31 PM, Brian E Carpenter
<[e-mail]> wrote:
> Hi,
>
> I'm probably repeating myself, but it seems clear that this draft
> in its present form will never get anywhere. Firstly I will try to
> justify this statement, and secondly I'll try to make some
> constructive suggestions.
>
> I. The problems with the current draft:
>
> I.1. No RFC is allowed to have more than five authors without
> an extremely good reason. If six or seven people have contributed
> roughly equal amounts you might just be able to persuade the
> RFC Editor to list everybody, but 18? Never.
> https://tools.ietf.org/html/rfc7322#section-4.1.1
>
> I.2. More serious is the tone, which starts with the Abstract.
> "The network operator and vendor community has clearly indicated..."
> is, to put it mildly, out of place in an IETF document. We work
> by facts and rough consensus, not by declarations by vested
> interests. I think a lot of people will simply stop reading
> the draft after that sentence.
>
> The tone needs to be rational and factual argument about why
> the proposed mechanism is both desirable and harmless. The
> abstract needs to be a factual summary.
>
> I.3. A detail is that since this draft recommends ignoring
> a rule in RFC 8200, it needs to be aimed at the standards
> track with Updates: 8200.
>
> I.4. Another detail is that in some places the draft seems
> to assume that only segment routing headers will be
> candidates for insertion. That may be true today, but
> probably not for ever.
>
+1

I'm also leary of proposals that redefine protocol behavior on the
basis that it will only be used in a controlled domain. This entails
assumptions that all devices (both intermediate devices and end hosts)
in the domain play by these rules, creates several corner cases that
need to be dealt with, and necessitates rationalization that packets
using non-interoperable protocol are never leaked out of the domain.

For instance, here is a corner case that I see...

>From the draft:

"The source domain may decide to place the IPv6 extension header
insertion where it suits its best: at the source of the packet or at
any midpoint within the source domain"

This statement implies that all hosts are under control of the source
domain, but that is not typically the case. A source host on its own
accord may create a packet with extension headers, some of which might
be the same type that intermediate devices insert and remove. It's not
clear what the disposition is of such packets and their extension
headers in in this draft.

Another question that comes to mind is why encapsulation does not work
here. That is encapsulate the packet on ingress to the domain, use
whatever extension headers are needed in the outer header, and
decapsulate on egress (i.e. this was the original "answer" to
extension header insertion). I'm guessing this might be because of
packet overhead, but it would be nice to see the reasons articulated.

Tom

> II. Constructive suggestions.
>
> I understand that the idea is to propose that this rule
> in https://tools.ietf.org/html/rfc8200#section-4 :
>
> "  Extension headers (except for the Hop-by-Hop Options header) are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node (or each of the set of nodes,
>    in the case of multicast) identified in the Destination Address field
>    of the IPv6 header."
>
> MAY be ignored within an administrative domain for packets that
> terminate within that domain. If that's the intention, I think
> there are several logical steps in the argument that need to
> be laid out. A lot of the ideas are already in the draft; this
> is mainly about making a clear and logical case that the whole
> community can understand.
>
> 1. Introduction, outline of use cases [1].
> 2. Precise definition of a domain and of its boundary, ingresses and egresses.
> 3. Explanation of how the class of packets eligible for header insertion are identified [2].
> 4. Explanation of how the well-known issues are avoided (PMTUD, fragmentation, IPSec).
> 5. Clear statement of what header manipulations are allowed and which devices may perform them.
> 6. Precise statement of which text in RFC 8200 is updated.
> 7. Security considerations
>
> [1] More details on use cases could be an appendix.
>
> [2] https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02#section-3
> is IMHO correct as far as transit packets go. But it
> should be presented as a mainstream part of the proposal,
> not as an example.
>
> I hope this is helpful.
>    Brian Carpenter
>
>
>
> On 21/11/2017 07:33, [e-mail] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>>         Title           : Insertion of IPv6 Segment Routing Headers in a Controlled Domain
>>         Authors         : Daniel Voyer
>>                           Daniel Bernier
>>                           John Leddy
>>                           Clarence Filsfils
>>                           Darren Dukes
>>                           Stefano Previdi
>>                           Stefano Salsano
>>                           Antonio Cianfrani
>>                           David Lebrun
>>                           Olivier Bonaventure
>>                           Prem Jonnalagadda
>>                           Milad Sharif
>>                           Hani Elmalky
>>                           Ahmed Abdelsalam
>>                           Robert Raszuk
>>                           Arthi Ayyangar
>>                           Dirk Steinberg
>>       Filename        : draft-voyer-6man-extension-header-insertion-02.txt
>>       Pages           : 14
>>       Date            : 2017-11-20
>>
>> Abstract:
>>    The network operator and vendor community has clearly indicated that
>>    IPv6 header insertion is useful and required.  This is notably the
>>    case when the entire journey of the packet remains in its source
>>    domain.  In such a context, it does not matter where the extension
>>    header is inserted.  The source domain may decide to place the IPv6
>>    extension header insertion where it suits its best: at the source of
>>    the packet or at any midpoint within the source domain.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02
>> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-02
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------