Hi Joel and Dukes, Glad to see the safety situation is more clear now, although
Action2 inevitably violates RFC8200 design principle yet. I can feel you have
made many efforts to clarify how each action of insertion complies with 8200
and they are safe in the SR domain, well done, thanks! :) And, I agree, the
constraint that excludes other EH than SRH may limit the flexibility for future
extension. Is this constraint so important? Besides, as opposed to Encap mode,
Insertion mode can improve transfer efficiency, and has other
advantages/shortcomings. So, I think we need to elaborate that as a kind of
motivation to introduce Insertion mode. Because of Encap mode is in the main
SRH draft now. :) FYI, have a good day. Best regards, SING Moonlight Thoughts
SING Team. Guangzhou, China Signature is customized by Netease Mail Master On
09/21/2019 12:54, Joel M. Halpern wrote: 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 >
-------------------------------------------------------------------- >
-------------------------------------------------------------------- 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
