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

[[e-mail]]

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]> On Behalf Of Adrian Farrel
Sent: 25 March 2021 22:56
To: 'Daniele Ceccarelli' <daniele.ceccarelli=[e-mail]>;
'CCAMP' <[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-statemen
t/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