Model Overview


BBS use case aims at using ONAP for the design, creation and activation of the High Speed Internet Access CFS.

Model Design

BBS - ModelOverview

Representation in SDC

Resource Representations

Modeled ResourceSDC RepresentationA&AI objectTOSCA file
ONT NNIConnection PointcpontNni.yaml & ontNni.json (for import)

PON UNI

Connection Pointcp

ponUni.yaml & ponUni.json (for import)

OLT NNIConnection Point

cp

oltNni.yaml & oltNni.json (for import)
ODN ConnectionVNF Virtual LinkN/A
Access ConnectivityVirtual Function Componentgeneric-vnfaccessConnectivity.yaml
Internet ProfileVirtual Function Componentgeneric-vnfinternetProfile.yaml
CPE (PNF)Virtual Function ComponentpnfcpePnf.yaml

Composition of services

ServiceComposed Of
HSIA CFS (BBS E2E Service)

CPE VF*
- CPE VFC

ONT-NNI CP

ODN Connection Vnf Virtual Link

PON-UNI CP

Access Connectivity VF
- Access Connectivity VFC

OLT-NNI CP


Internet Profile VF
- Internet Profile VFC


(*) with workaround to model PNF in SDC

Representation in A&AI

BBS in AAI

Model Parameter Life-cycle

Table on information model 'storage' and discovery-inventory analysis for BBS use case parameters

BBS Parameter Table

ONAP AwarenessSDNC (Access Discovery)SDN-C (Edge Discovery)SDC (Service Creation from Portal)DCAE Registration PNFSDN-C (Access Service)

DCAE

CPE Auth

A&AI
 Service (HSIA)
 RG MAC Add

Input


Input 
 Service Type

Input


Input 
 Upstream Speed

Input 


 Input 
 Downstream Speed

Input


 Input 
 Remote ID

Input (Optional)  Input
Input (used to find the CFS associated with PNF) Input
 Orch Status



Derived - Obtained from CFS associated with PNF in PNF RegistrationDerived - Obtained from CFS associated w PNF and MAC Address Input
 HSIA Access    
 CPE/ONT PNF      
 PNF Name

Input (CorrelationID) SourceName
 SourceName Input
 MAC Address


Input
Input Input
 Manufacturer

 Onboarded CSAR ArtifactInput 

 Input
 Serial Number


 Input

  

 Input
 Model


 Input

 Input
 Type

 Onboarded CSAR Artifact Input

 Input
 SW Version


 Input (Optional)
  Input (Optional) Input
Attachment Point (new field)


Input

Input
CPE Authentication State




Input (Used to derive the CFS orchestration status)
ONT NNI (PORT)



  Input from response when access connectivity is created
 Input
 ODN Virtual Link 



Input from response when access connectivity is created
 Input
Access Connectivity
Service Type



Input (from CFS)

Upstream Speed



Input (from CFS)

Downstream Speed



Input (from CFS)

 PON UNI
 CVLAN

 Input (Optional) Input Input when access connectivity is created or CFS if not in DCAE Reg
 Input
Expected ONT ID

 Input (Optional)
 Input (from CFS)
 Input

OLT Name

Input

 Derived (Attachment Point)

Input
OLT PON SlotInput

 Derived (Attachment Point)

Input
OLT PON PortInput

 Derived (Attachment Point)

Input
OLT NNI
SVLANInput
Input (Optional)Input Input when access connectivity is created or CFS if not in DCAE Reg
Input
OLT NameInput




Input
OLT NNI SlotInput




Input
OLT NNI PortInput




Input

BBS Parameter Table

ONAP AwarenessSDNC (Access Discovery)SDN-C (Edge Discovery)SDC (Service Creation from Portal)DCAE Registration PNFSDN-C (Access Service)

DCAE

CPE Auth

A&AI
 Service (HSIA)
 RG MAC Add

Input


Input 
 Service Type

Input


Input 
 Upstream Speed

Input 


 Input 
 Downstream Speed

Input


 Input 
 Remote ID

Input (Optional)  Input
Input (used to find the CFS associated with PNF) Input
 Orch Status



Derived - Obtained from CFS associated with PNF in PNF RegistrationDerived - Obtained from CFS associated w PNF and MAC Address Input
 HSIA Access    
 CPE/ONT PNF      
 PNF Name

Input (CorrelationID) SourceName
 SourceName Input
 MAC Address


Input
Input Input
 Manufacturer

 Onboarded CSAR ArtifactInput 

 Input
 Serial Number


 Input

  

 Input
 Model


 Input

 Input
 Type

 Onboarded CSAR Artifact Input

 Input
 SW Version


 Input (Optional)
  Input (Optional) Input
Attachment Point (new field)


Input

Input
CPE Authentication State




Input (Used to derive the CFS orchestration status)
ONT NNI (PORT)



  Input from response when access connectivity is created
 Input
 ODN Virtual Link 



Input from response when access connectivity is created
 Input
Access Connectivity
Service Type



Input (from CFS)

Upstream Speed



Input (from CFS)

Downstream Speed



Input (from CFS)

 PON UNI
 CVLAN

 Input (Optional) Input Input when access connectivity is created or CFS if not in DCAE Reg
 Input
Expected ONT ID

 Input (Optional)
 Input (from CFS)
 Input

OLT Name

Input

 Derived (Attachment Point)

Input
OLT PON SlotInput

 Derived (Attachment Point)

Input
OLT PON PortInput

 Derived (Attachment Point)

Input
OLT NNI
SVLANInput
Input (Optional)Input Input when access connectivity is created or CFS if not in DCAE Reg
Input
OLT NameInput




Input
OLT NNI SlotInput




Input
OLT NNI PortInput




Input
HSIA Edge
Transport Connection
Input



Input (Just added after Edge/ Access Discovery)
BNG UNI
Input



Input

Service-instance-related information

See AAI-BBS Proposals for Dublin Release#BBSProposalsforDublinRelease-Item6.Specificdecisionsmadeforeachattribute 


BBS Properties Per HSIA CFS Service Instance
Input Source
ONAP Components that must fetch the value from A&AIDoes it really need A&AI storage?

A&AI Metaname 

(for Metadata)

RG MAC Address

Service Order via Ext API

It also comes in the CPE Authentication Event

bbs-event-processor
DCAE microservice
(it fetches existing value from A&AI to compare it with the new value coming from PNF CPE authentication event in order to deduce if there is any mismatch)
Yes, as metadata of CFS service instancergw-mac-address
Correlation ID (PNF-name)

Service Order via Ext API

It also comes in the sourceName of the PNF registration event's commonEventHeader


Yes, as property of PNF object
Service TypeService Order via Ext API

SO / bbs-apex-policy

(during Access Connectivity and Internet Profile VFCs creation & update)

Yes, as metadata of CFS service instanceservice-type
Access IDPNF registration event

SDN-C or SO? / bbs-apex-policy

(during Internet Profile VFC creation & update)

Yes, as metadata of CFS service instanceremote-id
Upstream SpeedService Order via Ext API

SDN-C or SO? / bbs-apex-policy

(during Internet Profile VFC creation & update)

Yes, as metadata of CFS service instanceup-speed
Downstream SpeedService Order via Ext API

SDN-C or SO? / bbs-apex-policy

(during Internet Profile VFC creation & update)

Yes, as metadata of CFS service instancedown-speed

OLT Name

PNF registration event
(extracted from attachment point)


OLT PON portPNF registration event
(extracted from attachment point)


OLT PON slotPNF registration event
(extracted from attachment point)


CVLAN

PNF registration event

Service Order via Ext API [optional - if not provided by Access SDN M&C]

SDN-C or SO? / bbs-apex-policy

(during Internet Profile VFC creation & update)

Yes, as metadata of CFS service instancecvlan
SVLAN

PNF registration event

Service Order via Ext API [optional - if not provided by Access SDN M&C]

SDN-C or SO? / bbs-apex-policy

(during Internet Profile VFC creation & update)

Yes, as metadata of CFS service instancesvlan
Expected ONT IDService Order via Ext API [optional]

SDN-C or SO?

(for Access Connectivity VFC creation)

Yes, as metadata of CFS service instanceexpected-ont-id
CPE ManufacturerPNF registration event
Yes, as property of PNF objectNot Applicable
CPE ModelPNF registration event
Yes, as property of PNF objectNot Applicable
CPE Equipment TypePNF registration event
Yes, as property of PNF objectNot Applicable
CPE Serial NumberPNF registration event
Yes, as property of PNF objectNot Applicable
CPE SW Version

PNF registration event 

(also present in CPE Authentication Event)


Yes, as property of PNF objectNot Applicable

Attachment Point

(Not a real BBS modeling property, since its constituent parts are captured in other model properties)

PNF registration event
bbs-event-processor
DCAE microservice
(it fetches existing value from A&AI to compare it with the new value coming from PNF re-registration event in order to deduce if it is a true relocation)
Yes, as value of link-name property of a logical-link bridged to the PNF objectNot Applicable

ONT NNI Port


CPE PNF onboarding in SDC


OLT NNI Slot


PNF registration event


OLT NNI Port


PNF registration event


TOSCA Models


HSIA Access RFS : CPE 
tosca_definitions_version: tosca_simple_yaml_1_0_0
node_types: 
  org.openecomp.resource.vfc.OntPnf: #we cannot use the namespace like "tosca.nfv.nodes" cause SDC's restriction
    derived_from: org.openecomp.resource.abstract.nodes.PNF
    properties:
      cpe_id:
        type: string
        required: true
      pnf_name:
        type: string
        required: true
      mac_addr:
        type: string
        required: true
      manufacturer:
        type: string
        required: true
      serial_num:
        type: string
        required: true
      model:
        type: string
        required: true
      attachment_point:
        type: string
        required: true
      is_pnf: # temporary parameter
        type: boolean
        required: true
        default: true
#      ont_type: reuse nf_type in Generic_PNF
#        type: string
#        required: true
#      ont_sw_version: reuse software_versions in Generic_PNF
#        type: string
#        required: true
    capabilities:
        virtual_binding:
          type: tosca.capabilities.nfv.VirtualBindable
          occurrences:
          - 1
          - UNBOUNDED

CpePnf.yml

HSIA Access RFS : AccessConnectivity 
tosca_definitions_version: tosca_simple_yaml_1_0_0
node_types: 
  org.openecomp.resource.vfc.accessConnectivity: 
    derived_from: tosca.nodes.Root
    description: olt
    properties:
      service_type:
        type: string
        required: true
      upstream_speed:
        type: string
        required: true
      downstream_speed:
        type: string
        required: true
    capabilities:
        virtual_binding:
          type: tosca.capabilities.nfv.VirtualBindable
          occurrences:
          - 1
          - UNBOUNDED

access_connectivity.yml

HSIA Access RFS : OntNni 
tosca_definitions_version: tosca_simple_yaml_1_0_0
node_types: 
  org.openecomp.resource.cp.OntNni: 
    derived_from: tosca.nodes.nfv.VduCp
    properties:
      ont_port:
        type: string
        required: true
    requirements:
        - virtual_link:
            capability: tosca.capabilities.nfv.VirtualLinkable
            relationship: tosca.relationships.nfv.VirtualLinksTo
            node: tosca.nodes.nfv.VnfVirtualLink
        - virtual_binding:
            capability: tosca.capabilities.nfv.VirtualBindable
            relationship: tosca.relationships.nfv.VirtualBindsTo
            node: org.openecomp.resource.vfc.OntPnf

OntNni.rar

HSIA Access RFS : PonUni 
tosca_definitions_version: tosca_simple_yaml_1_0_0
node_types: 
  org.openecomp.resource.cp.PonUni: 
    derived_from: tosca.nodes.nfv.VduCp
    properties:
      expected_ont_id:
        type: string
        required: true
      cvlan_id:
        type: string
        required: true
      olt_name:
        type: string
        required: true
      olt_pon_port:
        type: string
        required: true
      olt_pon_slot:
        type: string
        required: true
    requirements:
        - virtual_link:
            capability: tosca.capabilities.nfv.VirtualLinkable
            relationship: tosca.relationships.nfv.VirtualLinksTo
            node: tosca.nodes.nfv.VnfVirtualLink
        - virtual_binding:
            capability: tosca.capabilities.nfv.VirtualBindable
            relationship: tosca.relationships.nfv.VirtualBindsTo
            node: org.openecomp.resource.vfc.accessConnectivity

PonUni.rar

HSIA Access RFS : OLTNNI 
tosca_definitions_version: tosca_simple_yaml_1_0_0
node_types: 
  org.openecomp.resource.cp.OltNni: 
    derived_from: tosca.nodes.nfv.VduCp
    properties:
      olt_name:
        type: string
        required: true
      olt_nni_port:
        type: string
        required: true
      olt_nni_slot:
        type: string
        required: true
      svlan:
        type: string
        required: true        
    requirements:
        - virtual_link:
            capability: tosca.capabilities.nfv.VirtualLinkable
            relationship: tosca.relationships.nfv.VirtualLinksTo
            node: tosca.nodes.nfv.VnfVirtualLink
        - virtual_binding:
            capability: tosca.capabilities.nfv.VirtualBindable
            relationship: tosca.relationships.nfv.VirtualBindsTo
            node: org.openecomp.resource.vfc.accessConnectivity

OltNni.rar

HSIA Access RFS : InternetProfile 
tosca_definitions_version: tosca_simple_yaml_1_0_0
node_types: 
  org.openecomp.resource.vfc.InternetProfile: 
    derived_from: tosca.nodes.Root
    properties:
      rg_mac_addr:
        type: string
        required: true
      service_type:
        type: string
        required: true
      upstream_speed:
        type: string
        required: true
      downstream_speed:
        type: string
        required: true
      remote_id:
        type: string
        required: true
    capabilities:
        virtual_binding:
          type: tosca.capabilities.nfv.VirtualBindable
          occurrences:
          - 1
          - UNBOUNDED

InternetProfile.yaml

  • No labels

28 Comments

  1. Stavros Kanarakis

    This is a first conceptual proposal on how we could model the use case. It is a high level decomposition of the RFS services/resources based on the initial Wiki modeling depiction. It does not contain any specific domain models per RFS yet.



    ASSUMPTIONS

    • One vBNG, one vAAA, one vDCHP in the Edge Network
    • One NNI per OLT
    • OLT connects to one vBNG
    • Access SDN M&Cs installed in the network
    • Transport connection established between Access SDN M&Cs and vBNG
    • Business customer who will be the target of the HSIA service has already been created in ONAP


    NOTES

    • Infrastructure (shared) RFS Services: instantiated outside any HSIA CFS service instance lifecycle
    • Non-infrastructure RFS Services: instantiated during the HSIA CFS service instance lifecycle


    The steps mentioned below are not meant to be a flow diagram representation. It is just an enumeration of generic steps and how they relate with the RFS services/resources depicted in the diagram.


    HSIA activation sub-use case (incorporating Topology Discovery) based on proposed modeling


    1. Instantiate the Edge RFS infrastructure instance. This service instance will hold information about the predefined list of VMs for AAA/DHCP/BNG
    2. Register all the external Access SDN M&Cs with ONAP so that A&AI gets their network topologies (OLT PON Ports/ OLT NNIs). At the same time, statically onboard the Edge UNIs/NNIs in A&AI (no topology discovery for Edge domain)
    3. Instantiate the HSIA CFS service by providing all the necessary access service details (ONT S/N, access profile, etc.). Associate the ONT S/N with the business customer on which the service is being instantiated. Perform workflow to add the ONT to the A&AI as an inactive PNF entry. Wait until ONT gets bootstrapped and registered to ONAP.
    4. ONT bootstraps and registers as a PNF (via DCAE). We extract the ONT Serial Number - PON UNI association. From A&AI, we can verify that this is a new registration because there will be no existing association with a PON UNI for this serial number. We also extract from A&AI the business customer associated with the registered PNF ONT (again from the ONT serial number).
    5. Based on the PON UNI extracted above, we can discover the associated OLT NNI from A&AI (since the assumption is that all PON UNIs from the same OLT leverage a single OLT NNI)
    6. At this point, we can instantiate the Access Connectivity non-infrastructure RFS.
    7. We then instantiate the ONT non-infrastructure RFS that will be connected to the Access Connectivity RFS
    8. We can instruct SDN-C to propagate the necessary configuration (OLT/ONT related) towards Access SDN M&C
    9. We instantiate the Internet Access non-infrastructure RFS to capture the speed profile of the HSI subscription.
    10. We can instruct SDN-C to propagate the necessary configuration (AAA) towards Edge SDN M&C
    11. Wait for ONT to become activated (RG activated event)


    1. David Perez Caparros

      This is good. Just a couple of comments:

      - Does the concept of allotted resource apply here? See Allotted Resource Model.
      "Allotted Resources are portions of one service which can be allotted to be used as resources by another."
      Perhaps, the option of connecting ONTF RFS with Access Conn. RFS fits better, let's discuss it.

      - How could we add here the option where the traffic shaping (speed profile) is enforced by the Access Conn RFS? e.g. SEBA case

      1. Stavros Kanarakis

        Hi David,

        I know that Allotted Resource Model is best suited for a shared service concept. I used it because many ONT RFS instances could re-use the same Access Conn. RFS in case they land on the same PON port of that specific OLT (one Access Conn. RFS is bound to a specific PON port having been discovered by topology discovery).

        I have seen allotted resource model usage in the CCVPN but in their case I admit it is a better fit. That is why I have made a comment about allotted resources in step 8 of my list above.

        If there is any conceptually better alternative, I will be more than happy to discuss it of course.

        For your second question, could you please elaborate a bit more? I am not familiar with the SEBA case.

        1. Stavros Kanarakis

          I have edited the proposal to remove the Allotted Resource concept between the ONT RFS and the Access Connectivity RFS. David is right, the concept is towards 1-1 mapping between the two RFSs instead of a shared service.

        2. David Perez Caparros

          For your second question, could you please elaborate a bit more? I am not familiar with the SEBA case.

          As of today, we (Swisscom) do subscriber traffic shaping in the BNG and not in the OLT/Central Office. With proposals like SEBA (SDN Enabled Broadband Access), traffic shaping seems to be done directly in the Access POD (Central Office), before the metro link. If you look at the OSAM use case, which is using SEBA, subscriber speed profiles are configured in the Access POD (Models for OSAM) and (Flows for OSAM#4-SubscriberRegistrationFlow). SEBA exposes speed profile management (https://drive.google.com/drive/folders/1DTU68lFim6sIQ7Rpd3PPTY0gfWdeD9oO). The Access POD/SEBA is seen as a big OLT by OSS/BSS (at least in AT&T case: https://docs.google.com/document/d/1nou2c8AsRzhaDJmA_eYvFgd0Y33KiCsioveU77AOVCI/edit). 

          1. Keong Lim

            Hi David Perez Caparros,

            Why are the SEBA files hosted on google docs and google drive rather than on the ONAP wiki?

            There was a similar issue at the VF2F ONAP Project Developers Event, Dec 10 - 12, 2018, (Virtual Webinars) using the gitlab wiki instead of ONAP wiki (see chat log Dec 12 from 07:05:24) Gildas Lanilis .


            1. David Perez Caparros

              Hi Keong, SEBA is an ONF project (https://www.opennetworking.org/seba/), not related to ONAP. OSAM is an ONAP use case using SEBA. 

          2. Stavros Kanarakis

            To my understanding, when SO workflow will request from SDN-C to configure OLT/ONT, at that point, the respective DG that will be executed, can query A&AI to fetch the actual subscription speed value from either the HSIA CFS service instance or the Internet Access RFS instance (in case we instantiate it earlier … something that is not depicted in the steps I have above in the proposal).

            So, DG logic has the option of propagating this piece of information towards Access SDN M&C in case traffic shaping is done in Access POD.

            Does this answer your second question?

  2. Weitao Gao

    I tried to classify the BBS related modeling by using SDC/TOSCA language: 

    1. Modeled as PNF

    PNF

    Attributes

    ONT(CPE)

    String: ONT Serial Number

    String: ONT Port

    String: version

    String: EquipmentID (type)

    OLT

    String: OLT Name

    String: OLT Slot

    String: OLT Port

    (v)BNG

    No Specific Requirements

    2. Modeled as External Connection Point

    ExtCP

    Attributes

    Remark

    ONT NNI

    No Specific Attributes


    PON UNI

    String: Service Type


    String: Upstream Bandwidth


    String: Downstream Bandwidth


    String: CVLAN-ID


    String: A-OLT Name


    String: OLT-Port


    String: OLT-SLOT


    String: ONT Serial No.


    String: ONT-Port


    OLT NNI

    String: SVLAN-ID


    String: A-OLT Name


    String: OLT-Port


    String: OLT-SLOT


    BNG UNI

    String: SVLAN-ID

    Maybe the BNG Uni could reuse thesegmentIdas the SVLAN-ID insideVirtualLink?

    BNG NNI

    String: IPAddress

    Ipaddress also could reuse thestartIpandendIpas theIpaddress

    VTEP

    ?


    3. Modeled As Virtual Link

    Link

    Attributes

    Access Link

    String: OTO ID

    String: OMDF connector

    String: Splitting ratio

    Metro Link

    ?

  3. Tim Carey

    For the TOSCA definition:


    Use of olt in names - there are actually different types of ANs (e.g., DSLAM, OLT) - so maybe we need a generic Access RFS and then a specialized AccessOLT RFS with the PON parameters (e.g. Fiber).


    We could then name the common elements an_name, an_uni_xxx, an_nni_xxx. Also you probably need a an_nni_slot unless the UNI/NNI naming conventions will include shelf/slot/port - if you don't need the an_uni_slot attribute.



  4. Tim Carey

    In the TOSCA definitions - I thought we descoped the transport elements from this use case for Dublin? If so do we need the TOSCA definitions?

    1. Weitao Gao

      Agree, the Transport part is pre-instantiated and no Usecase involve this part currently.

      1. Stavros Kanarakis

        I agree that is is descoped but what is not clear to me is how we are going to select any pre-defined static links if not modeled somehow in our final modeling. We can discuss it further.

  5. Weitao Gao

     Stavros Kanarakis , Seems like your modeling proposal based on the Target Internal DM Reference. As far as I know, this DM will not be implemented in Dublin Release. Thinh Nguyenphu Xu Yang shitao liPlease correct me if I'm wrong.

  6. Weitao Gao

    Agreement from Stavros and Victor: 

    1. model the ONT(CPE) as a PNF (how to model a PNF)
    2. model the OLT as a Connectivity and put the PON UNI and OLT NNI as the properties.
    3. Transport part will be descoped from BBS modeling part in Dublin Release.
    4. ONT UNI will be modeled as Connection Point.


    BNG UNI/NNI will be modeled as VNF CP?

  7. Stavros Kanarakis

    Changed the conceptual diagram to reflect what we agreed with Victor

  8. michail salichos

    Just a clarification, we are not planning to support separate VNF's for BNG, AAA and DHCP servers at the Edge, there will be a single Ubuntu-based VM running these services and ONAP will be "seeing" the Edge as an external SDN controller. Also, to reflect on the aforementioned Edge design, the conceptual diagrams in this wiki page depict an internal network  between AAA, BNG and DHCP, which will not be the case

    1. Tim Carey

      Michail,

      Ok that works as well - we weren't sure of the Infrastructure edge - What would you like to call the single VNF that combines the BNG, AAA and DHCP servers? 

      1. michail salichos

        No preference, how about "Edge VNF"?

        1. David Perez Caparros

          just BNG VNF, Edge VNF may be too abstract

  9. Stavros Kanarakis

    Ok, we will remove all VNFs in the Edge leaving only a BNG VNF.

    Need to decide if we need any properties/attributes for the resources below

    • BNG VNF
    • BNG UNI Connection Point
    • BNG NNI Connection Point

    At least BNG UNI is needed as a CP in order to connect with the OLT NNI via a Transport Connection virtual link. I want to clarify if we also need BNG NNI somehow in our model to hold something actually useful for us in the use case.

    Also, having it as a CP, requires a virtual link somewhere that we can link to.  This virtual link could represent the internet in the conceptual diagram but I think it does not buy us anything for our use case.

    What do you think?

  10. David Perez Caparros

    I agree. Let's use BNG VNF and BNG UNI CP. At least for Dublin, we don't need to model the BNG NNI CP. 


    1. Stavros Kanarakis

      David,

      I have removed all clutter in the conceptual diagram.

      Can you please comment if you think we might need any new properties/attributes for BNG (both VNF and internal CP)?

      1. David Perez Caparros

        Hi Stavros,

        BNG:

        - name

        BNG UNI CP:

        - UNI slot

        - UNI port

        - S-VLAN

        I don't foresee additional properties at the moment.

  11. Bryan Guo

    I have a question about PON-UNI : why does Fiber-ID appear here? we can create service without Fiber-ID.

    Assuming it must be needed,how can we get it?

    1. Stavros Kanarakis

      Fiber-ID is still in question. It has not yet been finalized. Please note that this attribute is assignable, it does not need to exist as an input for the service. Rather, it will be attached to the resource instance at run-time.

      1. David Perez Caparros

        - Fiber-ID should be part of the ODN vLink, but for Dublin we are not adding extra properties to vLinks. I think we can safely remove it from PON UNI CP

        - What is the reasoning for keeping 'OLT name' in both PON UNI CP and PON NNI CP? 

        - we should keep Internet Profile RFS outside HSIA Access RFS, as it can be applied to both Access or HSIA Edge RGS, correct? can we avoid having service type, upSpeed, downSpeed properties in both Access Device RFS and Internet Profile RFS? 

        We need to review and finalize the model during this week's call.

        1. Stavros Kanarakis

          Fiber-ID has been removed for Dublin.

          'OLT Name' exists in both CPs because it will help us identify the proper topology object in AAI (topology discovery will have the terminal-points under a node). We can discuss it further if we have a different view on this.

          We can also further discuss the Internet Profile RFS positioning and relevant properties in our meeting, I agree.