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

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Nov 2019 19:17:14 +1300

Hi,

Results from a very partial reading of this version:
 
>    In each deployment, traffic traversing an SR domain is encapsulated
>    in an outer IPv6 header for its journey through the SR domain.

Add: "The source and destination addresses in the outer header both lie within the SR domain."
And explain how that is *enforced*. (You mention this later, in section 3.1, but still not how it is enforced.)

>    The packet leaving the SR
>    domain is exactly the same (except for the hop-limit update) as the
>    packet entering the SR domain.

Is the hop limited decremented by 1, 2 or some other number? By analogy with RFC4213, it should probably be 1.

>    The SR domain is designed with link MTU sufficiently greater than the
>    MTU at the ingress edge of the SR domain.

"sufficiently"? Is it possible to calculate the largest possible insertion, and therefore say something more precise than "sufficiently"? You come back to this point in section 7 but the phrase "the maximum encapsulation overhead deemed required by the deployment" is no better than "sufficiently". Also, section 7 says: "The exact number is operator specific and is outside the scope of this document." I don't think that's OK; I think it's necessary to indicate how this can be calculated. How will an operator new to SR6 learn how to make the calculation?

The very next sentence says "Some indications on how to plan this are provided in the following sections." Well, it's still vague. For example "The maximum encapsulation size of any node within the SR domain is limited to a specific value, this maximum is used to calculate the maximum link MTU". What specific value? How is it determined?

Then: "Any packet exceeding the MTU of a link generates an IPv6 ICMP error message "packet too big" back to the source of the packet." Which source, the SR domain ingress or the encapsulated packet's source?

Finally, this draft is now a factual statement about vendor and operator practice. Why does it need to be an IETF stream RFC? In many ways it's exactly the sort of document that is published as an Independent Submission stream RFC.

   Brian

On 20-Nov-19 18:22, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Deployments With Insertion of IPv6 Segment
>     Routing Headers
>         Authors         : Daniel Voyer
>                           Clarence Filsfils
>                           Darren Dukes
>                           Satoru Matsushima
>                           John Leddy
>                           Zhenbin Li
>                           James Guichard
> 	Filename        : draft-voyer-6man-extension-header-insertion-08.txt
> 	Pages           : 12
> 	Date            : 2019-11-19
> 
> Abstract:
>    SRv6 is deployed in multiple provider networks.
> 
>    This document describes the usage of SRH insertion and deletion
>    within the SR domain and how security and end-to-end integrity is
>    guaranteed.
> 
> 
> 
> 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-08
> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-08
> 
> 
> 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
> [email-masked]
> 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
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 22 Nov 2019 09:42:09 +0000

Brian, thanks for the lightning read :)

> On Nov 21, 2019, at 2:17 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

OK, I’ll take a look at that.

> Is the hop limited decremented by 1, 2 or some other number? By analogy with RFC4213, it should probably be 1.

Ah good note, perhaps a ref to RFC4273 is needed for context.

> The very next sentence says "Some indications on how to plan this are provided in the following sections." Well, it's still vague. For example "The maximum encapsulation size of any node within the…

I think 9.3 is what you’re looking for.

> Then: "Any packet exceeding the MTU of a link generates an IPv6 ICMP error message "packet too big" back to the source of the packet." Which source, the SR domain ingress or the encapsulated packet…

We’ve said all packets within the SR Domain have source and dest within the domain, so this is the source of the outer IPv6 header.  But point taken, the text is not clear.

Thanks!
  Darren

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------