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

On Sun, 22 Sep 2019, 03:04 Tom Herbert, <tom@herbertland.com> wrote:

> 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 entire use of the word "insertion" is incorrect if the ID is now only
proposing encapsulation/tunnelling to carry transit traffic across the SR
domain.

According to Google, the meaning of "insert" is:

place, fit, or push (something) into something else.

The process of encapsulation, by creating a new IPv6 packet, and creating
one or more new EHs following it (which may be derived from EHs received
from somewhere else), and then carrying the existing packet unmodified as
payload in the new packet, does not involve any "place, fit, or push
(something) *into* something else".

Encapsulation is addition to the outside of the existing.

I don't really understand why people are seeming to want to cling to using
the word insertion, despite it being entirely inaccurate when using
encapsulation.

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

At each point where a function using the SRH needs to be performed, that is
one segment's and point, and another segment's start point.

They would also be an IPv6 tunnel end point and another tunnel's start
point (segments and tunnels are 1:1). The new outgoing segment tunnel
header would have the local device as its source address, providing
attribution.

In other words a sequence of segments in an SR over IPv6 network would be a
sequence of distinct IPv6 tunnels, 1:1 for the entire path.

This model is entirely compliant with RFC 8200, and as tunnels end points
are hosts using RFC 8200's definitions, host EHs such as Destination
Option, or AH and ESP can be used in an RFC 8200 compliant manner.

Regards,
Mark.

> Tom
>
>
> Tom
>
> On Fri, Sep 20, 2019 at 9:35 PM Darren Dukes (ddukes) <ddukes@cisco.com>
> 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: <internet-drafts@ietf.org>
> > 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
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>