Subject: [Detnet] Comments on draft-ietf-detnet-yang-04.txt

From: "Don Fedyk" <[email-masked]>
Date: Tue, 18 Feb 2020 18:17:25 -0500

Hi

Last December I looked at a way to MAP the draft-ietf-detnet-yang-04.txt
YANG model to  draft-ietf-detnet-flow-information-model-06. 

After several iterations I came up with a model.   

https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/1

https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/2

This model is also discussed in a presentation.  An we discussed on the
DetNet call Monday Feb 10th.

https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/3

In the meeting Monday Feb 17th I was asked to comment specifically on the
draft-ietf-detnet-yang-04.txt. (Here is my list of items and each issue lead
to a what a rearranged model which lead to the resulting new model above.). 

*	First off the draft-ietf-detnet-yang-04.txt YANG was hard to map to
the Flow Model.   (We had a few variations in the flow model too and once
that solidified, I rearranged parts of the YANG model to match the flow
model.) 
*	In draft-ietf-detnet-yang-04.txt there is a top level node id: I did
not understand why node ID was needed. (removed)
*	The draft-ietf-detnet-yang-04.txt model is flat:  the config list
contains one of an app-flow, a service sub-layer, a forwarding sublayer all
in the same name space. (In the proposal applications, services and
forwarding sublayers are separated and have the own name spaces). 

*	It was unclear in the draft-ietf-detnet-yang-04.txt how the
applications layer interfaces were referenced.(I've  added specific
references in the new model). 
*	In draft-ietf-detnet-yang-04.txt a large number of flat service
layer options are configured at the applications layer and at the forwarding
sublayer. These did not map to existing IETF models even though there is a
lot of reuse in DetNet. 

(In the proposed model I added an application interface and reused  IP/MPLS
YANG constructs for input/ingress and output/egress operations.  The
existing IP/MPLS model uses a hierarchy of matching on type (IP/MPLS) then
refining the match. I also reused the same groupings for the applications
and forwarding sublayer.  ) 

*	The application layer had its own matching functions for ingress but
simply pointed to a egress forwarding layer. I have a separate application
egress that uses the same YANG groupings for applications and forwarding
layers. )
*	(After rearranging the model lent itself to be more symmetrical in
the Application and Forwarding sub-layer interfaces and I leveraged that.)

I think that summarize the major points I found on
draft-ietf-detnet-yang-04.txt.  

Best Regards,

Don

---

From: 유연철 <[email-masked]>
Date: Mon, 24 Feb 2020 05:22:32 +0000

Dear Don,

Thank you for your comments on draft-ietf-detnet-yang-04.

Please, see my thoughts on your comments starting with [Yeoncheol]

출발: detnet <[email-masked]>(Don Fedyk <[email-masked]> 대신)
날짜: 2020년 2월 19일 수요일 오전 8:17
받는 사람: 'DetNet WG' <[email-masked]>
주제: [Detnet] Comments on draft-ietf-detnet-yang-04.txt

Hi

Last December I looked at a way to MAP the draft-ietf-detnet-yang-04.txt YANG model to  draft-ietf-detnet-flow-information-model-06.

This model is also discussed in a presentation.  An we discussed on the DetNet call Monday Feb 10th.
https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/3

In the meeting Monday Feb 17th I was asked to comment specifically on the draft-ietf-detnet-yang-04.txt. (Here is my list of items and each issue lead to a what a rearranged model which lead to the resulting new model above.).

  *   First off the draft-ietf-detnet-yang-04.txt YANG was hard to map to the Flow Model.   (We had a few variations in the flow model too and once that solidified, I rearranged parts of the YANG model to match the flow model.)

[Yeoncheol] Yes, it is. The Flow Model is a model of network viewpoint, and the draft-ietf-detnet-yang-04is  to configure equipment from node perspective, so it is difficult to map. That’s why, in the side meeting of the last IETF, we decided to modify current flow information model, so that two models could be aligned.

  *   In draft-ietf-detnet-yang-04.txt there is a top level node id: I did not understand why node ID was needed. (removed)

[Yeoncheol] Since the draft-ietf-detnet-yang-04 is for configuring the equipment from the node's point of view. a node ID needs to be included. Other YANG models, such as ietf-routing.yang, contains a node ID to specify to which node configuration is applied.

  *   The draft-ietf-detnet-yang-04.txt model is flat:  the config list contains one of an app-flow, a service sub-layer, a forwarding sublayer all in the same name space. (In the proposal applications, services and forwarding sublayers are separated and have the own name spaces).

[Yeoncheol] DetNet IP and DetNet MPLS require different sub-layers. DetNet IP does not need a service sub-layer, while DetNet MPLS needs both service and forwarding sub-layers. We felt that a flat structure might be better to avoid introducing unnecessary choice statements and to specify different sub-layers more flexibly. However, I feel that this is a matter of favors, and I am ok with changing the structure to be hierarchical.

  *   It was unclear in the draft-ietf-detnet-yang-04.txt how the applications layer interfaces were referenced.(I’ve  added specific references in the new model).
[Yeoncheol] Yes, we need to add an interface parameter to the app-flow.

  *   In draft-ietf-detnet-yang-04.txt a large number of flat service layer options are configured at the applications layer and at the forwarding sublayer. These did not map to existing IETF models even though there is a lot of reuse in DetNet.

[Yeoncheol] I also think that we need to reuse existing IETF models as many as possible. For the next version of draft-ietf-detnet-yang, we need to look into this point.

(In the proposed model I added an application interface and reused  IP/MPLS YANG constructs for input/ingress and output/egress operations.  The existing IP/MPLS model uses a hierarchy of matching on type (IP/MPLS) then refining the match. I also reused the same groupings for the applications and forwarding sublayer.  )

  *   The application layer had its own matching functions for ingress but simply pointed to a egress forwarding layer. I have a separate application egress that uses the same YANG groupings for applications and forwarding layers. )

[Yeoncheol] This can be addressed by adding an interface parameter to the out-segments of the app-flow in draft-ietf-detnet-yang.

  *   (After rearranging the model lent itself to be more symmetrical in the Application and Forwarding sub-layer interfaces and I leveraged that.)

I think that summarize the major points I found on draft-ietf-detnet-yang-04.txt.

Best Regards,
Don

Best Regards,
Yeoncheol

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 25 Feb 2020 10:46:06 -0500

Hi Yeoncheol 

Some comments inline [Don]

Thanks,

Don

From: 유연철 <[email-masked]> 
Sent: Monday, February 24, 2020 12:23 AM
To: Don Fedyk <[email-masked]>; 'DetNet WG' <[email-masked]>
Subject: Re: [Detnet] Comments on draft-ietf-detnet-yang-04.txt

Dear Don,

출발: detnet < <mailto:[email-masked]> [email-masked]>(Don Fedyk < <mailto:[email-masked]> [email-masked]> 대신)
날짜: 2020년 2월 19일 수요일 오전 8:17
받는 사람: 'DetNet WG' < <mailto:[email-masked]> [email-masked]>
주제: [Detnet] Comments on draft-ietf-detnet-yang-04.txt

Hi

 <https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/1> https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/1

 <https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/2> https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/2

 <https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/3> https://github.com/detnet-wg/draft-ietf-detnet-yang/issues/3

[Don] My effort has been to produce a YANG model for the flow model.   I think it is worthwhile going down this path. 

[Don] We agreed on the call today that the node id is not part of the DetNet Config it is already in other YANG models. 

[Don] Ok. It is tough to get it right on the first time.  I currently have a couple choice statement I don’t need also.   I will update the YANG model from the feedback of today’s call.

[Don] I think we agree on this point. 

[Don] Again we agree here. 

[Don] I’m not saying I got it exactly right but the model has a high correlation to the DetNet-flow model draft.  There is all the point that came up in the call today that a DetNet flow is:

DetNet flow

      A sequence of packets that conforms uniquely to a flow identifier

      and to which the DetNet service is to be provided.  It includes

      any DetNet headers added to support the DetNet service and

      forwarding sub-layers.

In the DetNet flow YANG I propose the service and the forwarding layers are configured and this results in a DetNet flow but you don’t configure the DetNet flow itself. 

Best Regards,

Don 

Best Regards,

Yeoncheol