YANG model for ROADM optical impairments #28

sergiobelotti · 2020-02-26T11:45:57Z

Adding modifications to the YANG model to introduce the attributes for optical impairments for the ROADM node.

EstherLerouzic · 2020-02-26T17:14:41Z

@sergiobelotti , I have compiled with pyang and a today's import of layer0-type yang model https://github.com/YangModels/yang/blob/master/experimental/ietf-extracted-YANG-modules/ietf-layer0-types%402019-11-28.yang:
there are two errors:

ietf-optical-impairment-topology.yang:418: error: type "standard-mode" not found in module "ietf-layer0-types"
ietf-optical-impairment-topology.yang:439: error: type "vendor-identifier" not found in module "ietf-layer0-types"

standard-mode has been suppressed in this commit: YangModels/yang@f278c2f and probably replaced with operational-mode

vendor-identifier has been suppressed in this commit YangModels/yang@d7c356d

(which I find stange because operatinal-mode description in my opinion is not sufficient to ensure that tsp from different vendors are compatible/interoperable ...)

I read the detail of your changes a give you more details

regards

EstherLerouzic · 2020-02-26T17:25:11Z

ietf-optical-impairment-topology.yang

@@ -248,15 +245,15 @@ module ietf-optical-impairment-topology {
        config false;
        description "Identifier of the carrier";
      }
-    }        
+    }
  }

  grouping optical-fiber-data {


this grouping is not used

EstherLerouzic · 2020-02-26T17:26:37Z

ietf-optical-impairment-topology.yang

      "sigma in the Gausian Noise Model";
    }
  }
-
+
  grouping optical-channel-data {


this grouping is not used

EstherLerouzic · 2020-02-26T17:29:55Z

ietf-optical-impairment-topology.yang

+        units "ps/nm/km";
+        description "Cromatic Dispersion";
+      }            
+      leaf pdl {


If would suggest to use the same wording as roadm-xxx -> roadm-pdl

EstherLerouzic · 2020-02-26T17:30:22Z

ietf-optical-impairment-topology.yang

+          fraction-digits 5;
+        }
+        units "ps/nm/km";
+        description "Cromatic Dispersion";


thanks, done

EstherLerouzic · 2020-02-26T17:30:59Z

ietf-optical-impairment-topology.yang

+        type decimal64 {
+          fraction-digits 5;
+        }
+        units "ps/nm/km";


I think this one is in ps/nm not per km

EstherLerouzic · 2020-02-26T17:32:04Z

ietf-optical-impairment-topology.yang

+          fraction-digits 8;
+          range "0..max";
+        }
+        units "ps/(km)^0.5"; 


I think this one should be in ps (not per km^1/2)

EstherLerouzic · 2020-02-26T17:32:24Z

ietf-optical-impairment-topology.yang

+        type decimal64 {
+          fraction-digits 2;
+        }
+        units db ;


EstherLerouzic · 2020-02-26T17:32:45Z

ietf-optical-impairment-topology.yang

+        type decimal64 {
+          fraction-digits 2;
+        }
+        units db;


sergiobelotti · 2020-02-27T10:11:49Z

@sergiobelotti , I have compiled with pyang and a today's import of layer0-type yang model https://github.com/YangModels/yang/blob/master/experimental/ietf-extracted-YANG-modules/ietf-layer0-types%402019-11-28.yang:
there are two errors:

ietf-optical-impairment-topology.yang:418: error: type "standard-mode" not found in module "ietf-layer0-types"
ietf-optical-impairment-topology.yang:439: error: type "vendor-identifier" not found in module "ietf-layer0-types"

standard-mode has been suppressed in this commit: YangModels/yang@f278c2f and probably replaced with operational-mode

vendor-identifier has been suppressed in this commit YangModels/yang@d7c356d

(which I find stange because operatinal-mode description in my opinion is not sufficient to ensure that tsp from different vendors are compatible/interoperable ...)

I read the detail of your changes a give you more details

regards

Hi Sergio, All,

Thanks for the information, the previous email from Esther did not come to me. I added Esther in this loop as well.

I tracked the changes in previous ietf-layer0-types versions, and share the following findings:

From draft-ietf-ccamp-layer0-types-02, the ‘standard-mode’ and the ‘operational-mode’ are merged into ‘operational-mode’, referencing to G.698.2; so the parameters who are referencing to ‘standard-mode’ should be switched to ‘operational-mode’;
The ‘vendor-identifier’ was removed in draft-ietf-ccamp-layer0-types-03;

We understand the concern you have, and agree that these parameters are probably useful in the impairment models. Actually Italo and I have some future consideration about the versioning of ietf-layer0-types, which has been mentioned in the side meeting but may need discussion as well.
a) We have now the version 1 ietf-layer0-types closing to publication, targeting on serving the wson and flexi-grid topology models;
b) In future we are having a version 2 of ietf-layer0-types which are used for both a) and impairment-topology; it’s expected version 2 is much bigger than the version 1, as much impairment parameters are introduced;
c) The versioning is exactly where your questions come from. Some of the parameters which are ONLY used by impairment, such as ‘operational-mode’ in the above, should be left to version 2, and will probably be removed in the version 1 ietf-layer0-types.
d) We do have concerns about the versioning management for YANG models, and there is no perfect solution at this moment. We are working with YANG doctors on how to solve the problem as well.

Hopefully such explanation helps proceeding the work, please feel free to comments, thank you.

BTW, is this issue open on the ccamp-wg github? I did not find #28 so cannot follow up in public way.

Best wishes,
Haomian

EstherLerouzic

Hope this helps!
I will try to build a json instance out of this and see if we miss anything
thanks a lot!
regards

EstherLerouzic · 2020-02-26T17:35:22Z

ietf-optical-impairment-topology.yang

+           with the inputs either routed to different output ports,
+           or all but 1 blocked";
+      }
+      leaf maxloss-exp {


same comment on unit db and naming roadm-maxloss-exp

EstherLerouzic · 2020-02-26T17:36:18Z

ietf-optical-impairment-topology.yang

+          fraction-digits 8;
+          range "0..max";
+        }
+        units "ps/(km)^0.5"; 


unit in ps (same comment)

EstherLerouzic · 2020-02-26T17:36:32Z

ietf-optical-impairment-topology.yang

+        type decimal64 {
+          fraction-digits 5;
+        }
+        units "ps/nm/km"; 


EstherLerouzic · 2020-02-26T17:36:59Z

ietf-optical-impairment-topology.yang

+        units "ps/nm/km"; 
+        description "Cromatic Dispersion";
+      }            
+      leaf pdl {


name roadm-pdl

EstherLerouzic · 2020-02-26T17:37:12Z

ietf-optical-impairment-topology.yang

+          fraction-digits 5;
+        }
+        units "ps/nm/km"; 
+        description "Cromatic Dispersion";


EstherLerouzic · 2020-02-26T17:38:50Z

ietf-optical-impairment-topology.yang

+        type decimal64 {
+          fraction-digits 2;
+        }
+        units dB ;


EstherLerouzic · 2020-02-26T17:39:26Z

ietf-optical-impairment-topology.yang

+    }
+  }
+
+  grouping roadm-drop-path {


same comments as for add

EstherLerouzic · 2020-02-26T17:40:48Z

ietf-optical-impairment-topology.yang

+        "This augment is only valid for Optical Impairment topology";
+    }
+    description
+      "node attributes augmentantion for optical-impairment RAODM node";


augmentantion - > augmentation
RAODM -> ROADM

ietf-optical-impairment-topology.yang

EstherLerouzic · 2020-02-27T10:09:58Z

ietf-optical-impairment-topology.yang

+    description
+      "node attributes augmentantion for optical-impairment RAODM node";
+
+    list path-impairment {


change to roadm-path-impairment ?

I originally put exactly this name, but I received one comment realted to the fact,, in the choice you already have the mention of "roadm" (roadm-express-path, roadm-add roadm.drop) so no need still to highlight roadm word.

sergiobelotti · 2020-02-27T13:55:46Z

@sergiobelotti , I have compiled with pyang and a today's import of layer0-type yang model https://github.com/YangModels/yang/blob/master/experimental/ietf-extracted-YANG-modules/ietf-layer0-types%402019-11-28.yang:
there are two errors:

ietf-optical-impairment-topology.yang:418: error: type "standard-mode" not found in module "ietf-layer0-types"
ietf-optical-impairment-topology.yang:439: error: type "vendor-identifier" not found in module "ietf-layer0-types"

standard-mode has been suppressed in this commit: YangModels/yang@f278c2f and probably replaced with operational-mode
vendor-identifier has been suppressed in this commit YangModels/yang@d7c356d
(which I find stange because operatinal-mode description in my opinion is not sufficient to ensure that tsp from different vendors are compatible/interoperable ...)
I read the detail of your changes a give you more details
regards

Hi Sergio, All,

Thanks for the information, the previous email from Esther did not come to me. I added Esther in this loop as well.

I tracked the changes in previous ietf-layer0-types versions, and share the following findings:

From draft-ietf-ccamp-layer0-types-02, the ‘standard-mode’ and the ‘operational-mode’ are merged into ‘operational-mode’, referencing to G.698.2; so the parameters who are referencing to ‘standard-mode’ should be switched to ‘operational-mode’;

The ‘vendor-identifier’ was removed in draft-ietf-ccamp-layer0-types-03;

We understand the concern you have, and agree that these parameters are probably useful in the impairment models. Actually Italo and I have some future consideration about the versioning of ietf-layer0-types, which has been mentioned in the side meeting but may need discussion as well.
a) We have now the version 1 ietf-layer0-types closing to publication, targeting on serving the wson and flexi-grid topology models;
b) In future we are having a version 2 of ietf-layer0-types which are used for both a) and impairment-topology; it’s expected version 2 is much bigger than the version 1, as much impairment parameters are introduced;
c) The versioning is exactly where your questions come from. Some of the parameters which are ONLY used by impairment, such as ‘operational-mode’ in the above, should be left to version 2, and will probably be removed in the version 1 ietf-layer0-types.
d) We do have concerns about the versioning management for YANG models, and there is no perfect solution at this moment. We are working with YANG doctors on how to solve the problem as well.

Hopefully such explanation helps proceeding the work, please feel free to comments, thank you.

BTW, is this issue open on the ccamp-wg github? I did not find #28 so cannot follow up in public way.

Best wishes,
Haomian

The simple way to proceed for the moment is to introduce definitions directly into ietf-optical-impairment-topology module like this:

typedef operational-mode {
type string;
description
"Vendor-specific mode that guarantees interoperability.";
reference "ITU-T G.698.2 (11/2018)";
}

typedef standard-mode {
type string;
description
"ITU-T G.698.2 standard mode that guarantees interoperability.
It must be an string with the following format:
B-DScW-ytz(v) where all these attributes are conformant
to the ITU-T recomendation";
reference "ITU-T G.698.2 (11/2018)";
}

typedef vendor-identifier {
type string;
description
"vendor identifier that uses vendor-specific mode";
reference
"RFC7581: Routing and Wavelength Assignment Information
Encoding for Wavelength Switched Optical Networks";
}

If agreed I can proceed in this way.

EstherLerouzic · 2020-02-27T14:20:21Z

The simple way to proceed for the moment is to introduce definitions directly into ietf-optical-impairment-topology module like this:

I agree with this !

EstherLerouzic · 2020-02-27T18:02:08Z

Here is the json template created out of the yang
(using pyang -f sample-xml-skeleton --sample-xml-skeleton-default and xmltodict python package)
output.txt

added ROADM power optical impairments description

italobusi

It is a good starting point and ready to be merge and used for the next I-D update

italobusi · 2020-03-04T23:07:28Z

@sergiobelotti , @EstherLerouzic : I have just discovered that there is another option to resolve the layer0-types versioning issue, without the need to copy the definitions which have been removed:

  import ietf-layer0-types {
    prefix "layer0-types";
    revision-date 2019-05-15;
  }

See: https://tools.ietf.org/html/rfc7950#section-5.1.1

EstherLerouzic

Here is my rapid review

EstherLerouzic · 2020-03-05T15:34:39Z

ietf-optical-impairment-topology.yang

+        "list of available baud-rates. Baud-rate is the unit for
+         symbol rate or modulation rate in symbols per second or
+         pulses per second. It is the number of distinct symbol
+         changes (signaling events) made to the transmission medium


signal instead of signaling

EstherLerouzic · 2020-03-05T15:35:42Z

ietf-optical-impairment-topology.yang

-      "String identifier of fiber type referencing a specification in
-      a separate equipment catalog";
+    description "String identifier of fiber type referencing a specification in a
+separate equipment catalog";


indent on 586

EstherLerouzic · 2020-03-05T15:38:03Z

ietf-optical-impairment-topology.yang

+           with the inputs either routed to different output ports,
+           or all but 1 blocked";
+      }
+      leaf roadm-maxloss-exp {


-exp is maybe too short (could be understoop as expecte as this word is also on the description
-> change to -expr ?

deleted exp. We have malloss in all, express, add and drop roadm path, and the context is defined by the container.

EstherLerouzic · 2020-03-05T15:39:29Z

ietf-optical-impairment-topology.yang

+           with the inputs either routed to different output ports,
+           or all but 1 blocked.
+           In the case of add path it is the total of the add block
+           + the egress amp crosstalk contributions.";


egress WSS crosstalk ?

correct. Thanks to suggest.

EstherLerouzic · 2020-03-05T15:41:11Z

ietf-optical-impairment-topology.yang

+           assuming no additional add path loss is added.  
+           This is used to establish the minimum required transponder output power required 
+           to hit the ROADM egress target power levels and preventing to hit the WSS attenuation limits.
+           If the add path contains an internal amplifier,this loss value should be based 


blank after the comma
final "." on next line

not sure to have got the problem. Can you elaborate it?

This is my understanding:

If the add path contains an internal amplifier, this loss value should be based on worst case expected amplifier gain due to ripple or gain uncertainty.";

EstherLerouzic · 2020-03-05T16:20:16Z

ietf-optical-impairment-topology.yang

+           drop path amplifier,or simply,to reduce the power of a “strong” carrier(due to ripple,for example), 
+           then the use of the ROADM input power levels and the above drop losses is not appropriate.
+           This parameter corresponds to the worst case per carrier power levels expected 
+           at the output of the drop block.To be noted that the net power levels from the drop block consider 


the sentence 'To be noted that ...' is a bit obscure when there is not the exact computation with it : maybe add that: a detail example of the comparison using these parameters is detailed in section xxx of the document xxx

ok. We will add correct referecne when a related text will be added in the draft, ok?

EstherLerouzic · 2020-03-05T16:21:59Z

ietf-optical-impairment-topology.yang

+           then the use of the ROADM input power levels and the above drop losses is not appropriate.
+           This parameter corresponds to the best case per carrier power levels expected 
+           at the output of the drop block.To be noted that the net power levels from the drop block consider 
+           these power levels,and the power levels calculated with the drop loss attributes,if both are defined.


same comment:
the sentence 'To be noted that ...' is a bit obscure when there is not the exact computation with it : maybe add that: a detail example of the comparison using these parameters is detailed in section xxx of the document xxx
blank after ','

ok, as above

EstherLerouzic · 2020-03-05T16:34:17Z

ietf-optical-impairment-topology.yang

+           drop path amplifier,or simply,to reduce the power of a “strong” carrier(due to ripple,for example), 
+           then the use of the ROADM input power levels and the above drop losses is not appropriate.
+           This parameter corresponds to the typical case per carrier power levels expected 
+           at the output of the drop block.To be noted that the net power levels from the drop block consider 


I think the sentence 'To be noted ... is different for ptyp. in Colin slides the ptyp determines the power of the group of carriers, if several carriers are extrated on the same drop path (drop block)... not clear to me if it is for the pmaxxnb_carriers or Pminxnb_carriers ... Maybe remove the sentence a say that a detailed description is for further work ?

I've removed the sentence. We will check further with Colin.

EstherLerouzic · 2020-03-05T16:37:27Z

ietf-optical-impairment-topology.yang

+          "Optical Signal-to-Noise Ratio (OSNR).
+           Expected OSNR contribution of the drop path amplifier(if present) for the case of additional 
+           drop path loss (before this amplifier) in order to hit a target power level (per carrier).
+           If both, the OSNR based on the ROADM input power level(Pcarrier=Pref+10Log(carrier_baudrate/ref_baud)+delta_power)


long line: add spaces around operators ' + '
change worst to minimum value

EstherLerouzic · 2020-03-05T16:38:59Z

ietf-optical-impairment-topology.yang

+        description 
+          "Drop path Noise Figure. 
+           If the drop path contains an amplifier,this is the noise figure of that amplifier,
+           inferred to the ROADM input port.This permits to determine amplifier OSNR contribution 


input port -> ingress port

dieterbeller

I will still provide minor comments later.

ietf-optical-impairment-topology.yang

dieterbeller · 2020-03-05T17:59:43Z

ietf-optical-impairment-topology.yang

-    description 
-      "List of modulation types the OTSi supports";
+    description
+      "List determining all the available modulations";


Why has this been changed? Please undo.

dieterbeller · 2020-03-05T18:00:03Z

ietf-optical-impairment-topology.yang

-        
-    leaf-list available-modulation-types {
+
+    leaf-list available-modulation {


Why has this been changed? Please undo.

dieterbeller · 2020-03-05T18:00:18Z

ietf-optical-impairment-topology.yang

    }

-    leaf configured-modulation-type {
+    leaf modulation-type {


Why has this been changed? Please undo.

dieterbeller · 2020-03-05T18:00:51Z

ietf-optical-impairment-topology.yang

-      description 
-      "Currently configured OTSi modulation type";
+      description
+      "Modulation configured for the transponder";


Why has this been changed? Please undo.

dieterbeller · 2020-03-05T18:01:10Z

ietf-optical-impairment-topology.yang

@@ -198,23 +230,23 @@ module ietf-optical-impairment-topology {
      description "configured baud-rate";
    }

-    leaf-list available-FEC-types {
+    leaf-list available-FEC {


Why has this been changed? Please undo.

dieterbeller · 2020-03-05T18:01:23Z

ietf-optical-impairment-topology.yang

      type identityref {
      base FEC;
      }
      config false;
      description "List determining all the available FEC";
    }

-    leaf configured-FEC-type {
+    leaf FEC-type {


Why has this been changed? Please undo.

dieterbeller · 2020-03-05T18:04:22Z

ietf-optical-impairment-topology.yang

  }
-    
+
  grouping sliceable-transponder-attributes {


The term "sliceable-transponder" is very unclear. The description does not provide more information what a sliceable transponder is. Therefore, a better term shall be used.

Could you propose something? Suggestion feature can be used.

I think we need more work on the transponder model (I have just created an open issue #29 )

For this version we either keep the current name or change it to transponder-attributes

If you change the grouping name you have also to change the code where you use this grouping

dieterbeller · 2020-03-05T18:07:24Z

ietf-optical-impairment-topology.tree

@@ -81,3 +81,52 @@ module: ietf-optical-impairment-topology
  augment /nw:networks/nw:network/nw:node/tet:te/tet:tunnel-termination-point:
    +--ro transponder-list* [carrier-id]
       +--ro carrier-id    uint32
+  augment /nw:networks/nw:network/nw:node/tet:te/tet:te-node-attributes:
+    +--ro path-impairment* [path-impairment-id]


As discussed: replace "path-impairment*" with "roadm-path-impairments*

Co-Authored-By: italobusi <italo.busi@huawei.com>

dieterbeller · 2020-03-08T10:20:50Z

ietf-optical-impairment-topology.yang

@@ -55,66 +55,67 @@ module ietf-optical-impairment-topology {
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info).";

-  revision 2019-05-30 {
+  revision 2020-03-03 {


Shall we use 2020-03-09 as revision date? This will be the submission date of the draft.

yes, modified with new commit

Modified version date

sergiobelotti added 5 commits February 26, 2020 12:24

Add files via upload

c2999fa

Delete ietf-optical-impairment-topology@2020-02-26.yang

540bd80

Add files via upload

cb0edcd

Delete ietf-optical-impairment-topology-tree

05d28d7

Add files via upload

47ee5f9

sergiobelotti requested review from agva123, dieterbeller, EstherLerouzic and italobusi February 26, 2020 11:47

sergiobelotti self-assigned this Feb 26, 2020

EstherLerouzic reviewed Feb 26, 2020

View reviewed changes

EstherLerouzic reviewed Feb 27, 2020

View reviewed changes

sergiobelotti added 3 commits March 3, 2020 12:59

Add files via upload

146aab9

Add files via upload

c40f66b

Add files via upload

55c2ace

added ROADM power optical impairments description

italobusi approved these changes Mar 4, 2020

View reviewed changes

EstherLerouzic approved these changes Mar 5, 2020

View reviewed changes

EstherLerouzic reviewed Mar 5, 2020

View reviewed changes

dieterbeller approved these changes Mar 5, 2020

View reviewed changes

dieterbeller reviewed Mar 5, 2020

View reviewed changes

sergiobelotti and others added 2 commits March 6, 2020 10:58

Update ietf-optical-impairment-topology.yang

b442bb5

Co-Authored-By: italobusi <italo.busi@huawei.com>

Add files via upload

4d20e81

dieterbeller reviewed Mar 8, 2020

View reviewed changes

Add files via upload

43c77ef

Modified version date

sergiobelotti merged commit 94b1b00 into ietf-ccamp-wg:master Mar 12, 2020

sergiobelotti mentioned this pull request May 12, 2020

Modeling of optical impairments for ROADMs #9

Closed

sergiobelotti mentioned this pull request Jun 11, 2021

ROADM impairments for C+L band #68

Merged


		leaf-list available-modulation-types {

		leaf-list available-modulation {

YANG model for ROADM optical impairments #28

YANG model for ROADM optical impairments #28

Conversation

sergiobelotti commented Feb 26, 2020

EstherLerouzic commented Feb 26, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sergiobelotti commented Feb 27, 2020

EstherLerouzic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sergiobelotti commented Feb 27, 2020

EstherLerouzic commented Feb 27, 2020

EstherLerouzic commented Feb 27, 2020

italobusi left a comment

Choose a reason for hiding this comment

italobusi commented Mar 4, 2020 • edited Loading

EstherLerouzic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dieterbeller left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

italobusi commented Mar 4, 2020 •

edited

Loading