IETF conflict review for draft-irtf-sdnrg-layer-terminology
conflict-review-irtf-sdnrg-layer-terminology-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-10-20
|
01 | Amy Vezza | 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 … 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 |
2014-10-20
|
01 | Amy Vezza | IESG has approved the conflict review response |
2014-10-20
|
01 | Amy Vezza | Closed "Approve" ballot |
2014-10-20
|
01 | Amy Vezza | Conflict Review State changed to Approved No Problem - announcement sent from Approved No Problem - announcement to be sent |
2014-10-16
|
01 | Cindy Morgan | Conflict Review State changed to Approved No Problem - announcement to be sent from IESG Evaluation |
2014-10-16
|
01 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-10-16
|
01 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-10-15
|
01 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-10-15
|
01 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2014-10-15
|
01 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-10-14
|
01 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2014-10-14
|
01 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-10-14
|
01 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-10-14
|
01 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-10-14
|
01 | Adrian Farrel | [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 … [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. |
2014-10-14
|
01 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-10-13
|
01 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-10-13
|
01 | Benoît Claise | [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 … [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. |
2014-10-13
|
01 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-10-12
|
01 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-10-11
|
01 | Adrian Farrel | [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 … [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 |
2014-10-11
|
01 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-10-11
|
01 | Adrian Farrel | [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 … [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). |
2014-10-11
|
01 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-10-11
|
01 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-10-11
|
01 | Adrian Farrel | Created "Approve" ballot |
2014-10-11
|
01 | Adrian Farrel | Conflict Review State changed to IESG Evaluation from AD Review |
2014-10-11
|
01 | Adrian Farrel | New version available: conflict-review-irtf-sdnrg-layer-terminology-01.txt |
2014-10-11
|
00 | Adrian Farrel | New version available: conflict-review-irtf-sdnrg-layer-terminology-00.txt |
2014-10-01
|
00 | Adrian Farrel | Telechat date has been changed to 2014-10-16 from 2014-10-02 |
2014-10-01
|
00 | Adrian Farrel | Conflict Review State changed to AD Review from Needs Shepherd |
2014-10-01
|
00 | Adrian Farrel | Shepherding AD changed to Adrian Farrel |
2014-10-01
|
00 | Cindy Morgan | Notification list changed to : "Lars Eggert" , draft-irtf-sdnrg-layer-terminology@tools.ietf.org, dmm@sprint.net, irsg@irtf.org |
2014-10-01
|
00 | Cindy Morgan | Placed on agenda for telechat - 2014-10-02 |
2014-10-01
|
00 | Cindy Morgan | Notification list changed to : "Lars Eggert" , draft-irtf-sdnrg-layer-terminology@tools.ietf.org, dmm@sprint.net |
2014-10-01
|
00 | Lars Eggert | IETF conflict review requested |