Subject: [Teas] Martin Vigoureux's No Objection on draft-ietf-teas-actn-framework-14: (with COMMENT)

From: Martin Vigoureux <[email-masked]>
Date: Thu, 24 May 2018 01:56:45 -0700

Martin Vigoureux has entered the following ballot position for
draft-ietf-teas-actn-framework-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hello,

thank you for this document. I have few questions for clarification:

* I'm not sure to understand your definition of Domain. You say:
Specifically within this document we mean a part of an operator's network that
is under common management. I'm not sure to understand what common means. 
Also, you add a sentence after that but it didn't help me, in fact it confused
me further. Is it the managed entities which have something in common or is
that the managing entities which have something in common? In the latter case
what would be the common thing?

On that matter, I would suggest to capitalise the first letter of all the
occurrences of domain which correspond to this definition (with the hope that
all of them do).

Fig. 1 shows the Customer in relation with the Service Provider but Fig. 2
shows a boundary between Customer and Network Operator. Are the NO and SP
merged in Fig. 2?

You say:
   The PNC functions can be implemented as part of an SDN domain
   controller, a Network Management System (NMS), an Element Management
   System (EMS), an active PCE-based controller [Centralized] or any
   other means to dynamically control a set of nodes and that is
   implementing an NBI compliant with ACTN specification.
I have few comments:
which ACTN specification are you referring to ?
Usually when I read "comply with a specification", I expect to read a
MUST/SHOULD in the same sentence. I can understand that you don't want to put a
compliance requirement, but then you might want to use another word than
"compliant". NBI is not defined/expanded anywhere in the doc. In fact it's the
only place where it appears. And in fact seeing it here while Fig. 2 talks
about SBI only makes the reader uncertain. One way out of this would be to make
it appear on Fig 2. because it's just the same interface, seen from the other
direction.

You say:
   A PNC domain includes all the resources under the control of a
   single PNC.  It can be composed of different routing domains and
   administrative domains, and the resources may come from different
   layers.
Is that consistent with the definition of Domain? More precisely, is that
consistent with the last sentence of the Domain definition which says:
   Network elements will often be grouped into domains based on
   technology types, vendor profiles, and geographic proximity.

4.1. MDSC Hierarchy
Can there be more than two levels in the MDSC hierarchy? In other words, can an
MDSC-L for an MDSC-H be itself an MDSC-H for an MDSC-L? As a side note, since I
made the mistake while writing this, you have two occurrences of MSDC (instead
of MDSC) in the doc .

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 24 May 2018 11:36:08 +0100

Hi Martin,

Thanks for the comments. Although I am not a front page author, I am answering
the first of the comments because some of the text in question was probably
mine.

I'll leave the rest for Young and Danielle.

> is under common management. I'm not sure to understand what common

The definition of "common" we're using is:
"belonging to or shared by two or more individuals or things or by all members
of a group"

So we could say (note, we also forgot to comma a subclause)
OLD
        Specifically within this document
        we mean a part of an operator's network that is under common
        management.
NEW
        Specifically, within this document,
        we mean a part of an operator's network that is under shared
        operational management using the same instances of a tool and
        the same policies.
END

(But actually, I find the original cleaner)

> what would be the common thing?

The following sentence is:
        Network elements will often be grouped into
        domains based on technology types, vendor profiles, and
        geographic proximity.

Examples of this would be:
- WDM equipment is managed using different instances of tools and
   different policies from TDM equipment
- Optical equipment from vendor A is managed using different instances
   of tools and different policies from vendor B
- A ring or a metro network is usually managed using different instances
  of tools and different policies from other networks

> occurrences of domain which correspond to this definition (with the hope that

My experience of the RFC Editor is that they really hate that form of
capitalisation. And since *all* mentions of "domain" in this document conform to
this definition, I think the document is consistent and no capitalisation is
needed.

Cheers,
Adrian

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 24 May 2018 15:13:31 +0200

Adrian,

thank you for your quick reply.
Actually I prefer the new text :-) but I let you decide which one to use.

Ok for not capitalising the first letter of domain. I note however there 
is one such occurrence:
    border nodes in Domain Y to PE2

cheers
-m

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 24 May 2018 14:47:35 +0000

Hi Martin,

Regarding the other issues:

I have few comments:

Usually when I read "comply with a specification", I expect to read a MUST/SHOULD in the same sentence. I can understand that you don't want to put a compliance requirement, but then you might want to use another word than "compliant". NBI is not defined/expanded anywhere in the doc. In fact it's the only place where it appears. And in fact seeing it here while Fig. 2 talks about SBI only makes the reader uncertain. One way out of this would be to make it appear on Fig 2. because it's just the same interface, seen from the other direction.

[DC] We’re referring to the documents that describe the ACTN MPI and CMI interfaces. (which is basically a set of YANG models like e.g. the TE-Topology, TE-tunnel, etc). Basically the idea is: “I’m not telling you here what you have to implement to be compliant with and ACTN MPI, but it you can implement and ACTN MPI on top of one of the boxes listed above, such box can be put into the ACTN controllers hierarchy and that works just fine”.

You say:

   layers.

Is that consistent with the definition of Domain? More precisely, is that consistent with the last sentence of the Domain definition which says:

[DC] I would say yes, in the sense that all the nodes controlled by the same PNC for a PNC domain. Usually all the from the same technology are grouped under the control of the same PNC, or the ones from the same vendor. Obviously can be stated better…

4.1. MDSC Hierarchy

Can there be more than two levels in the MDSC hierarchy? In other words, can an MDSC-L for an MDSC-H be itself an MDSC-H for an MDSC-L? As a side note, since I made the mistake while writing this, you have two occurrences of MSDC (instead of MDSC) in the doc .

[DC] exactly, yes.

Cheers

Daniele

> -----Original Message-----

> From: Martin Vigoureux <[email-masked]>

> Sent: giovedì 24 maggio 2018 15:14

> To: [email-masked]; 'The IESG' <[email-masked]>

> Cc: [email-masked]; [email-masked];

> [email-masked]; [email-masked]

> Subject: Re: [Teas] Martin Vigoureux's No Objection on draft-ietf-teas-actn-

> framework-14: (with COMMENT)

> Ok for not capitalising the first letter of domain. I note however there is one

> such occurrence:

> > Thanks for the comments. Although I am not a front page author, I am

> > answering the first of the comments because some of the text in

> > question was probably mine.

> >> Specifically within this document we mean a part of an operator's

> >> network that is under common management. I'm not sure to understand

> >> what common means.

> > "belonging to or shared by two or more individuals or things or by all

> > members of a group"

> > So we could say (note, we also forgot to comma a subclause) OLD

> >> Also, you add a sentence after that but it didn't help me, in fact it

> >> confused me further. Is it the managed entities which have something

> >> in common or is that the managing entities which have something in

> >> common? In the latter case what would be the common thing?

> >> On that matter, I would suggest to capitalise the first letter of all

> >> the occurrences of domain which correspond to this definition (with

> >> the hope that all of them do).

> > capitalisation. And since *all* mentions of "domain" in this document

> > conform to this definition, I think the document is consistent and no

> > capitalisation is needed.

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 24 May 2018 21:18:59 +0200

Hi Daniele,

thanks.
Please see in-line.

-m

Le 2018-05-24 à 16:47, Daniele Ceccarelli a écrit :
> MUST/SHOULD in the same sentence. I can understand that you don't want 
> to put a compliance requirement, but then you might want to use another 
> word than "compliant". NBI is not defined/expanded anywhere in the doc. 
> In fact it's the only place where it appears. And in fact seeing it here 
> while Fig. 2 talks about SBI only makes the reader uncertain. One way 
> out of this would be to make it appear on Fig 2. because it's just the 
> same interface, seen from the other direction.
> 
> [DC] We’re referring to the documents that describe the ACTN MPI and CMI 
> interfaces. (which is basically a set of YANG models like e.g. the 
> TE-Topology, TE-tunnel, etc). Basically the idea is: “I’m not telling 
> you here what you have to implement to be compliant with and ACTN MPI, 
> but it you can implement and ACTN MPI on top of one of the boxes listed 
> above, such box can be put into the ACTN controllers hierarchy and that 
> works just fine”.
ok ...
So you're saying that what an implementation would have to comply with 
is out of the scope of this document. Why not be explicit about that?

What about my comment on NBI?

> Is that consistent with the definition of Domain? More precisely, is 
> that consistent with the last sentence of the Domain definition which says:
> 
> [DC] I would say yes, in the sense that all the nodes controlled by the 
> same PNC for a PNC domain. Usually all the from the same technology are 
> grouped under the control of the same PNC, or the ones from the same 
> vendor. Obviously can be stated better…
ok. I was probably confused by layer/technology

> 
> 4.1. MDSC Hierarchy
> 
> Can there be more than two levels in the MDSC hierarchy? In other words, 
> can an MDSC-L for an MDSC-H be itself an MDSC-H for an MDSC-L? As a side 
> note, since I made the mistake while writing this, you have two 
> occurrences of MSDC (instead of MDSC) in the doc .
> 
> [DC] exactly, yes.
Wouldn't it be worth saying it?

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 25 May 2018 06:28:04 +0000

Hi Martin,

cleaning up a bit
[snip]

> > [DC] We’re referring to the documents that describe the ACTN MPI and
> > CMI interfaces. (which is basically a set of YANG models like e.g. the
> > but it you can implement and ACTN MPI on top of one of the boxes
> > listed above, such box can be put into the ACTN controllers hierarchy
> > and that works just fine”.
> ok ...
> So you're saying that what an implementation would have to comply with is
> out of the scope of this document. Why not be explicit about that?
> 
[>DC] Exactly. Yes, worth saying it.

> What about my comment on NBI?
[>DC] missed it sorry. Since it occurs just once we can extend it. 

[snip]
> >
> > 4.1. MDSC Hierarchy
> >
> > Can there be more than two levels in the MDSC hierarchy? In other
> > words, can an MDSC-L for an MDSC-H be itself an MDSC-H for an MDSC-L?
> > As a side note, since I made the mistake while writing this, you have
> > two occurrences of MSDC (instead of MDSC) in the doc .
[>DC] will fix it too.
> Wouldn't it be worth saying it?
[>DC] Ok. What about this addition in section 4.1:

OLD
The hierarchy of MDSCs can be seen in Figure 4.

NEW
The hierarchy of MDSC can be recursive, where an MDSC-H is in turn an MDSC-L to an higher level MDSC-H. An example of hierarchy can be seen in Figure 4.

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 25 May 2018 10:02:56 +0200

Thank you Daniele.

I had one outstanding question:

Fig. 1 shows the Customer in relation with the Service Provider but Fig. 
2 shows a boundary between Customer and Network Operator. Are the NO and 
SP merged in Fig. 2?

Thx
-m

---

From: Leeyoung <[email-masked]>
Date: Sun, 27 May 2018 08:53:14 +0000

Hi Martin,

To follow-up with this email and to close up the thread, we will change:

OLD: Domain Y to PE2
NEW: domain Y to PE2

Thanks. 
Young

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]] 
Sent: Thursday, May 24, 2018 8:14 AM
To: [email-masked]; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Martin Vigoureux's No Objection on draft-ietf-teas-actn-framework-14: (with COMMENT)

Adrian,

Ok for not capitalising the first letter of domain. I note however there is one such occurrence:
    border nodes in Domain Y to PE2

cheers
-m

---

From: Leeyoung <[email-masked]>
Date: Sun, 27 May 2018 09:26:36 +0000

Hi Martin,

On your one outstanding question, you are correct. In Figure 2, the NO and SP are merged. 

With this, are there any other issues still pending? Please let us know. 

Thanks.
Young

-----Original Message-----
From: Martin Vigoureux [mailto:[email-masked]] 
Sent: Friday, May 25, 2018 3:03 AM
To: Daniele Ceccarelli <[email-masked]>; [email-masked]; 'The IESG' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Teas] Martin Vigoureux's No Objection on draft-ietf-teas-actn-framework-14: (with COMMENT)

Thank you Daniele.

Fig. 1 shows the Customer in relation with the Service Provider but Fig. 
2 shows a boundary between Customer and Network Operator. Are the NO and SP merged in Fig. 2?

Thx
-m

Le 2018-05-25 à 8:28, Daniele Ceccarelli a écrit :
>>> CMI interfaces. (which is basically a set of YANG models like e.g. 
>>> the TE-Topology, TE-tunnel, etc). Basically the idea is: “I’m not 
>>> telling you here what you have to implement to be compliant with and 
>>> ACTN MPI, but it you can implement and ACTN MPI on top of one of the 
>>> boxes listed above, such box can be put into the ACTN controllers 
>>> hierarchy and that works just fine”.
>> ok ...
>> So you're saying that what an implementation would have to comply 
>> with is out of the scope of this document. Why not be explicit about that?
>>
>>> As a side note, since I made the mistake while writing this, you 
>>> have two occurrences of MSDC (instead of MDSC) in the doc .
> [>DC] will fix it too.
>>>
>>> [DC] exactly, yes.

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 28 May 2018 09:57:39 +0200

Hello Young,

if you could mention this somewhere that would help the reader I think.

beyond that I'm good. Many thanks for addressing all my comments.

-m