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

From: Tianran Zhou <[email-masked]>
Date: Wed, 5 Jan 2022 02:12:24 +0000

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

---

From: <[email-masked]>
Date: Wed, 5 Jan 2022 07:32:02 +0000

Hi Tianran, all,

I support adoption, obviously.

FWIW, I don't have any IPR nor I'm aware of any related to this I-D.

Cheers,
Med

De : OPSAWG <[email-masked]> De la part de Tianran Zhou
Envoyé : mercredi 5 janvier 2022 03:12
À : [email-masked]
Cc : [email-masked]
Objet : [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi WG,

Cheers,
Tianran

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Wei Wang" <[email-masked]>
Date: Thu, 6 Jan 2022 21:28:37 +0800

Hi Tianran,
&nbsp; &nbsp; I support the adoption.

Best Regards,
Wei
------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Tianran Zhou"                                                                                    <zhoutianran=[email-masked]&gt;;
Date:&nbsp;Wed, Jan 5, 2022 10:12 AM
To:&nbsp;"[email-masked]"<[email-masked]&gt;;
Cc:&nbsp;"[email-masked]"<[email-masked]&gt;;
Subject:&nbsp;[OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi WG,
 
&nbsp;

 
&nbsp;

 
&nbsp;

&nbsp;

 
&nbsp;
 
Cheers,
 
Tianran

---

From: Benoit Claise <[email-masked]>
Date: Thu, 6 Jan 2022 17:56:42 +0100

Hi,

I support the adoption.
This is a much needed functionality, required to provide a layered view 
of the network (the service layer in this case). I like the fact it's 
based on the I2RS topology model.

One clarification though.

     From that standpoint, and considering the architecture
        depicted in Figure 1, the goal of this document is to provide a
        mechanism to show via a YANG-based interface an abstracted network
        view from the network controller to the service orchestration layer
        with a focus on where a service can be delivered to customers.

"can be delivered" or is delivered?

In this figure,

                                                         .---.
                                                         |CE2|
                                                         '-+-'
                                                           |
              .---. .---. .---.              .---.       .-+-.
            +-|sap|-|sap|-|sap|-+          +-|sap|-------|sap|-+
            | '---' '---' '---' |          | '---'       '---' |
   .---.  .---.                 |          |                   |
   |CE1+--+sap|      PE1        |          |         PE2       |
   '---'  '---'                 |          |                   |
            |                   |          |                   |
            +-------------------+          +-------------------+

            +-------------------+          +-------------------+
            |                   |          |                   |
            |                   |          |                 .---.  .---.
            |         PE3       |          |        PE4      |sap+--+CE5|
            |                   |          |                 '---'  '---'
            | .---. .---. .---. |          | .---. .---. .---. |
            +-|sap|-|sap|-|sap|-+          +-|sap|-|sap|-|sap|-+
              '---' '---' '-+-'              '---' '---' '---'
                            |                        |
                          .-+-.                    .-+-.
                          |CE3|                    |CE4|
                          '-+-'                    '-+-'

1. Do we want to say that there are existing SAPs on PE routers, to 
which we can deploy new services?
2. Or do we want to say there is an existing service that connects CE2 
to a specific SAP on PE2?

1. implies that  we have to list all the potential SAP types that 
"could" be delivered. And I don't know yet which service type will be 
configured. So I potentially need the full list of the "service-type" 
derived identities
2. implies that only the existing configured SAP type needs to be documented

The figures and texts points to 1., but 2 would be useful to me.
So what's happening when a specific service type is configured on this 
CE2-facing SAP on PE2, the SAP-type goes a list to the unique configured 
SAP-type?
In other words, can I do a filter on my topology for all the L3VPN 
configured SAPs?

Regards, Benoit

On 1/5/2022 3:12 AM, Tianran Zhou wrote:
> 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).
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Jan 2022 18:46:20 -0000

Thanks Tianran,

I think that this is a good thing to be working on, and that this document
is a reasonable starting point.

I support adoption and promise to review the draft as it goes forward.

Adrian

From: OPSAWG <[email-masked]> On Behalf Of Tianran Zhou
Sent: 05 January 2022 02:12
To: [email-masked]
Cc: [email-masked]
Subject: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi WG,

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

Cheers,

Tianran

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 7 Jan 2022 15:02:23 +0800

Hi WG,

I support the adoption.

Regards,
Peng Liu

[email-masked]
 
From: Tianran Zhou
Date: 2022-01-05 10:12
To: [email-masked]
CC: [email-masked]
Subject: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00
Hi WG,

 

Cheers,
Tianran

---

From: <[email-masked]>
Date: Fri, 7 Jan 2022 09:26:39 +0000

Hi Benoît,

Thank you for comments.

Please see inline.

Cheers,
Med

De : OPSAWG <[email-masked]> De la part de Benoit Claise
Envoyé : jeudi 6 janvier 2022 17:57
À : Tianran Zhou <zhoutianran=[email-masked]>; [email-masked]
Cc : [email-masked]
Objet : Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi,

I support the adoption.
This is a much needed functionality, required to provide a layered view of the network (the service layer in this case). I like the fact it's based on the I2RS topology model.

   with a focus on where a service can be delivered to customers.
"can be delivered" or is delivered?
[Med] We could actually say “can be (or is) delivered” but we didn’t at that stage of the document because “is delivered” will also require manipulating service-specific modules.

I suggest we make this change: s/the goal of this document/a goal of this document

In this figure,

                                                        .---.

                                                        |CE2|

                                                        '-+-'

                                                          |

  .---.  .---.                 |          |                   |

  '---'  '---'                 |          |                   |

           |                   |          |                   |

           |                   |          |                   |

           |                   |          |                 .---.  .---.

           |                   |          |                 '---'  '---'

                           |                        |

                         .-+-.                    .-+-.

                         |CE3|                    |CE4|

                         '-+-'                    '-+-'

1. Do we want to say that there are existing SAPs on PE routers, to which we can deploy new services?
2. Or do we want to say there is an existing service that connects CE2 to a specific SAP on PE2?
[Med] Both are in scope. For the second one, we only indicate that an interface is currently used for the delivery of a service. This is inferred from the *-status data nodes. We will update the text to make this clearer in the next iteration.

1. implies that  we have to list all the potential SAP types that "could" be delivered. And I don't know yet which service type will be configured. So I potentially need the full list of the "service-type" derived identities
[Med] service-types can be controlled/restricted (e.g., capabilities of a PE, supported services in a network, etc.).

2. implies that only the existing configured SAP type needs to be documented
[Med] Not necessary. A physical interface can also be exposed as a SAP even if no service is actually bound to it.

The figures and texts points to 1., but 2 would be useful to me.
So what's happening when a specific service type is configured on this CE2-facing SAP on PE2, the SAP-type goes a list to the unique configured SAP-type?
In other words, can I do a filter on my topology for all the L3VPN configured SAPs?
[Med] What we had in mind is to use a filter based on sap-type under network-types. However, I’m not sure this type of filtering is supported in NETCONF (presence, leaf-list). Of course, the filtering can be done locally at the orchestrator, but will need to think about this further and document the intended behavior. Thank you.

Regards, Benoit

Cheers,
Tianran

OPSAWG mailing list

[email-masked]<mailto:[email-masked]>

---

From: Hongwei Li <[email-masked]>
Date: Fri, 7 Jan 2022 15:28:34 -0600

Hi WG,
I support the adoption.

I will review and provide comments as it moves forward.

Thanks,
Hongwei

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

---

From: Victor Lopez <[email-masked]>
Date: Wed, 12 Jan 2022 16:29:37 +0100

Hi,

I support as coauthor

I am not aware of any IPR related to this I-D.

Victor

---

From: Oscar González de Dios <[email-masked]>
Date: Wed, 12 Jan 2022 15:42:14 +0000

Hi Tianran, all

                Holidays were good while they lasted :)

                As a co-author of the document, I support the adoption of the document.

                Best Regards and looking forward to receive further inputs,

                               Oscar

De: OPSAWG <[email-masked]> En nombre de Tianran Zhou
Enviado el: miércoles, 5 de enero de 2022 3:12
Para: [email-masked]
CC: [email-masked]
Asunto: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi WG,

Cheers,
Tianran

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 19 Jan 2022 18:09:57 +0530

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.
2) Is the attachment-id the key via which the SAP is linked to the physical
topology? More text on this would be useful.
3) Consider adding an example (JSON or XML) of how this model would be used
alongside L3SM.
4) Can SAP be used for NNI? Some clarification would be nice!

Thanks!
Dhruv