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

[Gyan Mishra <[e-mail]>]

Sent from my iPhone

> On Oct 14, 2019, at 7:53 PM, Mark Smith <[e-mail]> wrote:
> 
>> On Tue, 15 Oct 2019 at 10:31, Gyan Mishra <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Mon, Oct 14, 2019 at 6:56 PM Mark Smith <[e-mail]> wrote:
>>> 
>>> Hi  Tom,
>>> 
>>>> On Tue, 15 Oct 2019 at 08:53, Tom Herbert <[e-mail]> wrote:
>>>> 
>>>>> On Mon, Oct 14, 2019 at 2:15 PM Mark Smith <[e-mail]> wrote:
>>>>> 
>>>>> Now that tunnelling has been accepted, and that a distinct IP tunnel could be created for each segment, 1:1, with tunnel/segment heads or tails being the place where the SRH can be created or transferred, with or without modification, or over from the previous segment/tunnel, which does comply with RFC8200 (as tunnel endpoints are IPv6 hosts), there is no functional need for mid-tunnel anonymous insertion.
>>>>> 
>>>> Mark,
>>>> 
>>>> I would tend to agree. It seems that the only purported benefit of SR
>>>> insertion over tunneling is that it saves packet overhead. But I don't
>>>> think that really pans out. In insertion without attribution, the
>>>> difference is twenty-four bytes overhead, but if attribution is done
>>>> (like node modifying the packet puts it address in it somewhere), then
>>>> the overhead is as little as eight bytes (possibly even less if there
>>>> is only one entry in the SID list). Relative to the potential large
>>>> size of the SRH itself, I don't seethe potential savings in overhead
>>>> to be very impressive especially relative to the complexities of
>>>> defining a robust and secure protocol for EH insertion.
>>>> 
>>> 
>>> Once an IPv6 tunnel is considered a link-layer (because it is and is
>>> being used that way), then there are opportunities to perform forms of
>>> compression on the inner payload packet to reduce overhead between the
>>> tunnel end-points, as link-layers don't process payloads (nothing new
>>> here, no lower layers are supposed to process their upper layer
>>> payloads at any layer).
>>> 
>>> I don't know much about it, however it looks like Robust Header
>>> Compression (RoHC) could be used (RFC5795) to compress the inner
>>> packet headers while the packet is in flight across the current IPv6
>>> tunnel/SR segment/virtual link. A quick Internet search finds a few
>>> implementations, including a couple of open source ones.
>>> 
>>> RoHC might be too stateful or not able to be performed fast enough on
>>> high speed links. The following method is stateless, takes advantage
>>> of IPv6 networks having many /64s, using them to identify tunnel
>>> endpoints (rather than /128s), and leverages the common fields and
>>> field semantics between the inner and outer header, using the outer
>>> header fields as proxies for the inner header fields while the packets
>>> are in flight.
>>> 
>>> "Skinny IPv6 in IPv6 Tunnelling"
>>> https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00
>>> 
>>> As long as it provides attribution (the source /64 in its case), and
>>> is fully reverseable, excepting the mutable Traffic Class and Flow
>>> Label fields, I think it too could be an option to reduce inner packet
>>> overhead if 128 bit SIDs are used.
>>> 
>>> Regards,
>>> Mark.
>>> 
>>> [Gyan]  unfortunately we would have multiple EH insertions so that GRE tunnel won’t work.
>> 
>> 
>> In that stick diagram I had sent the 1st EH insertion is on the ingress PE of the SRv6 domain and then for Ti-LFA at the PLR (point of local repair) for IP fast reroute backup path a 2nd EH insertion which would be at mid point somewhere  along the path to the 1st outer tunnel endpoint so you would have at a minimum 2 encapsulations in following RFC 8200.  So 6in6 tunnel won’t work unfortunately.
>> 
> 
> Well firstly, I'm going to pretty much not bother trying to understand
> anything where you suggest insertion, because I've literally spent
> hours of my own time writing up why I disagree with it and the
> problems it causes.
> 
> It sounds like you think there can't be a 6in6in6 tunnel. Or a
> 6in6in6in6 tunnel.
> 
> There's nothing that technically stops tunnels being inside tunnels.
> Same as LSPs inside LSPs ...
> 
> Have a read of
> 
> "IP Tunnels in the Internet Architecture"
> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10
> 
> if you haven't already.

[Gyan] So in theory some say once this I-D becomes approved standard at some point vendors will implement the feature and support but anyone doing SRv6 today which is supported in Cisco XR 7.0 and I believe Juniper and Huawei supports however today the multi tunnel stacking feature is not an option for today’s deployments.
> 
>> 
>>     I think the only viable option is the using a virtual interface like a loopback for the /64 SID to be in compliance with RFC 8200.
>> 
>> Gyan
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Tom
>>>> 
>>>> 
>>>>> So what is the reason to persist with it? It doesn't make sense to me that people are clinging to an idea that has so many flaws and contradictions to standard behaviour, when there is a method that works without these flaws and contradictions.
>>>>> 
>>>>> Determining whether or not to perform deeper packet processing (SRH processing in this case) on a packet, using the packets' DA, is conventional, traditional, and implemented in billions of deployed devices, both hosts and routers.
>>>>> 
>>>>> Contrast that with a device having to purposely ignore literally every packets' DA that it looks at, to search all of those packets for an SRH to then determine if it should perform SR processing on it. Unconventional, non-traditional, and a capability I'd guess is likely to be deployed in way less than 10 000 devices,  and likely less than 1000.
>>>>> 
>>>>> Not updating SAs after packet modification, and having to purposely ignoring packets' DAs, is down a rat hole that NAT also lives in.
>>>>> 
>>>>> Regards,
>>>>> Mark.
>>>>> 
>>>>>> On Tue, 15 Oct 2019, 02:54 Tom Herbert, <[e-mail]> wrote:
>>>>>> 
>>>>>> On Sat, Oct 12, 2019 at 2:58 PM Brian E Carpenter
>>>>>> <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I'd like to comment on this version. It is in fact a complete rewrite compared to
>>>>>>> its predecessors and I thank the authors for that. The tone is now purely technical,
>>>>>>> and that's a great improvement.
>>>>>>> 
>>>>>>> It's also, IMHO, accurate in its statements about the relationship with RFC 8200.
>>>>>>> In particular:
>>>>>>> 
>>>>>>>>   Action 2 inserts an SRH in a packet within the SR domain at a node
>>>>>>>>   not in the destination address, and inserts more than one SRH in a
>>>>>>>>   packet.  This does not appear to be permitted by the statements
>>>>>>>>   quoted above from RFC8200.  However, the restrictions above are not
>>>>>>>>   applicable within the SR domain.  Every source node participating in
>>>>>>>>   the SR domain expects SRH insertion, relies on it for services
>>>>>>>>   provided by the SR domain, correctly processes ICMP errors, and
>>>>>>>>   according to RFC8200 must process multiple SRH in the same packet.
>>>>>>> 
>>>>>>> That statement "the restrictions above are not applicable within the SR domain"
>>>>>>> is (it seems to me) a normative statement. It might be even clearer to state it
>>>>>>> as such:
>>>>>>>  ...the restrictions above SHOULD NOT be applied within the SR domain.
>>>>>>> 
>>>>>> Brian,
>>>>>> 
>>>>>> Dissecting this a bit:
>>>>>> 
>>>>>> "Every source node participating in the SR domain expects SRH insertion"
>>>>>> 
>>>>>> That is awfully inclusive and seems to be retroactively creating a
>>>>>> fundamental property of SR domains. Also, no opt out form source? I
>>>>>> would expect that in most use cases, probably all in deployment today,
>>>>>> the SR EH is set at the ingress node into the SR domain and describes
>>>>>> the path to egress. The fact that some intermediate node might insert
>>>>>> an EH could conceivably be a security issue in such deployments more
>>>>>> than anything. IMO, if EH is allowed then source nodes should be able
>>>>>> to opt out, or even better EH insertion should always be opt in from
>>>>>> the source. If a source node wishes to enforce that no EHs are
>>>>>> inserted it can do that with AH (assuming that AH were properly
>>>>>> specified to interact with SRH)..
>>>>>> 
>>>>>> The draft also states that the source and destination are required to
>>>>>> be in the same SR domain for EH insertion. This needs to be specified
>>>>>> as a MUST. The obvious question this raises is: how does an
>>>>>> intermediate node know that a source and destination are in the SR
>>>>>> domain? I would infer that the authors are probably assuming that this
>>>>>> can be done by specifying a prefix for the SR domain or maybe a
>>>>>> whitelist of addresses? This is easy enough to propose, but on a
>>>>>> network of even moderate scale I'm not convinced it's manageable. I
>>>>>> suggest an alternative is for the source node to mark packets for
>>>>>> which EH insertion is permissible (i.e. the opt in model). This could
>>>>>> be done for instance by the source setting a null SR header (no SIDs)
>>>>>> with a flag that indicates EH insert is permitted.
>>>>>> 
>>>>>> "correctly processes ICMP errors"
>>>>>> 
>>>>>> That presumes that correct processing of ICMP errors is well defined.
>>>>>> Consider this scenario:
>>>>>> 
>>>>>> An intermediate node inserts an SRH with HMAC, a subsequent downstream
>>>>>> node attempts to verify the HMAC and fails to verify. The downstream
>>>>>> node sends an ICMP packet back to the source. What is source supposed
>>>>>> to do with this ICMP error? (note this is just one scenario, the
>>>>>> general case is how to deal with ICMP errors sent because of error in
>>>>>> the inserted EH). There is nothing that source host can do within the
>>>>>> protocol to avoid further occurrences of the error. At best they'll
>>>>>> log it, but since there's no attribution so now somebody someone needs
>>>>>> to track down who is inserting the EH-- in a complex network that may
>>>>>> be non-trivial.
>>>>>> 
>>>>>> Attribution is critical. One obvious way to address this would be for
>>>>>> the node inserting the EH to put its address into the SRH, but then
>>>>>> that reduces the overhead savings of SR EH insertion compared to
>>>>>> encapsulation to be just eight bytes (destination address in
>>>>>> encapsulation is same as last address in insert SID list). IMO, it
>>>>>> would be better to just do encapsulation instead.
>>>>>> 
>>>>>> Another hole is correct ICMP processing is reflected in:
>>>>>> 
>>>>>> "The SR domain ingress edge processing the ICMP error SHOULD log the
>>>>>> error and decrement the ingress edge MTU for traffic traversing the SR
>>>>>> domain (if it's greater than the IPv6 minimum MTU of 1280 bytes)"
>>>>>> 
>>>>>> Okay, but what if the source _is_ already at minimum MTU for PMTU?
>>>>>> Note that SRH can be hundreds of byte and now with insertion there can
>>>>>> be multiple SRHs of these is a packet, I don't think this is something
>>>>>> that can be easily dismissed with the typical assumption that all
>>>>>> networks can just set MTUs large enough.
>>>>>> 
>>>>>> "However, the restrictions above are not applicable within the SR domain"
>>>>>> 
>>>>>> I think the wording here is wrong for the intent of the draft. All the
>>>>>> normative "MUSTs" in RFC8200 and other appropriate standards are
>>>>>> applicable to _all_ use cases of the protocol. I see no provision in
>>>>>> RFC8200 that its requirements, like prohibition of EH insertion, are
>>>>>> conditional based on the environment in which the protocol is
>>>>>> deployed. So RFC8200 is applicable in SR domains, limited domains, and
>>>>>> the Internet. IMO, this draft is trying to justify an exception to the
>>>>>> requirements and should be written as such. Presumably, the exception
>>>>>> might be palatable if it maintains robustness, interoperability, and
>>>>>> spirit of requirements of RFC8200.
>>>>>> 
>>>>>> Tom
>>>>>> 
>>>>>>>>   the SR domain expects SRH insertion
>>>>>>> Clearly it's a WG question whether on not we want to put this on the standards
>>>>>>> track. I hope we can discuss it as a technical question. My subsidiary
>>>>>>> question is: does the description of an SR domain (here and in RFC8402)
>>>>>>> provide enough security and operational assurance that this SHOULD NOT is
>>>>>>> safe?
>>>>>>> 
>>>>>> Hi Brain,
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Regards
>>>>>>>   Brian Carpenter
>>>>>>> j
>>>>>>>> On 21-Sep-19 16:20, [e-mail] wrote:
>>>>>>>> 
>>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>        Title           : Insertion of IPv6 Segment Routing Headers in a Controlled Domain
>>>>>>>>        Authors         : Daniel Voyer
>>>>>>>>                          Clarence Filsfils
>>>>>>>>                          Darren Dukes
>>>>>>>>                          Satoru Matsushima
>>>>>>>>                          John Leddy
>>>>>>>>      Filename        : draft-voyer-6man-extension-header-insertion-07.txt
>>>>>>>>      Pages           : 13
>>>>>>>>      Date            : 2019-09-20
>>>>>>>> 
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 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-07
>>>>>>>> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-07
>>>>>>>> 
>>>>>>>> A diff from the previous version is available at:
>>>>>>>> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-07
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 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
>>>>>>>> [e-mail]
>>>>>>>> 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
>>>>>>>> 
>>>>>>> 
>>>>>>> --------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list
>>>>>>> [e-mail]
>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------
>>>>>> 
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> --
>> 
>> Gyan S. Mishra
>> 
>> IT Network Engineering & Technology
>> 
>> Verizon Communications Inc. (VZ)
>> 
>> 13101 Columbia Pike FDC1 3rd Floor
>> 
>> Silver Spring, MD 20904
>> 
>> United States
>> 
>> Phone: [phone]
>> 
>> Email: [e-mail]
>> 
>> www.linkedin.com/in/networking-technologies-consultant
>> 
>>