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

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

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]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>