Subject: [CCAMP] A Recap of Update to Draft "YANG Data Model for FlexE Interface Management"

From: Jiangyuanlong <[email-masked]>
Date: Mon, 15 Jul 2019 12:28:43 +0000

Dear CCAMPers,

After the IETF 104th meeting, some authors of draft-jiang-ccamp-flexe-yang and draft-xiaobn-ccamp-flexe-yang-mod had twice met and discussed the possibility of combining these two drafts. But authors of the two drafts had quite different opinions on the target and methodology of the FlexE YANG model, thus we decided to update the drafts in its own right until our WG makes a decision on how this work shall be proceeded.

Here is a brief summary of draft-jiang-ccamp-flexe-yang ("YANG Data Model for FlexE Interface Management"):
1. the philosophy of the model is treating a whole FlexE Group as an interface, and treating the Flex Clients in a FlexE Group as sub-interfaces, so that the same interface logic applies (i.e., familiar flavor).
2. Since a FlexE client is decoupled from the FlexE PHYs, it is modeled as a new type of interface, so that new FlexE clients can be more appropriately modeled, and more easily be augmented to support some new MAC layer features, such as flow control, and etc.
3. it is modeled as a simple flat tree, and leave out internal data plane implementation dependent artifacts where management and control planes do not care much, such as FlexE Instance, Calendar A and B.
3. it uses the nomenclatures which are more compatible with the YANG style in the IETF.
Please see https://tools.ietf.org/html/draft-jiang-ccamp-flexe-yang-01 for the details. Your comments and involvements will be much appreciated.

Best regards,
Yuanlong

---

From: <[email-masked]>
Date: Tue, 16 Jul 2019 09:32:02 +0800 (CST)

Hi Yuanlong,

Thanks for your introduction about the updates.

May I suggest we give some analysis and rationale description in the slides presented. I think this could make us easier to figure out which one is better. We also submit one companion draft draft-wang-ccamp-flexe-control-analysis-02, trying to give some analysis.

I also suggest we focus on the detail about FlexE specific modelling work instead of more on interface. If I understand correctly, interface/sub-interface management is a general topic. It depends on how to model FlexE. 

In addition, some questions for discussion about interface mentioned in the email: 

1), if we treat FlexE as a kind of typical Ethernet, then do we need to define additional interface for FlexE? or we can use FlexE group identifier to do this?

2), whether FlexE client can be model as a separate layer? Because the answer of this question can help clarify whether we need to define interface/sub-interface for FlexE client.

I would put some material/description about these issues in the slides.

Thanks

Qilei

原始邮件

发件人：Jiangyuanlong <[email-masked]>
收件人：CCAMP ([email-masked]) <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2019年07月15日 20:36
主 题 ：[CCAMP] A Recap of Update to Draft "YANG Data Model for FlexEInterface Management"

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

Dear CCAMPers,

 

 

Best regards,

Yuanlong

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 17 Jul 2019 06:29:00 +0000

Hi Qilei,

I would be glad to see more analysis and rationale on the FlexE YANG work.
But IMHO, two key references are not included in your draft draft-wang-ccamp-flexe-control-analysis-02<https://datatracker.ietf.org/doc/draft-wang-ccamp-flexe-control-analysis/>, i.e., OIF-FLEXE-02.0 “Flex Ethernet 2.0 Implementation Agreement”, and OIF-FLEXE-ND-01.0 “FlexE Neighbor Discovery Implementation Agreement”. I would encourage you to give more analysis on these two fundamental documents.
Considering that OIF-FLEXE-ND-01.0 already provides discovery and negotiation capability, I think it would be a duplicate work for you to do this type of things in the FlexE YANG. Furthermore, these features will complicate the YANG module unnecessarily.
Please see my further comments inline.

Thanks,
Yuanlong

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 16, 2019 9:32 AM
To: Jiangyuanlong <[email-masked]>
Cc: [email-masked]
Subject: Re:[CCAMP] A Recap of Update to Draft "YANG Data Model for FlexEInterface Management"

Hi Yuanlong,

May I suggest we give some analysis and rationale description in the slides presented. I think this could make us easier to figure out which one is better. We also submit one companion draft draft-wang-ccamp-flexe-control-analysis-02<https://datatracker.ietf.org/doc/draft-wang-ccamp-flexe-control-analysis/>, trying to give some analysis.

YJ: Yes, our draft proposes a new interface type for FlexE Group. We model the FlexE Group as an interface, because a FlexE Group has the common characteristics of an interface, e.g.,  identifies a stream of network traffic (potentially at any layer); an anchor point to apply features and protocol forwarding configuration on that stream of traffic; it can be enabled/disabled and monitored as a whole. Not sure how a FlexE group identifier can accomplish this.

YJ: Yes, definitely our draft also proposes a new interface type for FlexE Client.

Thanks

Qilei

原始邮件
发件人：Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
收件人：CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2019年07月15日 20:36
主 题 ：[CCAMP] A Recap of Update to Draft "YANG Data Model for FlexEInterface Management"
_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

Dear CCAMPers,

Best regards,
Yuanlong

---

From: <[email-masked]>
Date: Thu, 18 Jul 2019 09:14:43 +0800 (CST)

Hi Yuanlong,

Thanks. Please let me give some explanation.

The reason that I refer to ITU-T document instead of OIF is we received comments during discussion when progressing flexe-fwk that we'd better do that. For the reference, I should put FlexE IA in. Thanks for capturing this. Besides, there is another reason if I have correct understanding, usually when we start the modelling work of other SDO (e.g, OTN, FlexE), following the startand of equipment model is better.

And for the neighbor discovery, I don't think we mentioned any discovery related work in the draft.

Thanks

Qilei

原始邮件

发件人：Jiangyuanlong <[email-masked]>
收件人：王其磊10101413;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2019年07月17日 14:29
主 题 ：RE: Re:[CCAMP] A Recap of Update to Draft "YANG Data Model forFlexEInterface Management"

Hi Qilei,

But IMHO, two key references are not included in your draft draft-wang-ccamp-flexe-control-analysis-02,  i.e., OIF-FLEXE-02.0 “Flex Ethernet 2.0 Implementation Agreement”, and OIF-FLEXE-ND-01.0 “FlexE Neighbor Discovery Implementation Agreement”. I would encourage you to give more analysis on these two fundamental documents.

 

Thanks,

Yuanlong

 

Hi Yuanlong,

Thanks

Qilei

 

原始邮件

日 期 ：2019年07月15日 20:36

Dear CCAMPers,

 

 

Best regards,

Yuanlong

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 23 Jul 2019 06:21:02 +0000

Qilei,

Thanks for your explanation.
Regarding the standard of equipment model, are you referring to G.875 (OTN protocol-neutral management information model) or G.8052 (Ethernet protocol-neutral management information model)?
Is your purpose to follow the same information model defined there? But please be aware that ITU-T may also develop its own YANG models, such as G.8052.1 and G.8052.2.
I must say our purpose is to develop a YANG data model for a generic FlexE interface, which can be applied to routers and other transport equipment.

As for the neighbor discovery, the protocol can provide information of remote PHYs (i.e., remote-phy-interface in bonded-phys), thus configuration of the remote PHY will be unnecessary, furthermore, the protocol can verify the connectivity of PHYs.

BTW, according to the general assumptions for the FlexE, (group number, client number) will uniquely identify a FlexE client between a pair of FlexE nodes, not just a single client number, thus it is inappropriate to model flexe-clients in parallel with flexe-groups (as a result, globally unique client number is mandated in your current model).

Regards,
Yuanlong

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 18, 2019 9:15 AM
To: Jiangyuanlong <[email-masked]>
Cc: [email-masked]
Subject: Re:[CCAMP] A Recap of Update to Draft "YANG Data Model forFlexEInterface Management"

Hi Yuanlong,

Thanks

Qilei

原始邮件
发件人：Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
收件人：王其磊10101413;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2019年07月17日 14:29
主 题 ：RE: Re:[CCAMP] A Recap of Update to Draft "YANG Data Model forFlexEInterface Management"
Hi Qilei,

Thanks,
Yuanlong

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Tuesday, July 16, 2019 9:32 AM
To: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re:[CCAMP] A Recap of Update to Draft "YANG Data Model for FlexEInterface Management"

Hi Yuanlong,

Thanks

Qilei

原始邮件

Dear CCAMPers,

Best regards,
Yuanlong

---

From: <[email-masked]>
Date: Tue, 23 Jul 2019 19:56:55 +0800 (CST)

Hi Yuanlong,

Sorry for not able to make this clear, I was referring to G.8023 - equipment function.

For FlexE client, I would say, the creation of FlexE client does not have to be in parallel with FlexE group. That's also our understanding and what we have done in the model. 

Thanks

Qilei

原始邮件

发件人：Jiangyuanlong <[email-masked]>
收件人：王其磊10101413;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2019年07月23日 14:21
主 题 ：RE: Re:[CCAMP] A Recap of Update to Draft "YANG Data ModelforFlexEInterface Management"

Qilei,

 

 

 

Regards,

Yuanlong

 

Hi Yuanlong,

Thanks

Qilei

原始邮件

收件人：王其磊10101413;

日 期 ：2019年07月17日 14:29

Hi Qilei,

 

Thanks,

Yuanlong

 

Hi Yuanlong,

Thanks

Qilei

 

原始邮件

日 期 ：2019年07月15日 20:36

Dear CCAMPers,

 

 

Best regards,

Yuanlong

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 23 Jul 2019 12:39:07 +0000

Hi authors,

Thanks a lot for the update and summary of one of the two drafts. During
your presentations @IETF105 could you please make sure to highlight what are
the commonalities between the two drafts (the parts you agree on) and the
parts you don't agree on and that didn't make a merge possible?

Many thanks,

Daniele  

From: CCAMP <[email-masked]> On Behalf Of Jiangyuanlong
Sent: den 15 juli 2019 08:29
To: CCAMP ([email-masked]) <[email-masked]>
Cc: [email-masked]
Subject: [CCAMP] A Recap of Update to Draft "YANG Data Model for FlexE
Interface Management"

Dear CCAMPers,

After the IETF 104th meeting, some authors of draft-jiang-ccamp-flexe-yang
and draft-xiaobn-ccamp-flexe-yang-mod had twice met and discussed the
possibility of combining these two drafts. But authors of the two drafts had
quite different opinions on the target and methodology of the FlexE YANG
model, thus we decided to update the drafts in its own right until our WG
makes a decision on how this work shall be proceeded.

Here is a brief summary of draft-jiang-ccamp-flexe-yang ("YANG Data Model
for FlexE Interface Management"):

1. the philosophy of the model is treating a whole FlexE Group as an
interface, and treating the Flex Clients in a FlexE Group as sub-interfaces,
so that the same interface logic applies (i.e., familiar flavor). 

2. Since a FlexE client is decoupled from the FlexE PHYs, it is modeled as a
new type of interface, so that new FlexE clients can be more appropriately
modeled, and more easily be augmented to support some new MAC layer
features, such as flow control, and etc.

3. it is modeled as a simple flat tree, and leave out internal data plane
implementation dependent artifacts where management and control planes do
not care much, such as FlexE Instance, Calendar A and B.

3. it uses the nomenclatures which are more compatible with the YANG style
in the IETF.

Please see https://tools.ietf.org/html/draft-jiang-ccamp-flexe-yang-01 for
the details. Your comments and involvements will be much appreciated.

Best regards,

Yuanlong

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 24 Jul 2019 07:08:05 +0000

Hi Daniele,

I will update the slides with a highlight page as you kindly proposed.
BTW, I could not attend the IETF 105th meeting on site, but my colleague Zitao will present the slides for us, and I will try my best to join the CCAMP session remotely.

Thanks much,
Yuanlong

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Tuesday, July 23, 2019 8:39 PM
To: Jiangyuanlong <[email-masked]>; CCAMP ([email-masked]) <[email-masked]>
Cc: [email-masked]
Subject: RE: A Recap of Update to Draft "YANG Data Model for FlexE Interface Management"

Hi authors,

Thanks a lot for the update and summary of one of the two drafts. During your presentations @IETF105 could you please make sure to highlight what are the commonalities between the two drafts (the parts you agree on) and the parts you don't agree on and that didn't make a merge possible?
Many thanks,

Daniele

From: CCAMP <[email-masked]<mailto:[email-masked]>> On Behalf Of Jiangyuanlong
Sent: den 15 juli 2019 08:29
To: CCAMP ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] A Recap of Update to Draft "YANG Data Model for FlexE Interface Management"

Dear CCAMPers,

Best regards,
Yuanlong

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 24 Jul 2019 08:51:18 +0000

Qilei,

G.8023 "forms part of a suite of ITU-T Recommendations covering the full functionality of Ethernet transport network architecture and equipment (e.g., Recommendations ITU-T G.8010/Y.1306 and ITU-T G.8021/Y.1341)". G.8052 already contains UML information model based on G.8021/Y.1341, thus it is very likely for G.8052 to support G.8023 in the near future. Maybe we need to liaise to  ITU-T firstly  for developing a YANG model in the IETF following ITU-T G.8023, IMHO.
That is also one reason we focus on a generic FlexE interface in draft-jiang-ccamp-flexe-yang instead. Furthermore, several venders have already implemented routers with the support of FlexE (Though we believe this model can also be applicable to other transport equipments).

In my previous email, "model flexe-clients in parallel with flexe-groups" refers to the position of flexe-goups and flexe-clients in your tree diagram:
module: ietf-flexe-yang
   +--rw flexe-configuration
      +--rw flexe-groups
      |  +--rw flexe-group* [group-number]
      |     +--rw group-number        uint32
      |     .
      |     .
      |     .
      +--rw flexe-clients
         +--rw flexe-client* [client-number]
            +--rw client-number         uint16
            .
            .
In FlexE, client-number should have a local significance, but your model mandates a global significance of client-number (as 65534 is the maximum of valid client-number, a global client-number will not be scalable in a large network). For example, in a typical FlexE network scenario, Flexe group 1 has a client with client-number 10, and Flexe group 2 has another client with client-number 10 (this is valid since these two clients can be uniquely identified by the tuple (group-number, client-number)). But this example cannot be configured by you model (only one client with client-number 10 is possible as client-number is the key).

Thanks,
Yuanlong

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 23, 2019 7:57 PM
To: Jiangyuanlong <[email-masked]>
Cc: [email-masked]
Subject: Re:[CCAMP] A Recap of Update to Draft "YANG Data ModelforFlexEInterface Management"

Hi Yuanlong,

Thanks

Qilei

原始邮件

Regards,
Yuanlong

Hi Yuanlong,

Thanks

Qilei

原始邮件

Thanks,
Yuanlong

Hi Yuanlong,

Thanks

Qilei

原始邮件

Dear CCAMPers,

Best regards,
Yuanlong