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

Hi,

I'd like to comment on this version. It is in fact a complete rewrite compared to
its predecessors and I thank the authors for that. The tone is now purely technical,
and that's a great improvement.

It's also, IMHO, accurate in its statements about the relationship with RFC 8200.
In particular:

>    Action 2 inserts an SRH in a packet within the SR domain at a node
>    not in the destination address, and inserts more than one SRH in a
>    packet.  This does not appear to be permitted by the statements
>    quoted above from RFC8200.  However, the restrictions above are not
>    applicable within the SR domain.  Every source node participating in
>    the SR domain expects SRH insertion, relies on it for services
>    provided by the SR domain, correctly processes ICMP errors, and
>    according to RFC8200 must process multiple SRH in the same packet.

That statement "the restrictions above are not applicable within the SR domain"
is (it seems to me) a normative statement. It might be even clearer to state it
as such:
  ...the restrictions above SHOULD NOT be applied within the SR domain.

Clearly it's a WG question whether on not we want to put this on the standards
track. I hope we can discuss it as a technical question. My subsidiary
question is: does the description of an SR domain (here and in RFC8402)
provide enough security and operational assurance that this SHOULD NOT is
safe?

Regards
   Brian Carpenter

On 21-Sep-19 16:20, internet-drafts@ietf.org 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
>                           Clarence Filsfils
>                           Darren Dukes
>                           Satoru Matsushima
>                           John Leddy
> 	Filename        : draft-voyer-6man-extension-header-insertion-07.txt
> 	Pages           : 13
> 	Date            : 2019-09-20
> 
> Abstract:
>    Traffic traversing an SR domain is encapsulated in an outer IPv6
>    header for its journey through the SR domain.
> 
>    To implement transport services strictly within the SR domain, the SR
>    domain may require insertion or removal of an SRH after the outer
>    IPv6 header of the SR domain.  Any segment within the SRH is strictly
>    contained within the SR domain.
> 
>    The SR domain always preserves the end-to-end integrity of traffic
>    traversing it.  No extension header is manipulated, inserted or
>    removed from an inner transported packet.  The packet leaving the SR
>    domain is exactly the same (except for the hop-limit update) as the
>    packet entering the SR domain.
> 
>    The SR domain is designed with link MTU sufficiently greater than the
>    MTU at the ingress edge of the SR 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-07
> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07
> 
> 
> 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
> I-D-Announce@ietf.org
> 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
> 