Subject: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

From: Qin Wu <[email-masked]>
Date: Fri, 21 Jan 2022 12:35:32 +0000

Thanks Dhruv for valuable review, see reply inline below.

发件人: OPSAWG [mailto:[email-masked]] 代表 Dhruv Dhody
发送时间: 2022年1月19日 20:40
收件人: Tianran Zhou <zhoutianran=[email-masked]>
抄送: [email-masked]; [email-masked]
主题: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi Tianran,

I have read the I-D and I support its adoption.

Few comments -

1) Figure 1 uses the term "Service Network Models" which is not defined and not aligned to RFC 8309.
[Qin Wu]  I think it is referred to network configuration models since it sits on top of controller described in figure 3 of RFC8309. But I am not sure RFC8309 is better reference  since RFC8309 introducse layered SDN architecture and split orchestrator into service orchestrator and network orchestrator which intends to align with MEF SLO project.
I suggest we can align with RFC8969 instead, which use the term “network model” and reduce confusion when the number of layers in our targeted architecture is different from on described in figure 3 of RFC8309.
2) Is the attachment-id the key via which the SAP is linked to the physical topology? More text on this would be useful.
[Qin Wu] Yes the attachment-id is the key for service-attachment –point list which can mapped to the specific port in the physical topology, yes, we can make this clear in the update.

3) Consider adding an example (JSON or XML) of how this model would be used alongside L3SM.
[Qin Wu] Good suggestion and will add.

4) Can SAP be used for NNI? Some clarification would be nice!
[Qin Wu] Yes, I think we cover NNI use case, see the text in the introduction
“
With the help of
   other data models (e.g., L3SM [RFC8299<https://datatracker.ietf.org/doc/html/rfc8299>] or L2SM [RFC8466<https://datatracker.ietf.org/doc/html/rfc8466>]),
   hierarchical control elements could determine the feasibility of an
   end-to-end IP connectivity or L2VPN connectivity and therefore derive
   the sequence of domains and the points of interconnection to use.

”
I think the point of interconnection can be exposed attachment point in the NNI case.

Thanks!
Dhruv

On Wed, Jan 5, 2022 at 7:42 AM Tianran Zhou <zhoutianran=[email-masked]<mailto:[email-masked]>> wrote:
Hi WG,

I assume most of you are back to work.
Hope you had a good holiday.

As a follow up action after IETF 111, this mail starts a working group adoption call for draft-dbwb-opsawg-sap-00.
https://datatracker.ietf.org/doc/draft-dbwb-opsawg-sap/

This document defines a YANG data model for representing an abstract view of the provider network topology containing the points from which its services can be attached (e.g., basic connectivity, VPN, network slices).

Please review and comment.
We will conclude this adoption call after two weeks.

Cheers,
Tianran
_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Dhruv Dhody <[email-masked]>
Date: Sat, 22 Jan 2022 09:38:04 +0530

Hi Qin,

On Fri, Jan 21, 2022 at 6:05 PM Qin Wu <[email-masked]> wrote:

> *发件人:* OPSAWG [mailto:[email-masked]] *代表 *Dhruv Dhody
> *发送时间:* 2022年1月19日 20:40
> *收件人:* Tianran Zhou <zhoutianran=[email-masked]>
> *抄送:* [email-masked]; [email-masked]
> *主题:* Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00
>
>
>
> Hi Tianran,
>
> [Qin Wu]  I think it is referred to network configuration models since it
> sits on top of controller described in figure 3 of RFC8309. But I am not
> sure RFC8309 is better reference  since RFC8309 introducse layered SDN
> architecture and split orchestrator into service orchestrator and network
> orchestrator which intends to align with MEF SLO project.
> I suggest we can align with RFC8969 instead, which use the term “network
> model” and reduce confusion when the number of layers in our targeted
> architecture is different from on described in figure 3 of RFC8309.
>

Dhruv: Works for me!

> 2) Is the attachment-id the key via which the SAP is linked to the
> physical topology? More text on this would be useful.
>
> [Qin Wu] Yes the attachment-id is the key for service-attachment –point
> list which can mapped to the specific port in the physical topology, yes,
> we can make this clear in the update.
>
>
>    other data models (e.g., L3SM [RFC8299
> <https://datatracker.ietf.org/doc/html/rfc8299>] or L2SM [RFC8466
> <https://datatracker.ietf.org/doc/html/rfc8466>]),
>
Dhruv: In that case, what would be the sap-type is not clear to me. Maybe
we need a new type for this and perhaps a figure that also describes this
case.

Thanks!
Dhruv

> Thanks!
> Dhruv
>
>
>
> On Wed, Jan 5, 2022 at 7:42 AM Tianran Zhou <zhoutianran=
> [email-masked]> wrote:
>
> Hi WG,
>
>
>
> As a follow up action after IETF 111, this mail starts a working group
> adoption call for draft-dbwb-opsawg-sap-00.
>
> This document defines a YANG data model for representing an abstract view
> of the provider network topology containing the points from which its
> services can be attached (e.g., basic connectivity, VPN, network slices).
>
>
>
> [email-masked]