Dear Arc Team,

I take the stand with Srini and support the fact that, there should be a
way for ONAP to save runtime information of VNFs / NS in realtime. However
I believe that, this be the base scope of AAI, not a separate component /
service inside ONAP. I make this statement after analysing AAI. Thanks to
Srini for raising this question, which prompted me to have closer look into
AAI.

I was under the assumption that, AAI is capable of the following :

   1. Persisting customer, cloud, VF & NS information, along with
   relationships.
   2. Track In-Use Vs Available information in realtime.
   3. Persist runtime information of VNF/NS service instance w.r.t to SDC
   Model of VF & NS

My earlier response to Srini was based on my assumption that, AAI can
persist runtime model of VNF-D / NSD. The necessary connectivity & other
parameters could still be part of VNF-D and as long as the information is
in VNF-D, AAI should be able to persist runtime value, thanks to SDC Model
Loader component inside AAI.

On a closer look, I found out that, AAI is not covering point 2 & 3 . If
that's the actual case, then I begin to question the name of this component
- active & available inventory.

We should debate this in broader forum. I'm saying not w.r.t connectivity
params feature asked by Srini, but in the perspective of, persisting basic
runtime information model of a given VNF / NS.

BR,
Viswa

On Tue, Jan 8, 2019 at 5:25 AM Keong Lim <[email protected]> wrote:

> Hi Jonathan,
>
> On Tue, Jan  8, 2019 at 12:47 AM, Jonathan Gathman wrote:
> >   I wanted to let you know that AAF already has a real time Service
> Locator,
> > that includes the following information:
> >
> >    Name:  Hierarchical name of service – (i.e. org.onap.aai)
> >    hostname: FQDN
> >    port: (obvious)
> >    latitude: When more than one instance exists, use with longitude to
> > determine closest service via Great Circle
> >    longitude:  When more than one instance exists, use with latitude to
> > determine closest service via Great Circle
> >
> >   How it might help you:
> >
> >   1.  Current AAF version relies on Public FQDN, which, given K8s, would
> > correlate to multiple K8s Service Implementations
> >   2.  Resilient and Global in scope (Lat/Long allows talking to remote
> service
> > that is closest, when possible, but also allows contacting any service,
> if
> > closer ones are not available)
>
> Using latitude/longitude to calculate distance on the Great Circle is
> interesting, but "closest" in geographic distance is not the same thing as
> "closest" by ping latency or network topology, e.g. the transmission path
> might be via satellite links instead of fibre cables, or the transmission
> path might be going the "long way around" due to lack of direct connections.
>
> Does locator use
> https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Anycast&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=9F3pNUkzjE-2v1eTClkRVakDRN8GH7Bm-wt1lWkxoUyyDORTqf5MxNO_GrMBs0gZ&m=KFSj-dts8mj9RZIJZVSXmx085WWcinEzoACQWhhJVl4&s=IE8TKQjTXAv1nfS4M63R2chAaci0tPQRwsiORfHeqv0&e=
> to select the "closest" server?
>
> Also, if the "closest" server is apparently down / not responsive, how
> much delay will there be until the next server is contacted?
>
> Curious to know the performance characteristics, since each call to an AAI
> API will also result in a call to AAF. There are already concerns amongst
> AAI clients about the performance of the system and there more proposals
> for very high rates of data transfer in/out of AAI.
>
>
> Keong
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14841): https://lists.onap.org/g/onap-discuss/message/14841
Mute This Topic: https://lists.onap.org/mt/28971385/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to