Date   

fd.io information visiblity

Joel Halpern
 

For those of us working on this project, we know to look at the wiki, and after a little while where on the wiki to look for information.

 

For an outsider trying to get information, they start from the www.fd.io page.

If they are looking for information on our projects, they have to guess that they should look under “community”, and then go to the “developer wiki” (even though they are not a developer) and then find the projects.

 

It seems like it would help if www.fd.io would clearly identify some of the information from the wiki that is of use to visitors.

I know we can correct this directly, but I believe we can ask LF staff to do so?

Do others share this concern?

 

Yours,

Joel


fd.io Events page on Wiki

Edward Warnicke
 

We now have an fd.io Events Page on the wiki:


Currently it has content for ONS 2016 (next week):


Ed


Lets OpenSource our fd.io decks on the wiki

Edward Warnicke
 

One of the things I've found very helpful in other communities, is folks Open Sourcing their decks for talks given about community topics so we can share and improve on each others slides.

I've started a page on the wiki here:


For that purpose.  Please feel free to add to it :)

Ed


Re: Agenda for today's meeting

Edward Warnicke
 

No worries, it brings up the fact we should probably have a standing agenda item for folks to talk about project's in preformation :)

Ed

On Thu, Mar 10, 2016 at 8:17 AM, Keith Burns <alagalah@...> wrote:
Sorry for the short notice, but was wondering if I could get a mention for putting together a NETLINK project proposal and gauging interest. 

I know of at least 4 folks:
  • me, Matt Johnson, Frederick Kautz, Christopher Liljenstolpe.
The idea would be to create a gdoc/unlinked wiki page to iterate on the proposal (eschewing more meetings) and I may set up an “unofficial” #fdio-netlink IRC channel if folks would prefer to try and use that to discuss.

Thanks.

_______________________________________________
tsc mailing list
tsc@...
https://lists.fd.io/mailman/listinfo/tsc


Agenda for today's meeting

Keith Burns <alagalah@...>
 

Sorry for the short notice, but was wondering if I could get a mention for putting together a NETLINK project proposal and gauging interest. 

I know of at least 4 folks:
  • me, Matt Johnson, Frederick Kautz, Christopher Liljenstolpe.
The idea would be to create a gdoc/unlinked wiki page to iterate on the proposal (eschewing more meetings) and I may set up an “unofficial” #fdio-netlink IRC channel if folks would prefer to try and use that to discuss.

Thanks.


Reminder: fd.io TSC Meeting this morning, new Webex

Edward Warnicke
 

Just a reminder to folks that the TSC meeting is at 8am PST this morning,
and the logistics of the meeting are all here:


Please note, the Webex has changed since last week, so go to the one on the web page :)

Ed


Re: Request Creation Review for Overlay Network Engine

Vina Ermagan
 

Great, thank you.

Best,
Vina

From: Edward Warnicke <hagbard@...>
Date: Tuesday, March 8, 2016 at 11:22 AM
To: Vina Ermagan <vermagan@...>
Cc: "tsc@..." <tsc@...>, "Florin Coras (fcoras)" <fcoras@...>
Subject: Re: [tsc] Request Creation Review for Overlay Network Engine

Thank you for your request, I have added you to the future agenda items here:


Ed

On Mon, Mar 7, 2016 at 4:37 PM, Vina Ermagan (vermagan) <vermagan@...> wrote:

Dear TSC,

Overlay Network Engine (ONE) proposed a project on 03/07/2016:

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

https://lists.fd.io/pipermail/project-lifecycle/2016-March/000000.html

I would like to request a creation review for Overlay Network Engine on 03/24/2016.

Thank you,

Vina Ermagan



_______________________________________________
tsc mailing list
tsc@...
https://lists.fd.io/mailman/listinfo/tsc


Re: Request Creation Review for Overlay Network Engine

Edward Warnicke
 

Thank you for your request, I have added you to the future agenda items here:


Ed

On Mon, Mar 7, 2016 at 4:37 PM, Vina Ermagan (vermagan) <vermagan@...> wrote:

Dear TSC,

Overlay Network Engine (ONE) proposed a project on 03/07/2016:

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

https://lists.fd.io/pipermail/project-lifecycle/2016-March/000000.html

I would like to request a creation review for Overlay Network Engine on 03/24/2016.

Thank you,

Vina Ermagan



_______________________________________________
tsc mailing list
tsc@...
https://lists.fd.io/mailman/listinfo/tsc


Apologies for Cal invites from me....

Keith Burns <alagalah@...>
 

Not sure what happened folks, I simply went to accept Ed's updates and delete the ones that had been forwarded to me... for some reason that resulted in spam from me.

Please ignore those Cal invites from me. Calendaring and I are not friends, never have been, never will :)



Invitation: VPP Weekly Project Meeting @ Tue Mar 8, 2016 6pm - 7pm (avi.dorfman@gmail.com)

Avi Dorfman <avi.dorfman@...>
 

VPP Weekly Project Meeting

When
Tue Mar 8, 2016 6pm – 7pm Jerusalem
Where
https://cisco.webex.com/ciscosales/j.php?MTID=m416dc3547e2fe977ad7b16fcc8b27547 (map)
Calendar
avi.dorfman@...
Who
Avi Dorfman - organizer
tsc@...
discuss@...
vpp-dev@...

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Request Creation Review for Overlay Network Engine

Vina Ermagan
 

Dear TSC,

Overlay Network Engine (ONE) proposed a project on 03/07/2016:

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

https://lists.fd.io/pipermail/project-lifecycle/2016-March/000000.html

I would like to request a creation review for Overlay Network Engine on 03/24/2016.

Thank you,

Vina Ermagan



Project Proposal for Overlay Network Engine

Vina Ermagan
 

Dear TSC,

Please accept this project proposal for Overlay Network Engine for consideration.

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

Thank you,

Vina Ermagan


Invitation: VPP Weekly Project Meeting @ Tue Mar 8, 2016 8am - 9am (alagalah(gmail))

Keith Burns <alagalah@...>
 

VPP Weekly Project Meeting

When
Tue Mar 8, 2016 8am – 9am Pacific Time
Where
https://cisco.webex.com/ciscosales/j.php?MTID=m416dc3547e2fe977ad7b16fcc8b27547 (map)
Calendar
alagalah(gmail)
Who
Keith Burns - organizer
tsc@...
discuss@...
vpp-dev@...

Going?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Updated Invitation: fd.io TSC Meeting @ Weekly from 9am to 10am on Thursday (fd.io Meeting and Event Details)

Edward Warnicke
 

This event has been changed.

fd.io TSC Meeting

Changed: Agenda can be found here: https://wiki.fd.io/view/TSC#Agenda

Meeting logistics can be found here:
https://wiki.fd.io/view/TSC#Meeting_Schedule_and_Logistics

When
Changed: Weekly from 9am to 10am on Thursday Mountain Time
Where
https://cisco.webex.com/ciscosales/j.php?MTID=mbad32d7a08e0d0c7727400cd34ce420d (map)
Calendar
fd.io Meeting and Event Details
Who
Ed Warnicke - creator
tsc@...
discuss@...
vpp-dev@...

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Updated Invitation: fd.io TSC Meeting @ Weekly from 9am to 10am on Thursday (fd.io Meeting and Event Details)

Edward Warnicke
 

This event has been changed.

fd.io TSC Meeting

Agenda can be found here: https://wiki.fd.io/view/TSC#Agenda


https://cisco.webex.com/ciscosales/j.php?MTID=mbad32d7a08e0d0c7727400cd34ce420d

Password: default
Meeting number:203 059 649
Host key: 202817

Audio connection:
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)

When
Weekly from 9am to 10am on Thursday Mountain Time
Where
https://cisco.webex.com/ciscosales/j.php?MTID=mbad32d7a08e0d0c7727400cd34ce420d (map)
Calendar
fd.io Meeting and Event Details
Who
Ed Warnicke - creator
tsc@...
discuss@...
vpp-dev@...

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Updated Invitation: VPP Weekly Project Meeting @ Weekly from 9am to 10am on Tuesday (fd.io Meeting and Event Details)

Edward Warnicke
 

This event has been changed.

VPP Weekly Project Meeting

Changed: This is the weekly VPP Project Meeting

Agenda: https://wiki.fd.io/view/VPP/Meeting#Agenda

Meeting Logistics: https://wiki.fd.io/view/VPP/Meeting#Meeting_Details
(please note, due to technical difficulties, the Webex has been changed since last week (Mar 1,2016).

When
Changed: Weekly from 9am to 10am on Tuesday Mountain Time
Where
https://cisco.webex.com/ciscosales/j.php?MTID=m416dc3547e2fe977ad7b16fcc8b27547 (map)
Calendar
fd.io Meeting and Event Details
Who
Ed Warnicke - creator
tsc@...
discuss@...
vpp-dev@...

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Updated Invitation: VPP Weekly Project Meeting @ Weekly from 9am to 10am on Tuesday (fd.io Meeting and Event Details)

Edward Warnicke
 

This event has been changed.

VPP Weekly Project Meeting

This is the weekly VPP Project Meeting

Agenda: https://wiki.fd.io/view/VPP/Meeting#Agenda

https://cisco.webex.com/ciscosales/j.php?MTID=m416dc3547e2fe977ad7b16fcc8b27547

Meeting number: 203 537 710
Meeting password: default
Host key: 913173

Join by phone
+1-408-525-6800 Call-in toll number (US/Canada)
+1-866-432-9903 Call-in toll-free number (US/Canada)
Access code: 203 537 710
Numeric meeting password: 98137286

Global Call in Numbers: https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=339843062&tollFree=1

Toll Free Calling Restrictions: https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=339843062&tollFree=1

When
Weekly from 9am to 10am on Tuesday Mountain Time
Where
https://cisco.webex.com/ciscosales/j.php?MTID=m416dc3547e2fe977ad7b16fcc8b27547 (map)
Calendar
fd.io Meeting and Event Details
Who
Ed Warnicke - creator
tsc@...
discuss@...
vpp-dev@...

Going?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


TSC Agenda for Mar 10, 2016

Edward Warnicke
 

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


In addition, because we have several agenda items for subsequent meetings that we already knowa about, those are being tracked here:


Ed


Re: Project Proposal for NSH-Based Service Function Chaining

Ash <ashlee@...>
 

Makes sense to me. 

On Sun, Mar 6, 2016 at 5:44 PM, Keith Burns (krb) <krb@...> wrote:

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

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!
>>>
>