[Layer1-types WG LC] ODUflex #56

italobusi · 2020-01-23T10:37:50Z

The support of ODUflex in layer1-types needs to be enhanced:

In order to setup an ODUflex LSP, additional information should be added to the otn-path-bandwidth grouping to indicate the ODUflex bit rate (e.g., 3 Gb/s) and which TS allocation rule to use (section 5.1 or section 5.2 of RFC7139)
In order to support path computation for an ODUflex LSP, additional information should be added to the otn-link-bandwidth grouping to report the maximum ODUflex rate supported.
For example, on free OTU4 Link, it is possible to setup an ODUflex with any rate up to 100 Gb/s but, after a 3Gb/s ODUflex is setup, it would be possible to setup other ODUflex with any rate up to 97 Gb/s.
There are four ODUflex types in Table 7-2 of ITU-T G.709: CBR, GFP-F, IMP and FlexE-aware and three types in RFC7139: CBR, GFP-F non-resizable and GFP-F resizable. The definitions of the ODUflex identities should be revisited after the otn-path-bandwidth and the otn-link-bandwidth groupings have been updated
Editorial c/ODUFlex/ODUflex/

The text was updated successfully, but these errors were encountered:

italobusi · 2020-02-12T16:09:50Z

2020-02-12 Haomian/Italo

Regarding point 1, this could be a possible solution (aligned with G.709 Ed.06 just consented):

augment /te:te/te:tunnels/te:tunnel/te:te-bandwidth
          /te:technology:
  +--:(otn)
     +--rw odu-type?   identityref
     +--rw (oduflex-type)?
        +--:(cbr)
        |  +--rw client-type       identityref      // should check it is the same in client-signal model
        +--:(gfp)
        |  +--rw oduflex-gfp-n     uint8 (1..80)    // n of ODUflex(GFP, n, k)
        |  +--rw oduflex-gfp-k?    enum             // k of ODUflex(GFP, n, k) need to be supported with v6 (k=2, 3, 4)
        +--:(imp)
        |  +--rw oduflex-imp-s     uint16           // s of ODUflex(IMP, s)
        +--:(flexe)
        |  +--rw oduflex-flexe-n   uint16           // n of ODUflex(FlexE-aware)
        +--:(packet)
           +--rw oduflex-rate      uint16           // in Gbit/s

@haomianzheng : update the YANG model (evaluate the must/when statements to be added). Please consider the updated YANG tree proposal: #56 (comment)

@italobusi : propose some text for the draft to explain the solution

italobusi · 2020-02-12T16:11:17Z

2020-02-12 Haomian/Italo

Regarding point 2, the ODUflex bandwidth availability can be inferred from the available TS information. No need to change the YANG model.

@italobusi : propose some text for the draft to explain the solution

italobusi · 2020-02-12T16:23:47Z

2020-02-12 Haomian/Italo

Regarding points 3 and 4: there is no need to differentiate between CBR, GFP-F, IMP and FlexE-aware ODUflex types. However, there is a need to differentiate between resizable and non-resizable ODUflex.

It is therefore proposed to define two odu-types identities: ODUflex and ODUflex-resizable. The ODUflex-resizable can only be used with GFP mapping.

This should be taken into account in the when/must statements to be defined as per comment #56 (comment)

@haomianzheng : update the YANG model

@italobusi : propose some text for the draft to explain the solution

italobusi · 2020-02-13T16:31:38Z

Updated YANG tree proposal:

augment /te:te/te:tunnels/te:tunnel/te:te-bandwidth
          /te:technology:
  +--:(otn)
     +--rw odu-type?   identityref
     +--rw (oduflex-type)?
        +--:(generic)
        |  +--rw rate-multiplier   uint16
        |  +--rw rate-divider      uint16
        |  +--rw rate              uint64
        +--:(cbr)
        |  +--rw client-type       identityref      // should check it is the same in client-signal model
        +--:(gfp)
        |  +--rw gfp-n             uint8 (1..80)    // n of ODUflex(GFP, n, k)
        |  +--rw gfp-k?            enum             // k of ODUflex(GFP, n, k) need to be supported with v6 (k=2, 3, 4)
        +--:(flexe-client)
        |  +--rw flexe-client      union(enum (10G, 40G), uint16)    // ODUflex(IMP, s): 10G (s=2); 40G (s=8); n (s=5*n, when mapping n*25G FlexEC)
        +--:(flexe-aware)
        |  +--rw flexe-aware-n     uint16           // n of ODUflex(FlexE-aware)
        +--:(packet)
           +--rw packet-rate       uint16           // in Gbit/s

Proposal updated on 2020-02-24: #56 (comment)

This version updated the above editorial comments, solves the issues #50, #54, #57, #58. Issues still open on: #49, #55, #56.

italobusi · 2020-02-24T09:45:20Z

2020-02-24 Updated YANG tree proposal:

augment /te:te/te:tunnels/te:tunnel/te:te-bandwidth
          /te:technology:
  +--:(otn)
     +--rw odu-type?   identityref
     +--rw (oduflex-type)?
        +--:(generic)
        |  +--rw nominal-bit-rate            uint64 // in bit/s
        +--:(cbr)
        |  +--rw client-type       identityref      // should check it is the same in client-signal model
        +--:(gfp-n-k)
        |  +--rw gfp-n             uint8 (1..80)    // n of ODUflex(GFP, n, k)
        |  +--rw gfp-k?            enum             // k of ODUflex(GFP, n, k) need to be supported with v6 (k=2, 3, 4)
        +--:(flexe-client)
        |  +--rw flexe-client      union(enum (10G, 40G), uint16)    // ODUflex(IMP, s): 10G (s=2); 40G (s=8); n (s=5*n, when mapping n*25G FlexEC)
        +--:(flexe-aware)
        |  +--rw flexe-aware-n     uint16           // n of ODUflex(FlexE-aware)
        +--:(packet)     // both GFP-F and IMP
           +--rw opuflex-payload-rate       uint64           // in Kbit/s

haomianzheng · 2020-02-25T04:05:05Z

2020-02-24 Updated YANG tree proposal:

augment /te:te/te:tunnels/te:tunnel/te:te-bandwidth
          /te:technology:
  +--:(otn)
     +--rw odu-type?   identityref
     +--rw (oduflex-type)?
        +--:(generic)
        |  +--rw nominal-bit-rate            uint64 // in bit/s
        +--:(cbr)
        |  +--rw client-type       identityref      // should check it is the same in client-signal model
        +--:(gfp-n-k)
        |  +--rw gfp-n             uint8 (1..80)    // n of ODUflex(GFP, n, k)
        |  +--rw gfp-k?            enum             // k of ODUflex(GFP, n, k) need to be supported with v6 (k=2, 3, 4)
        +--:(flexe-client)
        |  +--rw flexe-client      union(enum (10G, 40G), uint16)    // ODUflex(IMP, s): 10G (s=2); 40G (s=8); n (s=5*n, when mapping n*25G FlexEC)
        +--:(flexe-aware)
        |  +--rw flexe-aware-n     uint16           // n of ODUflex(FlexE-aware)
        +--:(packet)     // both GFP-F and IMP
           +--rw opuflex-payload-rate       uint64           // in Kbit/s

Question1: on the potential choice 'oduflex-type': who is specifying this value? Is it expected to be specified in the odu-type?
Question2: for the 'generic' branch, which odu-types have been covered? Current understanding is k~=flex would be all covered, including ODU0/1/2/3/4/1e/2e/3e1/3e2/25/50/Cn, correct?

New (or revised) identities would also be needed for :
ODUflex-cbr (replacing ODUFlex-cbr)
ODUflex-gfp-n-k (replacing current ODUFlex-gfp);
ODUflex-flexe-aware
ODUflex-flexe-client
ODUflex-packet

italobusi · 2020-02-25T15:06:01Z

2020-02-24 Updated YANG tree proposal:
augment /te:te/te:tunnels/te:tunnel/te:te-bandwidth
          /te:technology:
  +--:(otn)
     +--rw odu-type?   identityref
     +--rw (oduflex-type)?
        +--:(generic)
        |  +--rw nominal-bit-rate            uint64 // in bit/s
        +--:(cbr)
        |  +--rw client-type       identityref      // should check it is the same in client-signal model
        +--:(gfp-n-k)
        |  +--rw gfp-n             uint8 (1..80)    // n of ODUflex(GFP, n, k)
        |  +--rw gfp-k?            enum             // k of ODUflex(GFP, n, k) need to be supported with v6 (k=2, 3, 4)
        +--:(flexe-client)
        |  +--rw flexe-client      union(enum (10G, 40G), uint16)    // ODUflex(IMP, s): 10G (s=2); 40G (s=8); n (s=5*n, when mapping n*25G FlexEC)
        +--:(flexe-aware)
        |  +--rw flexe-aware-n     uint16           // n of ODUflex(FlexE-aware)
        +--:(packet)     // both GFP-F and IMP
           +--rw opuflex-payload-rate       uint64           // in Kbit/s
Question1: on the potential choice 'oduflex-type': who is specifying this value? Is it expected to be specified in the odu-type?
Question2: for the 'generic' branch, which odu-types have been covered? Current understanding is k~=flex would be all covered, including ODU0/1/2/3/4/1e/2e/3e1/3e2/25/50/Cn, correct?

New (or revised) identities would also be needed for :
ODUflex-cbr (replacing ODUFlex-cbr)
ODUflex-gfp-n-k (replacing current ODUFlex-gfp);
ODUflex-flexe-aware
ODUflex-flexe-client
ODUflex-packet

The oduflex-type is specified by the attribute(s) being used. If the nominal-bit-rate attribute is used, the (generic) case has been selected. If the gfp-n attribute is used, the (gfp-n-k) case has been selected.

Therefore there is no need to define different identities for the different oduflex types. Only two odu-types identities are needed: ODUflex and ODUflex-resizable. See #56 (comment).

For consistency, the different attributes should have a when statement since they can be used only when the odu-type is ODUflex. The (gfp-n-k) can also be used when the odu-type is ODUflex-resizable.

Therefore, for the other cases (e.g., ODU0), only the odu-type attribute is used.

based on 3rd update, #55 solved: convert the range type to enumeration; #56 solved: add the ODUflex descriptions to otn-link-bandwidth and otn-path-bandwidth.

haomianzheng · 2020-02-26T06:42:39Z

Updated the groupings 'otn-link-bandwidth' and 'otn-path-bandwidth' as requested. Slight following differences are:

we try to make everything optional, i.e., with a '?' in the tree;
created typedef for enumeration and union;

TBD: Descriptions to be reviewed to avoid confusion.

Updated tree clips as follow:

augment /nw:networks/nw:network/nw:node
          /nt:termination-point/tet:te
          /tet:interface-switching-capability
          /tet:max-lsp-bandwidth/tet:te-bandwidth
          /tet:technology:
  +--:(otn)
     +--rw odu-type?                     identityref
     +--rw (oduflex-type)?
        +--:(generic)
        |  +--rw nominal-bit-rate?       uint64
        +--:(cbr)
        |  +--rw client-type?            identityref
        +--:(gfp-n-k)
        |  +--rw gfp-n?                  uint8
        |  +--rw gfp-k?                  l1-types:gfp-k
        +--:(flexe-client)
        |  +--rw flexe-client?
        |          l1-types:flexe-client
        +--:(flexe-aware)
        |  +--rw flexe-aware-n?          uint16
        +--:(packet)
           +--rw opuflex-payload-rate?   uint64

The full tree can be achieved at: 9fcc6a0

haomianzheng · 2020-02-27T09:10:06Z

TBD After discussion @italobusi and @haomianzheng on 20200227:

put 'mandatory true' for the first value of each branch;
remove the choice in otn-link-bandwidth;
conditional with a 'when' for odu-type must be either 'ODUflex' or 'ODUflex-resizable'.

Followup of #55 and #56 has been done; Editorial changes incoporated.

Make a few values mandatory true per #56.

italobusi · 2020-03-19T16:38:38Z

Closed in https://tools.ietf.org/html/draft-ietf-ccamp-layer1-types-05

italobusi added the enhancement New feature or request label Jan 23, 2020

italobusi assigned italobusi and haomianzheng Jan 23, 2020

italobusi added this to the Layer1-types WG LC milestone Jan 23, 2020

haomianzheng added a commit that referenced this issue Feb 24, 2020

Add files via upload

c5851ce

This version updated the above editorial comments, solves the issues #50, #54, #57, #58. Issues still open on: #49, #55, #56.

italobusi linked a pull request Feb 24, 2020 that will close this issue

YANG Doctor: 1st update #52

Merged

haomianzheng added a commit that referenced this issue Feb 26, 2020

4th update: proposing #55 and #56

18e53c3

based on 3rd update, #55 solved: convert the range type to enumeration; #56 solved: add the ODUflex descriptions to otn-link-bandwidth and otn-path-bandwidth.

italobusi removed a link to a pull request Feb 27, 2020

YANG Doctor: 1st update #52

Merged

haomianzheng added a commit that referenced this issue Feb 29, 2020

5th update: updating #55 and #56

79785d0

Followup of #55 and #56 has been done; Editorial changes incoporated.

haomianzheng added a commit that referenced this issue Feb 29, 2020

change with 5th update on l1-types

2e93399

Make a few values mandatory true per #56.

italobusi closed this as completed Mar 19, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Layer1-types WG LC] ODUflex #56

[Layer1-types WG LC] ODUflex #56

italobusi commented Jan 23, 2020

italobusi commented Feb 12, 2020 •

edited

italobusi commented Feb 12, 2020 •

edited

italobusi commented Feb 12, 2020

italobusi commented Feb 13, 2020 •

edited

italobusi commented Feb 24, 2020

haomianzheng commented Feb 25, 2020 •

edited

italobusi commented Feb 25, 2020 •

edited

haomianzheng commented Feb 26, 2020 •

edited

haomianzheng commented Feb 27, 2020

italobusi commented Mar 19, 2020

[Layer1-types WG LC] ODUflex #56

[Layer1-types WG LC] ODUflex #56

Comments

italobusi commented Jan 23, 2020

italobusi commented Feb 12, 2020 • edited

italobusi commented Feb 12, 2020 • edited

italobusi commented Feb 12, 2020

italobusi commented Feb 13, 2020 • edited

italobusi commented Feb 24, 2020

haomianzheng commented Feb 25, 2020 • edited

italobusi commented Feb 25, 2020 • edited

haomianzheng commented Feb 26, 2020 • edited

haomianzheng commented Feb 27, 2020

italobusi commented Mar 19, 2020

italobusi commented Feb 12, 2020 •

edited

italobusi commented Feb 12, 2020 •

edited

italobusi commented Feb 13, 2020 •

edited

haomianzheng commented Feb 25, 2020 •

edited

italobusi commented Feb 25, 2020 •

edited

haomianzheng commented Feb 26, 2020 •

edited