Re: [Detnet] Warren Kumari's No Objection on draft-ietf-detnet-ip-06: (with COMMENT)

[Warren Kumari <[e-mail]>]

On Thu, Jun 25, 2020 at 12:26 PM Lou Berger <[e-mail]> wrote:

> Hi Warren,
>
> Thanks for the comments.  It sounds like you are just
> echoing/reinforcing Alvaro's main points so would like to keep the
> conversation on that thread.  Is that okay?
>
>
Yup.
W



> Are there any other points you'd like to discuss?
>
> thanks,
>
> Lou
>
> On 6/24/2020 7:30 PM, Warren Kumari via Datatracker wrote:
> > Warren Kumari has entered the following ballot position for
> > draft-ietf-detnet-ip-06: No Objection
> >
> > 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-detnet-ip/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I'm balloting NoObj in the "I read the protocol action, and I trust the
> > sponsoring AD so have no problem." / "I have no cycles" sense. Due to
> other
> > work, I was not able to review this document nearly as thoroughly as I
> would
> > have liked, but I *do* support Alvaro's (and others) DISCUSS - there are
> many
> > places where the document says that the network MUST do something, but
> without
> > the something being particularly well defined;I'm sure that the authors /
> > DetNet WG understand what these are, but it's not clear from the document
> > itself -- I'm guessing that this is defined in other documents, but I
> wasn't
> > able to easily find them.
> >
> > I was mystified by " For some of the protocols 5-tuples and 6-tuples
> cannot be
> > used because the port information is not available (e.g., ICMP, IPSec
> ESP).
> > Same can be valid for flow aggregates. " - is this that the 5/6 tuples
> cannot
> > be used for flow aggregates? I went to try and find more info on flow
> > aggregates, and looked in ietf-detnet-data-plane-framework (which, like
> many of
> > the referenced draft-detnet- documents should be Normative references),
> but it
> > didn't seem to have much detail (other than that "There are many
> techniques to
> > achieve aggregation" -- where is how flow aggregation actually works
> > documented? This document (S4.4) says that: flow aggregation "is an
> important
> > technique for improving
> >     scaling by reducing the state per hop", but without understanding
> how flows
> >     are aggregated, and the state needed per flow, this is hard to
> evaluate. In
> >     addition "In either case, the management or control function that
> provisions
> >     the aggregate flows must ensure that adequate resources are
> allocated and
> >     configured to provide combined service requirements of the individual
> >     flows." -- if this "of the individual flows", or "of the aggregate
> flows"?
> >     Presumably there will be a difference.
> >
> > I found Section "5.3.  DetNet IP Traffic Treatment Procedures" to be
> very terse
> > -- I was expecting to read this and understand what *exactly* the IP
> Traffic
> > Treatment Procedures are - instead it seemed to feel more like
> "Implementations
> > must make sure that they provide the service that has been configured".
> The
> > section says: " Typical mechanisms used to provide different treatment to
> > different flows includes the allocation of system resources (such as
> queues and
> > buffers) and provisioning or related parameters (such as shaping, and
> > policing). " -- but this all feels fairly circular - where is the
> treatment of
> > traffic "when operating in an IP packet switched network." actually
> defined? If
> > I'm building a router/switch/similar, and what to provide support for
> DetNet
> > over IP, what *exactly* do I do with traffic once it has been
> identified? How
> > do I queue it differently? What happens if I cannot meet the
> requirement? Where
> > is this documented?
> >
> > Apologies for not being able to review this in the depth it deserves,
> > W
> >
> >
> >
> >
>


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf