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

[Lou Berger <[e-mail]>]

Hi,

Thank you for the comments.  Please see response (as co-author) in-line
below.

On 6/25/2020 9:01 AM, Éric Vyncke via Datatracker wrote:
> Éric Vyncke 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:
> ----------------------------------------------------------------------
>
> Thank you for the work put into this document.
>
> I support Roman's first DISCUSS.
>
> Please find below a couple on non-blocking COMMENTs; but, I would really
> appreciate a reply/answer/comment on all my COMMENTs.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == COMMENTS ==
>
> Please bear with my lack of DetNet expertise... but I have to ask the following
> question: how are IP fragments (i.e. lacking transport ports) processed? as
> they cannot match the 6-tuple.

they won't match.  Generally DetNet applications are expected to operate 
with fixed / maximum sized frames that are smaller than MTU.

Having this called out as a consideration certainly is reasonable.  How 
about adding the following to section 4.1:

           An important additional consideration for DetNet-aware end
           systems is avoiding IP fragmentation.  Full 6-tuple flow
           identification is not possible on IP fragments as fragments
           don't include the transport headers or their port
           information. As such, it is important that applications and/or
           end-systems use an IP packet size that will avoid
           fragmentation within the network when sending DetNet flows.
           The maximum size can be learned via path MTU discovery, <xref
           target="RFC1192"/> and <xref target="RFC8201"/>,  or via
           the controller plane.  Note that path MTU discovery relies on
           ICMP, which may not follow the same path as an individual
           DetNet flow.

and to section 6:

               For end systems, an optional maximum IP packet size
               that should be used for that outgoing DetNet IP flow.

> Related question: what about ICMP messages? They
> are often critical to a flow (PMTUd for instance, or traceroute) and should
> perhaps inherit the DetNet service?

This will be up to the controller (management and/or control) plane .

> -- Abstract --
> Beside being the smallest abstract I have ever read on an IETF document, I also
> wonder about the wording "IP packet switched network".
sorry, sometimes my butterfly gateway days show through.
> May be I am a purist,
> but, IP packet are forwarded and not switched. => recommend to add more meat in
> the abstract (notably differences with diffserv and intserv) *AND* remove the
> 'switched' word.

sure.

         This document specifies the DetNet data plane operation for IP 
hosts
         and routers that provide DetNet service to IP encapsulated data. No
         DetNet-specific encapsulation is defined to support IP flows; 
instead
         the existing IP and higher layer protocol header information is 
used to
         support flow identification and DetNet service delivery. This
         document builds on the DetNet Architecture and Data Plane 
Framework.

>
> -- Section 4.5 --
> "  While the DetNet IP data plane must support bidirectional DetNet
>     flows, there are no special bidirectional features with respect to
>     the data plane other than the need for the two directions of a co-
>     routed bidirectional flow to take the same path."
>
> This section does not use normative wording and I wonder whether the 'need' to
> take the same path will always be true as some links have different throughput
> up/down or their link loads could be different.

I agree with you.  How about:


           While the DetNet IP data plane must support bidirectional
           DetNet flows, there are no special bidirectional features within
           the data plane.  The special case of co-routed bidirectional
           DetNet flows are
           solely represented at the management and control plane levels,
           without specific support or knowledge within the DetNet data
           plane.  Fate sharing and associated or co-routed
           bidirectional flows can be managed at the control level.

> -- Section 5.1.2.1. --
> "  The rules defined in this section only apply when the IPv4 Protocol
>     or IPv6 Next Header Field contains the IANA defined value for UDP or
>     TCP."
>
> Is the intent to ignore those field when there is an IPv6 extension header
> between the IP and transport headers ? Same question for section 5.1.2.3.
yes, that's the current "simplified" functional definition.  (At least 
as I read it.)
>
> Does it also mean that SCTP is not supported?

It is supported, but only on the aggregate protocol level.  SCTP did 
come up at some point and the consensus was that it's header parsing 
should *not* be in the base/core DetNet IP document, but that the 
document should allow for such in a future RFC.  At least that's how I 
recall the consensus.

Changes covered here can be previewed at:

https://github.com/detnet-wg/data-plane-drafts/tree/working/lb/iesg-0625

https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/detnet-wg/data-plane-drafts/working/lb/iesg-0625/ip/draft-ietf-detnet-ip.xml


Thank you!



Lou

>
>
>