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