I see where the draft defines a set of constraints.
The constraint that there be no other extension headers is a fairly
drastic constraint, which would seem a cause for concern.
Putting that aside however, the draft does not seem to provide any
explanation for why insertion rather than additional encapsulation is
used. Particularly given the assumption that the MTU is large enough,
it seems the encapsulation could be used for all insertion cases.
Yours,
Joel
On 9/21/2019 12:34 AM, Darren Dukes (ddukes) 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] <mailto:[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
<http://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
