Hi,
I am your document shepherd for this journey.
Thanks for your work on the document so far, this is my review of your
draft. If you could work on updates or responses, I will continue with
the process of the shepherd write-up.
Hoping this gives you enough time to post an update before the IETF-114
lock-down.
Best,
Adrian
===
idnits points out there is a non-ASCII character in the reference
entry for [MEF17]
---
What is a "network YANG model"? The only places this is used are:
- The title
- The running head
- The reference entry in the revision clause
---
Section 1
For example, this concept is
used to decide where to attach and, thus, deliver the service in the
Layer 3 VPN Service Model (L3SM) [RFC8299] and the Layer 2 VPN
Service Model (L2SM) [RFC8466]. It can also be used to retrieve
where services, such as the Layer 3 VPN Network Model (L3NM)
[RFC9182] and the Layer 2 VPN Network Model (L2NM)
[I-D.ietf-opsawg-l2nm], are delivered to customers.
This is a bit confusing. I don't think L3NM and L2NM are services. This
just needs a bit of a tweak: L3SM and L2SM describe services; L3NM and
L2NM are used to derive the configuration information for the network to
enable delivery of the services in the SMs. So you could change the
second sentence to read:
It can also be used to retrieve
where such services are delivered to customers through the network
configuration described in the Layer 3 VPN Network Model (L3NM)
[RFC9182] and the Layer 2 VPN Network Model (L2NM)
[I-D.ietf-opsawg-l2nm].
---
Section 1
You have...
Multiple service types can be associated with a given network.
Whether a SAP topology is dedicated to a specific service or shared
among many services is deployment specific. This document supports
both deployment schemes.
The first sentence says "multiple service types" but the second sentence
is about "many services". Maybe...
A network may support multiple services, potentially of different
tyoes. Whether a SAP topology is dedicated to services of a specific
service type, an individual service, or shared among many services of
different types is deployment specific. This document supports all
of these deployment schemes.
---
Use of optional plural(s).
It's generally better style to use the plural when you mean "one or
more plurals" because one is just a special case of many.
---
I think some more clarity is needed around the discussion of UNI and
NNI reference points. In RFC 6215 the UNI is situated between the UNI-C
and UNI-N, but which of these is the SAP? Similarly, there are two
end-points associated with the NNI.
I think probably you intend the network side in both cases per Figure 4.
Maybe this can go into the short definition of the SAP in Section 2.
---
The depiction of the Abstract Topology in Figure 3 and the text above it
is *a* way of looking at an abstraction, but I think the user of the
topology also has some expectation of the connectivity between the PEs.
Perhaps you are assuming that this is a full mesh in all cases, but I am
not convinced that that would always be the case. So you should probably
represent the abstraction in one of the ways talked about in RFC 7329.
This is probably not substantially different from what you intended. You
could modify the abstraction through a virtual node, virtual network, or
virtual link model. That would lead you to one of these...
.---------. .---------.
| PE1 |----------| PE2 |
'---------'\___ /'---------'
| __\___/ |
| / \____ |
.---------./ \---------.
| PE3 |----------| PE4 |
'---------' '---------'
.---------. .---------.
| PE1 | | PE2 |
'---------'\ /'---------'
\.----./
| VN |
/'----'\
.---------./ \.---------.
| PE3 | | PE4 |
'---------' '---------'
.---------. .---------.
| PE1 | | PE2 |
'---------'\ /'---------'
\------/
( )
( )
( )
/------\
.---------./ \.---------.
| PE3 | | PE4 |
'---------' '---------'
---
"setup"
Verb : to set up
Noun : the setup
---
I don't object to the model you are showing for where service is
provided and therefore the demarcation between customer and provider.
But, as noted in draft-ietf-teas-network-slices, there may be a number
of options including:
- the CE is operated by the provider and the SAP is inside the CE
- the SAP is an exit port of the CE
- the SAP is a port on the PE or virtual channel on the AC
- the SAP is within the PE
Not sure there is anything you need to do about this unless something
springs to your mind when you read it.
---
Section 4
Also, the SAP is not a tunnel termination point (TTP) (Section 3.6 of
[RFC8795]) nor a link.
A very helpful clarification.
It's a bit orphaned where it is in Section 4. Shouldn't it be located
with the definition of SAP?
---
Section 4
Advanced low-level interface-specific data nodes are not exposed in
the SAP model. Filters based on the interface identifiers listed in
the SAP model can be used together with dedicated device models to
set or get such data.
This paragraph, on the other hand, doesn't mean so much to me. Not sure
what an "advanced low-level interface-specific data node" is.
---
I'm not sure I'm comfortable with the list of service types in the
identityref service-type. Two questions spring to mind:
- what happens when new service types are invented?
- why do we need this?
The second question might be answered by wanting to advertise multiple
SAPs to the customer but needing the customer to be able to work out
which SAPs support which services. Is that it?
---
I have a similar question about interface-type and encapsulation-type.
What happens when new types come along?
Should these and service-type be in an IANA-maintained module?
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
