Re: [CCAMP] WG adoption poll on draft-zhang-ccamp-l1-topo-yang-07

[Igor Bryskin <[e-mail]>]

Sorry, forgot the important thing, Yes, I support the adoption of this draft as WG document because the model is instrumental for the OTN layer  network traffic engineering hoping that the issue below will be resolved rather sooner than later.

Cheers,
Igor

From: Igor Bryskin
Sent: Thursday, April 27, 2017 11:05 AM
To: 'Fatai Zhang'; [e-mail]
Cc: [e-mail]
Subject: RE: WG adoption poll on draft-zhang-ccamp-l1-topo-yang-07

Hi,

Sorry to comment at this late stage. I have reviewed the model and noticed that parameters:

     +--rw tpn?                       uint16
      +--rw tsg?                       identityref
      +--rw protocol-type?             identityref
      +--rw adaptation-type?           adaptation-type
      +--rw sink-adapt-active?         boolean
      +--rw source-adapt-active?       boolean
      +--rw tributary-slots
      |  +--rw values*   uint8
      +--rw supported-payload-types* [index]
         +--rw index           uint16
         +--rw payload-type?   string

are attributed to client facing TE links. Instead, in my opinion they should be attributed to OTN layer Tunnel Termination Points (TTPs), the places where the ODUk connection(s) start and being used (i.e. adaptation happens) and where the parameters are relevant.
Rationale:

1)      client facing links may belong to a different layer (e.g. Ethernet), hence may not show up in the OTN TE topology, and this important information will be missing for the client;

2)      Depending on configuration, the same OTN TTP (e.g. the same ODU4 container) may adopt different layer payload (e.g. either ETH or SDH/STM);

3)      The multi-layer TE topology could be built bottom up. i.e.,first, create OTN TE tunnel from source to destination OTN layer TTPs, and after that, use the tunnel as a desired client layer TE link. To make this possible, the client must be aware of adaptation capabilities of all potential clients of a given OTN TTP.

Note that in the basic TE topology a server layer TTP has an attribute describing all potential clients of the TTP in question:

    container client-layer-adaptation {
         description
           "Containing capability information to support a client layer
            adaption in multi-layer topology.";
         list switching-capability {
           key "switching-capability encoding";
           description
             "List of supported switching capabilities";
           reference
             "RFC6001<https://tools.ietf.org/html/rfc6001>: Generalized MPLS (GMPLS) Protocol Extensions
              for Multi-Layer and Multi-Region Networks (MLN/MRN).
              RFC4202<https://tools.ietf.org/html/rfc4202>: Routing Extensions in Support of
              Generalized Multi-Protocol Label Switching (GMPLS).";
           leaf switching-capability {
             type identityref {
               base te-types:switching-capabilities;
             }
             description
               "Switching Capability for the client layer adaption.";
           }
           leaf encoding {
             type identityref {
               base te-types:lsp-encoding-types;
             }
             description
               "Encoding supported by the client layer adaption.";
           }
           leaf bandwidth {
             type te-bandwidth;
             description
               "Bandwidth available for the client layer adaption.";
           }
         }
       }

I suggest the OTN augmentation should augment the list with the parameter related to the adaptation, tributary slots, etc.

Igor

From: CCAMP [mailto:[e-mail]] On Behalf Of Fatai Zhang
Sent: Thursday, April 27, 2017 4:22 AM
To: [e-mail]
Cc: [e-mail]
Subject: [CCAMP] WG adoption poll on draft-zhang-ccamp-l1-topo-yang-07

Hi CCAMPers,
We now have the IPR declaration replies from all the authors.
This starts a two weeks poll on making [draft-zhang-ccamp-l1-topo-yang-07] a CCAMP working group document.
Please send email to the list indicating "yes/support" or "no/do not support" and a motivation for your reply, mandatory for the "not support" and nice to have for the "support".
Please note that no IPR was disclosed against this document.
The polling ends on Thursday May 11th.

Thanks,
Fatai & Daniele