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

["MORTON, ALFRED C (AL)" <[e-mail]>]

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:[e-mail]]
> Sent: Monday, August 10, 2020 8:00 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Brian Trammell <[e-mail]>; [e-mail]
> Subject: Erik Kline's Discuss on draft-ietf-ippm-route-09: (with DISCUSS
> and COMMENT)
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-ippm-route-09: Discuss
> 
.
> 
> ----------------------------------------------------------------------
> 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...
[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.

> 
> * 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?
> 
[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
Then, the way to identify different hops and attempts of the same IPv4 flow is:

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> [[ comments ]]
> 
> Overall, a very well written document, I thought; thank you.
[acm] 
:-)

> 
> [ section 3.3 ]
> 
> * Are N and Nmax actually determined at dst or are they determined by
>   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) 

> 
> [ section 3.5 ]
> 
> * s/can't be detected at IP layer/can't be detected at the IP layer/
[acm] 
ok
> 
> [ section 6 ]
> 
> * It looks like "parameter E" appears first in paragraph 5?  It might be
> good
>   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).

> 
>