Re: [Detnet] Alvaro Retana's Discuss on draft-ietf-detnet-ip-06: (with DISCUSS and COMMENT)

[Lou Berger <[e-mail]>]

Hi Alvaro,

On 6/25/2020 2:41 PM, Alvaro Retana wrote:
> On June 25, 2020 at 10:25:59 AM, Lou Berger wrote:
>
>
> Lou:
>
> Hi!
>
>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
> ...
>
> Thanks for the explanation!
>
>
>
>>> It is ok to define the mechanisms in a different document -- but there
>>> are no specific references. What exactly is this document requiring
>>> (MUST)? If there are no specifics on the mechanisms (or where they are
>>> defined), how can an implementation comply with this document?
>> This is a fair point, but I don't see where we have specific queuing
>> mechanisms defined. Now we certainly have on-wire behavior defined, e,g,
>> RFC 2212, and others have defined ones IEEE 802.1Qch. Our expectation
>> is that the management (YANG) and future control plane documents will
>> specific which forwarding treatment is expected for specific flows. We
>> also expect that the market (users/providers and vendors) will decide
>> ehcih are appropriate for different use cases and products just as is
>> done for MPLS-TE in general.
> My main concern is the combination of normative language (MUST/SHALL)
> + no specifics.  To solve it, I need you to either add specifics or
> not use normative language.

can you point to an RFC that has language that you'd like to see? 
RFC3290 has some nice language, but is informational.

Either way, I'll work with the co authors on wording to address this 
comment (which I think is limited to traffic treatment.)

Lou

> Defining mechanisms elsewhere, or letting the market decide, is ok.
> If that is where the WG is, then simply don't use normative language
> in these descriptions.

> If you come up with alternate text, then I'll clear my DISCUSS.
>
>
>>> What are the interoperability consequences if not all nodes comply with
>>> the same set of (undefined) mechanisms?
>> The traffic delivery won't be what's expected, and those vendors with
>> behavior not suited to particular applications won't be selected for
>> such networks. Again, taking a page from the MPLS-TE market place...
> Please add something like that to the text.  There are several places
> (e.g., the 3 examples in the DISCUSS and some comments below) that
> need that type of disclaimer/guidance.
>
> I wish there was a Deployment Considerations section, but that is
> probably too much to ask for a few additional sentences.
>
>
>
> ...
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> (1) §4.2 (DetNet Domain-Specific Considerations):
> ...
>> Possible consequences of not having such an agreement include
>> having some flows interfering with other flows, and for a
>> the traffic treatment expected for a service not being
>> provided.
> Sure.  As mentioned above, the same type of text is needed in multiple places.
>
>
>
>
>>> (2) §4.3.1 (Class of Service): "...DetNet nodes...MUST ensure that the
>>> CoS service classes do not impact the congestion protection and latency
>>> control mechanisms used to provide DetNet QoS."
> ...
>>> (b) Maybe it's just me, but I would think that the requirement is not at
>>> a node level (each node doing something), but within a DetNet domain;
>>> IOW, this sounds more like a provisioning requirement (even probably
>>> related to the text from §6 I quoted above).
>> I certainly agree there is a large interaction here.
> Then this is another opportunity for text related to the need to have
> the same/similar behavior/agreement/provisioning...even if the general
> expectation is per node and not explicitly defined.
>
>
>
> ...
>>> (4) §5.1.1.3 (IPv4 Protocol and IPv6 Next Header Fields):
> ...
>>> BTW, 0 is the IPv6 HbH option -- do you really want to exclude it?
>> I think so, but this was not extensively discussed. Do you think it's
>> the wrong call?
> I don't know.  But if all the other EHs are not excluded there must be
> a good reason.  I can imagine ways to use HbH to maybe carry other
> flow identification parameter...for later use.  Just thinking out
> loud...
>
>
>
> ...
>>> (8) I believe that these references should be Normative:
>>> I-D.ietf-detnet-data-plane-framework and RFC8655.
>> the data plane framework is informative so generally references to
>> informative docs are informative.
> Nope.
>
> A normative reference is one that "must be read to understand or
> implement the technology"...regardless of the status.
>
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>
>
> Thanks!
>
> Alvaro.
>