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

From: "John Mullooly (jmullool)" <[email-masked]>
Date: Mon, 21 Feb 2022 17:06:22 +0000

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.

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"?

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?

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.”

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

---

From: "Wubo (lana)" <[email-masked]>
Date: Thu, 24 Feb 2022 14:46:05 +0000

Hi John,

Thanks for the comments. Please see inline.

Regards,
Bo

发件人: John Mullooly (jmullool) [mailto:[email-masked]]
发送时间: 2022年2月22日 1:06
收件人: [email-masked]
抄送: [email-masked]
主题: Questions on teas-ietf-network-slice-nbi-yang

Hello Authors,

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 ?
[wubo] Yes, this is intention. we are following the principle in https://datatracker.ietf.org/doc/html/rfc8309#section-3.1, details of individual services  should be offered as extensions or augmentations of this.

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.
[wubo] I agree that the templates can be used to extend some specific implementation requirements. However, according to previous discussions on the mailing list, it is also suggested that LxSM can also be used to the cases you described.
And the slice service model is more useful when customers do not care about specific service implementation technologies.

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"?
[wubo]Yes, this is the method described in the current draft, but we are updating the model.
Since slice framework draft  is working on the slice service definition, a slice service may have multiple connection-matrixes/ connection-constructs.
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-05#section-3.2
Here is link of the new model: https://github.com/lana-wu/ietf-ns-nbi/blob/main/ietf-network-slice.tree

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?
[wubo] Please refer to the previous reply.

[wubo] You are correct on the modelling consideration on NSE and ep-network-access-points, ep-network-access-points could be optional. And about the node-id attribute, we will add it to our pending issue.

              "ep-id":"12",

[wubo] Thanks for catching this, we will fix this.

Thank You
John Mullooly