NSO Service Ownership begrijpen

Inleiding

In dit document worden het algemene concept, de algemene valkuilen en de oplossingen voor serviceeigendom in Cisco® Network Service Orchestrator (NSO) beschreven.

Voorwaarden

Vereisten

Dit document is van toepassing op alle momenteel beschikbare NSO-versies, inclusief NSO 6. Het beschreven gedrag is alleen van toepassing op NSO-instellingen die gebruikmaken van een combinatie van services en niet-serviceconfiguratie. Hoewel de specifieke opdrachten die in voorbeelden in dit document worden gebruikt, alleen van toepassing zijn op het gebruikte Network Element Driver (NED), is de onderliggende logica van toepassing op elk apparaat dat door NSO wordt beheerd.

Gebruikte componenten

• NSO 6.1.6
• NED: test-ned 1.0, een op maat gemaakte netconf NED met dit yang-model.

NED yang model:
module test-ned{
	namespace "http://example.org/ned/service-ownership";
	prefix ownership;
	import ietf-inet-types{ prefix inet;}

	list interface {
		key interface-name;
		leaf interface-name{
			type string;
		}

		leaf ip-address {
			type inet:ipv4-address;
		}
		
		leaf description {
			type string;
		}
	}
}

• Service: voorbeeld-service 1.0: een op maat gemaakte service met dit yang-model en -sjabloon

module example-service {
  namespace "http://com/example/exampleservice";
  prefix example-service;

  import ietf-inet-types {
    prefix inet;
  }
  import tailf-ncs {
    prefix ncs;
  }

  list example-service {
    key name;

    uses ncs:service-data;
    ncs:servicepoint "example-service";

    leaf name {
      type string;
    }
    leaf-list device {
      type leafref {
        path "/ncs:devices/ncs:device/ncs:name";
      }
    }
    leaf ipaddress {
      type inet:ipv4-address;
    }
  }
}


  
    
      {/device}
      
        
          FE1
          {/ipaddress}
        
      
    
  	

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

grondbeginselen

Het doel van service-eigendom is om NSO in staat te stellen te volgen welke configuratie is gerelateerd aan welke service. Wanneer u een service verwijdert, moet de NSO de bijbehorende configuratie verwijderen en gebruikt het service-eigendom om te bepalen welke configuratie moet worden verwijderd. Wanneer de configuratie eigendom is van meer dan één service, verwijdert het verwijderen van een van de services eenvoudig die eigendomsreferentie; De configuratie zelf blijft in de NSO-database (CDB) en op de apparaten van het netwerk.

Eigendom wordt weergegeven door middel van kortingen en backpointers. Een overzicht geeft aan hoeveel entiteiten dat deel van de configuratie bezitten. Een hertelling is gelijk aan het aantal serviceexemplaren plus 1 als de configuratie ook eigendom is van het apparaat. Een backpointer toont het pad van deze service-instanties. Er is geen backpointer om "apparaat eigendom" weer te geven. Backpointers worden alleen weergegeven in CDB voor lijsten en containers. Individuele bladeren tonen niet hun backpointers, maar ze erven van hun ouder.

Apparaat in eigendom

Naast dat de configuratie eigendom is van een service, kan deze ook eigendom zijn van het apparaat. Dit wordt ook wel "eigendom van het apparaat" of "niet-eigendom van de service" genoemd. Hoewel in dit document gebruik wordt gemaakt van 'apparaateigendom', moet u er rekening mee houden dat, hoewel dit gemakkelijker te begrijpen is, niet-serviceeigendom geen apparaten hoeft te omvatten. LSA-opstellingen of gestapelde services kunnen zonder apparaten een configuratie hebben die niet in het bezit is van de service.

Configuratie is eigendom van het apparaat wanneer de configuratie aan CDB wordt toegevoegd zonder gebruik te maken van een service-implementatie, maar in plaats daarvan een methode zoals synchroniseren vanaf, samenvoegen van taken of ncs_cli gebruikt om de configuratie in te stellen. Wanneer een service-exemplaar eigenaar wordt van een configuratie die al eigendom was van het apparaat, wordt de korting ingesteld op 2 om het gedeelde eigendom weer te geven. Wanneer de service-instantie wordt verwijderd, wordt de configuratie niet verwijderd, ondanks het feit dat slechts één service-instantie eigenaar is van de configuratie voordat deze wordt verwijderd. Bovendien voegt de configuratie die eigendom is van het apparaat een label voor "oorspronkelijke waarde" toe. Als een service-exemplaar de configuratie van het apparaat overschrijft en de service later wordt verwijderd, wordt de oorspronkelijke waarde hersteld.

Apparaateigendom wordt alleen toegewezen als de configuratie niet al in CDB bestond wanneer u deze toevoegt via niet-servicemiddelen. Configuratie die eigendom is van de service wordt geen eigendom van het apparaat na synchronisatie van. Maar configuratie die eigendom is van het apparaat wordt zowel eigendom van het apparaat als van de service als u een service bovenop implementeert.

Eigenaarschap in actie

Showcase: alleen eigendom van service

Wanneer u een service implementeert terwijl de doelconfiguratie leeg is, maakt de service de configuratie en wordt deze eigendom van de service. De gebruiker kan het eigendom controleren door een show-running-config commando te gebruiken en | display service-meta-data toe te voegen. Hoewel dit niet verplicht is, wordt aanbevolen om ook | display XML toe te voegen aangezien de standaard CLI-stijluitvoer niet altijd correct weergeeft hoe de gegevens in CDB worden gemodelleerd.

admin@ncs(config)# do show running-config devices device mydevice0 config
% No entries found.
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.1
admin@ncs(config-example-service-s1)# commit dry-run
cli {
    local-node {
        data  devices {
                  device mydevice0 {
                      config {
             +            interface FE1 {
             +                ip-address 192.0.2.1;
             +            }
                      }
                  }
              }
             +example-service s1 {
             +    device [ mydevice0 ];
             +    ipaddress 192.0.2.1;
             +}
    }
}
admin@ncs(config-example-service-s1)# commit
Commit complete.
admin@ncs(config-example-service-s1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.1
        
      
    
  

Als u bovendien een tweede service-exemplaar toevoegt dat op dezelfde configuratie is gericht, wordt het eigendom gedeeld door de twee service-instanties. De hertelling is 2 en er zijn 2 backpointers.

admin@ncs(config-example-service-s1)# example-service s2 device mydevice0 ipaddress 192.0.2.2
admin@ncs(config-example-service-s2)# commit dry-run
cli {
    local-node {
        data  devices {
                  device mydevice0 {
                      config {
                          interface FE1 {
             -                ip-address 192.0.2.1;
             +                ip-address 192.0.2.2;
                          }
                      }
                  }
              }
             +example-service s2 {
             +    device [ mydevice0 ];
             +    ipaddress 192.0.2.2;
             +}
    }
}
admin@ncs(config-example-service-s2)# commit
Commit complete.
admin@ncs(config-example-service-s2)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.2
        
      
    
  

Showcase: alleen apparaat in eigendom

Wanneer u gegevens aan CDB toevoegt met behulp van load merge, ncs_cli of sync-from, zonder het gebruik van een service, worden deze gegevens eigendom van het apparaat. De hertelling en backpointer zijn verborgen.

admin@ncs(config)# no example-service
admin@ncs(config)# commit
Commit complete.
admin@ncs(config)# do show running-config devices device mydevice0 config
% No entries found.
admin@ncs(config)# load merge merge-config.xml
Loading.
386 bytes parsed in 0.00 sec (137.22 KiB/sec)
admin@ncs(config)# commit dry-run
cli {
    local-node {
        data  devices {
                  device mydevice0 {
                      config {
             +            interface FE1 {
             +                ip-address 192.0.2.1;
             +            }
                      }
                  }
              }
    }
}
admin@ncs(config)# commit
Commit complete.
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.1
        
      
    
  

Showcase: eigendom van apparaat + eigendom van service

Dit voorbeeld laat zien hoe u eenvoudig een gecombineerd apparaat- en serviceeigendom kunt maken met behulp van een service en synchronisatie-van.

U implementeert de service en verwijdert de service vervolgens alleen in CDB met behulp van Geen netwerk vastleggen. Op deze manier bestaat de configuratie nog steeds op het eindapparaat. Wanneer u synchronisatie vanuit uitvoert, wordt de configuratie weer toegevoegd in CDB, maar het is eigendom van het apparaat in plaats van eigendom van de service. Onthoud dat running-config bij uitvoering in NSO u CDB-gegevens weergeeft, geen gegevens die momenteel op de apparaten staan.

admin@ncs(config)# no devices device mydevice0 config
admin@ncs(config)# commit
admin@ncs(config)# do show running-config devices device mydevice0 config
% No entries found.
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.1
admin@ncs(config-example-service-s1)# commit
admin@ncs(config-example-service-s1)# top
admin@ncs(config)# no example-service s1
admin@ncs(config)# commit no-networking
Commit complete.
admin@ncs(config)# devices device mydevice0 sync-from
result true
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.1
        
      
    
  

Na synchronisatie-van is de configuratie alleen eigendom van het apparaat. Refcounter is verborgen. Wanneer u de service opnieuw implementeert, wordt de hertelling 2, maar geeft backpointer slechts één service-instantie weer. De tweede refcounter staat voor apparaatbezit. Dezelfde regels zijn van toepassing als bij gedeelde service-eigendom, als de service wordt verwijderd, wordt de configuratie niet verwijderd omdat het apparaat ook gedeeltelijk eigenaar is van de configuratie.  Bovendien, als de servicegegevens niet overeenkomen met de "oorspronkelijke waarde" zoals opgeslagen in de service-meta-gegevens, keert NSO de waarde terug naar de "oorspronkelijke waarde" als de service wordt verwijderd.

admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.2
admin@ncs(config-example-service-s1)# commit dry-run
cli {
    local-node {
        data  devices {
                  device mydevice0 {
                      config {
                          interface FE1 {
             -                ip-address 192.0.2.1;
             +                ip-address 192.0.2.2;
                          }
                      }
                  }
              }
             +example-service s1 {
             +    device [ mydevice0 ];
             +    ipaddress 192.0.2.2;
             +}
    }
}
admin@ncs(config-example-service-s1)# commit
Commit complete.
admin@ncs(config-example-service-s1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.2
        
      
    
  

verzoenen

Syntaxis: <path-to-service instance> Reconcile opnieuw implementeren

Optionele vlaggen: { keep-non-service-config } dry-run { outformat native }

Doel

Het kerndoel van de verzoeningsfunctionaliteit is om gebruikers in staat te stellen zich te ontdoen van ongewenste apparaateigendom en eigendom volledig over te dragen aan de services. Wanneer gebruikers al een functionerend netwerk hebben en ze proberen het eigendom over te dragen aan NSO, introduceren ze meestal eerst de configuratie door middel van synchronisatie van bewerkingen. Zodra CDB alle netwerkconfiguratie heeft, implementeert de gebruiker service-instanties bovenop de bestaande configuratie. Op dit moment is de configuratie nog steeds eigendom van het apparaat, waardoor de service de configuratie kan verwijderen. Wanneer gebruikers hun services volledig eigendom van de configuratie willen geven, kunnen ze de compatibele functionaliteit gebruiken die 3 dingen doet.

1) 1) Eigendom overdragen aan diensten

2) 2) Verwijder de "originele waarde" vlaggen

3) 3) Eigendom van de dienst corrigeren

Eigendom overdragen aan services

Reconcile evalueert alle config die eigendom is van een service, en als het een config vindt die eigendom is van zowel deze service als het apparaat of anderszins eigendom is van een andere service, verwijdert het dit apparaateigendom, waardoor de service de exclusieve eigenaar wordt. Vermindering van de korting met 1.

Opmerking: als 2 services een stuk configuratie bezitten en die configuratie is ook niet in het bezit van de service, is de korting 3. Door een van de services met elkaar te combineren, wordt dat niet-serviceeigendom verwijderd, waardoor de korting wordt verlaagd tot 2 om beide services weer te geven.

Originele waardevlaggen verwijderen

Wanneer een service wordt geïmplementeerd en gegevens die niet in het bezit van een service zijn, overschrijft, wordt de hertelling 2 en voegt de NSO een tag "oorspronkelijke waarde" toe. Als de service-instantie ooit wordt verwijderd, probeert NSO terug te keren naar de oorspronkelijke waarde die vóór de service bestond.

Tijdens de reconciliatie wordt niet alleen de korting verlaagd, maar wordt ook de oorspronkelijke waarde verwijderd. Als u de service nu verwijdert, wordt die waarde leeg gemaakt of gewijzigd in een standaardwaarde zoals gedefinieerd door het yang-model.

Eigendom van service corrigeren

In sommige situaties kan eigendom verkeerd worden toegewezen. Ofwel de configuratie die eigendom is van het apparaat is ten onrechte eigendom van de service, ofwel de configuratie is ten onrechte eigendom van zowel de service als het apparaat, terwijl de verwachting is dat deze alleen eigendom is van de service.  Reconcile kan deze verkeerde uitlijning corrigeren. Dit is belangrijk om problemen te voorkomen waarbij de service de configuratie verwijdert die geen eigendom is van de service.

Afstemmen als opnieuw implementeren

Reconcile is een subfunctie van service re-deploy. Als een service niet synchroon loopt met de CDB, voert de verzoenbewerking naast het uitvoeren van de verzoenfunctie ook een herimplementatie uit.

Innerlijke werking verzoenen

Hoewel de exacte details van hoe Reconcile werkt alleen bekend zijn bij de ontwikkelaars, biedt dit document een vereenvoudigd begrip:

1) NSO corrigeert eigendom van diensten

2) NSO verwijdert alle configuratie die eigendom is van deze service-instantie van CDB, zelfs als deze ook eigendom is van andere services of eigendom is van het apparaat

3) NSO herimplementeert de service-instantie

4) NSO herstelt servicerestituties en backpointers van andere services

Problemen met betrekking tot Service Ownership

Reconcile mislukt

In het geval dat "re-deploy" werkt, maar "re-deploy reconcile" mislukt: dit kan erop wijzen dat u een conflict hebt ondervonden tussen hun service-ontwerp en de manier waarop de verzoeningsfunctie werkt.

Het probleem komt voort uit de servicecode die probeert de configuratie van de CDB te lezen die de service vervolgens implementeert. U kunt deze service alleen implementeren omdat de configuratie al gedeeltelijk bestaat in CDB voordat deze wordt geïmplementeerd. Maar tijdens de reconciliatie verwijdert NSO tijdelijk alle configuratie die eigendom is van deze service, inclusief de configuratie die de service probeert te lezen tijdens de herimplementatie van de service in de volgende stap. Dit resulteert meestal in een Java- of Python-fout die het niet lezen van de gegevens meldt.

Service verwijdert configuratie die geen eigendom is van service

In dit scenario ziet u dat de NSO de configuratie verwijdert die geen eigendom is van de service tijdens het verwijderen of opnieuw implementeren van de service. De reden hiervoor is dat de service-instantie de oorspronkelijke configuratie heeft gemaakt en deze in eigendom heeft, en dat u later handmatig (via ncs_cli, synchronisatie-vanuit of een andere methode) een deel van de configuratie hebt toegevoegd in een container of lijst die eigendom is van de service.

Dit nieuwe stuk configuratie wordt niet verondersteld eigendom te zijn van de service, maar omdat de service het volledige eigendom van de container of lijst heeft, is de service indirect eigenaar.

De manier om dit op te lossen is door Reconcile { keep-non-service-config } opnieuw te implementeren om het eigendom van de service te corrigeren. Wanneer u deze verbinding tot stand brengt, wordt de hertelling van de container of lijst verhoogd om aan te geven dat deze container of lijst zowel ondergeschikte als niet-onderhoudsknooppunten heeft. In de bovenliggende node hebben alleen de knooppunten die eigendom zijn van de service een hertelling en backpointer.

Showcase: service verwijdert configuratie die geen eigendom is van service

Beginnend met één service-instantie die met volledige eigendom is geïmplementeerd, voegt u handmatig een beschrijving toe aan de interface met behulp van ncs_cli.

admin@ncs(config-example-service-s1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.1
        
      
    
  

admin@ncs(config-example-service-s1)# top
admin@ncs(config)# devices device mydevice0 config interface FE1 description "This is an example description"
admin@ncs(config-interface-FE1)# commit
Commit complete.
admin@ncs(config-interface-FE1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.1
          This is an example description
        
      
    
  

Merk op dat de korting op <interface> 1 blijft, ook al is de configuratie die eigendom is van het apparaat toegevoegd. Wanneer u de service-instantie probeert te verwijderen, wordt de beschrijving ook verwijderd, hoewel deze geen deel mag uitmaken van de service-instantie. Om dit te voorkomen, kunt u de opdracht Reconcile uitvoeren.

admin@ncs(config-interface-FE1)# top
admin@ncs(config)# no example-service s1
admin@ncs(config)# commit dry-run
cli {
    local-node {
        data  devices {
                  device mydevice0 {
                      config {
             -            interface FE1 {
             -                ip-address 192.0.2.1;
             -                description "This is an example description";
             -            }
                      }
                  }
              }
             -example-service s1 {
             -    device [ mydevice0 ];
             -    ipaddress 192.0.2.1;
             -}
    }
}
admin@ncs(config)# abort
admin@ncs# config
Entering configuration mode terminal
admin@ncs(config)# example-service s1 re-deploy reconcile { keep-non-service-config }
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.1
          This is an example description
        
      
    
  

Na de reconciliatie is de recount voor de lijstinterface verhoogd naar 2. Ondertussen is het tellen van het IP-adres van het blad 1 gebleven. De vermelding in de lijst "interface FE1" bevat zowel gegevens die eigendom zijn van de dienst als gegevens die niet eigendom zijn van de dienst. Door Reconcile te gebruiken, evalueert de NSO het eigendom opnieuw en wijst hij de terugbetalingen dienovereenkomstig toe. Verwijdering is nu alleen gericht op de gebieden die volledig eigendom zijn van de service-instantie. Noch de beschrijving, noch de vermelding in de lijst wordt verwijderd.

admin@ncs(config)# no example-service s1
admin@ncs(config)# commit dry-run
cli {
    local-node {
        data  devices {
                  device mydevice0 {
                      config {
                          interface FE1 {
             -                ip-address 192.0.2.1;
                          }
                      }
                  }
              }
             -example-service s1 {
             -    device [ mydevice0 ];
             -    ipaddress 192.0.2.1;
             -}
    }
}

Keep-non-service-config vs Discard-non-service-config

Gebruikers begrijpen soms het gebruik van niet-serviceconfig.

In het voorbeeld van Reconcile werd "keep-non-service-config" gebruikt. Als er weggegooid wordt ziet het er als volgt uit:

admin@ncs(config)# example-service s1 re-deploy reconcile { discard-non-service-config } dry-run
cli {
    local-node {
        data  devices {
                   device mydevice0 {
                       config {
                           interface FE1 {
              -                description "This is an example description";
                           }
                       }
                   }
               }

    }
}

De standaardwaarde is "keep-non-service-config". Als geen van beide opties is gedefinieerd, houdt de NSO zich standaard aan. Weggooien wordt zelden gebruikt, omdat de meeste gebruikers liever behouden wat op hun netwerk staat, zelfs als het niet wordt beheerd door NSO. Reconcile { discard-non-service-config } dry-run kan worden gebruikt om uit te zoeken welke gegevenspunten in CDB bestaan die geen deel uitmaken van de serviceconfig, maar zouden worden verwijderd als de service werd verwijderd of opnieuw wordt geïmplementeerd.

Geen creatie

Een alternatief voor het gebruik van re-deploy om het eigendom van de service te corrigeren wanneer deze wordt gemengd met gegevens die niet in het bezit van de service zijn, is het voorkomen van het conflict met behulp van de nocreate-tag.

Dit is een tag die kan worden gebruikt in uw XML-servicesjabloon. In de documentatie staat: "niet maken: de samenvoeging heeft alleen invloed op configuratie-items die al in de sjabloon bestaan. Het maakt nooit de configuratie met deze tag. Het wijzigt alleen bestaande configuratiestructuren."

Het gebruik van deze tag heeft een interessant neveneffect: omdat de service de node niet maakt, neemt deze geen eigendom van de node.

Dit wordt vaak gebruikt om situaties te voorkomen waarin NSO probeert configuratie te verwijderen die het apparaat niet toestaat te worden verwijderd.

Merk op dat deze tag wordt overgeërfd door onderliggende knooppunten, dit betekent dat als u de nocreate-tag toevoegt aan de interface, deze ook van toepassing is op alle knooppunten in die interface, tenzij u ze markeert met een andere tag, zoals samenvoegen."

Voeg een tag noCreate toe aan de servicesjabloon. Als interface FE1 niet bestaat, wordt er niets geconfigureerd.

  
    
      {/device}
      
        
          FE1
          {/ipaddress}
        
      
    
  

Het pakket opnieuw compileren en laden en vervolgens testen.

admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
No entries found.
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.1
admin@ncs(config-example-service-s1)# commit dry-run
cli {
    local-node {
        data +example-service s1 {
             +    device [ mydevice0 ];
             +    ipaddress 192.0.2.1;
             +}
    }
}

Hoewel dezelfde parameters zijn gedefinieerd als voorheen, worden de interface of een onderliggende configuratie niet gemaakt in de apparaatconfiguratie.

samenvoegen

Voeg een merge tag toe aan de configuratie binnen de interface. Voeg geen tag toe aan "interface-naam" omdat dit de sleutel is van de lijstinterface. De sleutel moet altijd het gedrag van de lijst kunnen erven. Het pakket opnieuw compileren en laden.

  
    
      {/device}
      
        
          FE1
          {/ipaddress}
        
      
    
  

De interface FE1 handmatig configureren voordat u de service implementeert.

admin@ncs(config)# no example-service
admin@ncs(config)# commit
admin@ncs(config)# do show running-config devices device mydevice0 config | display service-meta-data | display xml
No entries found.
admin@ncs(config)# devices device mydevice0 config interface FE1
admin@ncs(config-interface-FE1)# commit dry-run
cli {
    local-node {
        data  devices {
                  device mydevice0 {
                      config {
             +            interface FE1 {
             +            }
                      }
                  }
              }
    }
}
admin@ncs(config-interface-FE1)# commit
Commit complete.
admin@ncs(config-interface-FE1)# top
admin@ncs(config)# example-service s1 device mydevice0 ipaddress 192.0.2.1
admin@ncs(config-example-service-s1)# commit dry-run
cli {
    local-node {
        data  devices {
                  device mydevice0 {
                      config {
                          interface FE1 {
             +                ip-address 192.0.2.1;
                          }
                      }
                  }
              }
             +example-service s1 {
             +    device [ mydevice0 ];
             +    ipaddress 192.0.2.1;
             +}
    }
}
admin@ncs(config-example-service-s1)# commit
Commit complete.
admin@ncs(config-example-service-s1)# do show running-config devices device mydevice0 config | display service-meta-data | display xml

  
    
      mydevice0
      
        
          FE1
          192.0.2.1
        
      
    
  

Interface heeft een verborgen refcount 1: interface werd geïmplementeerd met behulp van ncs_cli, maar het heeft een no-create-tag in het servicepakket; de service heeft geen eigendom genomen. Het is eigendom van het apparaat.

Primair heeft korting 1: het is alleen eigendom van de service

Als de service-instantie wordt verwijderd, wordt alleen het IP-adres verwijderd, omdat dat het enige deel is dat volledig eigendom is van de service.