Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? My only comment is the same as the one I placed on the telco-wg service function chaining spec [1]. That is, I don't believe this work should be done in the Neutron API at all. Rather, I believe these concepts belong in an entirely separate (from Neutron) API endpoint and project. Of course, the reference implementation of service function chaining would make calls out to the Neutron API for plumbing purposes -- e.g. make me a port on this L2 network, etc. I strongly believe having a separate project for service function chaining is the right long-term strategy for this, since the SFC concepts are not the same as Neutron's. SFC isn't really about networking (in terms of connectivity). Instead, SFC is about the *orchestration* of virtual (and sometimes non-virtual) resources into a hot-reconfigurable pipeline for directing packets across the network. Thoughts? -jay [1] https://review.openstack.org/#/c/169201/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
On 18 June 2015 at 09:54, Jay Pipes jaypi...@gmail.com wrote: On 06/18/2015 12:46 PM, Armando M. wrote: On 18 June 2015 at 04:30, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? My only comment is the same as the one I placed on the telco-wg service function chaining spec [1]. That is, I don't believe this work should be done in the Neutron API at all. Rather, I believe these concepts belong in an entirely separate (from Neutron) API endpoint and project. Of course, the reference implementation of service function chaining would make calls out to the Neutron API for plumbing purposes -- e.g. make me a port on this L2 network, etc. I strongly believe having a separate project for service function chaining is the right long-term strategy for this, since the SFC concepts are not the same as Neutron's. SFC isn't really about networking (in terms of connectivity). Instead, SFC is about the *orchestration* of virtual (and sometimes non-virtual) resources into a hot-reconfigurable pipeline for directing packets across the network. That's along the same lines of the comments I made on the same spec [1]. Having said that, in my opinion to realize Service Function Chaining use cases more than one API (extension) is required, because more than one component needs to be involved (from compute all the way to networking elements). And yes, you do need an orchestrator for that and I don't believe this orchestrator is Neutron. The effort initiated here is an acknowledgement of this fact. The API (and following PoC's) underpinning this effort will be solely focused on the chaining/traffic classification/flow handling aspect of the broad SFC universe. Once it is done, it won't be complete, in the sense that something else needs to tell us how to create and managed the (and I quote you) hot-reconfigurable pipeline for directing packets across the network. After all, Neutron needs to understand how to direct packets across the network, and we cannot do that today (at least in a flexible and API driven manner). This is what this effort is about. Perhaps we should make this clearer. There a WIP proposal defined in [2], and it is still taking shape. It would be great if you could provide your input along the way. Do you think we're aligning in the thinking process? OK, cool, glad to hear this. Yes, that would work for me. And yeah, I'll review the [2] proposal. Sweet! Cheers, Armando Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
On 18 June 2015 at 04:30, Jay Pipes jaypi...@gmail.com wrote: On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? My only comment is the same as the one I placed on the telco-wg service function chaining spec [1]. That is, I don't believe this work should be done in the Neutron API at all. Rather, I believe these concepts belong in an entirely separate (from Neutron) API endpoint and project. Of course, the reference implementation of service function chaining would make calls out to the Neutron API for plumbing purposes -- e.g. make me a port on this L2 network, etc. I strongly believe having a separate project for service function chaining is the right long-term strategy for this, since the SFC concepts are not the same as Neutron's. SFC isn't really about networking (in terms of connectivity). Instead, SFC is about the *orchestration* of virtual (and sometimes non-virtual) resources into a hot-reconfigurable pipeline for directing packets across the network. That's along the same lines of the comments I made on the same spec [1]. Having said that, in my opinion to realize Service Function Chaining use cases more than one API (extension) is required, because more than one component needs to be involved (from compute all the way to networking elements). And yes, you do need an orchestrator for that and I don't believe this orchestrator is Neutron. The effort initiated here is an acknowledgement of this fact. The API (and following PoC's) underpinning this effort will be solely focused on the chaining/traffic classification/flow handling aspect of the broad SFC universe. Once it is done, it won't be complete, in the sense that something else needs to tell us how to create and managed the (and I quote you) hot-reconfigurable pipeline for directing packets across the network. After all, Neutron needs to understand how to direct packets across the network, and we cannot do that today (at least in a flexible and API driven manner). This is what this effort is about. Perhaps we should make this clearer. There a WIP proposal defined in [2], and it is still taking shape. It would be great if you could provide your input along the way. Do you think we're aligning in the thinking process? Thanks, Armando Thoughts? -jay [1] https://review.openstack.org/#/c/169201/ [2] https://review.openstack.org/#/c/192933/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
On 06/18/2015 12:46 PM, Armando M. wrote: On 18 June 2015 at 04:30, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 06/17/2015 02:24 PM, Cathy Zhang wrote: Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? My only comment is the same as the one I placed on the telco-wg service function chaining spec [1]. That is, I don't believe this work should be done in the Neutron API at all. Rather, I believe these concepts belong in an entirely separate (from Neutron) API endpoint and project. Of course, the reference implementation of service function chaining would make calls out to the Neutron API for plumbing purposes -- e.g. make me a port on this L2 network, etc. I strongly believe having a separate project for service function chaining is the right long-term strategy for this, since the SFC concepts are not the same as Neutron's. SFC isn't really about networking (in terms of connectivity). Instead, SFC is about the *orchestration* of virtual (and sometimes non-virtual) resources into a hot-reconfigurable pipeline for directing packets across the network. That's along the same lines of the comments I made on the same spec [1]. Having said that, in my opinion to realize Service Function Chaining use cases more than one API (extension) is required, because more than one component needs to be involved (from compute all the way to networking elements). And yes, you do need an orchestrator for that and I don't believe this orchestrator is Neutron. The effort initiated here is an acknowledgement of this fact. The API (and following PoC's) underpinning this effort will be solely focused on the chaining/traffic classification/flow handling aspect of the broad SFC universe. Once it is done, it won't be complete, in the sense that something else needs to tell us how to create and managed the (and I quote you) hot-reconfigurable pipeline for directing packets across the network. After all, Neutron needs to understand how to direct packets across the network, and we cannot do that today (at least in a flexible and API driven manner). This is what this effort is about. Perhaps we should make this clearer. There a WIP proposal defined in [2], and it is still taking shape. It would be great if you could provide your input along the way. Do you think we're aligning in the thinking process? OK, cool, glad to hear this. Yes, that would work for me. And yeah, I'll review the [2] proposal. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? Thanks, Cathy From: Nicolas BOUTHORS [mailto:nicolas.bouth...@qosmos.com] Sent: Wednesday, June 17, 2015 12:03 AM To: Armando Migliaccio; Henry Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; Cathy Zhang; Moshe Levi; Joe D'Andrea; Ryan Tidwell; Vikram Choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: RE: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining In IETF SFC draft-penno-sfc-appid-00 proposed a notion of ApplicationId, a generic attribute that can be included in NSH metadata. This reflects also on ODL SFC wich has introduced the Application Id as a parameter that can be used by the Classifier to steer traffic into a chain. I suggest we include this parameter in the Flow Filter resource, so that application aware service chaining can be done. ApplicationId is typically encoded in a 32 bit field. Application Identification Data Format The following table displays the Selector ID default length for the different Classification Engine IDs. Classification Selector ID default Engine ID Name length (in bytes) IANA-L3 1 PANA-L3 1 IANA-L4 2 PANA-L4 2 USER-Defined 3 PANA-L2 5 PANA-L7 3 ETHERTYPE2 LLC 1 PANA-L7-PEN 3 (*) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Class. Eng. ID |zero-valued upper-bits ... Selector ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nicolas -Original Message- From: Jenkins (Code Review) [mailto:rev...@openstack.org] Sent: mercredi 17 juin 2015 08:46 To: Armando Migliaccio; Louis Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; cathy; Moshe Levi; Joe D'Andrea; Ryan Tidwell; vikram.choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining Jenkins has posted comments on this change. Change subject: Neutron API for Service Chaining .. Patch Set 8: Verified+1 Build succeeded (check pipeline). - gate-neutron-specs-docs http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62//doc/build/html/http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62/doc/build/html/ : SUCCESS in 3m 51s - gate-neutron-specs-python27 http://logs.openstack.org/46/177946/8/check/gate-neutron-specs-python27/271ef19/ : SUCCESS in 2m 31s -- To view, visit https://review.openstack.org/177946 To unsubscribe, visit https://review.openstack.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ic0df6070fefd9ead6589fa2da6c49824d7ae3941 Gerrit-PatchSet: 8 Gerrit-Project: openstack/neutron-specs Gerrit-Branch: master Gerrit-Owner: Louis Fourie louis.fou...@huawei.commailto:louis.fou...@huawei.com Gerrit-Reviewer: Adolfo Duarte adolfo.dua...@hp.commailto:adolfo.dua...@hp.com Gerrit-Reviewer: Armando Migliaccio arma...@gmail.commailto:arma...@gmail.com Gerrit-Reviewer: Berezovsky Irena irenab@gmail.commailto:irenab@gmail.com Gerrit-Reviewer: Bob Melander bob.melan...@gmail.commailto:bob.melan...@gmail.com Gerrit-Reviewer: Gal Sagie
Re: [openstack-dev] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining
Hi Nicolas, Thanks for your suggestion. Yes, we can add Application ID to the parameter of the flow classifier/filter. The next updated version will reflect this. Actually in its existing design, the parameter field of the flow classifier can be extended in the future to include more flow descriptors for more granular differentiation of flows. Per earlier suggestion from Isaku etc., we can also add a “context” field to the service chain API. The context field will include information such as “the encapsulation mechanism” used by the service functions in the chain, which can be NSH, VLAN, none etc. so that the Service Function Forwarder (the vSwcitch) knows whether it should act as a SFC proxy or not and if acting as a Proxy, what is the chain correlation mechanism between the Service Function Forwarder and the Service Function. Any comments/questions/suggestions? Thanks, Cathy From: Nicolas BOUTHORS [mailto:nicolas.bouth...@qosmos.com] Sent: Wednesday, June 17, 2015 12:03 AM To: Armando Migliaccio; Henry Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; Cathy Zhang; Moshe Levi; Joe D'Andrea; Ryan Tidwell; Vikram Choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: RE: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining In IETF SFC draft-penno-sfc-appid-00 proposed a notion of ApplicationId, a generic attribute that can be included in NSH metadata. This reflects also on ODL SFC wich has introduced the Application Id as a parameter that can be used by the Classifier to steer traffic into a chain. I suggest we include this parameter in the Flow Filter resource, so that application aware service chaining can be done. ApplicationId is typically encoded in a 32 bit field. Application Identification Data Format The following table displays the Selector ID default length for the different Classification Engine IDs. Classification Selector ID default Engine ID Name length (in bytes) IANA-L3 1 PANA-L3 1 IANA-L4 2 PANA-L4 2 USER-Defined 3 PANA-L2 5 PANA-L7 3 ETHERTYPE2 LLC 1 PANA-L7-PEN 3 (*) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Class. Eng. ID |zero-valued upper-bits ... Selector ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nicolas -Original Message- From: Jenkins (Code Review) [mailto:rev...@openstack.org] Sent: mercredi 17 juin 2015 08:46 To: Armando Migliaccio; Louis Fourie Cc: Isaku Yamahata; Gal Sagie; vishwanath jayaraman; Swaminathan Vasudevan; Ila Palanisamy; Adolfo Duarte; Ritesh Anand; Lynn Li; Bob Melander; Berezovsky Irena; Subrahmanyam Ongole; cathy; Moshe Levi; Joe D'Andrea; Ryan Tidwell; vikram.choudhary; Ruijing; Yatin Kumbhare; Miguel Angel Ajo; Numan Siddique; Yuriy Babenko; YujiAzama Subject: Change in openstack/neutron-specs[master]: Neutron API for Service Chaining Jenkins has posted comments on this change. Change subject: Neutron API for Service Chaining .. Patch Set 8: Verified+1 Build succeeded (check pipeline). - gate-neutron-specs-docs http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62//doc/build/html/http://docs-draft.openstack.org/46/177946/8/check/gate-neutron-specs-docs/6955f62/doc/build/html/ : SUCCESS in 3m 51s - gate-neutron-specs-python27 http://logs.openstack.org/46/177946/8/check/gate-neutron-specs-python27/271ef19/ : SUCCESS in 2m 31s -- To view, visit https://review.openstack.org/177946 To unsubscribe, visit https://review.openstack.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ic0df6070fefd9ead6589fa2da6c49824d7ae3941 Gerrit-PatchSet: 8 Gerrit-Project: openstack/neutron-specs Gerrit-Branch: master Gerrit-Owner: Louis Fourie louis.fou...@huawei.commailto:louis.fou...@huawei.com Gerrit-Reviewer: Adolfo Duarte adolfo.dua...@hp.commailto:adolfo.dua...@hp.com Gerrit-Reviewer: Armando Migliaccio arma...@gmail.commailto:arma...@gmail.com Gerrit-Reviewer: Berezovsky Irena irenab@gmail.commailto:irenab@gmail.com Gerrit-Reviewer: Bob Melander bob.melan...@gmail.commailto:bob.melan...@gmail.com Gerrit-Reviewer: Gal Sagie
