Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt> - #22 & #23ECMP

["Darren Dukes (ddukes)" <[e-mail]>]

Thanks Joel.

Darren

> On Apr 24, 2018, at 11:15 AM, Joel M. Halpern <[e-mail]> wrote:
> 
> Thank you.  I do not know why when I went there earlier the datatracker did not offer me -12.  So it goes.
> 
> That text in section 5 is what I was looking for.  It seems quite clear and addresses what I asked for.  I am sorry I missed it.
> 
> Yours,
> Joel
> 
> On 4/24/18 11:11 AM, Darren Dukes (ddukes) wrote:
>> Hi Joel, I added the work group to the CC list, I think it was missed in your original mail.
>> Though I met the requests for #22 and #23, I wanted to point out that section 5 fully defines “source node”:
>>       A host originating an IPv6 packet.
>>       An SR domain ingress router encapsulating a received packet in an
>>       outer IPv6 header followed by an SRH.
>> Here is rev 12 of the draft https://www.ietf.org/id/draft-ietf-6man-segment-routing-header-12.txt
>> Darren
>>> On Apr 24, 2018, at 10:32 AM, Joel M. Halpern <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> I tried to find rev 12 to read the actual text.  I relied on the summary you put in as a comment.
>>> 
>>> The texxt you quote does help with both this issue and the encapsulation issue.
>>> I find the usage of "source node" awkward and likely to confuse readers, but I can not claim it is wrong.
>>> Similarly, the second paragraph you quote does say that flow label ECMP support has to be fully deployed.  Again, it does so in a way that I fear will confuse readers, but I can not claim it is wrong.
>>> 
>>> Net: you have formally met request.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 4/24/18 10:24 AM, Darren Dukes (ddukes) wrote:
>>>> Hi Joel, did you read the ECMP section or revision 12?  This is pretty clear of what the source node must do when encapsulating a packet in an outer IPv6 header.
>>>> 5.4. Load Balancing and ECMP
>>>>    Within an SR domain, an SR source node encapsulates a packet in an
>>>>    outer IPv6 header for transport to an endpoint.  The SR source node
>>>>    MUST impose a Flow Label computed based on the inner packet.  The
>>>>    computation of the flow label is as recommended in [RFC6438] for the
>>>>    sending TEP.
>>>>    At any transit node within an SR domain, the flow label MUST be used
>>>>    as defined in [RFC6438] to calculate the ECMP hash toward the
>>>>    destination address.
>>>>> On Apr 24, 2018, at 6:55 AM, Joel M. Halpern <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> The comment does not seem to resolve the4 issue raised (and captured in the ticket).
>>>>> 
>>>>> The basic issue is that if flow label ECMP is not being used by the network, then the routers in the network will not be able to perform ECMP.  This will result in some form of problem (whether congestion, packet drops due to processing failure, or other misbehavior depends upon the exact equipment.)
>>>>> 
>>>>> The comment for ticket #23 seems to say that this is addressed by pointing at the RFC about flow label ECMP.  It is good that the RFC is referenced explicitly.  From what is there, this needs to be augmented with text noting that this needs to be implemented and enabled on the network in order for SRH to be used.
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 4/23/18 5:06 PM, Darren Dukes (ddukes) wrote:
>>>>>> Hi Joel, this mail was captured as the following tracked issues:
>>>>>> #22 <https://trac.ietf.org/trac/6man/ticket/22>, #23 <https://trac.ietf.org/trac/6man/ticket/23>, #24 <https://trac.ietf.org/trac/6man/ticket/24>, #25 <https://trac.ietf.org/trac/6man/ticket/25>, #26 <https://trac.ietf.org/trac/6man/ticket/26>
>>>>>> I’ve updated comments that all these as closed in revision 12 of the doc and some clarification in the thread.  Can you click on each and read the comments to each please, and respond to thi thread?
>>>>>> Thanks
>>>>>>   Darren
>>>>>>> On Mar 30, 2018, at 10:51 AM, Joel M. Halpern <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> I do not think this document is ready to be sent to the IETF and IESG for final approval.
>>>>>>> There are several kinds of problems.
>>>>>>> 
>>>>>>> ECMP1: The document asserts that entropy information is put into the flow label.   I wish this worked.  I helped bring this idea forward years ago, independent of SRH.  Unfortunately, there are two related problems.  First, adoption appears to be low.  Second, and more important, there are reports from the field that doing thi actually breaks other things and cause packet re-ordering under some circumstances.  As a result, vendors are suggesting that people turn it off even when it is available.
>>>>>>> ECMP2: If, with suitable analysis, we decide that this is actually safe to do, then the document needs to include both that analysis and clearly spelled out requirements that operators MUST verify that all their routers support this behavior and that they have enabled this behavior before turning on SRv6 usage.
>>>>>>> 
>>>>>>> Structure: The text in section 2.3 says "It is assumed in this document that the SRH is added to the packet by its source".  This is at best disingenuous.  It is very clear that the value of this behavior lies primarily in use by the network, not by the packet sources.  Claiming otherwise results in a document with minimal utility.  Even this document itself disagrees with this assertion.  Tucked into the very next section is text saying that "outer header with an SRH applied to the incoming packet".  If this behavior were a clearly spelled out requirement, rather than a "typically" and if the text in 2.3 were replaced with something realistic, then the document would at least be itnernally consistent and match the expected usages.
>>>>>>> 
>>>>>>> Edge filtering: The text on edge filtering does not actually state that prevention of packets with SRH and a current DA of an internal node is mandatory.  Unless it is clearly stated, the security considerations text as currently written is significantly weakened.  If it is mandatory, then again the deployment section needs to note that an operator needs to verify that all of his edge devices support such filtering and have it properly enabled in order to use SRv6.
>>>>>>> 
>>>>>>> Edge Filtering and hybrids: Other documents have talked about allowing external packets with SRv6 entries pointing to internal nodes (which means the DA upon arrival at the operator edge will be an internal node as I understand it).  It the intention is to permit that with appropriate security, then the edge filtering requirements need to be clear about the requirements for cryptographic validation at the edge.
>>>>>>> 
>>>>>>> Yours,
>>>>>>> Joel
>>>>>>> 
>>>>>>> On 3/29/18 4:30 PM, Bob Hinden wrote:
>>>>>>>> This message starts a two week 6MAN Working Group Last Call on advancing:
>>>>>>>>        Title           : IPv6 Segment Routing Header (SRH)
>>>>>>>>        Authors         : Stefano Previdi
>>>>>>>>                          Clarence Filsfils
>>>>>>>>                          John Leddy
>>>>>>>>                          Satoru Matsushima
>>>>>>>>                          Daniel Voyer
>>>>>>>> Filename       : draft-ietf-6man-segment-routing-header-11.txt
>>>>>>>> Pages          : 34
>>>>>>>> Date           : 2018-03-28
>>>>>>>> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header
>>>>>>>> as a Proposed Standard.  Substantive comments and statements of support
>>>>>>>> for publishing this document should be directed to the mailing list.
>>>>>>>> Editorial suggestions can be sent to the author.  This last call will
>>>>>>>> end on 12 April 2018.
>>>>>>>> An issue tracker will be setup to track issues raised on this document.
>>>>>>>> Thanks,
>>>>>>>> Bob & Ole
>>>>>>>> --------------------------------------------------------------------
>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>> --------------------------------------------------------------------
>>>>>>> 
>>>>>>> --------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list
>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------