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

[Brian E Carpenter <[e-mail]>]

Ron, great review. Here are a few comments on some of your comments.

On 05/04/2018 04:22, Ron Bonica wrote:
> Folks,
...> Section 2.2 SRv6 Segment (Comment 5)
> 
> According to RFC 8200:
> 
> "If, while processing a received packet, a node encounters a Routing header with an unrecognized Routing Type value, the required behavior of the node depends on the value of the Segments Left field, as follows:
> 
>  -  If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header.
> 
> -  If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type."
> 
> This is safe, so long as all Routing Extension Types use SL == 0  to indicate that the Routing Extension Header has been completely processed. It is may not be safe when SL == 0 means that one more segment needs to be processed. 
> 
> In the SRH, SL == 0 indicates that one more segment needs to be processed. The document should address this security consideration.
> 
> If you redefine the SL to match RFC 8200's definition, this problem resolves itself.

Yes, it seems completely wrong to change the generic definition of SL. It creates
confusion and introduces problems for no reason. What's hard to understand in
the phrase "segments left"? Your later comments make this 100% clear.

> Section 2.3  Segment Routing (SR) Domain (Comment 1)
> 
> RFC 8200 says:
> 
> "Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header."
> 
> Draft-ietf-6man-segment-routing-header says:
> 
> " It is assumed in this document that the SRH is added to the packet by its source, consistently with the source routing model defined in  [RFC8200].  For example:
> 
>    o  At the node originating the packet (host, server).
> 
>    o  At the ingress node of an SR domain where the ingress node receives an IPv6 packet and encapsulates it into an outer IPv6 header followed by a Segment Routing header."
> 
> This gives the reader the impression that draft-ietf-6man-segment-routing-header is in harmony with RFC 8200.
> 
> However, Sections 4.13, 5.2  and 5.3 of draft-filsfils-spring-srv6-network-programming offer procedures in which intermediate nodes insert Segment Routing Headers. (Sometimes, they insert a second SRH in a packet that already has an SRH).
> 
> Draft-ietf-6man-segment-routing-header should either proscribe SHR insertion (using RFC 2119 language)

IMHO it doesn't need to, since it has RFC8200 as a normative reference. The
"It is assumed..." sentence seems acceptable to me.

> or update the above-mentioned assumption and define scenarios in which Routing Extension Header insertion is acceptable.

The debate around draft-voyer-6man-extension-header-insertion is far from over,
and I don't see draft-filsfils-spring-srv6-network-programming progressing
until that is settled. (You are probably correct in your later comment that
spring-srv6-network-programming needs to be a normative reference, so that
will hold up the current draft anyway.)

...
> 
> Section 4.1  Endpoint Function (End)  (Comment 2)
> 
> This section says, " An SRv6-capable node MUST include the Flow Label of the IPv6 header in its hash computation for ECMP load-balancing."

(For anybody checking this, in the text "Flow Label" is misspelt "FlowLabel".)
 
> This works only if the node that originated the packet sets the Flow Label to something other than zero.

Well, we don't know what else is being used for ECMP, do we? If the flow label
is zero, it has no effect, but whatever other fields are used for ECMP might
do the job. It's a bit odd to mention ECMP exactly once in the document, with
no details.

(The flow label is mentioned once elsewhere, in section 4.2 "End.X: Endpoint
with Layer-3 cross-connect" but almost as a throw-away line.)

> Furthermore, load balancing will still break of intermediate, none SRv6-capable nodes don't include the Flow Label in the hash computation

Not necessarily. It only breaks in some ECMP topologies where some paths
contain flow-label balancers and others don't. In fact, it's not got
much to do with SRv6 at all.

> The draft needs a section on load balancing and ECMP.

Either that, or say nothing at all. If it is a requirement that sources
set the flow label, there needs to be a normative citation of RFC 6437,
which defines how to do it. (If you're encapsulating, RFC 6438 might
also be relevant.)

     Brian