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

["Darren Dukes (ddukes)" <[e-mail]>]

Brian, thanks for starting the thread.  There has been a lot of conversation on this topic now for quite some time, and most recently on this thread, with some good explanations… I see the following:
 
1 – RFC8200 has some non-normative text stating non-source nodes do not insert extension headers. Neither RFC2460 nor RFC8200 disallow an intermediate node from inserting SRH.
    - RFC2460 section 4 did not exclude insertion of SRH’s
    - Errata ID: 4657 suggested some text from Fernando disallowing insertion, however the disposition of that Errata was “Held for Document Update”
    - RFC8200 closed Errata 4657 and there is no normative statement disallowing extension header insertion, rather the suggestion.
2 – Others, including yourself, have provided some constructive suggestions/comments that can be expanded upon in upcoming revisions.  We’ll work toward that.

Thanks
  Darren

On 2017-11-27, 5: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.
    
    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
    >