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

["Joel M. Halpern" <[e-mail]>]

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
>>>>>> --------------------------------------------------------------------
>