Re: [OPSAWG] Document shepherd review of draft-ietf-opsawg-sap

Fri, 08 Jul 2022 10:17:06 -0700

Med,
Thanks for this.
Looking at it on my phone, it seems good.
Maybe "YANG network model" would resolve the question.
A
On 08/07/2022 09:37 mohamed.boucad...@orange.com wrote:


Hi Adrian,

Thanks for the meticulous review. Much appreciated.

You may track a first set of proposed changes at: https://tinyurl.com/sap-latest. Let me know is more is needed.

Please more context see inline.

Cheers,
Med

-----Message d'origine-----
De : Adrian Farrel <adr...@olddog.co.uk>
Envoyé : jeudi 7 juillet 2022 19:43
Objet : Document shepherd review of draft-ietf-opsawg-sap

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.

[Med] Thanks.

Best,
Adrian

===

idnits points out there is a non-ASCII character in the reference
entry for [MEF17]
[Med] I made some changes in the xml file. I hope this is fixed.

---

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

---
[Med] The intent was to reflect in the title this is a "network model" as per RFC8969. To avoid confusing readers not familiar with all these subtleties, I removed the mention from the title (and then reflected this in the reference and abbrev).

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

[Med] You got the intent :-) Fixed. Thanks.

---

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.

[Med] Works for me.

---

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.

[Med] fixed what I think is appropriate.

---

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.

[Med] Yes; see the mention about "customer-facing interfaces".

Added this NEW text to be more explicit:

NEW:
Such interfaces are referred to as UNI-N (User-to-Network Interface, Network side) [RFC6215].

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 |
'---------' '---------'

[Med] Went with the last one for the abstract figure.

---

"setup"

Verb : to set up
Noun : the setup

[Med] ACK.

---

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.
[Med] Slicing was exactly what motivated the careful wording in the definition of SAP:

Service Attachment Points (SAPs): An abstraction of the network
reference points (e.g., PE side of an AC) where network services
^^^^^
can be delivered and/or being delivered to customers.

I also changed the title of Section 3 to "Sample SAP Network Model Usage" to be clear this is just one main use, but other usages are.

---

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?

[Med] It is positioned here as this section is about clarifying the relationship with other models. I prefer to leave it here. Thanks.

---

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.
[Med] This is to say that the model does not intend to be used as an alternative to manage interfaces. The ids in the SAP can be used to build filters as per rfc6241.html#section-6 + appropriate device modules to set/get such advanced data. Tweaked the text a little bit. Hope this is better:

Advanced interface-specific data nodes are not included in the SAP
model. The interface identifiers listed in the SAP model can be used
as filters to set or get such data using device models (e.g.,
[RFC7224]).

---

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?
[Med] A new value will be defined (including proprietary ones). We do already have the following:

"Other service types can be defined in future YANG modules, if needed."

- why do we need this?
[Med] The value of having a list of identities in the spec is to make sure that consistent ids are used by implementations for these services rather than going with proprietary ids. It will be straightforward, for example, to map SAP information with the appropriate network configuration as the same service type is used in both models. This is at least the case for L2/L3 VPN:

These service types build on the types that are already defined in
[RFC9181] and additional types that are defined in this document.

Added this NEW text:

| Leveraging the service types defined in [RFC9181] is meant to
| ease the correlation between the SAP topology and the
| corresponding network modules that used to provision a specific
| service.

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?
[Med] This can be used to map a service request with the underlying capabilities and see if a requested service scope can be accommodated by the network. To handle such an order, the service orchestrator can make queries by setting the filter as a function of the requested service type/scope.

As this is deployment/implementation-specific, we only provide the external expected behavior:

Filters based on the service type can be used to access per-service
SAP topology.

---

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?
[Med] For encapsulation-type, we are reusing what is already in RFC9181.

For interface-type, we don't want to be specific as RFC7224 but expose the level of information that is useful for an orchestrator/controller. We do have a default value ("logical") if none of other ids fits. If for some reason, there is a need to define a specific value, then this is always possible in future modules that augments the SAP model (e.g., add a new leaf that is specific to that new type).

Identities are used here to ease defining future values.

_________________________________________________________________________________________________________________________

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

Reply via email to