Date   

Re: Project Proposal for NSH-Based Service Function Chaining

Keith Burns (krb) <krb@...>
 

I think this is all good.

If we keep the context that VPP is a dataplane, that needs to interface with a control plane it's all good.

Then things like SF proxy/bypass become use-cases for individual features such as NSI decrement.

It's possible in the future NSH could be used for other use cases, but for now, the dataplane features enabling SFC support are a great start

For example, we may not explicitly be doing any SFC OAM Rfc but instead providing explicit  features that enable it as a use case.

It may seem like sophistry but I assure you it's not. Many (all) the SFC rfcs require both control and data plane features. As such, the dataplane can provide the enabling features, and commensurate API to the control plane, and thats what we should be after.

In short, we treat things like SFC RFCs as use cases to support rather than complete compliance (we would be compliant with the data plane portions)

Hope that makes sense

On Mar 6, 2016 4:32 PM, "Joel M. Halpern" <jmh@...> wrote:
With regard to the service functions, I beliee we agree that service
functions enabled and assisted by VPP is in scope for the entirety of
fd.io.  And is useful.

I have not done much project creration in modern open soruce software,
but it seems to me that the scope is only useful if we keep it bounded.
  Given the broad range of service functions taht can leverage VPP (and
may or may not choose to tie to SFC), my gut feel is to keep the line as
currently drawn.  But folks with more experience can slap me upside the
head.

Yours,
Joel

On 3/6/16 7:14 PM, Zhou, Danny wrote:
> More comments inline.
>
>> -----Original Message-----
>> From: Joel M. Halpern [mailto:jmh@...]
>> Sent: Sunday, March 06, 2016 11:38 PM
>> To: Zhou, Danny; Jim Guichard (jguichar); tsc@...
>> Cc: Ed Warnicke (eaw); Gasparakis, Joseph; Keith Burns (krb);
>> afredette@...; therbert@...; J.Hendergart@...; Emran
>> Chaudhry (emran); markus.magnusson@...;
>> hakan.jonsson@...; ashlee@...; Jan Medved
>> (jmedved)
>> Subject: Re: Project Proposal for NSH-Based Service Function Chaining
>>
>> Comments in line.
>> Thank you for the suggestions.
>>
>> On 3/6/16 3:17 AM, Zhou, Danny wrote:
>>> Hi Jim,
>>>
>>> I have a few comments below after reviewing the proposal:
>>>
>>> 1)Do we need to add a bullet mentioning to-be-supported NSH transport,
>>> such as VxLAN-GPE, GRE and Ethernet. I think VxLAN-GPE and GRE are
>>> mandatory, and Ethernet is optional.
>>
>> We started out by putting a list of the detailed encaps in the charter.
>>    Ed then pointed out that the charter is the scope, not the release plan.  The
>> question of which encaps to do first / later / never is a release plan question, so
>> we removed the details.  We do need to do a release plan.  I expect that which
>> encaps wil be fully supported at first will depend upon which ones people are
>> interested in making work.
>>    From a scope perspective, any and all encaps are in scope.  Thus, we left the
>> bullet under Forwarding rather vague.
>>
>
> Ok, makes sense to me now. Thanks.
>
>>>
>>> 2)How about add "Support NSH Timestamping" to the miscellaneous section.
>>> We have a DPDK based PoC to implement IETF draft
>>> https://tools.ietf.org/html/draft-browne-ietf-sfc-nsh-timestamp-00 per
>>> customer requirement about breakdown of end-to-end SFC latency to
>>> diagnostic potentiation performance issue. It is based on MD Type 2 so
>>> should be a middle term feature, but like NSH traceroute it will be
>>> very useful in the production environment.
>>
>> Maybe, following the logic above, we should reword the first bullet under
>> miscellaneous to be NSH OAM support, which would include in scope work on
>> both traceroute and timestamping, as well as other OAM work we may want to
>> support?
>>
>
> NSH OAM support covers too many different features (some of them will be submitted
> to IETF SFC working group as new drafts in the future), unlike NSH transport case above
> which implicitly points out supported transport type as defined in the NSH draft. We could
> mention a OAM framework where those individual OAM features could fit it.
>
>>>
>>> 3)Can we add "Support TCP proxy for symmetric L4 flows". Though this
>>> feature depends on VPP to add L4 protocol, it will be very useful for
>>> including those stateful L4-l7 network services to SFC in the long term.
>>
>> This looks like it would cause scope creep into the various service functions that
>> people want to support using VPP.  I am not opposed to fd.io doing such work.  I
>> even think it is useful.  I am unclear whether that belongs in this project, or some
>> other affiliated project.  (The charter talks about the ability to create groups of
>> projects for coordination, which would seem applicable when we get there.)
>>
>
> There are four kinds of components in NSH dataplanes: Classifier, SFF, NSH-proxy and SF.
> Obviously, the current scope covers first three but not the SF one. The basic feature NSH manipulation
> feature such as Decrement SI for SF use case should be easily added, even though it is not mentioned
> in the scope. The TCP proxy such as L4-L7 load balancer, is widely used in in Cloud and Telco environment
> as a SF in the SFC.
>
> Do we position NSH SFC to cover SF as well? If we position VPP itself as SF, at least its currently available
> code only support coupled VxLAN-GPE and NSH header push/pop, and there is no way to decrement SI
> as well as support stateful SFs. I was hoping the NSH SFC project could fill the gap.
>
>> Yours,
>> Joel
>>
>>>
>>> -Danny
>>>
>>> *From:*Jim Guichard (jguichar) [mailto:jguichar@...]
>>> *Sent:* Friday, March 4, 2016 11:44 PM
>>> *To:* tsc@...
>>> *Cc:* Ed Warnicke (eaw) <eaw@...>; Gasparakis, Joseph
>>> <joseph.gasparakis@...>; Keith Burns (krb) <krb@...>;
>>> afredette@...; therbert@...; J.Hendergart@...; Emran
>>> Chaudhry (emran) <emran@...>; Joel M. Halpern
>>> <jmh@...>; markus.magnusson@...;
>>> hakan.jonsson@...; Zhou, Danny <danny.zhou@...>;
>>> ashlee@...; Jan Medved (jmedved) <jmedved@...>;
>>> Jim Guichard (jguichar) <jguichar@...>
>>> *Subject:* Project Proposal for NSH-Based Service Function Chaining
>>>
>>> Please accept this project proposal for NSH-based Service Function
>>> Chaining for consideration. We would like to request scheduling for
>>> the first TSC meeting after 2 weeks have passed to allow for public review.
>>>
>>>
>>>
>>> https://wiki.fd.io/view/Project_Proposals/NSH_SFC
>>>
>>> Thank you!
>>>
>


Re: Project Proposal for NSH-Based Service Function Chaining

Joel M. Halpern <jmh@...>
 

With regard to the service functions, I beliee we agree that service functions enabled and assisted by VPP is in scope for the entirety of fd.io. And is useful.

I have not done much project creration in modern open soruce software, but it seems to me that the scope is only useful if we keep it bounded. Given the broad range of service functions taht can leverage VPP (and may or may not choose to tie to SFC), my gut feel is to keep the line as currently drawn. But folks with more experience can slap me upside the head.

Yours,
Joel

On 3/6/16 7:14 PM, Zhou, Danny wrote:
More comments inline.

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@...]
Sent: Sunday, March 06, 2016 11:38 PM
To: Zhou, Danny; Jim Guichard (jguichar); tsc@...
Cc: Ed Warnicke (eaw); Gasparakis, Joseph; Keith Burns (krb);
afredette@...; therbert@...; J.Hendergart@...; Emran
Chaudhry (emran); markus.magnusson@...;
hakan.jonsson@...; ashlee@...; Jan Medved
(jmedved)
Subject: Re: Project Proposal for NSH-Based Service Function Chaining

Comments in line.
Thank you for the suggestions.

On 3/6/16 3:17 AM, Zhou, Danny wrote:
Hi Jim,

I have a few comments below after reviewing the proposal:

1)Do we need to add a bullet mentioning to-be-supported NSH transport,
such as VxLAN-GPE, GRE and Ethernet. I think VxLAN-GPE and GRE are
mandatory, and Ethernet is optional.
We started out by putting a list of the detailed encaps in the charter.
Ed then pointed out that the charter is the scope, not the release plan. The
question of which encaps to do first / later / never is a release plan question, so
we removed the details. We do need to do a release plan. I expect that which
encaps wil be fully supported at first will depend upon which ones people are
interested in making work.
From a scope perspective, any and all encaps are in scope. Thus, we left the
bullet under Forwarding rather vague.
Ok, makes sense to me now. Thanks.


2)How about add "Support NSH Timestamping" to the miscellaneous section.
We have a DPDK based PoC to implement IETF draft
https://tools.ietf.org/html/draft-browne-ietf-sfc-nsh-timestamp-00 per
customer requirement about breakdown of end-to-end SFC latency to
diagnostic potentiation performance issue. It is based on MD Type 2 so
should be a middle term feature, but like NSH traceroute it will be
very useful in the production environment.
Maybe, following the logic above, we should reword the first bullet under
miscellaneous to be NSH OAM support, which would include in scope work on
both traceroute and timestamping, as well as other OAM work we may want to
support?
NSH OAM support covers too many different features (some of them will be submitted
to IETF SFC working group as new drafts in the future), unlike NSH transport case above
which implicitly points out supported transport type as defined in the NSH draft. We could
mention a OAM framework where those individual OAM features could fit it.


3)Can we add "Support TCP proxy for symmetric L4 flows". Though this
feature depends on VPP to add L4 protocol, it will be very useful for
including those stateful L4-l7 network services to SFC in the long term.
This looks like it would cause scope creep into the various service functions that
people want to support using VPP. I am not opposed to fd.io doing such work. I
even think it is useful. I am unclear whether that belongs in this project, or some
other affiliated project. (The charter talks about the ability to create groups of
projects for coordination, which would seem applicable when we get there.)
There are four kinds of components in NSH dataplanes: Classifier, SFF, NSH-proxy and SF.
Obviously, the current scope covers first three but not the SF one. The basic feature NSH manipulation
feature such as Decrement SI for SF use case should be easily added, even though it is not mentioned
in the scope. The TCP proxy such as L4-L7 load balancer, is widely used in in Cloud and Telco environment
as a SF in the SFC.

Do we position NSH SFC to cover SF as well? If we position VPP itself as SF, at least its currently available
code only support coupled VxLAN-GPE and NSH header push/pop, and there is no way to decrement SI
as well as support stateful SFs. I was hoping the NSH SFC project could fill the gap.

Yours,
Joel


-Danny

*From:*Jim Guichard (jguichar) [mailto:jguichar@...]
*Sent:* Friday, March 4, 2016 11:44 PM
*To:* tsc@...
*Cc:* Ed Warnicke (eaw) <eaw@...>; Gasparakis, Joseph
<joseph.gasparakis@...>; Keith Burns (krb) <krb@...>;
afredette@...; therbert@...; J.Hendergart@...; Emran
Chaudhry (emran) <emran@...>; Joel M. Halpern
<jmh@...>; markus.magnusson@...;
hakan.jonsson@...; Zhou, Danny <danny.zhou@...>;
ashlee@...; Jan Medved (jmedved) <jmedved@...>;
Jim Guichard (jguichar) <jguichar@...>
*Subject:* Project Proposal for NSH-Based Service Function Chaining

Please accept this project proposal for NSH-based Service Function
Chaining for consideration. We would like to request scheduling for
the first TSC meeting after 2 weeks have passed to allow for public review.



https://wiki.fd.io/view/Project_Proposals/NSH_SFC

Thank you!


Re: Project Proposal for NSH-Based Service Function Chaining

Zhou, Danny <danny.zhou@...>
 

More comments inline.

-----Original Message-----
From: Joel M. Halpern [mailto:jmh@...]
Sent: Sunday, March 06, 2016 11:38 PM
To: Zhou, Danny; Jim Guichard (jguichar); tsc@...
Cc: Ed Warnicke (eaw); Gasparakis, Joseph; Keith Burns (krb);
afredette@...; therbert@...; J.Hendergart@...; Emran
Chaudhry (emran); markus.magnusson@...;
hakan.jonsson@...; ashlee@...; Jan Medved
(jmedved)
Subject: Re: Project Proposal for NSH-Based Service Function Chaining

Comments in line.
Thank you for the suggestions.

On 3/6/16 3:17 AM, Zhou, Danny wrote:
Hi Jim,

I have a few comments below after reviewing the proposal:

1)Do we need to add a bullet mentioning to-be-supported NSH transport,
such as VxLAN-GPE, GRE and Ethernet. I think VxLAN-GPE and GRE are
mandatory, and Ethernet is optional.
We started out by putting a list of the detailed encaps in the charter.
Ed then pointed out that the charter is the scope, not the release plan. The
question of which encaps to do first / later / never is a release plan question, so
we removed the details. We do need to do a release plan. I expect that which
encaps wil be fully supported at first will depend upon which ones people are
interested in making work.
From a scope perspective, any and all encaps are in scope. Thus, we left the
bullet under Forwarding rather vague.
Ok, makes sense to me now. Thanks.


2)How about add "Support NSH Timestamping" to the miscellaneous section.
We have a DPDK based PoC to implement IETF draft
https://tools.ietf.org/html/draft-browne-ietf-sfc-nsh-timestamp-00 per
customer requirement about breakdown of end-to-end SFC latency to
diagnostic potentiation performance issue. It is based on MD Type 2 so
should be a middle term feature, but like NSH traceroute it will be
very useful in the production environment.
Maybe, following the logic above, we should reword the first bullet under
miscellaneous to be NSH OAM support, which would include in scope work on
both traceroute and timestamping, as well as other OAM work we may want to
support?
NSH OAM support covers too many different features (some of them will be submitted
to IETF SFC working group as new drafts in the future), unlike NSH transport case above
which implicitly points out supported transport type as defined in the NSH draft. We could
mention a OAM framework where those individual OAM features could fit it.


3)Can we add "Support TCP proxy for symmetric L4 flows". Though this
feature depends on VPP to add L4 protocol, it will be very useful for
including those stateful L4-l7 network services to SFC in the long term.
This looks like it would cause scope creep into the various service functions that
people want to support using VPP. I am not opposed to fd.io doing such work. I
even think it is useful. I am unclear whether that belongs in this project, or some
other affiliated project. (The charter talks about the ability to create groups of
projects for coordination, which would seem applicable when we get there.)
There are four kinds of components in NSH dataplanes: Classifier, SFF, NSH-proxy and SF.
Obviously, the current scope covers first three but not the SF one. The basic feature NSH manipulation
feature such as Decrement SI for SF use case should be easily added, even though it is not mentioned
in the scope. The TCP proxy such as L4-L7 load balancer, is widely used in in Cloud and Telco environment
as a SF in the SFC.

Do we position NSH SFC to cover SF as well? If we position VPP itself as SF, at least its currently available
code only support coupled VxLAN-GPE and NSH header push/pop, and there is no way to decrement SI
as well as support stateful SFs. I was hoping the NSH SFC project could fill the gap.

Yours,
Joel


-Danny

*From:*Jim Guichard (jguichar) [mailto:jguichar@...]
*Sent:* Friday, March 4, 2016 11:44 PM
*To:* tsc@...
*Cc:* Ed Warnicke (eaw) <eaw@...>; Gasparakis, Joseph
<joseph.gasparakis@...>; Keith Burns (krb) <krb@...>;
afredette@...; therbert@...; J.Hendergart@...; Emran
Chaudhry (emran) <emran@...>; Joel M. Halpern
<jmh@...>; markus.magnusson@...;
hakan.jonsson@...; Zhou, Danny <danny.zhou@...>;
ashlee@...; Jan Medved (jmedved) <jmedved@...>;
Jim Guichard (jguichar) <jguichar@...>
*Subject:* Project Proposal for NSH-Based Service Function Chaining

Please accept this project proposal for NSH-based Service Function
Chaining for consideration. We would like to request scheduling for
the first TSC meeting after 2 weeks have passed to allow for public review.



https://wiki.fd.io/view/Project_Proposals/NSH_SFC

Thank you!


Re: Project Proposal for NSH-Based Service Function Chaining

Joel M. Halpern <jmh@...>
 

Comments in line.
Thank you for the suggestions.

On 3/6/16 3:17 AM, Zhou, Danny wrote:
Hi Jim,

I have a few comments below after reviewing the proposal:

1)Do we need to add a bullet mentioning to-be-supported NSH transport,
such as VxLAN-GPE, GRE and Ethernet. I think VxLAN-GPE and GRE are
mandatory, and Ethernet is optional.
We started out by putting a list of the detailed encaps in the charter. Ed then pointed out that the charter is the scope, not the release plan. The question of which encaps to do first / later / never is a release plan question, so we removed the details. We do need to do a release plan. I expect that which encaps wil be fully supported at first will depend upon which ones people are interested in making work. From a scope perspective, any and all encaps are in scope. Thus, we left the bullet under Forwarding rather vague.


2)How about add “Support NSH Timestamping” to the miscellaneous section.
We have a DPDK based PoC to implement IETF draft
https://tools.ietf.org/html/draft-browne-ietf-sfc-nsh-timestamp-00 per
customer requirement about breakdown of end-to-end SFC latency to
diagnostic potentiation performance issue. It is based on MD Type 2 so
should be a middle term feature, but like NSH traceroute it will be very
useful in the production environment.
Maybe, following the logic above, we should reword the first bullet under miscellaneous to be NSH OAM support, which would include in scope work on both traceroute and timestamping, as well as other OAM work we may want to support?


3)Can we add “Support TCP proxy for symmetric L4 flows”. Though this
feature depends on VPP to add L4 protocol, it will be very useful for
including those stateful L4-l7 network services to SFC in the long term.
This looks like it would cause scope creep into the various service functions that people want to support using VPP. I am not opposed to fd.io doing such work. I even think it is useful. I am unclear whether that belongs in this project, or some other affiliated project. (The charter talks about the ability to create groups of projects for coordination, which would seem applicable when we get there.)

Yours,
Joel


-Danny

*From:*Jim Guichard (jguichar) [mailto:jguichar@...]
*Sent:* Friday, March 4, 2016 11:44 PM
*To:* tsc@...
*Cc:* Ed Warnicke (eaw) <eaw@...>; Gasparakis, Joseph
<joseph.gasparakis@...>; Keith Burns (krb) <krb@...>;
afredette@...; therbert@...; J.Hendergart@...; Emran
Chaudhry (emran) <emran@...>; Joel M. Halpern
<jmh@...>; markus.magnusson@...;
hakan.jonsson@...; Zhou, Danny <danny.zhou@...>;
ashlee@...; Jan Medved (jmedved) <jmedved@...>;
Jim Guichard (jguichar) <jguichar@...>
*Subject:* Project Proposal for NSH-Based Service Function Chaining

Please accept this project proposal for NSH-based Service Function
Chaining for consideration. We would like to request scheduling for the
first TSC meeting after 2 weeks have passed to allow for public review.



https://wiki.fd.io/view/Project_Proposals/NSH_SFC

Thank you!


Re: Project Proposal for NSH-Based Service Function Chaining

Zhou, Danny <danny.zhou@...>
 

Hi Jim,

 

I have a few comments below after reviewing the proposal:

1)      Do we need to add a bullet mentioning to-be-supported NSH transport, such as VxLAN-GPE, GRE and Ethernet. I think VxLAN-GPE and GRE are mandatory, and Ethernet is optional.

2)      How about add “Support NSH Timestamping” to the miscellaneous section. We have a DPDK based PoC to implement IETF draft https://tools.ietf.org/html/draft-browne-ietf-sfc-nsh-timestamp-00 per customer requirement about breakdown of end-to-end SFC latency to diagnostic potentiation performance issue. It is based on MD Type 2 so should be a middle term feature, but like NSH traceroute it will be very useful in the production environment.

3)      Can we add “Support TCP proxy for symmetric L4 flows”. Though this feature depends on VPP to add L4 protocol, it will be very useful for including those stateful L4-l7 network services to SFC in the long term.

 

-Danny

 

From: Jim Guichard (jguichar) [mailto:jguichar@...]
Sent: Friday, March 4, 2016 11:44 PM
To: tsc@...
Cc: Ed Warnicke (eaw) <eaw@...>; Gasparakis, Joseph <joseph.gasparakis@...>; Keith Burns (krb) <krb@...>; afredette@...; therbert@...; J.Hendergart@...; Emran Chaudhry (emran) <emran@...>; Joel M. Halpern <jmh@...>; markus.magnusson@...; hakan.jonsson@...; Zhou, Danny <danny.zhou@...>; ashlee@...; Jan Medved (jmedved) <jmedved@...>; Jim Guichard (jguichar) <jguichar@...>
Subject: Project Proposal for NSH-Based Service Function Chaining

 

Please accept this project proposal for NSH-based Service Function Chaining for consideration. We would like to request scheduling for the first TSC meeting after 2 weeks have passed to allow for public review. 



 

Thank you!


Re: [discuss] fd.io training and Hackfest in Santa Cruz Apr 5-7

Joel Halpern
 

Hmmm.  I am a little confused by saying that the dates can not be moved.  I can believe that the host in Santa Cruz can’t do it the next week, but it would seem that between us we could find some way to do it a week later.

I would really prefer to do that.

 

Yours,

Joel

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Edward Warnicke
Sent: Friday, March 04, 2016 10:44 AM
To: tsc@...; vpp-dev@...; discuss@...
Subject: Re: [discuss] fd.io training and Hackfest in Santa Cruz Apr 5-7

 

Other TSC members, given the tightness of time, if you would please indicate if you have any objections to scheduling this Hackfest by Monday.  Past then, I'll take silence as golden :)

 

Ed

 

 

 

On Thu, Mar 3, 2016 at 11:10 AM, Edward Warnicke <hagbard@...> wrote:

As was discussed at the TSC today, we have an opportunity to do training and HackFest in Santa Cruz Apr 4-7.  The point was made that this is also the week of IETF, and a question was asked as to whether those dates could be moved.  I checked, and they cannot.

 

Shall we proceed then to get the community together for training and a hackfest on those dates?

 

Ed

 


Request Creation Review for Honeycomb

Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES@Cisco) <mmarsale@...>
 

Honeycomb proposed a project on March 4th 2016:

 

https://lists.fd.io/pipermail/tsc/2016-March/000026.html

 

I would like to request a creation review for Honeycomb on March 24th 2016 (Thursday 8AM PST).


Project Proposal for NSH-Based Service Function Chaining

Jim Guichard (jguichar) <jguichar@...>
 

Please accept this project proposal for NSH-based Service Function Chaining for consideration. We would like to request scheduling for the first TSC meeting after 2 weeks have passed to allow for public review. 


Thank you!


Re: fd.io training and Hackfest in Santa Cruz Apr 5-7

Edward Warnicke
 

Other TSC members, given the tightness of time, if you would please indicate if you have any objections to scheduling this Hackfest by Monday.  Past then, I'll take silence as golden :)

Ed



On Thu, Mar 3, 2016 at 11:10 AM, Edward Warnicke <hagbard@...> wrote:
As was discussed at the TSC today, we have an opportunity to do training and HackFest in Santa Cruz Apr 4-7.  The point was made that this is also the week of IETF, and a question was asked as to whether those dates could be moved.  I checked, and they cannot.

Shall we proceed then to get the community together for training and a hackfest on those dates?

Ed


Project Proposal for Honeycomb

Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES@Cisco) <mmarsale@...>
 

Please accept this project proposal for Honeycomb for consideration.

 

https://wiki.fd.io/view/Project_Proposals/Honeycomb

 

 


fd.io training and Hackfest in Santa Cruz Apr 5-7

Edward Warnicke
 

As was discussed at the TSC today, we have an opportunity to do training and HackFest in Santa Cruz Apr 4-7.  The point was made that this is also the week of IETF, and a question was asked as to whether those dates could be moved.  I checked, and they cannot.

Shall we proceed then to get the community together for training and a hackfest on those dates?

Ed


Re: TSC Agenda for Mar 3, 2016

Edward Warnicke
 

Also added making infrastructure tickets visible to the community to the agenda:


Ed

On Wed, Mar 2, 2016 at 1:26 PM, Edward Warnicke <hagbard@...> wrote:
Agenda updated with:

- Events
- TSC Proxy (ie, how do we want to handle proxies as a TSC)

On Tue, Mar 1, 2016 at 11:16 AM, Edward Warnicke <hagbard@...> wrote:
The TSC Agenda for the 8am PST meeting on Thu Mar 3, 2016 is posted here:


The major item being covered is security response procedures.

Please suggest any other agenda topics :)

Ed



Re: TSC Agenda for Mar 3, 2016

Edward Warnicke
 

Agenda updated with:

- Events
- TSC Proxy (ie, how do we want to handle proxies as a TSC)

On Tue, Mar 1, 2016 at 11:16 AM, Edward Warnicke <hagbard@...> wrote:
The TSC Agenda for the 8am PST meeting on Thu Mar 3, 2016 is posted here:


The major item being covered is security response procedures.

Please suggest any other agenda topics :)

Ed


Request Creation Review for CSIT

Maciek Konstantynowicz (mkonstan)
 

CSIT proposed a project on 26 Feb 2016, at 18:29UTC:

https://lists.fd.io/pipermail/tsc/2016-February/000020.html

I would like to request a creation review for CSIT on 17-MAR-2016.
-- 
Maciek

P.S. Followed template from here: 


On 26 Feb 2016, at 18:29, Maciek Konstantynowicz (mkonstan) <mkonstan@...> wrote:

Please accept this project proposal for CSIT for consideration.

https://wiki.fd.io/view/Project_Proposals/CSIT
-- 
Maciek





TSC Agenda for Mar 3, 2016

Edward Warnicke
 

The TSC Agenda for the 8am PST meeting on Thu Mar 3, 2016 is posted here:


The major item being covered is security response procedures.

Please suggest any other agenda topics :)

Ed


Project Proposal for CSIT

Maciek Konstantynowicz (mkonstan)
 

Please accept this project proposal for CSIT for consideration.

https://wiki.fd.io/view/Project_Proposals/CSIT
-- 
Maciek




TSC Meeting Minutes from 2016-02-25

Edward Warnicke
 


Reminder, fd.io TSC meeting at 8am PST tomorrow Thu Feb 25

Edward Warnicke
 

Meeting logistics here:


Agenda here:


Any feedback on the Agenda is welcome :)

Ed


TSC Agenda for Thursday Feb 25, 2016

Edward Warnicke
 

Please find the TSC Agenda for Thursday Feb 25, 2016 at:


Any and all feedback on the Agenda is welcome :)

Ed


[FD.io TSC] fd.io open to new Project Proposals

Edward Warnicke
 

The TSC today agreed on the 


As the mechanics for accepting new project proposals.

We look forward to proposals from the community for new projects.

Ed