Re: [Detnet] [DetNet] DetNet YANG Model Update

Jeong-dong Ryoo <ryoo@etri.re.kr> Wed, 20 May 2020 06:21 UTC

Return-Path: <ryoo@etri.re.kr>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23DD3A1201 for <detnet@ietfa.amsl.com>; Tue, 19 May 2020 23:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_MIMEOLE=1.899, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dooray.com header.b=SuRg6lXS; dkim=pass (2048-bit key) header.d=dooray.com header.b=SuRg6lXS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNuQ8ixv5sFt for <detnet@ietfa.amsl.com>; Tue, 19 May 2020 23:21:48 -0700 (PDT)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CC43A3AA3 for <detnet@ietf.org>; Tue, 19 May 2020 23:21:44 -0700 (PDT)
Received: from unknown (HELO smtp001.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 20 May 2020 15:21:38 +0900
X-Original-SENDERIP: 211.180.235.152
X-Original-MAILFROM: ryoo@etri.re.kr
X-Original-RCPTTO: detnet@ietf.org
DKIM-Signature: a=rsa-sha256; b=SuRg6lXSq58DVDUYUwTjzKn6fu5dAGEF2bn7hXNoCFfSrC2S5YZRwcMSJvy5fslpZr8OTSCuOV LyREK++uL1DSbBX2a5poj4MEce+NdJdArULuqEddcOhHMwvPCPHmj48hgKecHfspL82/KRVRShln viD3FdYhVDWBa6DbnoogIfmOciiCheoSIOBRb6SpxyKsrqYAnkbeoVgNOTKQnREV8hgKnKfj70Aa sGQ89VjRl3bR/+Abjp/Ar0NraGp5T+TtrE+nGvj+gkcDqKUQWXj12jPHAR0l699TAXuqVhbg3cnn Huq7zjgZPJ5VuB8NVzuKFC6z4VS/4sZqOw6R0VAQ==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=IAKf2N8O1XubrAhdUTG8QNUfX6jT1kTzpvOagR9+XtI=; h=From:To:Subject:Message-ID;
Received: from [10.162.225.103] (HELO send001.gov-dooray.com) ([10.162.225.103]) by smtp001.gov-dooray.com with SMTP id 0d14050c5ec4cc74; Wed, 20 May 2020 15:21:40 +0900
DKIM-Signature: a=rsa-sha256; b=SuRg6lXSq58DVDUYUwTjzKn6fu5dAGEF2bn7hXNoCFfSrC2S5YZRwcMSJvy5fslpZr8OTSCuOV LyREK++uL1DSbBX2a5poj4MEce+NdJdArULuqEddcOhHMwvPCPHmj48hgKecHfspL82/KRVRShln viD3FdYhVDWBa6DbnoogIfmOciiCheoSIOBRb6SpxyKsrqYAnkbeoVgNOTKQnREV8hgKnKfj70Aa sGQ89VjRl3bR/+Abjp/Ar0NraGp5T+TtrE+nGvj+gkcDqKUQWXj12jPHAR0l699TAXuqVhbg3cnn Huq7zjgZPJ5VuB8NVzuKFC6z4VS/4sZqOw6R0VAQ==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=IAKf2N8O1XubrAhdUTG8QNUfX6jT1kTzpvOagR9+XtI=; h=From:To:Subject:Message-ID;
From: Jeong-dong Ryoo <ryoo@etri.re.kr>
To: "'Gengxuesong (Geng Xuesong)'" <gengxuesong@huawei.com>, Don Fedyk <dfedyk@labn.net>
Cc: '유연철' <dbduscjf@etri.re.kr>, 'DetNet WG' <detnet@ietf.org>, 'DetNet Chairs' <detnet-chairs@ietf.org>
Message-ID: <kvr52xbngoqz.kvr52xbn5alp.g1@dooray.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_16045_767262598.1589955697714"
X-Dsn-Request: true
Importance: Normal
X-Priority: Normal
X-MSMail-Priority: Normal
Date: Wed, 20 May 2020 15:21:38 +0900
Sender: ryoo@etri.re.kr
References: <129f23f6a7d24a34b8b168b9a5fbdc8c@huawei.com> <003401d62895$80c105a0$824310e0$@labn.net> <e0f49355b783439bb4c37677771b3223@huawei.com> <003401d62cb4$59b8b160$0d2a1420$@labn.net> <kvj2y6k8fwpa.kvj2y6kbweey.g1@dooray.com> <009f01d62ddd$c63e6ad0$52bb4070$@labn.net>
In-Reply-To: <009f01d62ddd$c63e6ad0$52bb4070$@labn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/-gCU6l3KaAepuS98-0G-mIbHTls>
Subject: Re: [Detnet] [DetNet] DetNet YANG Model Update
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2020 06:21:52 -0000

Hi, Don,


Thank you for your email.

Yes, that is one piece of text that I was referring to. In addition, there is another piece of text below Figure 1:"The dotted line around the Service component of the Relay Nodes indicates that the transit routers are DetNet service aware but do not perform any DetNet service sub-layer function, e.g., PREOF (Packet Replication, Elimination and Ordering Function)."Please, note that the DetNet IP nodes do not perform "any" DetNet service sub-layer function.

With those two parts of text, I can conclude that we don't need to have service sub-layer parameters in DetNet YANG.&nbsp;
I think it is ok for a DetNet service to require only one sub-layer, not all sub-layers.&nbsp;

I don't think aggregation is the property that only the service sublayer can have. Every sub-layer can do the aggregation,&nbsp;
and often times, multiple flows of a one sub-layer are presented to its server (underlying) sub-layer as one aggregated flow.

Anyway, we can put the IP aggregation in either place. I just wanted to see a YANG model that is more aligned with architecture and data plane documents.


Best regards,

Jeong-dong



-----Original Message-----
From: "Don Fedyk" &lt;dfedyk@labn.net&gt;
To: &lt;ryoo@etri.re.kr&gt;; "'Gengxuesong (Geng Xuesong)'" &lt;gengxuesong@huawei.com&gt;;
Cc: "'유연철'" &lt;dbduscjf@etri.re.kr&gt;; "'DetNet WG'" &lt;detnet@ietf.org&gt;; "'DetNet Chairs'" &lt;detnet-chairs@ietf.org&gt;;
Sent: 2020-05-19 (화) 22:02:57 (UTC+09:00)
Subject: RE: Re: [Detnet] [DetNet] DetNet YANG Model Update

Hi Jeong-dong
&nbsp;
I believe you are referring to this:
&nbsp;
“ The service sub-layer generally requires
&nbsp; &nbsp;additional header fields to provide its service; for example see
&nbsp; &nbsp;[I-D.ietf-detnet-mpls]. &nbsp;Since no DetNet-specific fields are added to
&nbsp; &nbsp;support DetNet IP flows, only the forwarding sub-layer functions are
&nbsp; &nbsp;supported using the DetNet IP defined by this document.”
&nbsp;
This means to me that the IP service sub-layer can only do functions that are allowed with the existing &nbsp;headers.
Aggregation can be accomplished by using wildcards and 6 tuple.
In IPv4 that is about it.
In IPv6 the ability to use the flow label is also mentioned.
Any functions that require sequence numbers for PREOF would be not available for the current definition of &nbsp;IP service sub-layer.
We already have sequencing only in the MPLS section. &nbsp;The other attributes are not put in the packet but they are part of the service
context and should apply to the IP service sub-layer.
&nbsp;
So I think we are ok.
Cheers,
Don
&nbsp;
&nbsp;
&nbsp;
From: ryoo@etri.re.kr &lt;ryoo@etri.re.kr&gt;Sent: Monday, May 18, 2020 11:02 PMTo: 'Gengxuesong (Geng Xuesong)' &lt;gengxuesong@huawei.com&gt;; Don Fedyk &lt;dfedyk@labn.net&gt;Cc: '유연철' &lt;dbduscjf@etri.re.kr&gt;; 'DetNet WG' &lt;detnet@ietf.org&gt;; 'DetNet Chairs' &lt;detnet-chairs@ietf.org&gt;Subject: RE: Re: [Detnet] [DetNet] DetNet YANG Model Update

&nbsp;
Don, Xuesong and all,

&nbsp;

In the figures below, the boxes that belong to “Service Sub-layer” for “ALL” should be moved to MPLS service sub-layer since there are no sub-layer functions that can apply to DetNet IP. According to Introduction section of draft-ietf-detnet-ip-06, only the forwarding sub-layer functions are supported using the DetNet IP defined by the DetNet IP draft.&nbsp;
&nbsp;
In my opinion, DetNet IP flow aggregation should be done in the forwarding sub-layer. What do you think?&nbsp;
&nbsp;
Best regards,
&nbsp;

Jeong-dong&nbsp;
&nbsp;

-----Original Message-----

From: "Don Fedyk" &lt;dfedyk@labn.net mailto:dfedyk@labn.net&gt;

To: "'Gengxuesong (Geng Xuesong)'" &lt;gengxuesong@huawei.com mailto:gengxuesong@huawei.com&gt;;

Cc: "'유연철'" &lt;dbduscjf@etri.re.kr mailto:dbduscjf@etri.re.kr&gt;; "'DetNet WG'" &lt;detnet@ietf.org mailto:detnet@ietf.org&gt;; "'DetNet Chairs'" &lt;detnet-chairs@ietf.org mailto:detnet-chairs@ietf.org&gt;;

Sent: 2020-05-18 (월) 10:34:22 (UTC+09:00)

Subject: Re: [Detnet] [DetNet] DetNet YANG Model Update

&nbsp;

Hi Xuesong
See [Don] inline.
&nbsp;
Thanks Don
From: Gengxuesong (Geng Xuesong) &lt;gengxuesong@huawei.com mailto:gengxuesong@huawei.com&gt;Sent: Sunday, May 17, 2020 3:35 AMTo: Don Fedyk &lt;dfedyk@labn.net mailto:dfedyk@labn.net&gt;Cc: '유연철' &lt;dbduscjf@etri.re.kr mailto:dbduscjf@etri.re.kr&gt;; 'DetNet WG' &lt;detnet@ietf.org mailto:detnet@ietf.org&gt;; 'DetNet Chairs' &lt;detnet-chairs@ietf.org mailto:detnet-chairs@ietf.org&gt;Subject: RE: [Detnet] [DetNet] DetNet YANG Model Update


&nbsp;
Hi Don,
&nbsp;
Sorry for the delay of response. I agree to split the slides, and let’s do it in the call meeting of next Monday.
Here are some questions about the current version of the parameters. (in this email, please allow me to still keep them in the same figure for convenience):
1.&nbsp; &nbsp; &nbsp;&nbsp;Traffic &nbsp;Requirement/Specification

These two groups of parameters exist in all three layers. What is the relationship between them: &nbsp;same, mapping with each other, or totally different?
[Don] The traffic requirements and traffic spec must exist at the Service Sub-layer ..
The can also exist at the application.
Some values are additive &nbsp;(bandwidth) some are min or maximum &nbsp;(Delay).&nbsp;
At the forwarding sub layer they would probably get represented as traffic engineering number is the respected media (eg MPLS). &nbsp;
&nbsp;
2.&nbsp; &nbsp; &nbsp;&nbsp;Rank

Quote from draft-ietf-detnet-flow-information-model-10#section-5.7:
“The DnFlowRank attribute provides the rank of this flow relative to
&nbsp; &nbsp;other flows in the DetNet domain. &nbsp;Rank (range: 0-255) is used by the
&nbsp; &nbsp;DetNet domain to decide which flows can and cannot exist when network
&nbsp; &nbsp;resources reach their limit. &nbsp;Rank is used to help to determine which
&nbsp; &nbsp;flows can be bumped (i.e., removed from node configuration thereby
&nbsp; &nbsp;releasing its resources) if for example a port of a node becomes
&nbsp; &nbsp;oversubscribed (e.g., due to network re-configuration).”
I think the meaning of “rank” here is the same as above. The question is whether it only exists in service sub-layer.
[Don] Again it must exist at the service sub layer.&nbsp;
It logically exists at the application layer by association. &nbsp;You have to decide which service sub-layer the application uses and rank is a consideration.
&nbsp;
&nbsp;
3.&nbsp; &nbsp; &nbsp;&nbsp;Classifier

I think the “classifier” here is similar as “flow identification” in the existing YANG Model. If it is, why there is “classifier” in the forwarding sub-layer?
And there are two “classifier” in service sub-layer, what is the difference?
&nbsp;
[Don] Logically the function exist at many places when we consider IP aggregation in the current documents.&nbsp;
1)&nbsp; &nbsp; &nbsp;&nbsp;It may exist the application to qualify flows. &nbsp;It may also be all traffic from a port or interfaces.
2)&nbsp; &nbsp; &nbsp;&nbsp;In the service sub-layer it is needed when sending traffic to the application.&nbsp;
3)&nbsp; &nbsp; &nbsp;&nbsp;It exists in the forwarding sub-layer when forwarding traffic to the service-sublayer
&nbsp;
4.&nbsp; &nbsp; &nbsp;&nbsp;Encapsulation/decapsulation
Why encap/decap only exists in service sub-layer?
I have asked this question in the last call meeting and I remember the answer is that in forwarding sub-layer, encap/decap will reuse the current YANG Model in IETF. I think even if that is the case, a proper reference should be included in forwarding sub-layer. So the element should not be lost.
[Don] Yes we only have to define the service sub-layer encap the forwarding encap in MPLS exists.&nbsp;
&nbsp;
5.&nbsp; &nbsp; &nbsp;&nbsp;Aggregation
As we have discussed in the call meetings, different degree of aggregation should be allowed in the Yang Model. If I understand this right, it is implemented by the “Service sub-layer Ref” in service sub-layer and “forwarding sub-layer Ref” in forwarding sub-layer. I think more discussions are needed in this point, because aggregation may not need a brand new service sub-layer/forwarding sub-layer instance, and only limited parameters are necessary.
[Don] I was thinking about this. We should be using the current data plane documents.&nbsp;
I think we need to walk through an IP case and an MPLS case.&nbsp;
&nbsp;
6.&nbsp; &nbsp; &nbsp;&nbsp;Direction&nbsp;
As showed in the slide:&nbsp;

The direction of the flow influence the use of the parameters. In the existing YANG model, this is showed with “in-segment” and “out-segment”. It may require some discussions about how to do this in the new YANG Model.&nbsp;
[Don] I have put it in the model I supplied. &nbsp;
&nbsp;
&nbsp;
Best Regards
Xuesong
&nbsp;
From:&nbsp;Don Fedyk [mailto:dfedyk@labn.net mailto:dfedyk@labn.net] Sent: Wednesday, May 13, 2020 3:43 AMTo: Gengxuesong (Geng Xuesong) &lt;gengxuesong@huawei.com mailto:gengxuesong@huawei.com&gt;Cc: '유연철' &lt;dbduscjf@etri.re.kr mailto:dbduscjf@etri.re.kr&gt;; 'DetNet WG' &lt;detnet@ietf.org mailto:detnet@ietf.org&gt;; 'DetNet Chairs' &lt;detnet-chairs@ietf.org mailto:detnet-chairs@ietf.org&gt;Subject: RE: [Detnet] [DetNet] DetNet YANG Model Update


&nbsp;
Hi Xuesong
&nbsp;
Yes that is one way to do it. I think maybe if we had a slide per IP/ MPLS/ and Ethernet that covers the current drafts it would be beneficial.&nbsp;
Trying to put it all on one page may be confusing. &nbsp;
&nbsp;
Cheers
Don&nbsp;
&nbsp;
From: detnet &lt;detnet-bounces@ietf.org mailto:detnet-bounces@ietf.org&gt; On Behalf Of&nbsp;Gengxuesong (Geng Xuesong)Sent: Tuesday, May 12, 2020 8:23 AMTo: Don Fedyk &lt;dfedyk@labn.net mailto:dfedyk@labn.net&gt;Cc: '유연철' &lt;dbduscjf@etri.re.kr mailto:dbduscjf@etri.re.kr&gt;; 'DetNet WG' &lt;detnet@ietf.org mailto:detnet@ietf.org&gt;; 'DetNet Chairs' &lt;detnet-chairs@ietf.org mailto:detnet-chairs@ietf.org&gt;Subject: [Detnet] [DetNet] DetNet YANG Model Update


&nbsp;
Hi Don,
&nbsp;
As discussed in the call meeting yesterday, I reorganize the figure(the first one is the original one comes from your slide, and the second one is the updated one):
&nbsp;

&nbsp;

&nbsp;
Please check whether it goes along with your intention. If it does, we could continue the discussion based on this figure.
&nbsp;
&nbsp;
Best Regards
Xuesong
&nbsp;

_______________________________________________ detnet mailing list detnet@ietf.org mailto:detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet https://www.ietf.org/mailman/listinfo/detnet


&nbsp;