Child pages
  • TAPI Contributions and Presentations

Version 1.2 - 5 October 2020

Purpose of this document is to list the differences between YANG modules automatically generated and edited between TAPI 2.1.x and TAPI Next Major Release / Edge version.

Notes:

  1. Note that Edge does not have the “ interface realization ” association between context and service classes.
  2. Differences related to comments
  3. Modification for alignment
  4. For discussion
  5. New features for 2.1.x

 


1        Tapi Common

  1. Edge: copy streaming augment from 21x – now missing from “edited yang 21x”, present in “generated yang 21x”
  2. 21x: copy admin state pac comments from Edge
  3. 21x: copy lifecycle state pac comments from Edge
  4. 21x: copy global and local class comments from Edge
  5. 21x: copy operational state pac comments from Edge
  6. 21x: copy tapi-context and SIP class comments from Edge
  7. 21x: copy capacity-pac and termination-pac comments from Edge
  8. 213: delete resource and service spec
    1. Resource-spec in 213 is used by SIP, Link, Node, Topology, NEP, InterRuleGroup, NodeRuleGroup, CEP, SwitchControl,  Connection
    2. Service-spec in 213 is used by: NetworkTopologyService, ConnectivityService
  9. Edge: copy to 21x, no because is enum in 21x .

    identity OBJECT_TYPE {

        description "none";

    }

    identity OBJECT_TYPE_SERVICE_INTERFACE_POINT {

        base OBJECT_TYPE;

        description "none";

    }

  1. 21x: lifecycle-state copy comments from Edge
  2. Edge:  grouping bandwidth-profile and bandwidth-profile-type were defined in 21x, correctly removed from Edge (as Ethernet specific).
  3. 21x: missing the following types, which are defined in Edge:

   typedef mac-address {

        type string;

        description "pattern '[0-9a-fA-F]{2}(-[0-9a-fA-F]{2}){5}'

            description

            'The mac-address type represents a MAC address in the canonical

            format and hexadecimal format specified by IEEE Std 802. The

            hexidecimal representation uses uppercase characters.'";

    }

    typedef binary {

        type string;

        description "Represents any binary data, i.e., a sequence of octets.

            A binary type can be restricted by a length which defines the number of octets it contains.";

    }

    typedef timeticks {

        type string;

        description "type uint32

            The timeticks type represents a non-negative integer that represents the time, modulo 2^32 (4294967296 decimal), in hundredths of a second between two epochs.";

    }

    typedef object-type {

        type identityref {

            base OBJECT_TYPE;

        }

        description "The list of TAPI Common Object types/classes.";

    }

  1. 21x, rpc get/updated sip, copy UUID comments
    1. Note the difference of type, string (21x) vs. uuid (edge):

    rpc get-service-interface-point-details {

        description "none";

        input {

            leaf sip-id-or-name {

                type string ;

 

   rpc get-service-interface-point-details {

        description "none";

        input {

            leaf uuid {

                type uuid ;


2        Tapi Topology

  1. Edge: Link has protection-type and restoration-policy, while 213 has resilience-type.
    Edge: roll back to single attribute of 2.1.3
    https://github.com/OpenNetworkingFoundation/TAPI/issues/310
  2. Edge has Topology/boundary-node-edge-point (TopologyExposesBoundaryNEPs), 21x not.
    Consider adding to 2.1.x or removing from Edge
  3. 21x: copy comment of transitioned-layer-protocol-name from Edge
  4. Edge: NEP/availableCepLayerProtocol is richer than simple 21x supportedLayers
    Consider improve 2.1.x (otcc2020.AM.002-Transmission_Capability)
  5. NodeRuleGroup, recursive relationship, in Edge is “_composedRuleGroup”, in 21x is “_nodeRuleGroup”
    Consider align Edge to 2.1.x
  6. NodeRuleGroup/InterRuleGroup and rule/cepPortRole different config false .
    Consider update 2.1.x


2.1.x                                                       Edge – but also 2.1.x not edited! Wrong edited 2.1.x!
        list inter-rule-group {               list inter-rule-group {
         key 'uuid';                            key 'uuid';

             uses inter-rule-group;                 config false ;

             config false ;                          uses inter-rule-group;

 

         list cep-port-role {    list cep-port-role {

              uses port-role-rule;                            config false ;

              config false ;                        uses port-role-rule;
 

  1. 2.1.x ProtectionType, there is a typo, either correct 2.1.x (not bkw compatible) or make Edge wrong:

 

    typedef protection-type {

        type enumeration {

            enum NO_PROTECTON {

 

  1. ProtectionType, Edge has additional enum entries, consider enhance 2.1.x or remove from Edge:

 

 

            enum ONE_FOR_N_PROTECTION {

                description "none";

            }

            enum M_FOR_N_PROTECTION {

                description "none";

            }

            enum ONE_FOR_ONE_BY_N {

                description "none";

 

 

  1. Edge: all rpcs have comments on uuid (which are strings in 2.1.x)
  2. Edge has topology-object-type enum/identity


3        Tapi Connectivity

  1. Edge, Connection class has BoundingNode while 2.1.x not.
  2. 2.1.x: Connection class, copy container connection-spec-reference to Edge? Note that in TapiTopology, the Rule class has connection-spec-reference/ connectionSpec while in TapiConnectivity is connectionSpec Id
  3. 2.1.3: Node/_ownedNodeEdgePoint, Edge: Node/_nodeEdgePoint
  4. 21x: CEP/list CepRole (a string plus connection-spec-reference) while Edge: CEP/leaf protection-role
    • CepRole and ConnectionSpecReference not defined in Edge.
    • Note that 2.1.x CEP does not have protection role (only CSEP has it)
  5. ConnectivityConstraint, service-layer (layer-protocol-name) and connectivity-direction in 21x, not in Edge.
    Consider improving Edge, but note that direction is already in ConnectivityService!
    2.1.x has direction in ConnectivityConstraint, while Edge in ConnectivityService (anyway  ConnectivityConstraint is a 1:1 composite of ConnServ)
  6. 21x: copy service-level comment from Edge.
  7. No change needed: Edge: ConnectivityService, all references (connectivity-constraint; routing-constraint; topology-constraint; resilience-constraint) are StrictComposite , 21x are ExtendedComposite

        container connectivity-constraint {

            uses connectivity-constraint;

            description "none";

        }

  uses connectivity-constraint;

  • Edge: Note that 2.1.x is 0..1 topologyConstraint, while 0..* in Edge, local-id the key is mapped ( i.e. add to TopologyConstraint the LocalClass parent ):

        list topology-constraint {

            key 'local-id';

            uses tapi-path-computation:topology-constraint;

            description "none";

        }

  1. New feature from MEF L1, the reference to server-connectivity-service-end-point may address more than 1 (e.g. the two unreliable CSEP of a protection scheme on ENNI/INNI)
  2. Route class, Edge has _resilienceRoute, 2.1.x has _resilienceRoutePac , consider align Edge
  3. ResilienceConstraint, different model of protection/resilience type. Edge is more correct.
  4. 21x: Selection control is in Switch class, while in Edge is in ResilienceConstraint class (more correct)
  5. 21x: add fault-condition-determination to ResilienceConstraint class, plus related type
  6. ConnectivityObjectType not defined in 21x no change possible
  7. Edge: all rpcs have comment on uuid in Edge we may either remove all rpcs or enhance .
  8. create-connectivity-service, Edge adds input params: no need to change 21x
    • uuid
    • name
    • layer protocol name
    • topology constraint becomes a list
  9. update-connectivity-service, Edge adds input params:
    • uuid
    • name
    • topology constraint becomes a list
  10. 21x: full hierarchy (see below), while in Edge just uuid. No need to change

    rpc get-connection-end-point-details {

        description "none";

        input {

            leaf topology-id-or-name {

                type string;

                description "none";

            }

            leaf node-id-or-name {

                type string;

                description "none";

            }

            leaf nep-id-or-name {

                type string;

                description "none";

            }

            leaf cep-id-or-name {

                type string;

            }

        }

 

 

 

4        Tapi Equipment

No differences ( 12 July, in Edge fixed the SupportingPhysicalSpan augmentation of Link ) but the ObjectType which in Edge is defined in TapiCommon

Note also that in Edge the edited yang has “min-elements 1” for the list abstract-strand of physical-span. Note that both Edge and 2.1.x UML has 0..*, rather than 1..*

Edge has config false on expected/actual equipment of Equipment class – again only in the edited Edge Yang, uml is not specifying readonly…

 


5        Tapi OAM

  1. Edge: alarm-info and tca-info augments tapiNotification:Notification and “get-notification-list”, while 2.1.x alarm-info and tca-info are defined in TapiNotification and are composed into Notification.
    The TapiOam Edge model is shown in MEF 83 in an informative appendix.
    Considering that OAM is very likely not implemented, we may change 2.1.x in non-bkw comp way.
    (2.1.x no import tapi-notification)
    Edge includes perceived-tca-severity, perceived-severity-type, service-affecting, which in 2.1.x are defined in TapiNotification
    Edge includes extensions to tapi-notification:NOTIFICATION_TYPE (typedef oam-notification-type) (which in 2.1.x are all defined within TapiNotification)

    identity OAM_NOTIFICATION_TYPE {

    base tapi-notification:NOTIFICATION_TYPE;

        description "none";

    }
    identity OAM_NOTIFICATION_TYPE_ ALARM_EVENT {

        base OAM_NOTIFICATION_TYPE;

        description "none";

    }

    identity OAM_NOTIFICATION_TYPE_ THRESHOLD_CROSSING_ALERT {

        base OAM_NOTIFICATION_TYPE;

        description "none";
 

Similarly for typedef oam-object-type:
    identity OAM_OBJECT_TYPE {

    base tapi-common:OBJECT_TYPE;

        description "none";

    }
 

Edge adds the following base definitions (typedef alarm-condition-name, grouping pm-parameter/ typedef pm-parameter-name), which are augmented by TapiEth and TapiOdu

:

    identity ALARM_CONDITION_NAME {

        description "none";

    }

    identity PM_PARAMETER_NAME {

        description "none";

    }

 

Edge adds grouping pm-parameter/grouping pm-parameter-value

Edge adds threshold-crossing-qualifier


 

  1. 2.1.3 uses tapi-common:resource-spec, Edge uses tapi-common:global-class
  2. 2.1.x: pmCurrentData, PmHistoryData – Edge: currentData, historyData ( also the “-ref” in edited Yang )
  3. Edge: mep & oam-service-end-point, mep-identifier moved TapiEth eth-mep-common
  4. Edge: mep & oam-service-end-point, peer-mep-identifier moved to TapiEth eth-mep-sink
  5. Edge: mep & oam-service-end-point, direction discarded (TapiEth has eth-mep-sink/source)
  6. 2.1.x: oam-service-end-point – Edge: oam-service-point ( also the “-ref” in edited Yang )
  7. 2.1.x: meg has direction, not present in Edge meg
  8. 2.1.x: meg has meg-level, moved to TapiEth eth-meg-common
  9. 2.1.x: meg has meg-identifier, moved to TapiEth eth-meg-common
  10. Edge: oam-service has layer-protocol-name, 2.1.x not ( and the list is oam-service-point rather than end-point )
  11. 2.1.x: oam-service includes oam-profile and oam-constraint, Edge not (OamConstraint removed, OamProfile referred by oam-job and listed by oam-context, and param of create/get/delete-oam-profile )
  12. Edge: oam-service-point has is-mip, 2.1.x not
  13. 2.1.x: OamConstraints – Edge: class removed, because its attributes
    1. layerProtocolName: in Edge is in OamService,
    2. direction discarded in Edge
    3. megLevel moved to TapiEth eth-meg-common
  14. pm-current-data, pm-history-data:
    1. Edge: granularityPeriod and suspectIntervalFlag moved to a new class PmDataPac, conditional of both current and historyData.
    2. 2.1.x: timestamp – Edge: periodStartTime
  15. Edge pm-history-data adds period-start-time
  16. Edge OamProfile, pm-bin-data class removed (only attribute was granularityPeriod)
  17. pm-threshold, Edge adds applicable-job-type, threshold-parameter
  18. Edge has restructured RPCs

 


6        Tapi ODU

  1. Edge adds odu-meg-spec and odu-oam-service (augmenting OamService), 2.1.x can be enhanced
  2. Edge adds
  3. 21x OduTcmMepPac/ codirectional is “config false”, while in Edge is readwrite because OduTcmMepPac augments, besides OduMepSpec/Mep, also OduOamMep Service Point/OamServicePoint (provisioning). 2.1.x can be aligned.
  4. 21x: OduTcmMepPac inherits from OduTcmMipPac (only one attribute, tcmField), while in Edge the OduTcmMepPac does not inherit from OduTcmMipPac, and includes its tcmField. This likely because in Edge the OduTcmMipPac also includes codirectional attribute. Note also that in Edge the TcmMep/Mip tcmField is readwrite, while in 21x is “config false”. Is tcmField provisionable? Comment is “This attribute indicates the tandem connection monitoring field of the ODU OH”.
    2.1.x can be enhanced/aligned
  5. Edge adds odu-measurement-job
  6. Edge adds odu-error-performance-data, odu-delay-performance-data, odu-fec-performance-data (augmenting current/historyData). Evaluate to augment also a “ODU OAM” pac of ODU ttp/ctp.
  7. Edge adds odu-oam-mep-service-point, odu-oam-mip-service-point, 2.1.x can be enhanced
  8. Edge: odu-csep-ttp-pac/ configured-client-type is readwrite, 213 is “config false” – which seems wrong as it should be provisionable (through OduConnectivityServiceEndPointSpec)
  9. Edge has OTN_ALARM_CONDITION_NAME (all ODU related probable causes). Evaluate to enhance 2.1.x TapiNotification
  10. Edge has OTN_FAULT_CONDITION_DETERMINATION, ODU_OAM_JOB_TYPE
  11. Edge has

    typedef otn-fault-condition-determination {

        type identityref {

            base OTN_FAULT_CONDITION_DETERMINATION;

        }

        description "ITU-T-REC-G.873.1-201710

            Optical transport network: Linear protection";

    }

    typedef odu-oam-job-type {

        type identityref {

            base ODU_OAM_JOB_TYPE;

        }

        description "none";

    }

    grouping odu-counters {

        leaf bbe {

            type uint64;

            description "none";

        }

        leaf ses {

            type uint64;

            description "none";

        }

        leaf uas {

            type uint64;

            description "none";

        }

        description "none";

    }