Re: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

[Daniele Ceccarelli <[e-mail]>]

Indeed i forgot to add Thursday March 25th COmB (close of MY business) 😃

Jokes aside, thanks for the thorough review and thanks for the pointer to RFC5737, I couldn’t really understand what was wrong with the ID nits when saying “non compliant IPv4 addresses.

Authors, for your convenience I’m copying here below the address blocks to use:

   The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
   and 203.0.113.0/24 (TEST-NET-3) are provided for use in
   documentation.

Thanks
Daniele

From: Daniel King <[e-mail]> On Behalf Of [e-mail]
Sent: den 26 mars 2021 10:59
To: [e-mail]; Daniele Ceccarelli <[e-mail]>; 'CCAMP' <[e-mail]>
Subject: RE: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

Hi Adrian,

Thanks for the support and review of the document; your detailed comments and suggestions are very welcome. We will address them when we update the I-D.

BR, Dan.

From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Adrian Farrel
Sent: 25 March 2021 22:56
To: 'Daniele Ceccarelli' <daniele.ceccarelli=[e-mail]<mailto:daniele.ceccarelli=[e-mail]>>; 'CCAMP' <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

Hi,

I see Daniele got excited and requested publication, but it seems that it is still 25/3 where I live. Sorry my review is right at the deadline, but it’s a long document.

It's nice to see guidance on using IETF technology. Particularly useful when the ingredients include a list of YANG models. So I support publication of this document.

I did find it a hard read and confess to not having checked the JSON examples (55 pages were quite enough for me!).  Along the way I collected a few minor issues and whole host of nits.

Best,
Adrian


== Minor ==

You need to stop using legitimate IP addresses and switch to using
documentation ranges. idnits does point this out.

Suitable ranges are described in RFC 5737.

---

2.

   Connectivity Service: A service, or connectivity service, in the
   context of this document can be considered as some form of
   connectivity service between customer sites across the network
   operator's network [RFC8309].

That's a bit broken. "A connectivity service is some form of
connectivity service." :-)

---

2.

   Note - The three definitions above are currently in [TE-TUTORIAL]
   but it is expected that they will be moved to [TE-TUNNEL]. When this
   happens, the reference will be updated and the [TE-TUTORIAL]
   reference will be downgraded to Informative.

At this point in the publication cycle it is close to time to make a
choice on this point.

---

3.1 needs to explain the meaning of curly brackets {} in the notation.

---

5.4

   The notification mechanisms are protocol-dependent. It is assumed
   that the RESTCONF protocol, defined in [RFC8040], is used at the
   MPIs mentioned in this document.

Do you mean that the notification mechanisms are dependent on the
data plane technology, or on the protocol used to report the
notifications? If the latter (which seems most likely) then the first
sentence is self-evident, but (worse) it seems to conflict with the
second sentence that constrains use to RESTCONF.

---


== Nits ==

General point:
- noun "a setup"
- verb "to set up"

I called out some of these, but probably missed loads.

---

The Abstract should be the first thing in the document.

---

Abstract

OLD
   This document provides an analysis of the applicability of the YANG
   models defined by the IETF (Traffic Engineering Architecture and
   Signaling (TEAS) moreover, Common Control and Measurement Plane
   (CCAMP) WGs in particular) to support ODU transit services,
   Transparent client services and EPL/EVPL Ethernet services over OTN
   single and multi-domain network scenarios.
NEW
   This document provides an analysis of the applicability of the YANG
   models defined by the IETF (in particular in the Traffic Engineering
   Architecture and Signaling (TEAS) and Common Control and Measurement
   Plane (CCAMP) working groups) to support ODU transit services,
   transparent client services, and Ethernet Private Line/Ethernet
   Virtual Private Line (EPL/EVPL) services over Optical Transport
   Network (OTN) in single and multi-domain network scenarios.
END

---

1.

   Transport network domains, including Optical Transport Network (OTN)
   and Wavelength Division Multiplexing (WDM) networks, are typically
   deployed based on a single vendor or technology platforms.

s/technology platforms /on a single technology platform/

---

1.

s/are critical/is critical/

---

1.

OLD
   This document examines the applicability of the YANG models being
   defined by IETF (Traffic Engineering Architecture and Signaling
   (TEAS) moreover, Common Control and Measurement Plane (CCAMP) WGs in
   particular) to support Optical Transport Networks (OTN) single and
   multi-domain scenarios.
NEW
   This document examines the applicability of the YANG models defined
   by the IETF (in particular in the Traffic Engineering Architecture
   and Signaling (TEAS) and Common Control and Measurement Plane (CCAMP)
   working groups) to support OTN in single and multi-domain network
   scenarios.
END

---

1.1

s/based on the/based on the Framework for/
s/called MDSC-PNC Interface/called the MDSC-PNC Interface/
s/called CNC-MDSC Interface/called the CNC-MDSC Interface/

---

1.1
Expand "ODU" and "EPL/EVPL" on first use

---

2.

s/as an edge on TE graph/as an edge on the TE graph/
s/layer network of delivery of/layer network for delivery of/

---

2.

Expand FC and STM-n on first use

---

3.2

s/3.2. JSON code/3.2. JSON Code/

OLD
(TEAS and CCAMP WG in particular)
NEW
(in particular, the TEAS and CCAMP working groups)
END

s/by an "-"/by a "-"/
s/have been instead found/have been found/
s/some numbering scheme/a numbering scheme/

---

The numbering of the switches in Figure 1 is slightly confused.
It looks like you started numbering them at S1 through S8 in domain 1,
and then moved on to start at S11 in domain 2 but had to go up to S21
because of the number of switches. And then domain 3 starts at S31.

It's not important. Just odd.

---

4.1

s/MDSC control the/MDSC controls the/

---

4.1

   The split of functionality at the MPI in the ACTN architecture
   between the MDSC (multi-domain controller) and the PNCs (domain
   controllers)

You probably don't need to expand MDSC and PNC again.

---

4.1 and 4.2 mention MPI1, MPI2 etc....

Figure 2 does not number the MPIs. Perhaps it should.

---

4.2

s/PNcs/PNCs/

---

4.3

Please expand ETH and SDH on first use

---

4.3.1
   When a 10Gb IP link between R1 and R8 is needed
Do you mean "connection"? Or even "connectivity service".
Similar in later sections.

---

4.3.1

s/CMI,the/CMI, the/
s/to setup/to set up/

---

s/4.4. Multi-function Access Links/4.4. Multi-Function Access Links/

---

OLD
4.5.1. Linear Protection (end-to-end)
NEW
4.5.1. Linear Protection (End-to-End)
END

---

4.5.2

s/MDSC can request/the MDSC can request/
s/MDSC can also request/the MDSC can also request/ (twice)

---

4.6

OLD
   To realize the topology update, service update and restoration
   function, following notification types should be supported:
NEW
   To realize the three functions of topology update, service update,
   and restoration, the following notification types need to be
   supported:
END

---

4.7

   It is possible to define constraints to be taken into account during
   path computation procedures (e.g., IRO/XRO).

Should expand IRO and XRO.
Should also concern a reference.

---

5.1.1

s/AN1) moreover,/AN1). Moreover,/
s/both), as/both), are included as/
s/Figure 3 below./Figure 3./
s/Figure 4 below./Figure 4./

---

5.1.1 Figures 3 and 4

Are both abstract nodes called AN1? It's confusing.

---

I think we can fix Figure 5 to avoid the confusing link numbering as...

           .........................................
           :                                        :
           :         Physical Topology @ PNC1       :
           :                                        :
           :         +----+              +----+     :
           :         |    |S1-1          |    |S2-3 :
           :         | S1 |--------------| S2 |------ - -(S31)
           :         +----+          S2-1+----+     :
           :       S1-2/                    |S2-2   :
           :          /                     |       :
           :     S3-4/                      |       :
           :     +----+        +----+       |       :
           : S3-1|    |S3-3    |    |       |       :
   (R1)- - ------| S3 |--------| S4 |       |       :
           :     +----+    S4-1+----+       |       :
           :    S3-2\             \S4-2     |       :
           :         \             \        |       :
           :          \S5-1         \       |       :
           :           +----+        \      |       :
           :           |    |         \     |       :
           :           | S5 |          \    |       :
           :           +----+           \   |       :
   (R2)- - -----   S5-2/    \S5-3        \  |       :
           :    \     /      \        S8-2\ |S8-1   :
           : S6-1\   /S6-5    \S7-1        \|       :
           :     +----+      +----+      +----+     :
           :     |    |S6-4  |    |S7-4  |    |S8-5 :
   (R3)- - ------| S6 |------| S7 |------| S8 |------ - -(S32)
           : S6-2+----+  S7-2+----+  S8-3+----+     :
           :      /            |           |        :
   (R3)- - -------         S7-3|           |S8-4    :
           : S6-3              |           |        :
           :...................|...........|........:

                               |           |
                             (S11)      (S12)

---

5.1.1

s/it under PNC/it is the PNC's/

---

5.2

s/to setup/to set up/

---

5.2.1.1

s/To setup/To set up/
s/to setup/to set up/
s/5.2.1, MDSC/5.2.1, the MDSC/

---

5.2.2

   Appendix Error! Reference source not found. provides the detailed

I spy Microsoft Word!

---

5.2.3

s/MDSC understands/the MDSC understands/

---

5.2.3.1

s/When this IP link/When an IP link/ ??

---

5.2.4

s/MDSC understands/the MDSC understands/
s/To setup/To set up/ (three times)

---

OLD
5.3.1. Linear Protection (end-to-end)
NEW
5.3.1. Linear Protection (End-to-End)
END

---

5.3.1

s/MDSC performs/The MDSC performs/
s/both the paths for working/the paths for both the working/
s/MDSC would/the MDSC would/
s/MDSC requests/The MDSC requests/
s/with1+1/with 1+1/

---

5.3.2

s/Network domain 2 and 3/network domains 2 and 3/

---

5.4

s/On the perspective of MPI/From the perspective of the MPI/
s/receiving notification/receiving a notification/

---

6.

s/at remote node/at remote nodes/

---

Nice to see one of the authors thanking himself in the acknowledgments:)

From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Daniele Ceccarelli
Sent: 11 March 2021 17:37
To: CCAMP <[e-mail]<mailto:[e-mail]>>
Subject: [CCAMP] WG last call on draft-ietf-ccamp-transport-nbi-app-statement-12

CCAMP,

the IPR declaration collection has been successfully completed before the IETF week and we can move to the next step.

This starts a 2 weeks working group last call on draft-ietf-ccamp-transport-nbi-app-statement-12
The last call ends on Thursday March 25th. Please send you comments to the CCAMP mailing list.

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document https://datatracker.ietf.org/doc/draft-ietf-ccamp-transport-nbi-app-statement/history/
Please note that no IPR has been disclosed against this document.

If interested, please volunteer to be the shepherd of the draft.




Thanks

Daniele & Fatai