Subject: [Actn] PNC obtained through NMS

From: Nico Wauters <[email-masked]>
Date: Tue, 14 Jan 2014 18:39:16 +0100

Dear actn team,

Let me first introduce myself. I am Nico Wauters and founder of a Belgian
company with software solution focusing on transport inventory

and automation of transport processes for operations teams (
www.networkmining.com). This explain my interest in the actn topic

I read the draft and found it very interesting.

One of my comments on this ACTN draft is that it assumes G.MPLS in the PNC.

I would like to propose to add in paragraph 5.1 the alternative with a
traditional setup where the PNC is obtained through a vendor network
management system (NMS). Such NMS have typically a TMForum like NBI for
sharing inventory north bound and provisioning of traffic.

In our work we have seen that on the market only few vendors open their
G.MPLS to outside parties (as assumed in paragraph 5.1) and that G.MPLS is
used internally for signalling hidden under the NMS.

If NMS ‘s are involved (w/o direct access to G.MPLS via (v)PCE), I believe
there are two options to distinguish further:

·         one is where the NMS shares routes through the NBI. In this case
the NMS returns ‘PCE like routing data’. I call this option 2a (after
option 1 which is the G.MPLS option listed in the current draft).

·         Some NMS’s I know do not even return this level of detail (option
2b). They share through the NBI inventory data (including NE and topology
info) but will not detail the found routes. By sharing inventory the VNC
know where additional VNS  can be terminated (between which ports). As such
I believe it still can be used in an ACTN context

I hope you find this useful. I am curious to get your reaction

Nico Wauters

**

*T*: +32 2 211 34 62 | *M*: +32 497480614 | *Fax:* +32 2 218 89 73

*E*: [email-masked] <[email-masked]>* |
*W:* www.networkmining.com

http://www.networkmining.com/maildisclaimer.aspx

---

From: Leeyoung <[email-masked]>
Date: Tue, 14 Jan 2014 19:29:15 +0000

Hi Nico,

Thanks for providing your comments. I found it useful to broaden the scope of ACTN.

First of all, in Section 5.1, the term PNC a functional entity that can provide physical path computation and provisioning and other network control functions. In that regards, we do not necessarily assume that PNC is assumed by GMPLS control plane and PCE capability. As long as "PNC" provides path computation and provisioning and other connection control functions for physical network, I believe other manifestations such as NMS can be another form of the PNC.

But one disclaimer is that the Section 5.1 diagram does not necessarily mandate that GMPLS must have an open interface - that was not an intention here. All it says when VNC is separated from PNC, there must be an entity in the PNC that needs to provide some open interface to VNC. This entity is a "proxy" function per se on behalf of the PNC.

What really matters is to define the info and data model of the VNC-PNC interface (VPI). There could be some variations from option 1 and 2a if we were to include option 2b.

Regards,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of Nico Wauters
Sent: Tuesday, January 14, 2014 11:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Actn] PNC obtained through NMS

Dear actn team,

Let me first introduce myself. I am Nico Wauters and founder of a Belgian company with software solution focusing on transport inventory
and automation of transport processes for operations teams (www.networkmining.com<http://www.networkmining.com>). This explain my interest in the actn topic

One of my comments on this ACTN draft is that it assumes G.MPLS in the PNC.
I would like to propose to add in paragraph 5.1 the alternative with a traditional setup where the PNC is obtained through a vendor network management system (NMS). Such NMS have typically a TMForum like NBI for sharing inventory north bound and provisioning of traffic.

In our work we have seen that on the market only few vendors open their G.MPLS to outside parties (as assumed in paragraph 5.1) and that G.MPLS is used internally for signalling hidden under the NMS.

If NMS 's are involved (w/o direct access to G.MPLS via (v)PCE), I believe there are two options to distinguish further:

*         one is where the NMS shares routes through the NBI. In this case the NMS returns 'PCE like routing data'. I call this option 2a (after option 1 which is the G.MPLS option listed in the current draft).

*         Some NMS's I know do not even return this level of detail (option 2b). They share through the NBI inventory data (including NE and topology info) but will not detail the found routes. By sharing inventory the VNC know where additional VNS  can be terminated (between which ports). As such I believe it still can be used in an ACTN context

Nico Wauters

T: +32 2 211 34 62 | M: +32 497480614 | Fax: +32 2 218 89 73
E: [email-masked]<mailto:[email-masked]> | W: www.networkmining.com<http://www.networkmining.com/>

---

From: Nico Wauters <[email-masked]>
Date: Tue, 21 Jan 2014 18:39:36 +0100

Young, thanks for your comments on my previous email

Regarding the VPI, I was misled reading previous work where this is was the
acronym of  VNC-PCE while it is broadened to VCN-PCN interface?

Hence VPI can be based on PCE/GMPLS or alternatively based on NMS North
bound interface technologies (proprietary or standard based)?

I understand that the topology shared with the consumer can be abstracted.

Will the VNC have a detailed view of the physical topology (including
links) obtained from the PNC?

If yes, PNC shares upstream:

1.       Physical network topology (links between devices or nodes)

2.       Link utilization?

3.       Established tunnels/connections (with our without routing?)

4.       How the ‘virtual topology’ can be extend or list of possible new
end point (termination points) combinations  to fill the VNTM ?

5.       ….

If no, PNC does not share info on individual links therefore 1 and 2 are
not required

Regards

Nico

*From:* Leeyoung [mailto:[email-masked]]
*Sent:* dinsdag 14 januari 2014 20:29
*To:* Nico Wauters; [email-masked]
*Cc:* [email-masked]
*Subject:* RE: [Actn] PNC obtained through NMS

Hi Nico,

Thanks for providing your comments. I found it useful to broaden the scope
of ACTN.

First of all, in Section 5.1, the term PNC a functional entity that can
provide physical path computation and provisioning and other network
control functions. In that regards, we do not necessarily assume that PNC
is assumed by GMPLS control plane and PCE capability. As long as “PNC”
provides path computation and provisioning and other connection control
functions for physical network, I believe other manifestations such as NMS
can be another form of the PNC.

But one disclaimer is that the Section 5.1 diagram does not necessarily
mandate that GMPLS must have an open interface – that was not an intention
here. All it says when VNC is separated from PNC, there must be an entity
in the PNC that needs to provide some open interface to VNC. This entity is
a “proxy” function per se on behalf of the PNC.

What really matters is to define the info and data model of the VNC-PNC
interface (VPI). There could be some variations from option 1 and 2a if we
were to include option 2b.

Regards,

Young

*From:* ACTN [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Nico Wauters
*Sent:* Tuesday, January 14, 2014 11:39 AM
*To:* [email-masked]
*Cc:* [email-masked]
*Subject:* [Actn] PNC obtained through NMS

Dear actn team,

Nico Wauters

**

---

From: Leeyoung <[email-masked]>
Date: Tue, 21 Jan 2014 21:30:37 +0000

Hi Nico,

Please see inline for my comment.

Thanks.
Young

From: Nico Wauters [mailto:[email-masked]]
Sent: Tuesday, January 21, 2014 11:40 AM
To: Leeyoung
Cc: [email-masked]; [email-masked]
Subject: RE: [Actn] PNC obtained through NMS

Regarding the VPI, I was misled reading previous work where this is was the acronym of  VNC-PCE while it is broadened to VCN-PCN interface?
Hence VPI can be based on PCE/GMPLS or alternatively based on NMS North bound interface technologies (proprietary or standard based)?

YOUNG>> Yes. I would regard PNC as a functional block that provides a few key connectivity functions such as path computation and provisioning among others.
For the NMS based provider networks, it is inevitable for the VNC to have need to interface NMS based PNC. However, we would expect ACTN work to address
standard based VPI interfaces rather than proprietary.

I understand that the topology shared with the consumer can be abstracted.
Will the VNC have a detailed view of the physical topology (including links) obtained from the PNC?

YOUNG>> That is the current assumption. The degree of the physical topology the VNC would get from the PNC(s) depends on the business relationship between the VNC and the PNC(s).
I consider an abstraction level of the TED (that shows nodes and links) is a right level with which the VNC operates for Virutual Service Providers and some sophiscated customers. But I believe
The interface we are trying build on the VPI should be general and flexible enough to accomodate different customer needs.

2.       Link utilization?

4.       How the 'virtual topology' can be extend or list of possible new end point (termination points) combinations  to fill the VNTM ?

5.       ....

If no, PNC does not share info on individual links therefore 1 and 2 are not required

YOUNG>>  The combination of (1,2) and (3,4,5..) can be supported for a certain customers while only (3,4,5..) is another set of data the PNC can support for a certain cinstomers.
I believe certain sophisticated customers can handle both (1,2) and (3,4,5..) and want to see them at all.

Regards

Nico

From: Leeyoung [mailto:[email-masked]<mailto:[email-masked]>]
Sent: dinsdag 14 januari 2014 20:29
To: Nico Wauters; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] PNC obtained through NMS

Hi Nico,

Regards,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of Nico Wauters
Sent: Tuesday, January 14, 2014 11:39 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Actn] PNC obtained through NMS

Dear actn team,

Nico Wauters

---

From: Nico Wauters <[email-masked]>
Date: Thu, 23 Jan 2014 09:59:50 +0100

Young, please find a further comment from me on standard NMS NBI below in
yellow.

Regards Nico

*From:* Leeyoung [mailto:[email-masked]]
*Sent:* dinsdag 21 januari 2014 22:31
*To:* Nico Wauters
*Cc:* [email-masked]; [email-masked]
*Subject:* RE: [Actn] PNC obtained through NMS

Hi Nico,

Thanks.

Young

*From:* Nico Wauters
[mailto:[email-masked]<[email-masked]>]

*Sent:* Tuesday, January 21, 2014 11:40 AM
*To:* Leeyoung
*Cc:* [email-masked]; [email-masked]
*Subject:* RE: [Actn] PNC obtained through NMS

YOUNG>> Yes. I would regard PNC as a functional block that provides a few
key connectivity functions such as path computation and provisioning among
others.

For the NMS based provider networks, it is inevitable for the VNC to have
need to interface NMS based PNC. However, we would expect ACTN work to
address

Nico >> I agree, I propose however to be pragmatic in labelling something
proprietary and standard.
Note that in our experience, there are, next to the g.mlps/pce based
solutions also north bound interfaces for  NMS that can be categorized as
standardized (e.g. the tmforum standard previously TMF814 based on Corba
and MTOSI).
Both tmforum/NBI standards allow the NMS to expose topology and support
provisioning of connections matching exactly the requirements mentioned in
figure 4 of the draft of section 5.4 for PCE.

Hence my proposal is to refer in the doc to e.g. tmforum NBI standards (for
centralized managed solutions) as alternative to PCE based solutions that
rely on distributed control.

YOUNG>> That is the current assumption. The degree of the physical topology
the VNC would get from the PNC(s) depends on the business relationship
between the VNC and the PNC(s).

I consider an abstraction level of the TED (that shows nodes and links) is
a right level with which the VNC operates for Virutual Service Providers
and some sophiscated customers. But I believe

The interface we are trying build on the VPI should be general and flexible
enough to accomodate different customer needs.

2.       Link utilization?

5.       ….

YOUNG>>  The combination of (1,2) and (3,4,5..) can be supported for a
certain customers while only (3,4,5..) is another set of data the PNC can
support for a certain cinstomers.

I believe certain sophisticated customers can handle both (1,2) and
(3,4,5..) and want to see them at all.

Regards

Nico

Hi Nico,

Regards,

Young

Dear actn team,

Nico Wauters

**

---

From: Young Lee <[email-masked]>
Date: Tue, 28 Jan 2014 00:12:50 -0600

---------- Forwarded message ----------
From: "Young Lee" <[email-masked]>
Date: Jan 28, 2014 12:11 AM
Subject: Re: [Actn] PNC obtained through NMS
To: "Nico Wauters" <[email-masked]>
Cc:

Hi Nico,

This issue may be a bit sticky whether the actn work addresses tmf based
solutions on the vpi interface. I see that the vpi requirements can be
shared with control plane based PNC and NMS based PNC. Yet in terms of
developing 'standard' solution in IETF, tmf based solution is out of the
scope of Actn in my view. You can still claim that tmf based solution is
standard based (as tmf is a SDO) --- we have no problem with that. In the
Actn problem space in IETF, we would like develop one protocol solution
that works primary with control plane based PNC while supporting NMS based
PNC.

This is my view and I am open to hear the views of other Actn participants.

Regards,
Young
On Jan 23, 2014 2:59 AM, "Nico Wauters" <[email-masked]>
wrote:

> *From:* Nico Wauters [mailto:[email-masked]<[email-masked]>]
>
> Regarding the VPI, I was misled reading previous work where this is was
> the acronym of  VNC-PCE while it is broadened to VCN-PCN interface?
>
> Hence my proposal is to refer in the doc to e.g. tmforum NBI standards
> (for centralized managed solutions) as alternative to PCE based solutions
> that rely on distributed control.
>
>
>
>
>
> YOUNG>> That is the current assumption. The degree of the physical
> topology the VNC would get from the PNC(s) depends on the business
> relationship between the VNC and the PNC(s).
>
> The interface we are trying build on the VPI should be general and
> flexible enough to accomodate different customer needs.
>
>
>
> ·         one is where the NMS shares routes through the NBI. In this
> case the NMS returns ‘PCE like routing data’. I call this option 2a (after
> ·         Some NMS’s I know do not even return this level of detail
> (option 2b). They share through the NBI inventory data (including NE and
> topology info) but will not detail the found routes. By sharing inventory
> the VNC know where additional VNS  can be terminated (between which ports).
> As such I believe it still can be used in an ACTN context
>
>
>
> _______________________________________________
> ACTN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/actn
>
>

---

From: Nico Wauters <[email-masked]>
Date: Fri, 31 Jan 2014 13:52:01 +0100

Dear Young,

My suggestion is to put in the draft at least a placeholder for centralized
PCN solutions (NMS based) as this is the hard reality.

We,  as a company, have done quite some integration projects based on
"real" transport networks. In reality only few vendors, to be honest I
haven't seen any, give to 3rd part software access to the control plane. By
including in the ACTN drafts the NMS option for PCN, we make the concept
applicable on a much larger scale.

As you suggest it would be great to have the view of other people on this
mailing list

Regards

Nico

*From:* Young Lee [mailto:[email-masked]]
*Sent:* dinsdag 28 januari 2014 7:13
*To:* [email-masked]
*Subject:* Re: [Actn] PNC obtained through NMS

---------- Forwarded message ----------
From: "Young Lee" <[email-masked]>
Date: Jan 28, 2014 12:11 AM
Subject: Re: [Actn] PNC obtained through NMS
To: "Nico Wauters" <[email-masked]>
Cc:

Hi Nico,

Regards,
Young

Regards Nico

Hi Nico,

Thanks.

Young

*From:* Nico Wauters

2.       Link utilization?

4.       How the 'virtual topology' can be extend or list of possible new
end point (termination points) combinations  to fill the VNTM ?

5.       ....

Regards

Nico

Hi Nico,

is assumed by GMPLS control plane and PCE capability. As long as "PNC"

But one disclaimer is that the Section 5.1 diagram does not necessarily
mandate that GMPLS must have an open interface - that was not an intention
here. All it says when VNC is separated from PNC, there must be an entity
in the PNC that needs to provide some open interface to VNC. This entity is
a "proxy" function per se on behalf of the PNC.

Regards,

Young

Dear actn team,

If NMS 's are involved (w/o direct access to G.MPLS via (v)PCE), I believe
there are two options to distinguish further:

·         one is where the NMS shares routes through the NBI. In this case
the NMS returns 'PCE like routing data'. I call this option 2a (after
option 1 which is the G.MPLS option listed in the current draft).

·         Some NMS's I know do not even return this level of detail (option

Nico Wauters

**

---

From: Leeyoung <[email-masked]>
Date: Fri, 31 Jan 2014 16:02:08 +0000

Hi Nico,

I am in support of NMS based PNC as a place holder, but I am not sure if TMF-based solutions are sought out in IETF. VNC to PNC interaction can be internal or external (with trust and policy) and I don't see much difference if VNC interfaces NMS-based or Control Plane-based entity. As far as ACTN work is concerned, we'd develop interfaces/info models/protocols that work for both cases.

We are not talking about solutions at this stage.

Regards,
Young

From: ACTN [mailto:[email-masked]] On Behalf Of Nico Wauters
Sent: Friday, January 31, 2014 6:52 AM
To: Young Lee; [email-masked]
Subject: Re: [Actn] PNC obtained through NMS

Dear Young,

My suggestion is to put in the draft at least a placeholder for centralized PCN solutions (NMS based) as this is the hard reality.

We,  as a company, have done quite some integration projects based on "real" transport networks. In reality only few vendors, to be honest I haven't seen any, give to 3rd part software access to the control plane. By including in the ACTN drafts the NMS option for PCN, we make the concept applicable on a much larger scale.

As you suggest it would be great to have the view of other people on this mailing list

Regards
Nico

From: Young Lee [mailto:[email-masked]<mailto:[email-masked]>]
Sent: dinsdag 28 januari 2014 7:13
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Actn] PNC obtained through NMS

---------- Forwarded message ----------
From: "Young Lee" <[email-masked]<mailto:[email-masked]>>
Date: Jan 28, 2014 12:11 AM
Subject: Re: [Actn] PNC obtained through NMS
To: "Nico Wauters" <[email-masked]<mailto:[email-masked]>>
Cc:

Hi Nico,

This issue may be a bit sticky whether the actn work addresses tmf based solutions on the vpi interface. I see that the vpi requirements can be shared with control plane based PNC and NMS based PNC. Yet in terms of developing 'standard' solution in IETF, tmf based solution is out of the scope of Actn in my view. You can still claim that tmf based solution is standard based (as tmf is a SDO) --- we have no problem with that. In the Actn problem space in IETF, we would like develop one protocol solution that works primary with control plane based PNC while supporting NMS based PNC.

Regards,
Young
On Jan 23, 2014 2:59 AM, "Nico Wauters" <[email-masked]<mailto:[email-masked]>> wrote:
Young, please find a further comment from me on standard NMS NBI below in yellow.
Regards Nico

From: Leeyoung [mailto:[email-masked]<mailto:[email-masked]>]
Sent: dinsdag 21 januari 2014 22:31
To: Nico Wauters
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] PNC obtained through NMS

Hi Nico,

Thanks.
Young

From: Nico Wauters [mailto:[email-masked]]
Sent: Tuesday, January 21, 2014 11:40 AM
To: Leeyoung
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Actn] PNC obtained through NMS

Nico >> I agree, I propose however to be pragmatic in labelling something proprietary and standard.
Note that in our experience, there are, next to the g.mlps/pce based solutions also north bound interfaces for  NMS that can be categorized as standardized (e.g. the tmforum standard previously TMF814 based on Corba and MTOSI).
Both tmforum/NBI standards allow the NMS to expose topology and support provisioning of connections matching exactly the requirements mentioned in figure 4 of the draft of section 5.4 for PCE.

Hence my proposal is to refer in the doc to e.g. tmforum NBI standards (for centralized managed solutions) as alternative to PCE based solutions that rely on distributed control.

2.       Link utilization?

5.       ....

Regards

Nico

Hi Nico,

Regards,
Young

Dear actn team,

Nico Wauters

T: +32 2 211 34 62<tel:%2B32%202%20211%2034%2062> | M: +32 497480614<tel:%2B32%20497480614> | Fax: +32 2 218 89 73<tel:%2B32%202%20218%2089%2073>
E: [email-masked]<mailto:[email-masked]> | W: www.networkmining.com<http://www.networkmining.com/>

_______________________________________________
ACTN mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/actn