[RM] Chapter 3 - clarification of NFVI v VIM

[tomkivlin]

The diagram in section 3.1 (link) suggests that the "management software" is part of the NFVI. Is this not the VIM, and therefore not within NFVI but alongside it?

In addition the following definition seems confused:

NFVI Management Software: This consists of both the host Operating System (OS) responsible for managing the physical infrastructure resources as well as the virtualization/containerization technology which, on request, dynamically allocates hardware components and exposes them as virtual resources.

I would propose that the word "Management" is removed from the definition above so it reads "NFVI Software" - this would match later use of the term in the profiles sections.

In addition, section 3.3 (link) describes what I'd see as a VIM, but this doesn't match the description in section 3.1.

In summary, I would propose the following changes:

1. Change the diagram in 3.1 to show NFVI Management as being separate to NFVI
2. Remove the word "Management" from the definition in section 3.1
3. Add a section (3.5) that describes the "NFVI Software" component (this isn't included yet)
4. Change the title and wording of section 3.3 to refer to VIM (or another similar term that makes it clear it's the management of the virtual and physical resources)

[tomkivlin]

(PS I'm happy to make the changes if the WSLs are ok with the proposals)

[ulikleber]

Also the definition of the NFVI software could be improved.

[pgoyal01]

@tomkivlin W.r.t. "The diagram in section 3.1 (link) suggests that the "management software" is part of the NFVI. Is this not the VIM, and therefore not within NFVI but alongside it?" @BernardTsai-DT can better explain this but here is my half-cents.

The management software includes the VIM but is not only the VIM. The reference model tries not to get into the "implementation" (how the required functions are accomplished) and instead presents a high level "what" (or "black box") view. It does not dictate that the management software is the VIM (or more correctly VIM + Virtualisation software).

Maybe use of "NFVI" in this context is wrong or requires a statement clarifying what NFVI in the RM encompasses.

The term "virtual resources" could also be clarified to mean "virtual machines or containers (virtual or bare--metal)."

[tomkivlin]

The term "virtual resources" could also be clarified to mean "virtual machines or containers (virtual or bare--metal)."

I think if we want those resources to be bare metal, virtualised or containers then perhaps "logical resources" is a clearer term to use?

[tomkivlin]

Maybe use of "NFVI" in this context is wrong or requires a statement clarifying what NFVI in the RM encompasses.

Yes that would be helpful, if it isn't the same as ETSI NFVI.

[pgoyal01]

@tomkivlin "..perhaps "logical resources" is a clearer term to use" -- I know at one time during early stages the term was considered but there were objections: @BernardTsai-DT may be bale to shed more light.

[kedmison]

The use of Ironic came up in the context of RA01 meeting today, and it was observed that we have not actually specified that bare metal servers is a service that the RM offers (despite the possibility that Ironic offers) The suggestion in the RA01 meeting was that, for now, the use of Ironic be explicitly noted as limited to the use of RA02 for bare metal Kubernetes environments. I would thus not introduce the use of 'bare metal resources' into the list of what is offered by RM as a provisionable/logical resource, until such time as that decision is explicitly taken and endorsed.

[pgoyal01]

@kedmison as you noted, " the use of Ironic be explicitly noted as limited to the use of RA02 for bare metal Kubernetes environments" is only a suggestion. I think we still need discussion and some solid rationale (including value) as to why we should create such a restriction.

[kedmison]

@pgoyal01 I would suggest that if bare metal guests are not explicitly offered/considered in the reference model, their use should not be introduced by the RA... which is why I was suggesting that the RA create a restriction until such time as a discussion and decision is taken in the RM context as to whether to support bare metal guests.
If you agree, I can create an RM issue to host this discussion.

[markshostak]

@kedmison Kelvin, I'm ok with your creating an issue and driving the bare metal discussion (this is not the first time it's come up), but let's put some parameters around it. 1) Does it belong in the RM or the RA? I'm on the fence, as one architecture may choose to support it, while another may not 2) Assuming it does fall under RM purview, does it need to be addressed explicitly? Consider, just because something isn't explicitly codified in the RM, doesn't mean it's prohibited.

With answers to those 2 questions, we can open an issue. Thx, -Mark

[markshostak]

@BernardTsai-DT Hi Bernard, Can you comment on Tom's original question, pls? This area used to be much more explicit, so your insight would be helpful. Danke, -Mark

[BernardTsai-DT]

The diagram in section 3.1 (link) suggests that the "management software" is part of the NFVI. Is this not the VIM, and therefore not within NFVI but alongside it?

In addition the following definition seems confused:

NFVI Management Software: This consists of both the host Operating System (OS) responsible for managing the physical infrastructure resources as well as the virtualization/containerization technology which, on request, dynamically allocates hardware components and exposes them as virtual resources.

I would propose that the word "Management" is removed from the definition above so it reads "NFVI Software" - this would match later use of the term in the profiles sections.

In addition, section 3.3 (link) describes what I'd see as a VIM, but this doesn't match the description in section 3.1.

In summary, I would propose the following changes:

1. Change the diagram in 3.1 to show NFVI Management as being separate to NFVI

2. Remove the word "Management" from the definition in section 3.1

3. Add a section (3.5) that describes the "NFVI Software" component (this isn't included yet)

4. Change the title and wording of section 3.3 to refer to VIM (or another similar term that makes it clear it's the management of the virtual and physical resources)

I have deliberately not used the term VIM since I have a difficulty in describing a VIM independently from a NFVI since when looking at real implementations of cloud platforms you will see that you can not easily exchange a VIM since BIOS settings, OS of the host systems and network equipements as well as the actual management software are tightly integrated in order to provide the services of a virtualization/cloud platform.

[kedmison]

let's put some parameters around [bare-metal requests].

1. Does it belong in the RM or the RA? I'm on the fence, as one architecture may choose to support it, while another may not

The RM currently documents the profiles and sizes that a VNF vendor can expect from a CNTT architecture. RM 4.2.1.1 talks about the sizes of pre-defined compute flavours, and if we officially support bare metal then I would think that a bare-metal variant would be listed here.

2. Assuming it does fall under RM purview, does it need to be addressed explicitly? Consider, just because something isn't explicitly codified in the RM, doesn't mean it's prohibited.

Bare metal gets very interesting very fast... a VNFC winds up exposed to the actual underlying hardware choices (literal CPU model, core counts, NIC type, locally-attached storage, PCI bus, NUMA nodes, etc) and the VNFC being used has to have support for the NIC type, storage type, etc. Thus, at a minimum, there should be documentation on what the NIC type is (so a VNFC can ensure compatibility). I think it needs to be made explicit in order to avoid late-discovery of incompatibilities, but I'm open to whether it's in the RM or RA.

[ASawwaf]

Maybe use of "NFVI" in this context is wrong or requires a statement clarifying what NFVI in the RM encompasses.

Yes that would be helpful, if it isn't the same as ETSI NFVI.

@tomkivlin , NFVI Software is not ETSI terminology, So i preferred not to use it as it will lead of conflict , what did you think ?

[tomkivlin]

I have deliberately not used the term VIM since I have a difficulty in describing a VIM independently from a NFVI since when looking at real implementations of cloud platforms you will see that you can not easily exchange a VIM since BIOS settings, OS of the host systems and network equipements as well as the actual management software are tightly integrated in order to provide the services of a virtualization/cloud platform.

@BernardTsai-DT ok, yes that makes sense, I can understand the rationale. Looking back over this, if we leave the diagram as-is, the issue is then just the wording in 3.1 and 3.3. In 3.1, we have:

"NFVI Management Software: This consists of both the host Operating System (OS) responsible for managing the physical infrastructure resources as well as the virtualization/containerization technology which, on request, dynamically allocates hardware components and exposes them as virtual resources.

To me, the above reads like a description of the software elements of an NFVI, whereas in 3.3 we have something that is different - much more akin to the VIM. The two don't seem to be talking about the same thing - that's the crux of the issue I've raised.

So, if we ignore, for now, the discussion above about bare metal (separate issue needed for that I think), and we ignore the diagram in 3.1, we're left with the question of whether there is a terminology mismatch between sections 3.1 and 3.3 and what to do about it. I feel there are two options:

1. We change the wording in 3.1 to match the content in 3.3 - so we remove the content I've quoted in this comment and replace with content that relates to the management capabilities, or
2. We change the title of the existing wording in 3.1 to be "NFVI Software" (@ASawwaf - NFVI Software is used elsewhere in the RM to define the profiles, so whilst I get it's not an ETSI thing, it won't be unique to this chapter).

My vote is for the first, as NFVI Software isn't used in the diagram, so it would bear no relation to an element of the diagram. Thoughts? I'm happy to prepare a PR to continue the discussion with real changes.

[ASawwaf]

@tomkivlin , thanks , that you figure it out, I returned back to RM CH3 , from my POV NFVI Manmanget Software is actually the VIM , all listed function is VIM tasks, so I think we need to redefine it in RM @BernardTsai-DT @markshostak @tomkivlin @rabi-abdel What did you think ?

[rabi-abdel]

@markshostak is it possible please to identify individual to create a PR for the modification needed to Chapter 3? I suggest either @BernardTsai-DT or @tomkivlin to have a stab at this and create a PR for it.

[markshostak]

@tomkivlin Hi Tom, By all means... Thx, -Mark

[pgoyal01]

The change made by @tomkivlin necessitates a change in RM 3.3 NFVI Management Software, and also in RA-1 Chapters 3 and 4. I opened 3 issues( #716 , #717 and #718) for the same.

[tomkivlin]

@pgoyal01 ah, I was trying to align what I'd done in #715 to the description in RM 3.3, so if I've not done that, I perhaps need to update my PR rather than progressing #716. What do you see as the difference between the wording in #715 and RM 3.3?

[pgoyal01]

@tomkivlin I think the section RM 3.3 may have already been misaligned with the contents of RM 3.3.

In RA-1 Ch 3 and 4, it was as simple change from "NFVI Management Software (VIM)" to "Virtualised Infrastructure Manager (VIM)."

In case of RM 3.3 the description is not to the NFVI Management Software but to only the "Additional software is responsible for the management of logical constructs such as tenants, tenant workloads, resource catalogues, identities, access controls, security policies, etc."

At least 2 courses of action:

1. in the NFVI Management Software description of RM 3.1, after "Additional software is responsible for the management of ... policies, etc." add that this "additional software is referred to as the Virtual Resources Manager" (or some other suitable term). Change the Title of RM 3.3 to Virtual Resources Manager (or alternate) and add a sentence somewhere in 3.3 to indicate that the VRM can be a VIM or a combination of VIM and other software.
2. Modify RM 3.3 to include some content on the Operating System and Virtualisation / containerisation technology

This can be done in PR #715 and the issue #716 can be indicated to be fixed by PR#715 also.

[tomkivlin]

@pgoyal01 I'm completely confused!

I think the section RM 3.3 may have already been misaligned with the contents of RM 3.3

Do you mean RM 3.3 both times?? Confused otherwise.

In RA-1 Ch 3 and 4, it was as simple change from "NFVI Management Software (VIM)" to "Virtualised Infrastructure Manager (VIM)."

But @BernardTsai-DT's point was that NFVI Management Software is not only the VIM but also the software components of (within) the infra that manage physical and virtual resources.

Regarding your first idea, the point is that the bullet describing the box in the diagram is the same as section 3.3, it's not that 3.3 is a subset of the box in the diagram and the description. That's why I'm trying to align them.

Your second idea is sensible, I will add that in and then yes i think #716 should be covered.