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

[Erik Kline <[e-mail]>]

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) <[e-mail]>
wrote:

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