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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Thu, 25 Jun 2020 06:01:45 -0700

É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. 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?

-- Abstract --
Beside being the smallest abstract I have ever read on an IETF document, I also
wonder about the wording "IP packet switched network". 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.

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

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

Does it also mean that SCTP is not supported?

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jun 2020 13:09:08 -0400

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:
> 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

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

> wonder about the wording "IP packet switched network".
sorry, sometimes my butterfly gateway days show through.
> May be I am a purist,

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.

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

> 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