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

[Benoit Claise <[e-mail]>]

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/ 
> <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg