Hi Joel, 

Sent from my mobile

> On Sep 21, 2019, at 00:54, Joel M. Halpern <[email protected]> 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.
> 
DV: correct, you can use encapsulations but at the cost of 40bytes overhead. 
Running an operators backbone, with a widespread among of use cases, you need 
those bytes..

> Yours,
> Joel
Regards
Dan
> 
>> 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
> --------------------------------------------------------------------
> ------------------------------------------------------------------------------
> External Email: Please use caution when opening links and attachments / 
> Courriel externe: Soyez prudent avec les liens et documents joints
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to