interface - bidirectional and asynchronous words too implementation specific

[kiranmak]

Issue: Line 677 onwards, the definition of NBI and SBI has implementation specific async and bidirectional words. Now a new text is suggested. Please review new text.

TSC Northbound Interface (NBI): The TSC Northbound Interface is a bidirectional and an asynchronous interface between a higher level system, e.g. 'E2E network slice orchestrator' and the 'Transport slice controller'. It is a technology agnostic interface. ---- alternate text --- TSC Northbound Interface (NBI): is an interface between a higher level system, e.g. 'E2E network slice orchestrator' and the 'Transport slice controller'. It is a technology agnostic interface. Over this NBI, slice characteristics and other requirements can be informed to TSC and current state of a transport slice can be retrieved. --xx-- TSC Southbound Interface (SBI): The TSC Southbound interface is a bidirectional and an asynchronous interface between 'Transport slice controller' and network controller(s). These interfaces are technology-specific and can utilize many of the existing data models such as L2SM, L3SM, VPN, etc. ----- alternate text ----- TSC Southbound Interface (SBI): is an interface between 'Transport slice controller' and network controller(s). These interfaces are technology-specific and can utilize many of the existing data models such as L2SM, L3SM, VPN, etc. TSC may request network resources or retrieval of their current state.

[sergiobelotti]

While I have no problem with both NBI and SBI definiton , I'm a bit confused on the fact the examples of models reported i.e. L2SM, L3SM , following what RFC8309 has defined, are all customer-service models , or for VPN ( I guess you consider here draft-ietf-bess-l2vpn-yang) a service-delivery model. Both type of services are defined as "technology agnostic" in RFC 8309 and that would contrast with the definition.

[ewgray2k]

Hi Kiran.

Some suggestions below…

There should probably be a “-02” version of “draft-nsdt-teas-transport-slice-definition” at the GitHub repository, so that we can see a latest version. This is relevant because I assume that the “-01” version posted to the ID repository is changing, and we should use comments on the latest updated version.

I would suggest some minor changes to the definition for SBI, along the following lines:

• Change “an interface interface between” to “a logical interface that may exist between.”

Note that this requires a change to the definition of “Transport Network Controller” along similar lines, before this is complete - i.e. - something like this:

"Transport Network Controller (or network controller” is some form of network infrastructure controller that offers network resources to a higher level entity (or management system) to be used for network connectivity and PDU delivery guarantees needed to (for example) realize a particular transport slice."

I say “some form” because - in theory at least - the “infrastructure controller” could be anything between a “super-manager” (of subordinate management systems) to a hardware adaptation layer on a device on which a controller (or part of a distributed controller) is colocated.

The following line:

  "These are existing network controllers for a specific
  technology to realize transport slices in its network."

• may be omitted as whether or not they currently exist is not absolutely established, and - where they do currently exist - they are (or were) probably not originally intended exclusively for “[realizing] transport slices.” At the very least, this should be changed to read along the lines of:

  “These may be existing g network controllers associated with any set of specific technologies that may be adapted to the function of realizing transport slices in a network."

TSC Southbound Interface (SBI): The TSC Southbound interface is a bidirectional and an asynchronous interface between 'Transport slice controller' and network controller(s). These interfaces are technology-specific and can utilize many of the existing data models such as L2SM, L3SM, VPN, etc. ----- alternate text ----- TSC Southbound Interface (SBI): is an interface between 'Transport slice controller' and network controller(s). These interfaces are technology-specific and can utilize many of the existing data models such as L2SM, L3SM, VPN, etc. TSC may request network resources or retrieval of their current state.

[ewgray2k]

Sergio,

First of all, RFC 8309 uses "technology agnostic" in a highly qualified fashion, because certain aspects of a service are often very specific to a given technology.  In most cases, these technology specific aspects of a service are a large part of the defined network interface (User Network Interface [UNI] or Network-Network Interface [NNI]).

Specific VPN choices (L2VPN, L3VPN, etc.) are options that a service provider may choose in implementing a higher level service model (as illustrated in Figure 4 of RFC 8309).  The idea is that - to the extent possible - there is no more than a minimal predetermined relationship between any technology associated with a service and the technology used to provide it.

— Eric

On Mar 16, 2020, at 4:27 PM, sergiobelotti notifications@github.com wrote:

While I have no problem with both NBI and SBI definiton , I'm a bit confused on the fact the examples of models reported i.e. L2SM, L3SM , following what RFC8309 has defined, are all customer-service models , or for VPN ( I guess you consider here draft-ietf-bess-l2vpn-yang) a service-delivery model. Both type of services are defined as "technology agnostic" in RFC 8309 and that would contrast with the definition.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/teas-wg/teas-ns-dt/issues/14#issuecomment-599743159, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENTVIOU4EYMNPM64DBWZZTRH2DRVANCNFSM4LMP3VOQ.

[sergiobelotti]

Eric, thanks, I'm very clear in mind what RFC 8309 describe and in ACTN with other co-authors we used that reference also in draft-ietf-teas-actn-yang to express application of different ACTN YANG models. I agree on the meaning of "agnostic" in RFC8309, but that does not solve the fact some explanation at least of the term used in the slicing context has to be provided. And that is my suggestion. If L2SM and L3SM are "customer service model" they cannot be put as example of "technology-specific" model unless a clarification of what technology-specific means in in this context . You could use also your words (avoiding technology-specific) above saying that " SC Southbound Interface (SBI): is an interface between 'Transport slice controller' and network controller(s). These interfaces can utilize specific technology choices (e.g. L2SM,L3SM, etc,) as options to implement the higher level service request received at NBI level. TSC may request network resources or retrieval of their current state. " We do not mention technology-specific and we would avoid also confusion with respect fig 1 of Sec 4 in the framework in which it showed CMI in the ACTN (customer-service model technology-agnostic) and SBI for slicing .

[ewgray2k]

Sergio,

With layering, in general, there is significant ambiguity in what the role is for any layer, as the role it plays depends on where it is in the “stack.".

I agree that clarification is required.

But (and I have the impression that you probably agree - once the right level of clarification is there), because of this ambiguity, it is quite reasonable that L2SM and L3SM can be both “customer service models” and “technology specific” models - depending on where they are in relationship to whatever abstraction level you want to look at.

One reason for defining the “transport slice” abstraction is to possibly get away from having to be aware of which of these two “service models” applies below the TSC/NBI abstraction.

If we imagine that the TSC abstraction level makes it necessary only to define the termination type for the service, as well as specific Service Level Objectives that apply, there is no reason why the TSC could not use either service model to map the higher-level service request on to an underlying network.

It remains to be determined if this is done directly (i.e. - the TSC NBI directly includes L2SM and L3SM models) or indirectly. Neither of these should be explicitly determined in the definition or framework drafts - right?

— Eric

On Mar 17, 2020, at 5:22 AM, sergiobelotti notifications@github.com wrote:

Eric, thanks, I'm very clear in mind what RFC 8309 describe and in ACTN with other co-authors we used that reference also in draft-ietf-teas-actn-yang to express application of different ACTN YANG models. I agree on the meaning of "agnostic" in RFC8309, but that does not solve the fact some explanation at least of the term used in the slicing context has to be provided. And that is my suggestion. If L2SM and L3SM are "customer service model" they cannot be put as example of "technology-specific" model unless a clarification of what technology-specific means in in this context . You could use also your words (avoiding technology-specific) above saying that " SC Southbound Interface (SBI): is an interface between 'Transport slice controller' and network controller(s). These interfaces can utilize specific technology choices (e.g. L2SM,L3SM, etc,) as options to implement the higher level service request received at NBI level. TSC may request network resources or retrieval of their current state. " We do not mention technology-specific and we would avoid also confusion with respect fig 1 of Sec 4 in the framework in which it showed CMI in the ACTN (customer-service model technology-agnostic) and SBI for slicing .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/teas-wg/teas-ns-dt/issues/14#issuecomment-599965483, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENTVIO7WMT6GMGT2BLBXGLRH46NJANCNFSM4LMP3VOQ.

[kiranmak]

Hi Eric, About changing Network controller definition, I feel uncomfortable with the use of "a higher level entity (or management system)"... and connectivity and PDU delivery guarantees needed to...." ^^^^^^ In my opinion: Section 4 has defined transport slice and in preceding bullet we define TSC. So the original definition is quite concise.

• Here "higher-level entity" of interest is TSC, I would prefer not to de-focus from this.
• PDU delivery guarantees are embedded in the transport slice definition. so we can keep it concise. in addition no where in definitions we have gone to the level of PDU, so that will become something new.

This does not mean I do not agree with your explanation. It's just that I don't want to explain non-transport slice related details of network controller - for me this is the entity TSC has to talk to for SBI.

Would you agree to the following definition?

Transport Network Controller: is some form of network infrastructure controller that offers network resources to TSC to realize a particular transport slice. These may be existing network controllers associated with one or more specific technologies that may be adapted to the function of realizing transport slices in a network.

[kiranmak]

Hi Sergio, Eric, I agree with Eric's explanation in https://github.com/teas-wg/teas-ns-dt/issues/14#issuecomment-601838318. it is quite clear. Even for me L2SM, L3SM are technology specific where technology is L2 or L3 service. The exercise for transport slice definition is to describe transport slice as a first class entity. It may map fully or partially to either L2SM, L3SM, L2VPN etc.

I think when we get to the next level of details, we must add relevant text - There is a document we need to start on "existing technologies relevance", perhaps either there or if it suits framework - we can add the discussion there.

[ewgray2k]

Your suggested wording looks good to me.

On Mar 22, 2020, at 4:23 PM, kiranmak notifications@github.com wrote:

Hi Eric, About changing Network controller definition, I feel uncomfortable with the use of "a higher level entity (or management system)"... and connectivity and PDU delivery guarantees needed to...." ^^^^^^ In my opinion: Section 4 has defined transport slice and in preceding bullet we define TSC. So the original definition is quite concise.

Here "higher-level entity" of interest is TSC, I would prefer not to de-focus from this. PDU delivery guarantees are embedded in the transport slice definition. so we can keep it concise. in addition no where in definitions we have gone to the level of PDU, so that will become something new. This does not mean I do not agree with your explanation. It's just that I don't want to explain non-transport slice related details of network controller - for me this is the entity TSC has to talk to for SBI.

Would you agree to the following definition?

Transport Network Controller: is some form of network infrastructure controller that offers network resources to TSC to realize a particular transport slice. These may be existing network controllers associated with one or more specific technologies that may be adapted to the function of realizing transport slices in a network.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/teas-wg/teas-ns-dt/issues/14#issuecomment-602266749, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENTVIKZNNUNNIXPG4JD4CTRIZXTDANCNFSM4LMP3VOQ.

[sergiobelotti]

Sergio, With layering, in general, there is significant ambiguity in what the role is for any layer, as the role it plays depends on where it is in the “stack.".

SB> absolutely correct

I agree that clarification is required. SB> Yes, as I said I have nothing against Kiran definiton, but I thing some text to clarify the meaning of "technology" vs. "agnostic" here would be needed , and I would be ready to help writing if needed .

But (and I have the impression that you probably agree - once the right level of clarification is there), because of this ambiguity, it is quite reasonable that L2SM and L3SM can be both “customer service models” and “technology specific” models - depending on where they are in relationship to whatever abstraction level you want to look at.

SB> Yes, Eric, I agree. It makes sense.

One reason for defining the “transport slice” abstraction is to possibly get away from having to be aware of which of these two “service models” applies below the TSC/NBI abstraction. If we imagine that the TSC abstraction level makes it necessary only to define the termination type for the service, as well as specific Service Level Objectives that apply, there is no reason why the TSC could not use either service model to map the higher-level service request on to an underlying network. SB> yes I agree

It remains to be determined if this is done directly (i.e. - the TSC NBI directly includes L2SM and L3SM models) or indirectly. Neither of these should be explicitly determined in the definition or framework drafts - right?

SB> Yes no need to be said in the definition or in a framework. This has to be accomplish when real interface discussion starting. — Eric

… On Mar 17, 2020, at 5:22 AM, sergiobelotti @.***> wrote: Eric, thanks, I'm very clear in mind what RFC 8309 describe and in ACTN with other co-authors we used that reference also in draft-ietf-teas-actn-yang to express application of different ACTN YANG models. I agree on the meaning of "agnostic" in RFC8309, but that does not solve the fact some explanation at least of the term used in the slicing context has to be provided. And that is my suggestion. If L2SM and L3SM are "customer service model" they cannot be put as example of "technology-specific" model unless a clarification of what technology-specific means in in this context . You could use also your words (avoiding technology-specific) above saying that " SC Southbound Interface (SBI): is an interface between 'Transport slice controller' and network controller(s). These interfaces can utilize specific technology choices (e.g. L2SM,L3SM, etc,) as options to implement the higher level service request received at NBI level. TSC may request network resources or retrieval of their current state. " We do not mention technology-specific and we would avoid also confusion with respect fig 1 of Sec 4 in the framework in which it showed CMI in the ACTN (customer-service model technology-agnostic) and SBI for slicing . — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AENTVIO7WMT6GMGT2BLBXGLRH46NJANCNFSM4LMP3VOQ.

Hi Eric, I agree substantially in your comments. See in line. Thanks Sergio

[sergiobelotti]

Hi Sergio, Eric, I agree with Eric's explanation in #14 (comment). it is quite clear. Even for me L2SM, L3SM are technology specific where technology is L2 or L3 service. The exercise for transport slice definition is to describe transport slice as a first class entity. It may map fully or partially to either L2SM, L3SM, L2VPN etc.

I think when we get to the next level of details, we must add relevant text - There is a document we need to start on "existing technologies relevance", perhaps either there or if it suits framework - we can add the discussion there.

Hi Kiran, yes I also agree on Eric's comment you pointed out. If I've not misinterpreted Eric's word, a brief clarification would be needed regarding "agnostics" vs. "technology specific" and in particular for the usage at this level of customer service level. The there is the second part of the issue that is how the mapping will happen if directly into TSC or indirectly (e.g. in the network controller ??) ,and this you're right would be part of a different draft, not in framework or in definition. Are we on the same page? I hope so. Sergio

[kiranmak]

Here's the proposed wording that would go just below SBI/NBI discussion.

Note on technology -agnostic vs -specific use: These terms are used in a transport slice's context. A logical slice is not concerned with the underlying network protocol or technology (such as L2VPN, L2VPN, etc.) or corresponding service model (L2SM, L3SM, etc.) representing it. Therefore, for example, both L2VPN, L2SM are technology-specific from a customer of a slice's view. Technology-agnostic simply means representing a transport slice completely as a logical entity.