Subject: ECMP in draft-ietf-6man-segment-routing-header

From: Tom Herbert <[email-masked]>
Date: Thu, 10 May 2018 11:41:40 -0700

Hi,

Section 5.4 (Load Balancing and ECMP) has several MUSTs related to
ECMP processing. I don't believe that there are normative requirements
for ECMP so it seems like these should be SHOULDs at best..

Also, this statement is confusing:

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

But RFC6438  says "The flow label in the outer packet SHOULD be set by
the sending TEP to a 20-bit value".

So it seems like for an IP tunnel with SR flow label MUST be set, but
for other IPIP tunnels it's only  a SHOULD per RFC6438.

More generally, I don't see why load balancing or flow label needs any
special consideration for segment routing. This section could probably
be removed entirely without loss of meaning.

Tom

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 10 May 2018 11:48:53 -0700

+1

Cheers,
Jeff
On 5/10/18, 11:41, "ipv6 on behalf of Tom Herbert" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    

    
    
    Tom
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 May 2018 15:48:21 -0400

As someone who asked for this text, I have to ddisagree strongly with you.

Other portions of the docuemnt state that the expectation of this 
document on the domain is that it will use the flow label for ECMP.
In particular, routers that are not upgraded to understand SRv6, and 
which do not follow this requirement, are likely to be unable to provide 
ECMP to SRv6 packets.

As such, it is important to readers that the behavioral requirement be 
stated explicitly.  I appreciate the authors putting this text in.

Yours,
Joel

---

From: Tom Herbert <[email-masked]>
Date: Thu, 10 May 2018 13:50:31 -0700

On Thu, May 10, 2018 at 12:48 PM, Joel M. Halpern <[email-masked]> wrote:
> Other portions of the docuemnt state that the expectation of this document
> on the domain is that it will use the flow label for ECMP.
> In particular, routers that are not upgraded to understand SRv6, and which
> do not follow this requirement, are likely to be unable to provide ECMP to
> SRv6 packets.
>
Joel,

Sure, but the same thing would be true for any header format where
routers haven't been upgraded to parse over extension headers or parse
over some new type of encapsulation to find ports for the ECMP hash. I
still don't see why SRv6, which is nothing more than an EH and IPIP
encapsulation, is special in this regard. ECMP (especially flow based
ECMP) is just an optimization. It cannot be required for proper
operation of IPv6. If the implication in the draft is that SRv6
doesn't function correctly without the network meeting the ECMP
requirements in that section, then that might be an issue with the
protocol.

Actually, I'm all for using the flow label for ECMP and the sooner all
vendors support it the sooner we can eliminate a bunch of DPI. But
reality is there are still a lot of operators that turn it off because
of bad OOO interaction with stateful firewalls. Regardless of the
requirements set here, there are going to be networks where SRv6 is
run but flow label won't be used in at least some routers for ECMP.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 May 2018 15:07:51 +1200

If I recall correctly, the reason that RFC6438 has SHOULDs is because
there's always the option of just hashing the address pair, in which
case all traffic between the same two addresses will follow the same
path (exactly the same as if the flow label is set to zero).

I don't think it's impossible for the present draft to raise this
to an operational MUST, but indeed it's worth pointing out that
if doing this for SRH packets, you SHOULD++ do it for all packets.

It would be rather silly to have better ECMP balancing for SRH traffic
than for normal traffic, but it doesn't break anything that I can see.
(Server load balancing is another problem.)

Regards
   Brian