Subject: [ippm] Erik Kline's Discuss on draft-ietf-ippm-route-09: (with DISCUSS and COMMENT)

From: Erik Kline via Datatracker <[email-masked]>
Date: Mon, 10 Aug 2020 17:00:26 -0700

Erik Kline has entered the following ballot position for
draft-ietf-ippm-route-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-route/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ section 4.1 ]

* I don't quite understand this apparent reliance on IPv6 flows being routed or
  load-balanced by src/dst and flow label alone.  I know of implementations
  where that is not the case at all, and in fact RFC 6437 specifically advises
  that the flow label alone not be relied upon.  Quoting section 2:

  o  Forwarding nodes such as routers and load distributors MUST NOT
     depend only on Flow Label values being uniformly distributed.  In
     any usage such as a hash key for load distribution, the Flow Label
     bits MUST be combined at least with bits from other sources within
     the packet, so as to produce a constant hash value for each flow
     and a suitable distribution of hash values across flows.
     Typically, the other fields used will be some or all components of
     the usual 5-tuple.  In this way, load distribution will still
     occur even if the Flow Label values are poorly distributed.

  Perhaps I'm seriously misunderstanding something though...

* In the bulleted list following the final paragraph, the IP identification
  field is an IPv4-only header field.  What is the recommended mechanism for
  IPv6?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

Overall, a very well written document, I thought; thank you.

[ section 3.3 ]

* Are N and Nmax actually determined at dst or are they determined by
  src when replies are received?

[ section 3.5 ]

* s/can't be detected at IP layer/can't be detected at the IP layer/

[ section 6 ]

* It looks like "parameter E" appears first in paragraph 5?  It might be good
  to provide some "E means exhaustive..." explanatory sentence.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 11 Aug 2020 14:06:31 +0000

Hi Erik,

Thanks for your review, let's try to answer/clear your DISCUSS and comments.

All changes below have been added to the working version.

Al

> -----Original Message-----
> From: Erik Kline via Datatracker [mailto:[email-masked]]
> Sent: Monday, August 10, 2020 8:00 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Brian Trammell <[email-masked]>; [email-masked]
> Subject: Erik Kline's Discuss on draft-ietf-ippm-route-09: (with DISCUSS
> and COMMENT)
> 
.
[acm] 
I think the change below might help. The context in the first sentence is simply fields that must be maintained constant. I understand this second sentence as referring to the IP Header-only, and we can make this more clear:
OLD
In IPv6, it is sufficient to be routed identically if the IP source and destination addresses and the FlowLabel are constant, see RFC 6437.
NEW
When considering IPv6 headers, it is necessary to ensure that the IP source and destination addresses and the FlowLabel are constant, see RFC 6437.

>   field is an IPv4-only header field.  What is the recommended mechanism for
[acm] In each item of the bullet list above the final paragraph, we dealt with IPv6, saying:

... For IPv6, the field FlowLabel, Src and Dst SHOULD be the same.

The last paragraph indicates the changes for IPv4-only, so we can clarify that:
OLD
Then, the way to identify different hops and attempts of the same flow is:
NEW

[acm] 
:-)

>   src when replies are received?
[acm] 
N is determined when a packet actually reaches dst (for a given flow).
Nmax is calculated at the src using all replies from dst: Nmax = Max(N) 

> * s/can't be detected at IP layer/can't be detected at the IP layer/
[acm] 
ok
>   to provide some "E means exhaustive..." explanatory sentence.
[acm] 
This was one of Ben's comments. We changed the sentence to read:

This procedure could be done for a single Member Route flow, an non-exhaustive search with parameter E (defined below) set as False, or for every detected Route Ensemble flow (E=True).

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Aug 2020 17:59:55 -0700

These make good sense to me, thank you.

I'll clear my discuss since, as you say, these changes are in the working
version (and I assume the doc will be in "Revised I-D needed" after/as of
the telechat).

Many thanks!

On Tue, Aug 11, 2020 at 7:06 AM MORTON, ALFRED C (AL) <[email-masked]>
wrote:

> I think the change below might help. The context in the first sentence is
> simply fields that must be maintained constant. I understand this second
> sentence as referring to the IP Header-only, and we can make this more
> clear:
> OLD
> In IPv6, it is sufficient to be routed identically if the IP source and
> destination addresses and the FlowLabel are constant, see RFC 6437.
> NEW
> When considering IPv6 headers, it is necessary to ensure that the IP
> source and destination addresses and the FlowLabel are constant, see RFC
> 6437.
>
> >
> This procedure could be done for a single Member Route flow, an
> non-exhaustive search with parameter E (defined below) set as False, or for
> every detected Route Ensemble flow (E=True).
>
> >
> >
>
>