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

[mohamed.boucadair]

Hi Daniel, 

Thank you. 

> Additionally, some drafts still reference draft-ogondio-
> opsawg-uni-topology, so those authors will need to update their
> document(s) (https://datatracker.ietf.org/doc/draft-ogondio-opsawg-uni-
> topology/referencedby/) to the new I-D.

FYI. I confirm that we have already made that change in, e.g., L3NM: 
https://www.rfc-editor.org/authors/rfc9182.txt 

   Network Topology Modules:  An L3VPN involves nodes that are part of a
  topology managed by the service provider network.  The topology
  can be represented using the network topology YANG module defined
  in [RFC8345] or its extension, such as a network YANG module for
  Service Attachment Points (SAPs) [YANG-SAPs].

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de dan...@olddog.co.uk
> Envoyé : jeudi 6 janvier 2022 15:11
> À : 'opsawg' 
> Cc : 'opsawg-chairs' 
> Objet : Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00
> 
> Hi Folks,
> 
> (Strong) Support!
> 
> When I saw the adoption poll, it took me a few seconds to remember this
> I-D replaces:
> 
> A YANG Model for User-Network Interface (UNI) Topologies draft-ogondio-
> opsawg-uni-topology
> 
> As an author of I-D(s) in TEAS and CCAMP related to draft-dbwb-opsawg-
> sap-00, it would be great to see this work progress as we will be
> referencing it. Additionally, some drafts still reference draft-ogondio-
> opsawg-uni-topology, so those authors will need to update their
> document(s) (https://datatracker.ietf.org/doc/draft-ogondio-opsawg-uni-
> topology/referencedby/) to the new I-D.
> 
> Furthermore, we are investigating to implement the described SAP
> function/model with (IETF) network slicing, within the EU project
> TeraFlow (https://www.teraflow-h2020.eu/) - there will be at least one
> vendor implementation. Once we have the implementation details, we will
> provide these to the authors of "draft-dbwb-opsawg-sap".
> 
> BR, Dan.
> 
> De : OPSAWG <mailto:opsawg-boun...@ietf.org> De la part de Tianran Zhou
> Envoyé : mercredi 5 janvier 2022 03:12 À : mailto:opsawg@ietf.org Cc :
> mailto:opsawg-cha...@ietf.org Objet : [OPSAWG] WG Adoption Call for
> draft-dbwb-opsawg-sap-00
> 
> 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
> 
> _
> 
> 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.
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_

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 prote

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

[Dhruv Dhody]

Hi Qin,

On Fri, Jan 21, 2022 at 6:05 PM Qin Wu  wrote:

> Thanks Dhruv for valuable review, see reply inline below.
>
>
>
> *发件人:* OPSAWG [mailto:opsawg-boun...@ietf.org] *代表 *Dhruv Dhody
> *发送时间:* 2022年1月19日 20:40
> *收件人:* Tianran Zhou 
> *抄送:* opsawg@ietf.org; opsawg-cha...@ietf.org
> *主题:* 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.
>

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.
>
>
> 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.
>
>
>
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  40huawei@dmarc.ietf.org> 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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Qin Wu]

Thanks Bo, I believe Dhruv asked the similar question as you raised.
Yes, I think interconnection point in end to end connectivity spanning across 
multiple domains can be saps.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Wubo (lana)
发送时间: 2022年1月19日 22:27
收件人: Tianran Zhou ; opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

Hi Tianran, all,

I support the adoption. I have read the draft. The draft is a necessary piece 
to realize L3SM, L2SM, and network slice services.

I have one clarification comment. The introduction says that the SAP model can 
be used together with the service model to derive the interconnection points in 
a multi-domain scenario. Are the interconnection points are also SAPs?

Best regards,
Bo
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2022年1月5日 10:12
收件人: opsawg@ietf.org<mailto:opsawg@ietf.org>
抄送: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
主题: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Qin Wu]

Thanks Dhruv for valuable review, see reply inline below.

发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Dhruv Dhody
发送时间: 2022年1月19日 20:40
收件人: Tianran Zhou 
抄送: opsawg@ietf.org; opsawg-cha...@ietf.org
主题: 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 
mailto:40huawei@dmarc.ietf.org>> 
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
OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Wubo (lana)]

Hi Tianran, all,

I support the adoption. I have read the draft. The draft is a necessary piece 
to realize L3SM, L2SM, and network slice services.

I have one clarification comment. The introduction says that the SAP model can 
be used together with the service model to derive the interconnection points in 
a multi-domain scenario. Are the interconnection points are also SAPs?

Best regards,
Bo
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Tianran Zhou
发送时间: 2022年1月5日 10:12
收件人: opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Dhruv Dhody]

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

On Wed, Jan 5, 2022 at 7:42 AM Tianran Zhou  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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Oscar González de Dios]

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  En nombre de Tianran Zhou
Enviado el: miércoles, 5 de enero de 2022 3:12
Para: opsawg@ietf.org
CC: opsawg-cha...@ietf.org
Asunto: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

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



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
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Victor Lopez]

Hi,

I support as coauthor

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

Victor

El mié, 5 ene 2022 a las 3:12, Tianran Zhou () escribió:

> 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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Hongwei Li]

Hi WG,
I support the adoption.

I will review and provide comments as it moves forward.

Thanks,
Hongwei



> On 1/5/2022 3:12 AM, Tianran Zhou 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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_
>
> 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.
>
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[mohamed.boucadair]

Hi Benoît,

Thank you for comments.

Please see inline.

Cheers,
Med

De : OPSAWG  De la part de Benoit Claise
Envoyé : jeudi 6 janvier 2022 17:57
À : Tianran Zhou ; opsawg@ietf.org
Cc : opsawg-cha...@ietf.org
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.

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

'-+-'

  |

 .---. .---. .---.  .---.   .-+-.

   +-|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?
[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

On 1/5/2022 3:12 AM, Tianran Zhou 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 n

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

[liupeng...@outlook.com]

Hi WG,

I support the adoption.

Regards,
Peng Liu



liupeng...@outlook.com
 
From: Tianran Zhou
Date: 2022-01-05 10:12
To: opsawg@ietf.org
CC: opsawg-cha...@ietf.org
Subject: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Adrian Farrel]

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  On Behalf Of Tianran Zhou
Sent: 05 January 2022 02:12
To: opsawg@ietf.org
Cc: opsawg-cha...@ietf.org
Subject: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

 

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/>
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Benoit Claise]

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:


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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[daniel]

Hi Folks, 

(Strong) Support!

When I saw the adoption poll, it took me a few seconds to remember this I-D 
replaces:

A YANG Model for User-Network Interface (UNI) Topologies
draft-ogondio-opsawg-uni-topology

As an author of I-D(s) in TEAS and CCAMP related to draft-dbwb-opsawg-sap-00, 
it would be great to see this work progress as we will be referencing it. 
Additionally, some drafts still reference draft-ogondio-opsawg-uni-topology, so 
those authors will need to update their document(s) 
(https://datatracker.ietf.org/doc/draft-ogondio-opsawg-uni-topology/referencedby/)
 to the new I-D.

Furthermore, we are investigating to implement the described SAP function/model 
with (IETF) network slicing, within the EU project TeraFlow 
(https://www.teraflow-h2020.eu/) - there will be at least one vendor 
implementation. Once we have the implementation details, we will provide these 
to the authors of "draft-dbwb-opsawg-sap". 

BR, Dan.  
 
De : OPSAWG <mailto:opsawg-boun...@ietf.org> De la part de Tianran Zhou
Envoyé : mercredi 5 janvier 2022 03:12
À : mailto:opsawg@ietf.org
Cc : mailto:opsawg-cha...@ietf.org
Objet : [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00
 
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
_
 
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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Wei Wang]

Hi Tianran,
    I support the adoption.


Best Regards,
Wei
-- Original --
From:   
 "Tianran Zhou" 
   
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Qin Wu]

Support as coauthor, I am not aware of any IPR related to this I-D.

-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 mohamed.boucad...@orange.com
发送时间: 2022年1月5日 15:32
收件人: Tianran Zhou ; opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: Re: [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

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 mailto:opsawg-boun...@ietf.org>> De la 
part de Tianran Zhou
Envoyé : mercredi 5 janvier 2022 03:12
À : opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc : opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Objet : [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

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

_



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.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[mohamed.boucadair]

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  De la part de Tianran Zhou
Envoyé : mercredi 5 janvier 2022 03:12
À : opsawg@ietf.org
Cc : opsawg-cha...@ietf.org
Objet : [OPSAWG] WG Adoption Call for draft-dbwb-opsawg-sap-00

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

_

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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Tianran Zhou]

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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg