IETF conflict review for draft-irtf-sdnrg-layer-terminology
conflict-review-irtf-sdnrg-layer-terminology-01

The following approval message was sent
From: The IESG
To: "Lars Eggert" , draft-irtf-sdnrg-layer-terminology@tools.ietf.org, dmm@sprint.net, irsg@irtf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-irtf-sdnrg-layer-terminology-03

The IESG has completed a review of draft-irtf-sdnrg-layer-terminology-03
consistent with RFC5742.


The IESG has no problem with the publication of 'SDN Layers and
Architecture Terminology'  as
an Informational RFC.


The IESG has concluded that this work is related to IETF work done in the
Netconf, Netmod, I2RS, PCE, BFD, and ForCES working groups, but this
relationship does not prevent publishing.


The IESG would also like the IRTF to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-irtf-sdnrg-layer-terminology/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-irtf-sdnrg-layer-terminology/

The process for such documents is described in RFC 5743 

Thank you,

The IESG Secretary

[Ballot comment]
[Comment updated to include review comments from Nobo Akiya]
[Comment updated further to include review by Julien Meuric]

In addition to my 5742 conflict review, I have also reviewed this
document. My comments are for the IRTF and authors in the hope they
may be useful for improving the document. They do not need discussion
with me unless that will be of value to the authors, and the comments
can freely be ignored or discarded.

I have sent the document to the chairs of the I2RS, PCE, and BFD
working groups to ask them to check the details in sections 4.4, 4.6,
and 4.7 respectively. I don't expect their responses to be blocking on
publication, but I do feel that their review is important.

---

Fundamentally missing in all of the descriptions of "planes" is the
concept of free, inter-entity communication within a plane. The focus
in the document is, of course, on the north/south communication between
entities in different planes, but this tends to give the impression of
isolation of entities within any one plane.

Maybe the concept of "planes" is so well known that this should be
obvious to the reader, but I feel that explaining the concept of planes
would be helpful in preventing stove-pipe thinking. This understanding
(which would be false) is only exacerbated by Figure 1 which (owing in
some part to the essentials of ASCII Art and in some part to your
intention of highlighting the north/south interactions) gives a strong
impression of a single entity in a plane doing stuff in isolation
within its own plane.

I don't propose a change to the figure, and I think a few words on the
nature of a "plane" would address the whole issue.

FWIW, the "issues" persists in the main body of text with some smudging
of terminology. Thus, in section 3.2, ...

  Each network device has
  both a Forwarding Plane and an Operational Plane.

...suggests that there are multiple instances of a plane each
instantiated in a different device. Where, I think, it's really the
other way around: each device has a presence in the various planes.

Another example is in section 3.3...

  The control plane is usually distributed and is responsible mainly
  for the configuration of the forwarding plane using a Control Plane
  Southbound Interface (CPSI) with DAL as a point of reference.  CP is
  responsible for instructing FP about how to handle network packets.

  Communication between control planes, colloquially referred to as the
  "east-west" interface, is usually implemented through gateway
  protocols such as BGP [RFC4271] or other protocols such as PCEP
  [RFC5440].

...The communication between control planes is an interesting concept
compared to the communicaiton within a control plane (which is usually
distributed as you say). I guess, from your example of BGP, that you
are talking about communications in the control plane between islands of
control plane elements that communicate amongst themselves.

------

On page 10 you have

  Further, traditionally, the control plane has been
  tightly coupled with the network device.

Yet this is in contradiction to the text on page 3

  Further, the concept
  of separating the control and data planes, which is prominent in SDN,
  has been extensively discussed even prior to 1998

And, indeed, the "traditional" tight coupling will not be recognized by
people coming from the older (and therefore more traditional?) world of
transport networking.

I think you probably just want to relax your "tightly coupled" to be
talking about the distribution of control plane function and its
implementation on network devices "in many networks especially in
Internet routers and Ethernet switches" (or some such wording).

---

Section 3.2 has

  Examples of Forwarding Plane abstraction
  models are ForCES [RFC5812] and OpenFlow [OpenFlow].  Examples of the
  Operational Plane abstraction model include the ForCES model
  [RFC5812], the YANG model [RFC6020], and SNMP MIBs [RFC3418].

This gives the impression that YANG models and MIB modules are not
examples of Forwarding Plane abstraction, but I think they are (or can
be).

---

In Section 3.3 I think you are trying to make a sideways statement about
the novelty of SDN, but you are overstating the facts.

  Communication between control planes, colloquially referred to as the
  "east-west" interface, is usually implemented through gateway
  protocols such as BGP [RFC4271] or other protocols such as PCEP
  [RFC5440]. However, the corresponding protocol messages are in fact
  exchanged in-band and subsequently redirected by the forwarding plane
  to the control plane for further processing.

Of course, it depends what you mean! Consider a device receiving
OpenFlow messages. Those messages somehow arrive through the forwarding
plane and are extracted for local processing (i.e., they are not
forwarded).

But my main beef is with you sauing that control plane messages are
exchanged in-band. This will be a surprise to implementers of optical
equipment where this is completely impossible.

---

I think that, notwithstanding your explanations, your readers will have
some problems understanding the distinction between control and
management planes as described in this document, especially sections 3.3
and 3.4. This is notwithstanding section 3.5.

People have been accustomed to considering "management plane" to be the
communication of functions in a north-south mode between a centralised
management station (under human or software control) and network
devices. Thus, an NMS programming forwarding instructions into a network
device would be considered (historically) to be interacting in the
management plane.

You are somewhat redefining this (which is fine - you can define what
you need for your own framework) so that you call these programming
instructions "CPSI", and you call the NMS that is making the programming
decisions "control plane."

I am not suggesting that you change your terminology (unless you
suddenly decide you want to!), but I am pointing out that your readers
may be stumbling (as I did) over this difference. Thus, you may want to
make your definitions of the functionality of the different planes far
clearer and possibly include a statement of the differences compared to
previous ways of discussing the topic.

---

CORBA in section 3.6 might benefit from a reference.

---

Given the content, and contrasting with section 4.1, section 4.2 should
probably be labelled
  4.2.  NETCONF / YANG

---

In Section 4.4 you say...

  Essentially, I2RS aims to make the routing information
  base (RIB) programmable thus enabling new kinds of network
  provisioning and operation.

While this is *an* aim and indeed a critical deliverable, your phrasing
seems to imply that this is *the* aim of I2RS.

Maybe your point is that, in the context of the control of forwarding
systems, this is the function most relevant to SDN that I2RS is working
on.

---

The discussion of PCEP in section 4.6 is OK as far as it goes. But more
attention should be paid to the work in the PCE working group related to
stateful and active PCEs.
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-app/
There is good background discussion of this in
https://datatracker.ietf.org/doc/draft-ietf-pce-questions/

The active PCE can be used to prod the network to establish LSPs and so
has a different place in the architecture you are describing.

Furthermore, there has been established discussion of the use of PCEP in
an even more proactive interaction with the network as discussed in
https://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/
(which is on its way toward pulication as an AD sponsored IETF consensus
informational RFC).

===================

Nobo Akiya (IETF BFD WG co-chair) provided the following additional comments. Please consider them.

Hi Authors,

I have few comments in the Section 4.7 of draft-irtf-sdnrg-layer-terminology-02.

> 4.7.  BFD
>
>    Bidirectional Forwarding Detection (BFD) [RFC5880], is an IETF-
>    standardized network protocol designed for detecting communication
>    failures between two adjacent forwarding elements.

This description is fairly good, but couple of comments.
1) Usage of "path failures" instead of "communication failures" will be more appropriate.
2) It might also be helpful to then briefly describe what "path" can include. Take a look at following documents to get ideas:
  - RFC5881 - single-hop BFD
  - RFC5883 - multi-hop BFD
  - RFC5884 - BFD MPLS
  - RFC7130 - BFD on LAG

If both comments are considered, the result might look more like BFD charter texts. If so, that's probably the right results.

http://datatracker.ietf.org/wg/bfd/charter/

>    It is intended to
>    be implemented in some component of the forwarding engine of a
>    system, in cases where the forwarding and control engines are
>    separated.

"It is intended" might be too strong.
- Yes it is true that BFD was carefully designed such that it can be implemented in hardware [easier], and there are some such implementations.
- It is also true that some implementations place the SW BFD module "close to" the forwarding engine within the system.
- However, it is also true that there are some implementations that places the SW BFD module fairly "far away" from the forwarding engine within the system.

It is, therefore IMO, too strong to say "It is intended to be implemented ..." but probably reasonable to say "It is often implemented ...".

>    BFD provides a low-overhead solution for (end-to-end)
>    detection of failures, even over technologies that have no or limited
>    support to do so, such as virtual circuits, various L3/L4 tunnels and
>    MPLS LSPs.

Couple of things threw me off from above.
- (end-to-end)
- technologies that have no or limited support to do so.

Similar to the first comment at the top of this email, my suggestion is to model this text closer to what is in the BFD charter.

>    With respect to Figure 1, a BFD agent could be a control plane
>    service or application that would use the CPSI towards the forwarding
>    plane to send/receive BFD packets.  Better, as it was intended for, a
>    BFD agent can run on the device as an application and use the
>    forwarding plane to send/receive BFD packets and update the
>    operational plane resources accordingly.

This is the paragraph that we want to get right. Using the terminologies from your document:

[snip]
      Forwarding Plane (FP) - The collection of resources across all
      network devices responsible for forwarding traffic.

      Operational Plane (OP) - The collection of resources responsible
      for managing the overall operation of individual network devices.

      Control plane (CP) - The collection of functions responsible for
      controlling one or more network devices.  CP instructs network
      devices with respect to how to process and forward packets.  The
      control plane interacts primarily with the forwarding plane and to
      a lesser extent with the operational plane.

      Management plane (MP) - The collection of functions responsible
      for monitoring, configuring and maintaining one or more network
      devices or parts of network devices.  The management plane is
      mostly related with the operational plane and less with the
      forwarding plane.
[snip]

It is clear that the BFD module will need to reside in each network device, somewhere under the DAL. The first thing that is important to figure is which element under the DAL does the BFD belong in: Forwarding Plane, App, Operational Plane. The Forwarding Plane, as described above, is responsible for forwarding traffic. That's definitely not the job of BFD. Thus I would argue that the BFD belongs in the App or Operational Plane. Either way, because the BFD is not in the Forwarding Plane, it sounds like it is through the Management Plane that BFD operations come into the DAL.

What gets more interesting is that often BFD alone is not sufficient. What I mean is that BFD is used by "something" so that "something" can quickly be notified of the path failure and react accordingly. In the SDN Layer Architecture:
1. "something" may be something residing in the Application Plane, so that it can influence the Forwarding Plane through the Control Plane.
2. "something" may be something residing in the Control Plane, so that it can influence the Forwarding Plane.

If you envision (1) to be the only case, then the Figure 1 looks correct.
If you envision (2) to also be a valid case, then the Figure 1 may need an interface (line) between the Control Plane and the Management Plane.

Something to think about.

Thanks!

-Nobo

=============

Julien Meuric co-chair of the IETF's PCE working group provided the following comments. Please consider them.

I'm rather puzzled by the 2nd paragraph in section 3.3.:
"or other protocols such as PCEP [RFC5440].  However, the corresponding
protocol messages are in fact exchanged in-band..."
2 comments:
- even if not only related to PCEP, I don't understand the use of
"however" here (feels like "in-band messaging is necessarily bad");
- AFAIK, it isn't mandatory to convey these messages in-band, and I feel
uncomfortable with a text that turns a typical use-case into a drawback
of a protocol itself.

[Ballot comment]
I feel that this document will be a foundational building block for the entire IETF and not only the SDN research community, as explained in the abstract:

    This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer- reviewed literature, the RFC series, and relevant documents by other standards organizations.


Therefore, (and maybe due to the OPS & SDN relationship), I wanted to review it. Yes, I know, IESG is supposed to only evaluate the conflict review (RFC 5732).
Disclaimer: I have not been following the sdnrg discussions.

- I'm not sure what the following statement adds:

    This document has been extensively reviewed, discussed, and commented by the vast majority of SDNRG members, a community which certainly exceeds 100 individuals. It is the consensus of SDNRG that this document should be published in the IRTF Stream RFC Series [RFC5743].


- I'm always surprised by the multiplication of planes these days: data, control, management and now operational and application
First, there is a definition for forwarding plane, but I see "data plane" being use in "Further, the concept of separating the control and data planes .."
Second, there are already some definitions in http://tools.ietf.org/html/rfc7276#section-2.2.4. This is a pity that those doc. are not in line.
Third, the term operational plane is new to me. I've been spending some time trying to understand the link with the management plane...
My personal view is that adding operational and application plane is confusing, most probably because I don't understand (any longer maybe, because I thought I did) what a "plane" is: an interface, a set of protocols and mechanisms, or a termination point (like the operational state "The operational plane is usually the termination point for management plane services and applications").
This document would benefit from an explanation (and this would be a perfect topic for SDNRG IMO). I believe that this feedback is in line with Adrian's one.

- a key aspect of SDN is the notion of "northbound" and "southbound" interfaces. If you know about controller/SDN, you know that it means northbound or southbound of a controller. This message is not clear in the document.

- I'm surprised not to see the notion of controller in figure 1
Based on my previous point, and this text ..

  The SDN northbound interface is implemented in the Network Services
  Abstraction Layer of Figure 1.

..., does it mean that the 2 middle boxes are "controllers"? I don't think so.

- Minor point.
If you define the management plane for monitoring as well (and not only configuration), then you could add IPFIX (and potentially syslog) to

  If the Management Plane is not embedded in the
  network device, the MPSI is certainly a protocol.  Examples of MPSIs
  are ForCES [RFC5810], NETCONF [RFC6241], OVSDB [RFC7047] and SNMP
  [RFC3411].

Why because it seems there is a tendency in SDN to only think of configuration for the management plane.
For example:

  In
  contrast, the management plane reacts generally at longer time
  frames, i.e. minutes, hours or even days, and thus wire-efficiency is
  not always a critical concern.  A good example of this is the case of
  changing the configuration state of the device.

If you think about IPFIX, the export rate might be X/sec where X >  1.

- I'm surprised see BFD in the draft. Why an OAM protocol in SDN? If you want to mention OAM, then why only one?

To summarize: I had a lot of hope for this document. I was hoping that it could be referred to by many other documents, WGs and BoFs (SUPA comes to mind first, then ACTN), and I'm a little bit disappointed. Would it be a WG document, I would file a DISCUSS. However, as an IESG member, I'm ONLY doing the conflict review (RFC 5732). This document doesn't conflict, so "no objection", but it leaves me with more questions than answers I'm afraid.

[Ballot comment]
[Comment updated to include review comments from Nobo Akiya]

In addition to my 5742 conflict review, I have also reviewed this
document. My comments are for the IRTF and authors in the hope they
may be useful for improving the document. They do not need discussion
with me unless that will be of value to the authors, and the comments
can freely be ignored or discarded.

I have sent the document to the chairs of the I2RS, PCE, and BFD
working groups to ask them to check the details in sections 4.4, 4.6,
and 4.7 respectively. I don't expect their responses to be blocking on
publication, but I do feel that their review is important.

---

Fundamentally missing in all of the descriptions of "planes" is the
concept of free, inter-entity communication within a plane. The focus
in the document is, of course, on the north/south communication between
entities in different planes, but this tends to give the impression of
isolation of entities within any one plane.

Maybe the concept of "planes" is so well known that this should be
obvious to the reader, but I feel that explaining the concept of planes
would be helpful in preventing stove-pipe thinking. This understanding
(which would be false) is only exacerbated by Figure 1 which (owing in
some part to the essentials of ASCII Art and in some part to your
intention of highlighting the north/south interactions) gives a strong
impression of a single entity in a plane doing stuff in isolation
within its own plane.

I don't propose a change to the figure, and I think a few words on the
nature of a "plane" would address the whole issue.

FWIW, the "issues" persists in the main body of text with some smudging
of terminology. Thus, in section 3.2, ...

  Each network device has
  both a Forwarding Plane and an Operational Plane.

...suggests that there are multiple instances of a plane each
instantiated in a different device. Where, I think, it's really the
other way around: each device has a presence in the various planes.

Another example is in section 3.3...

  The control plane is usually distributed and is responsible mainly
  for the configuration of the forwarding plane using a Control Plane
  Southbound Interface (CPSI) with DAL as a point of reference.  CP is
  responsible for instructing FP about how to handle network packets.

  Communication between control planes, colloquially referred to as the
  "east-west" interface, is usually implemented through gateway
  protocols such as BGP [RFC4271] or other protocols such as PCEP
  [RFC5440].

...The communication between control planes is an interesting concept
compared to the communicaiton within a control plane (which is usually
distributed as you say). I guess, from your example of BGP, that you
are talking about communications in the control plane between islands of
control plane elements that communicate amongst themselves.

------

On page 10 you have

  Further, traditionally, the control plane has been
  tightly coupled with the network device.

Yet this is in contradiction to the text on page 3

  Further, the concept
  of separating the control and data planes, which is prominent in SDN,
  has been extensively discussed even prior to 1998

And, indeed, the "traditional" tight coupling will not be recognized by
people coming from the older (and therefore more traditional?) world of
transport networking.

I think you probably just want to relax your "tightly coupled" to be
talking about the distribution of control plane function and its
implementation on network devices "in many networks especially in
Internet routers and Ethernet switches" (or some such wording).

---

Section 3.2 has

  Examples of Forwarding Plane abstraction
  models are ForCES [RFC5812] and OpenFlow [OpenFlow].  Examples of the
  Operational Plane abstraction model include the ForCES model
  [RFC5812], the YANG model [RFC6020], and SNMP MIBs [RFC3418].

This gives the impression that YANG models and MIB modules are not
examples of Forwarding Plane abstraction, but I think they are (or can
be).

---

In Section 3.3 I think you are trying to make a sideways statement about
the novelty of SDN, but you are overstating the facts.

  Communication between control planes, colloquially referred to as the
  "east-west" interface, is usually implemented through gateway
  protocols such as BGP [RFC4271] or other protocols such as PCEP
  [RFC5440]. However, the corresponding protocol messages are in fact
  exchanged in-band and subsequently redirected by the forwarding plane
  to the control plane for further processing.

Of course, it depends what you mean! Consider a device receiving
OpenFlow messages. Those messages somehow arrive through the forwarding
plane and are extracted for local processing (i.e., they are not
forwarded).

But my main beef is with you sauing that control plane messages are
exchanged in-band. This will be a surprise to implementers of optical
equipment where this is completely impossible.

---

I think that, notwithstanding your explanations, your readers will have
some problems understanding the distinction between control and
management planes as described in this document, especially sections 3.3
and 3.4. This is notwithstanding section 3.5.

People have been accustomed to considering "management plane" to be the
communication of functions in a north-south mode between a centralised
management station (under human or software control) and network
devices. Thus, an NMS programming forwarding instructions into a network
device would be considered (historically) to be interacting in the
management plane.

You are somewhat redefining this (which is fine - you can define what
you need for your own framework) so that you call these programming
instructions "CPSI", and you call the NMS that is making the programming
decisions "control plane."

I am not suggesting that you change your terminology (unless you
suddenly decide you want to!), but I am pointing out that your readers
may be stumbling (as I did) over this difference. Thus, you may want to
make your definitions of the functionality of the different planes far
clearer and possibly include a statement of the differences compared to
previous ways of discussing the topic.

---

CORBA in section 3.6 might benefit from a reference.

---

Given the content, and contrasting with section 4.1, section 4.2 should
probably be labelled
  4.2.  NETCONF / YANG

---

In Section 4.4 you say...

  Essentially, I2RS aims to make the routing information
  base (RIB) programmable thus enabling new kinds of network
  provisioning and operation.

While this is *an* aim and indeed a critical deliverable, your phrasing
seems to imply that this is *the* aim of I2RS.

Maybe your point is that, in the context of the control of forwarding
systems, this is the function most relevant to SDN that I2RS is working
on.

---

The discussion of PCEP in section 4.6 is OK as far as it goes. But more
attention should be paid to the work in the PCE working group related to
stateful and active PCEs.
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-app/
There is good background discussion of this in
https://datatracker.ietf.org/doc/draft-ietf-pce-questions/

The active PCE can be used to prod the network to establish LSPs and so
has a different place in the architecture you are describing.

Furthermore, there has been established discussion of the use of PCEP in
an even more proactive interaction with the network as discussed in
https://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/
(which is on its way toward pulication as an AD sponsored IETF consensus
informational RFC).

===================

Nobo Akiya (IETF BFD WG co-chair) provided the following additional comments. Please consider them.

Hi Authors,

I have few comments in the Section 4.7 of draft-irtf-sdnrg-layer-terminology-02.

> 4.7.  BFD
>
>    Bidirectional Forwarding Detection (BFD) [RFC5880], is an IETF-
>    standardized network protocol designed for detecting communication
>    failures between two adjacent forwarding elements.

This description is fairly good, but couple of comments.
1) Usage of "path failures" instead of "communication failures" will be more appropriate.
2) It might also be helpful to then briefly describe what "path" can include. Take a look at following documents to get ideas:
  - RFC5881 - single-hop BFD
  - RFC5883 - multi-hop BFD
  - RFC5884 - BFD MPLS
  - RFC7130 - BFD on LAG

If both comments are considered, the result might look more like BFD charter texts. If so, that's probably the right results.

http://datatracker.ietf.org/wg/bfd/charter/

>    It is intended to
>    be implemented in some component of the forwarding engine of a
>    system, in cases where the forwarding and control engines are
>    separated.

"It is intended" might be too strong.
- Yes it is true that BFD was carefully designed such that it can be implemented in hardware [easier], and there are some such implementations.
- It is also true that some implementations place the SW BFD module "close to" the forwarding engine within the system.
- However, it is also true that there are some implementations that places the SW BFD module fairly "far away" from the forwarding engine within the system.

It is, therefore IMO, too strong to say "It is intended to be implemented ..." but probably reasonable to say "It is often implemented ...".

>    BFD provides a low-overhead solution for (end-to-end)
>    detection of failures, even over technologies that have no or limited
>    support to do so, such as virtual circuits, various L3/L4 tunnels and
>    MPLS LSPs.

Couple of things threw me off from above.
- (end-to-end)
- technologies that have no or limited support to do so.

Similar to the first comment at the top of this email, my suggestion is to model this text closer to what is in the BFD charter.

>    With respect to Figure 1, a BFD agent could be a control plane
>    service or application that would use the CPSI towards the forwarding
>    plane to send/receive BFD packets.  Better, as it was intended for, a
>    BFD agent can run on the device as an application and use the
>    forwarding plane to send/receive BFD packets and update the
>    operational plane resources accordingly.

This is the paragraph that we want to get right. Using the terminologies from your document:

[snip]
      Forwarding Plane (FP) - The collection of resources across all
      network devices responsible for forwarding traffic.

      Operational Plane (OP) - The collection of resources responsible
      for managing the overall operation of individual network devices.

      Control plane (CP) - The collection of functions responsible for
      controlling one or more network devices.  CP instructs network
      devices with respect to how to process and forward packets.  The
      control plane interacts primarily with the forwarding plane and to
      a lesser extent with the operational plane.

      Management plane (MP) - The collection of functions responsible
      for monitoring, configuring and maintaining one or more network
      devices or parts of network devices.  The management plane is
      mostly related with the operational plane and less with the
      forwarding plane.
[snip]

It is clear that the BFD module will need to reside in each network device, somewhere under the DAL. The first thing that is important to figure is which element under the DAL does the BFD belong in: Forwarding Plane, App, Operational Plane. The Forwarding Plane, as described above, is responsible for forwarding traffic. That's definitely not the job of BFD. Thus I would argue that the BFD belongs in the App or Operational Plane. Either way, because the BFD is not in the Forwarding Plane, it sounds like it is through the Management Plane that BFD operations come into the DAL.

What gets more interesting is that often BFD alone is not sufficient. What I mean is that BFD is used by "something" so that "something" can quickly be notified of the path failure and react accordingly. In the SDN Layer Architecture:
1. "something" may be something residing in the Application Plane, so that it can influence the Forwarding Plane through the Control Plane.
2. "something" may be something residing in the Control Plane, so that it can influence the Forwarding Plane.

If you envision (1) to be the only case, then the Figure 1 looks correct.
If you envision (2) to also be a valid case, then the Figure 1 may need an interface (line) between the Control Plane and the Management Plane.

Something to think about.

Thanks!

-Nobo

[Ballot comment]
In addition to my 5742 conflict review, I have also reviewed this
document. My comments are for the IRTF and authors in the hope they
may be useful for improving the document. They do not need discussion
with me unless that will be of value to the authors, and the comments
can freely be ignored or discarded.

I have sent the document to the chairs of the I2RS, PCE, and BFD
working groups to ask them to check the details in sections 4.4, 4.6,
and 4.7 respectively. I don't expect their responses to be blocking on
publication, but I do feel that their review is important.

---

Fundamentally missing in all of the descriptions of "planes" is the
concept of free, inter-entity communication within a plane. The focus
in the document is, of course, on the north/south communication between
entities in different planes, but this tends to give the impression of
isolation of entities within any one plane.

Maybe the concept of "planes" is so well known that this should be
obvious to the reader, but I feel that explaining the concept of planes
would be helpful in preventing stove-pipe thinking. This understanding
(which would be false) is only exacerbated by Figure 1 which (owing in
some part to the essentials of ASCII Art and in some part to your
intention of highlighting the north/south interactions) gives a strong
impression of a single entity in a plane doing stuff in isolation
within its own plane.

I don't propose a change to the figure, and I think a few words on the
nature of a "plane" would address the whole issue.

FWIW, the "issues" persists in the main body of text with some smudging
of terminology. Thus, in section 3.2, ...

  Each network device has
  both a Forwarding Plane and an Operational Plane.

...suggests that there are multiple instances of a plane each
instantiated in a different device. Where, I think, it's really the
other way around: each device has a presence in the various planes.

Another example is in section 3.3...

  The control plane is usually distributed and is responsible mainly
  for the configuration of the forwarding plane using a Control Plane
  Southbound Interface (CPSI) with DAL as a point of reference.  CP is
  responsible for instructing FP about how to handle network packets.

  Communication between control planes, colloquially referred to as the
  "east-west" interface, is usually implemented through gateway
  protocols such as BGP [RFC4271] or other protocols such as PCEP
  [RFC5440].

...The communication between control planes is an interesting concept
compared to the communicaiton within a control plane (which is usually
distributed as you say). I guess, from your example of BGP, that you
are talking about communications in the control plane between islands of
control plane elements that communicate amongst themselves.

------

On page 10 you have

  Further, traditionally, the control plane has been
  tightly coupled with the network device.

Yet this is in contradiction to the text on page 3

  Further, the concept
  of separating the control and data planes, which is prominent in SDN,
  has been extensively discussed even prior to 1998

And, indeed, the "traditional" tight coupling will not be recognized by
people coming from the older (and therefore more traditional?) world of
transport networking.

I think you probably just want to relax your "tightly coupled" to be
talking about the distribution of control plane function and its
implementation on network devices "in many networks especially in
Internet routers and Ethernet switches" (or some such wording).

---

Section 3.2 has

  Examples of Forwarding Plane abstraction
  models are ForCES [RFC5812] and OpenFlow [OpenFlow].  Examples of the
  Operational Plane abstraction model include the ForCES model
  [RFC5812], the YANG model [RFC6020], and SNMP MIBs [RFC3418].

This gives the impression that YANG models and MIB modules are not
examples of Forwarding Plane abstraction, but I think they are (or can
be).

---

In Section 3.3 I think you are trying to make a sideways statement about
the novelty of SDN, but you are overstating the facts.

  Communication between control planes, colloquially referred to as the
  "east-west" interface, is usually implemented through gateway
  protocols such as BGP [RFC4271] or other protocols such as PCEP
  [RFC5440]. However, the corresponding protocol messages are in fact
  exchanged in-band and subsequently redirected by the forwarding plane
  to the control plane for further processing.

Of course, it depends what you mean! Consider a device receiving
OpenFlow messages. Those messages somehow arrive through the forwarding
plane and are extracted for local processing (i.e., they are not
forwarded).

But my main beef is with you sauing that control plane messages are
exchanged in-band. This will be a surprise to implementers of optical
equipment where this is completely impossible.

---

I think that, notwithstanding your explanations, your readers will have
some problems understanding the distinction between control and
management planes as described in this document, especially sections 3.3
and 3.4. This is notwithstanding section 3.5.

People have been accustomed to considering "management plane" to be the
communication of functions in a north-south mode between a centralised
management station (under human or software control) and network
devices. Thus, an NMS programming forwarding instructions into a network
device would be considered (historically) to be interacting in the
management plane.

You are somewhat redefining this (which is fine - you can define what
you need for your own framework) so that you call these programming
instructions "CPSI", and you call the NMS that is making the programming
decisions "control plane."

I am not suggesting that you change your terminology (unless you
suddenly decide you want to!), but I am pointing out that your readers
may be stumbling (as I did) over this difference. Thus, you may want to
make your definitions of the functionality of the different planes far
clearer and possibly include a statement of the differences compared to
previous ways of discussing the topic.

---

CORBA in section 3.6 might benefit from a reference.

---

Given the content, and contrasting with section 4.1, section 4.2 should
probably be labelled
  4.2.  NETCONF / YANG

---

In Section 4.4 you say...

  Essentially, I2RS aims to make the routing information
  base (RIB) programmable thus enabling new kinds of network
  provisioning and operation.

While this is *an* aim and indeed a critical deliverable, your phrasing
seems to imply that this is *the* aim of I2RS.

Maybe your point is that, in the context of the control of forwarding
systems, this is the function most relevant to SDN that I2RS is working
on.

---

The discussion of PCEP in section 4.6 is OK as far as it goes. But more
attention should be paid to the work in the PCE working group related to
stateful and active PCEs.
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-app/
There is good background discussion of this in
https://datatracker.ietf.org/doc/draft-ietf-pce-questions/

The active PCE can be used to prod the network to establish LSPs and so
has a different place in the architecture you are describing.

Furthermore, there has been established discussion of the use of PCEP in
an even more proactive interaction with the network as discussed in
https://datatracker.ietf.org/doc/draft-farrkingel-pce-abno-architecture/
(which is on its way toward pulication as an AD sponsored IETF consensus
informational RFC).