Re: New Version Notification for draft-voyer-6man-extension-header-insertion-07.txt

[Tom Herbert <[e-mail]>]

Some comments:

Most of the constraints listed section 2.2 should be specified as
normative requirements.

"SR domain link MTU is sufficiently greater than the MTU at the
ingress edge of the SR domain..." should be the requirement: "The MTU
for all paths in the domain MUST be large enough to accommodate the
maximum length of an inserted SRH"

Also, for sizing MTU some guidance to the operator to determine what
the maximum length SRH they will ever need would be useful.

"Within the context of this document and the described SRH use-case
within the SR domain, the SR domain can guarantee that SRH is the sole
extension header after the outer IPv6 header." should be the
requirement "An SRH MUST NOT be inserted into a packet that already
has extension headers"

"All traffic within the SR domain has IPv6 source and destination
address within the SR domain." should be requirement: "All traffic
within the SR domain MUST have an IPv6 source and destination address
that is within the SR domain."

Similarly, "Only traffic sourced from and destined to nodes in the SR
domain may have an SRH inserted." could be: "Traffic sourced from or
destined to a node outside of the SR domain MUST NOT have an SRH
inserted."

About "IPv6 encapsulation and optional insertion of SRH at the SR
domain ingress edge generates a new IPv6 packet." and "IPv6
encapsulation and SRH insertion at SR Domain ingress edge."

This is a bit confusing in the use of the word "insertion" in the
context of encapsulation, and on first read it seemed to be allowing
SRH insertion at ingress into the domain (without encapsulating).
Instead of saying "insertion" here, maybe something like "the SRH may
be included when encapsulating". That is, reserve the term "insertion"
to explicitly mean when SRH is being inserted into an existing IPv6
packet without encapsulating.

The attribution problem hasn't been addressed. I imagine it may be
possible to put the address of the node inserting an SRH somewhere in
the header in order to provide proper attribution.

Tom


Tom

On Fri, Sep 20, 2019 at 9:35 PM Darren Dukes (ddukes) <[e-mail]> wrote:
>
> Hello everyone, we’ve just submitted an updated draft that explains why SRH insertion is performed in an SR domain, how it is accomplished and why it is safe within the SR domain.
>
> The authors look forward to your comments and suggestions on how to improve this document.
>
> Thanks!
>   Darren (on behalf of the authors)
>
> Begin forwarded message:
>
> From: <[e-mail]>
> Subject: New Version Notification for draft-voyer-6man-extension-header-insertion-07.txt
> Date: September 21, 2019 at 12:20:13 AM EDT
>
>
> A new version of I-D, draft-voyer-6man-extension-header-insertion-07.txt
> has been successfully submitted by Darren Dukes and posted to the
> IETF repository.
>
> Name: draft-voyer-6man-extension-header-insertion
> Revision: 07
> Title: Insertion of IPv6 Segment Routing Headers in a Controlled Domain
> Document date: 2019-09-20
> Group: Individual Submission
> Pages: 13
> URL:            https://www.ietf.org/internet-drafts/draft-voyer-6man-extension-header-insertion-07.txt
> Status:         https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
> Htmlized:       https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-07
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07
>
> 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.
>
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------