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) <[email protected]> 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: <[email protected]> > 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 > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
