Subject: Re: [Teas] Questions on teas-ietf-network-slice-nbi-yang

From: Tarek Saad <[email-masked]>
Date: Mon, 7 Mar 2022 18:09:48 +0000

Hi John,

Thanks for the review and comments. I’m just following up on top of Bo’s responses. Please see more responses inline from my side..

From: Teas <[email-masked]> on behalf of John Mullooly (jmullool) <jmullool=[email-masked]>
Date: Monday, February 21, 2022 at 12:06 PM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [Teas] Questions on teas-ietf-network-slice-nbi-yang
Hello Authors,

I think this is important work, thank you for driving it. I have several questions on draft-ietf-teas-ietf-network-slice-nbi-yang. Sorry they are all listed in the same email!

1) In the YANG model, I see there is a "choice" for ns-slo-sle-policy where we can either choose "standard" or "custom". Where standard points to a pre-defined set of “standard” templates. The YANG model identifies the list of standard templates but does not highlight the SLO/SLE attributes that are in these templates, so does that mean that the attributes in the template are considered open ended and use-case/SP defined ?

2) I understand and agree that the slice service model should abstract and be technology-agnostic, but the customer still may want to dictate whether they want (for example) a L2 or a L3 based forwarding service (or L1 for that matter). The customer may want to generally request this slice “service” as it may have specific implications on how the customer configures their CE devices (if connecting to a L3VPN or a L2VPN service). Using the YANG model provided, how would a customer request a slice service type of L2 or L3? If not defined in the model, could we use an SP defined SLE in the ns-slo-sle-policy templates for this (i.e. extension of question #1 where SPs can build their own templates.). I think we need to make this extensible to future slice service types.
[TS]: indeed, this is important. We have extended ‘ns-tags’ to allow specifying the service type through a ‘tag’ of type ‘type of service’. Please refer to Appendix for an example (snipped below):

  "ietf-network-slice:network-slices": {
    "network-slice": [
      {
        "ns-id": "NS1",
        "ns-description": "URLLC",
        "ns-tags": {
          "ns-tag": [
            {
              "index": 1,
              "ns-tag-type": "ns-tag-customer",
              "ns-tag-value": "FOO"
            },
            {

              "index": 3,
              "ns-tag-type": "ns-tag-service",
              "ns-tag-value": "L2"
            }

3) On Section 4 you highlight “The logical topology types are: point-to-point, point-to-multipoint, multipoint-to-point, or multipoint-to-multipoint”. Yet for  “For connectivity-type, you have any-to-any, hub-spoke or custom type. Why isn't point-to-point considered? Yes, I understand that any-to-any would cover this assuming only two endpoints but I would think P2P would warrant it's own type. Otherwise, we would augment and include it under custom? Also, If point-to-point, what would be the endpoints "role"?
[TS]: ‘point-to-point’ is an identity type of  ‘ns-connectivity-type’. I agree, ‘endpoint-role’ may automate creation of connectivity constructs to realize the desired connectivity-type.

4) If using the template approach to generally define SLOs/SLEs for a slice and if we have uniform TE connection requirements across all endpoints,  it seems we would not need to define any ns-connections, as shown in the Example in Appendix A?
[TS]: yes, connectivity-constructs may be explicitly provisioned or automatically instantiated (i.e. exist in ephemeral data store only).

5) Regarding defining endpoints, I've followed earlier threads on defining "what is an endpoint" and I understand it could mean different things depending on the slice service boundary and type. But if we take an example that the endpoint is the PE interface facing the CE for either a L2 or L3 VPN service, then I need a clarification on the use of various attributes in the ns-endpoint YANG model. I understand that ep-id is "Uniquely identifies the NSE within Network Slice Controller (NSC)." So, is it assumed that the NSC abstracts the interface details (i.e. node/slot/port) from the customer and that the ep-id in the model would be used by the NSC to map to the specific PE device interface? (done a priori).  That would seem to be the case from the example in appendix A, but the first diagram in section 6.3 says the PE interfaces are defined in the ep-network-access-points section. So is the goal here I use ep-id to hide detail from the customer or optionally allow for the customer to specify the interfaces with the ep-network-access-points section? Wouldn’t network-access-node-id be redundant with node-id under ns-endpoint? In the second diagram in section 6.3 showing “NSEs with CE parameters”, the example is not clear on how 'ep-network-access-points' is used to map to CE parameters. i.e. the verbiage says “(Two nexthop interfaces )to retrieve the corresponding border link or PE, and further map to services/tunnels/paths.”

[TS]:  in the example in Appendix A, the 'ep-network-access-point' resembles a CE-PE link. In this case, the ‘network-access-tp-ip-address’ and ‘network-access-tp-ip-prefix-length’ designate the CE-PE link IP address and prefix length. The model allows to specify on per 'ep-network-access-point', the ‘incoming-rate-limits’ and ‘outgoing-rate-limits’ as well as a QoS policy name. Snipping from Appendix A for illustration:

              "ep-network-access-points": {
                "ep-network-access-point": [
                  {
                    "network-access-id": "AC1-VRF100",
                    "network-access-description": "VRF100 to PE1",
                    "network-access-node-id": "PE1",
                    "network-access-tp-id": "1",
                    "network-access-tp-ip-address": "192.0.1.2",
                    "network-access-tp-ip-prefix-length": 24,
                    "network-access-qos-policy-name": "QoS-Gold",

Regards,
Tarek

rw ep-network-access-points
           |     |  +--rw ep-network-access-point* [network-access-id]
           |     |     +--rw network-access-id             string
           |     |     +--rw network-access-description?   string
           |     |     +--rw network-access-node-id?       string
           |     |     +--rw network-access-tp-id?         string
           |     |     +--rw network-access-tp-ip?         inet:host
           |     |     +--rw mtu                           uint16

6) The example in Apendix A seems to imply that the ep-id abstracts the node/interface details. I believe you ahve an error where you indicate VLAN 20 versus showing VLAN 2 in the diagram?

              "ep-id":"12",
                  "ep-description":"slice1 ep2 connected to device 3",
                  "ep-role":"any-to-any-role",
                  "ns-match-criteria":[
                     {
                       "match-type":"ns-vlan-match",
                       "value":[
                           {
                             "index":"1",
                             "value":"20"
                            }

Thank You
John Mullooly