Subject: RE: VPN4DC at L3VPN in Taipei

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 11 Oct 2011 02:36:11 -0500

As Marshall indicated last week: VPN4DC will be discussed in the L3VPN
WG meeting in Taipei per Routing ADs' arrangement. 
There will be no BOF.
I am posting the VPN4DC BOF proposal (provided to AD on 10/2/2011) here
for the record. 
Hope this helps to provide additional background information, and
attract more interested participants.
 
VPN4DC BOF Proposal:

Working Group Name: Virtual Private Networks for Data Centers (VPN4DC)
IETF Area: Routing Area
Routing Area Director: Stewart Bryant ([email-masked])
Description of the Working Group:

The purpose of the VPN4DC is to define requirements and solutions for
establishing end-to-end (host-to-host) connectivity through layer 3 VPN
for Data Center and Cloud Services. 

(Note: The term layer 3 VPN here implies any type of IP technologies for
VPN. For example, IP VPN, BGP/MPLS VPN, or the combination of different
types of layer 3 VPNs to form end-to-end VPN solutions. These VPNs may
or may not be provisioned by Service Providers.)

Today when Data Centers are inter-connected through VPNs or other WAN
networks, the provisioning process for cloud services cross Service
Providers' and Enterprise's Data Centers, or cross different Service
Providers' Data Centers, is often manual, with long turn up time.
Security, scalability, and operational efficiency are issues due to lack
of standardized host-to-host VPN solutions. 
Modern data-centers require multi-tenant support for applications. For
security and administrative reasons it is desirable to isolate the
resources associated with a particular tenant in a VPN. This workgroup
will propose standard mechanisms to provide Layer 3 VPN connectivity to
end-systems while meeting scaling and manageability goals. This WG will
define requirements and protocol solutions to enable hosts in a Data
Center to join a specific Layer 3 VPN automatically through control
protocols, using Layer 3 VPN to provide secure any to any connections.
The Layer 3 VPN Gateway function which provides seamless VPN
connectivity between the segments of the networks will be defined.

In addition to proposing one or more layer 3 VPN technologies which
support(s) end-systems, the WG will focus on interoperability between
inter and intra DC VPN technologies and in making the VPN network
topology information available and controllable by applications.

Both of the following scenarios will be in scope:

1.	When VPN management system and Data Center management system can
communicate with each other,  the WG will identify the requirement and
protocols to automatically enable hosts in a Data Center to join a
specific VPN 

2.	When VPN management system and Data Center management system
can't communicate (which is often the case), the WG will identify the
requirement and protocols to automatically enable hosts in a Data Center
to join a specific VPN. 
The scope of the charter is limited to Layer 3 VPN solutions for Data
Center and Cloud Services with end-to-end connectivity. 
 
Non-goals: Layer 2 connectivity, and layer 3 Multicast.

The design principle for the protocols and solution development is to
leverage existing layer 3 VPN technologies already defined in IETF
whenever possible, including various IP and MPLS technologies. This
charter supports the creation of new protocols, extension to existing
protocols, and solutions proposed to use new and existing protocols.
When extending existing protocols, this WG will work with the WG(s)
responsible for the protocol being extended. 

BOF Agenda for IETF 82
November, 2011, Taibei
-	Discuss and agree on charter definitions: problems space, scope,
requirements, candidate solutions, general interests, encourage
participation from DC groups and from SP groups
-	Present initial draft of problem statements
-	Present initial draft of requirements
-	Present initial draft of use cases
-	Present one or more initial draft(s) of protocol solution(s)

Goals and Milestones for the proposed Working Group

March 2012    Post strawman WG goals and charter description
March 2012    Identify and document a limited set of candidate L3 VPN
solutions for DC
March 2012    Build small design teams for each proposed solution and
requirement doc
March 2012    Submit additional protocol definition draft(s) 
July 2012	  Submit problem statements, use case, and requirement
drafts as WG documents
July 2012     Submit initial draft of Framework document
July 2012	  Submit protocol solutions as WG documents 
July 2012	  Design teams to narrow down to small set of solutions
to be focused by WG
July 2012 	  Submit applicability statements for solutions proposed

July 2012     Post modified WG goals and charter with more details on
solutions and timelines
Nov. 2012     Submit problem statements, use cases, and requirements
draft to IESG for review
Nov. 2012	  Submit the protocol solutions to IESG for review
Nov. 2012	  Submit Framework document as WG document
Nov. 2012	  Submit applicability statements as WG documents 
Nov. 2012     Submit more protocol solutions as WG documents 
Nov. 2012     Submit initial OAM drafts 
Nov. 2012     Submit initial discovery protocol drafts
Nov. 2012     Submit initial security framework draft
Nov. 2012     Submit initial MIB drafts 
March 2013    Submit framework draft to IESG for review
March 2013	  Submit more protocol solutions and applicability
drafts to IESG for review
March 2013    Submit OAM drafts as WG document
March 2013    Submit more protocols and applicability drafts  as WG
document
March 2013    Post modified charter based on the progress of the WG
July 2013     Submit more protocol solutions and applicability drafts to
IESG for review
July 2013     Submit more protocol solutions and applicability drafts as
WG doc
July 2013     Submit security framework draft as WG document 
July 2013	  Submit discovery protocol drafts as WG documents
July 2013	  Submit MIB drafts as WG documents
July 2013	  Submit more protocols and applicability drafts  
Nov. 2013     Submit OAM drafts for IESG review 
Nov. 2013     Submit discovery protocol drafts for IESG review
Nov. 2013	  Submit more protocol solutions and applicability
drafts to IESG for review
Nov. 2013     Submit more protocol solutions and applicability drafts as
WG doc
Nov 2013      Submit Inter-op report
Nov 2013	  Post modified charter based on the progress of the WG 
March 2014    Submit security framework draft for IESG review
March 2014	  Submit MIB drafts for IESG review
March 2014 	  Submit more protocol solutions and applicability
drafts to IESG for review

In addition to the meeting in L3VPN WG session, we will also hold Bar
BOF meeting(s) in Taipei for those who are interested working on the
subject to discuss and work together. 

Thanks,
Luyuan

> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 4 Oct 2011 14:20:30 -0400
> From: Marshall Eubanks <[email-masked]>
> To: L3VPN <[email-masked]>, [email-masked],	Adrian Farrel
> 	<[email-masked]>
> Subject: VPN4DC at L3VPN in Taipei.
> Message-ID:
> 	<CAJNg7V+-
> [email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Stewart Bryant has requested that we hold an L3VPN meeting at IETF 82
> to consider and discuss VPN4DC.
> Specifically, we would
> 
> "need to emerge understanding the problem,
> the usage, the requirements, and the necessary charter changes."
> 
> This would be preparation for VPN4DC becoming a BOF.
> 
> Adrian set up some requirements for this meeting :
> 
> The problem needs to be discussed on the L3VPN list.
> 
> You need to have viable  -00 drafts before the cutoff.
> 
> Luyuan Fang has promised a draft before the cutoff.
> 
> If there is not significant discussion here on this issue, the session
> is likely to be canceled.
> 
> Please keep discussion of VPN4DC here on the L3VPN list.
> 
> Due to the tentative nature and special purpose of this meeting I
> don't think it is appropriate to make
> a general call for papers. However, if you would like to speak on
> VPN4DC, please prepare  a draft and let us (the WG Co-chairs) know.
> 
> Regards
> Marshall
> 
> P.S. Some background :
> 
> http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17)
> http://tools.ietf.org/id/draft-so-vdcs-01.txt
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 4 Oct 2011 13:36:06 -0500
> From: "Luyuan Fang (lufang)" <[email-masked]>
> To: "Marshall Eubanks" <[email-masked]>, "L3VPN"
> 	<[email-masked]>, 	"Adrian Farrel" <[email-masked]>
> Subject: RE: VPN4DC at L3VPN in Taipei.
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> Marshall,
> 
> I forwarded your mail to folks currently working on / interested in
> vpn4dc project.
> Thanks,
> Luyuan
> 
> 
> > -----Original Message-----
> > From: Marshall Eubanks [mailto:[email-masked]]
> > Sent: Tuesday, October 04, 2011 2:21 PM
> > To: L3VPN; Luyuan Fang (lufang); Adrian Farrel
> > Subject: VPN4DC at L3VPN in Taipei.
> >
> > Stewart Bryant has requested that we hold an L3VPN meeting at IETF
82
> > to consider and discuss VPN4DC.
> > Specifically, we would
> >
> > "need to emerge understanding the problem,
> > the usage, the requirements, and the necessary charter changes."
> >
> > This would be preparation for VPN4DC becoming a BOF.
> >
> > Adrian set up some requirements for this meeting :
> >
> > The problem needs to be discussed on the L3VPN list.
> >
> > You need to have viable  -00 drafts before the cutoff.
> >
> > Luyuan Fang has promised a draft before the cutoff.
> >
> > If there is not significant discussion here on this issue, the
> session
> > is likely to be canceled.
> >
> > Please keep discussion of VPN4DC here on the L3VPN list.
> >
> > Due to the tentative nature and special purpose of this meeting I
> > don't think it is appropriate to make
> > a general call for papers. However, if you would like to speak on
> > VPN4DC, please prepare  a draft and let us (the WG Co-chairs) know.
> >
> > Regards
> > Marshall
> >
> > P.S. Some background :
> >
> > http://www6.ietf.org/proceedings/81/slides/opsawg-3.pdf (page 17)
> > http://tools.ietf.org/id/draft-so-vdcs-01.txt
> 
> 
> ------------------------------
> 
> _______________________________________________
> L3VPN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l3vpn
> 
> 
> End of L3VPN Digest, Vol 88, Issue 2
> ************************************

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 11 Oct 2011 19:12:36 +0100

Luyuan,

<hat="l3VPN chair">

Some comments inline.

> Center and Cloud Services with end-to-end connectivity. 

I will admit I may not have read all the related drafts but IMO it would be good if the proposal or the drafts could be more explicit with regard to what functionality is already performed by L3VPN, what functionality is missing but you think comes under the remit of L3VPN and what functionality is required but is (at least currently) out of scope for L3VPN.

For example, (and I may have got the wrong end of the stick here) but my understanding from what I have read is that the goal is to interconnect machines (virtual or physical) in data centers via L3VPNs to other machines (virtual or physical) in the same or different data centers while also considering that those machines may move over time due to any number of reasons.

Today a customer of a VPN service can advertise which IP addresses are in which sites attached to that VPN service using a routing protocol over the CE-PE link (e.g. via OSPF) and that information is reflected to the relevant   PEs in that VPN service using MP-BGP.

It would be useful IMO if you could describe why that is not sufficient for your needs and how the current capabilities of L3VPNs map (or do not) to your needs. Is it just that the "CE" is no longer the access router for a VPN site but now starts to be implemented within a switch/router/hypervisor sat behind the access router? Is it that the CE (access router) still advertises routing to the PE as it would today but you are proposing some additional mechanism for installing state into switches/routers/hypervisors behind that CE and for how those switches/routers/hypervisors advertise that state to the CE for onward advertisement (by existing L3VPN mechanisms) to the upstream PE for that VPN site? Is it that the existing CE-PE advertisement mechanisms are unsuitable for some reason and a new CE-PE protocol is required? etc.

> -	Present one or more initial draft(s) of protocol solution(s)

While the topics above are valid topics to discuss I think it would also be beneficial to include specific aims for what you think the meeting should achieve beyond just presenting drafts and discussing material.

For example:
- Is the aim to discuss the work in general and receive feedback on it from the IETF community but nothing further at this stage?
- Is the aim to determine if there is consensus that the work is work that is required and should be taken on by IETF?
- Is the aim to determine if the work does/does not fit within the scope of L3VPN?
- etc (including some combination of the above).

> Goals and Milestones for the proposed Working Group

I think this list is far too long and likely to end up with any related discussion becoming unfocussed. Furthermore some of the milestones are pretty vague and essentially consist of "submit some more stuff for publication".

I'd suggest cutting it down considerably and focussing it on the most important items required to articulate the problem space, requirements & solutions in order to do something meaningful as a first step and have the scope/charter/problem space drafts describe why that initial focus is what you are proposing it should be in order to firstly help focus any discussions on the most important elements in order to reduce the risk of significant tangential discussions and secondly in order to demonstrate that there is a clear focus/outcome that you can envisage and that this is not intended to be an open ended project without clear goals and without any definition of when an acceptable (first stage) "end game" result has been achieved.

I'm happy to work with you (and I'm sure Marshall is too) either on the list of off-list (before bringing it back to the list to invite additional discussion on any changes) to iterate your proposal and the structure of the agenda/charter/milestones to try and ensure the discussion and outcome of the meeting is as fruitful as possible for you.

Ben

---

From: Pedro Marques <[email-masked]>
Date: Tue, 11 Oct 2011 13:36:58 -0700

Ben,

On Tue, Oct 11, 2011 at 11:12 AM, Ben Niven-Jenkins
<[email-masked]> wrote:

> It would be useful IMO if you could describe why that is not sufficient for your needs and how the current capabilities of L3VPNs map (or do not) to your needs.

The proposition is that l3vpn technology and capabilities map to the
problem of creating virtual networks for virtual machines, within and
spanning data-centers.

One common view point today, is that the VM connectivity problem
should be solved by spanning VLANs across the data-center, given the
capability to dynamically create them and adjust their membership
programatically. In that light, IP VPNs appear to be a promising
approach.

In order to achieve that, there need to be additional standardization
from what exists today. At the very least the "provisioning" interface
needs to be defined and there needs to be an appropriate interface
with the host. It is undesirable, in this space, to have IP VPN
forwarding knowledge in the data-center switching infrastructure, thus
the host becomes the CE and the PE simultaneously when it comes to
forwarding.

There are several other problems of interfacing between the
orchestration and the network control plane, which may or not be a
good fit for this group vs other groups.

My understanding is that the rational behind the vpn4dc bof proposal
is to find a home to standardize  IP VPN connectivity solutions for
VMs. The work required is probably very incremental on top of what
l3vpn has achieved so it isn't clear whether this work fits the
existing WG or if it requires some additional structure (or even if it
fits some other bof). What is believe is clear is that there is space
for a IP based solution for VM virtual networking.

regards,
  Pedro.

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 11 Oct 2011 17:17:20 -0500

Ben,

Thanks for your comments. See in-line.

> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 2:13 PM
> To: Luyuan Fang (lufang)
> Cc: [email-masked]
> Subject: Re: VPN4DC at L3VPN in Taipei
> 
> Luyuan,
> 
> <hat="l3VPN chair">
> 
> Some comments inline.
> 
> I will admit I may not have read all the related drafts but IMO it
> would be good if the proposal or the drafts could be more explicit
with
> regard to what functionality is already performed by L3VPN, what
> functionality is missing but you think comes under the remit of L3VPN
> and what functionality is required but is (at least currently) out of
> scope for L3VPN.
> 

Sure, Ning is updating the requirement draft. The old version is at 
http://tools.ietf.org/id/draft-so-vdcs-01.txt

For protocol examples, check these two new drafts.
http://tools.ietf.org/html/draft-marques-l3vpn-end-system-00
http://www.ietf.org/id/draft-marques-sdnp-flow-spec-00.txt

> For example, (and I may have got the wrong end of the stick here) but
> my understanding from what I have read is that the goal is to
> interconnect machines (virtual or physical) in data centers via L3VPNs
> to other machines (virtual or physical) in the same or different data
> centers while also considering that those machines may move over time
> due to any number of reasons.
> 
Correct.

> Today a customer of a VPN service can advertise which IP addresses are
> in which sites attached to that VPN service using a routing protocol
> over the CE-PE link (e.g. via OSPF) and that information is reflected
> to the relevant   PEs in that VPN service using MP-BGP.
> 
> It would be useful IMO if you could describe why that is not
sufficient
> for your needs and how the current capabilities of L3VPNs map (or do
> not) to your needs. Is it just that the "CE" is no longer the access
> router for a VPN site but now starts to be implemented within a
> switch/router/hypervisor sat behind the access router? Is it that the
> CE (access router) still advertises routing to the PE as it would
today
> but you are proposing some additional mechanism for installing state
> into switches/routers/hypervisors behind that CE and for how those
> switches/routers/hypervisors advertise that state to the CE for onward
> advertisement (by existing L3VPN mechanisms) to the upstream PE for
> that VPN site? Is it that the existing CE-PE advertisement mechanisms
> are unsuitable for some reason and a new CE-PE protocol is required?
> etc.
> 

Today's BGP/MPLS VPNs work well in the regular enterprise VPN scenarios.
It has been more 12 years since we first working on it. It is one of the
great technology success stories over the last decade. 

This BOF took a different focus on where and how we want to apply what
VPN technologies. It is about data center, cloud services, where the end
system is most suited with light weight control protocols. The
provisioning process today is rather segmented as we learned from
Service Providers, there is strong desire to have a standard, scalable
mechanism to solve the end-to-end/machine-to-machine connectivity
issues. Ning is updating his requirements draft to shade more light on
this. 

> While the topics above are valid topics to discuss I think it would
> also be beneficial to include specific aims for what you think the
> meeting should achieve beyond just presenting drafts and discussing
> material.
> 
> For example:
> - Is the aim to discuss the work in general and receive feedback on it
> from the IETF community but nothing further at this stage?
> - Is the aim to determine if there is consensus that the work is work
> that is required and should be taken on by IETF?

This proposed BOF had a goal to form a new WG to work on the topic,
separately from L3VPN. 

AD suggested to use L3VPN meeting session to discuss this work in
Taipei, so Chairs from L3VPN requested session for this purpose, under
the condition that we have mailing list discussion, and have at least
one vpn4dc related draft posted, otherwise there would be no L3VPN
meeting in Taipei as Marshall said in the earlier mail. 

We currently submitted two drafts, have at least two more coming soon,
and glad to see discussion picking up on the list. We also received
off-line mails from several folks expressed interests to this work. Our
goal is to together a group of people who are interested and willing to
work on the requirements and solutions, produce useful work to the end
users (SPs, DCs, Enterprises, etc.) as soon as possible.

Regarding charter, ADs/IESG will decide, I'd assume largely based on the
outcome of the meeting in Taipei, and the current mailing list
discussion. Keep in mind, there are several places involving not quite
the same but DC related discussion, some are more L2 focused, or has
application driven aspect, etc. Would be helpful for folks interested in
this work also check out the discussions in SDNP BOF (Tom forwarded the
info to this list), and NOV3 BOF (the discussion will take place in
L2VPN session and on L2VPN list).

We are using the list to discuss the vpn4dc topic as ADs instructed
(instead of using vpn4dc list), to clarify, there is no intention to
change what's working in L3VPN. This is kind of like borrowing the
"room".

> I think this list is far too long and likely to end up with any
related
> discussion becoming unfocussed. Furthermore some of the milestones are
> pretty vague and essentially consist of "submit some more stuff for
> publication".
> 
> I'd suggest cutting it down considerably and focussing it on the most
> important items required to articulate the problem space, requirements
> & solutions in order to do something meaningful as a first step and
> have the scope/charter/problem space drafts describe why that initial
> focus is what you are proposing it should be in order to firstly help
> focus any discussions on the most important elements in order to
reduce
> the risk of significant tangential discussions and secondly in order
to
> demonstrate that there is a clear focus/outcome that you can envisage
> and that this is not intended to be an open ended project without
clear
> goals and without any definition of when an acceptable (first stage)
> "end game" result has been achieved.
> 
> I'm happy to work with you (and I'm sure Marshall is too) either on
the
> list of off-list (before bringing it back to the list to invite
> additional discussion on any changes) to iterate your proposal and the
> structure of the agenda/charter/milestones to try and ensure the
> discussion and outcome of the meeting is as fruitful as possible for
> you.
> 

Sure, be happy to chat with you off-line, will ping you.

We plan to have Bar BOF meeting(s) as well to get things going. Will let
everyone know where and when once we get the room.

Thanks,
Luyuan

> > July 2013     Submit more protocol solutions and applicability
drafts
> to
> > IESG for review
> > July 2013     Submit more protocol solutions and applicability
drafts
> as
drafts
> as
--------------------------------------------------------------------
> --

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 11 Oct 2011 17:18:50 -0500

See my reply to Ben.
Luyuan

> From: UTTARO, JAMES [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 4:31 PM
> To: 'Ben Niven-Jenkins'; Luyuan Fang (lufang)
> Cc: [email-masked]
> Subject: RE: VPN4DC at L3VPN in Taipei
> 
> +1 on Ben's comments in re what functionality is missing in the
current
> L3VPN specification. I believe a detailed set of requirements will go
a
> long way in making this work applicable..
> 
> Jim Uttaro
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ben Niven-Jenkins
> To: Luyuan Fang
with
sufficient
today
related
reduce
to
clear
the
drafts
drafts
drafts

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 12 Oct 2011 01:03:08 +0100

Luyuan,

Thanks for your response. Let me say upfront that my interest in this work at this stage is purely that Marshall and I are going to have to chair your session in Taipei and so I'm just trying to understand a bit better what it is and the context of any discussion I'm expected to moderate.

More inline.
 
On 11 Oct 2011, at 23:17, Luyuan Fang (lufang) wrote:
> system is most suited with light weight control protocols.

One of the things I'm trying to understand is when & how these new light weight control protocols running on end systems in data centers are expected to interact with the existing L3VPN control protocols.

> The

One thing that might help my understanding at least would be a diagram or some prose that shows the components (hosts, gateways, CEs, PEs, etc.) sitting between a pair of hosts within the same VPN and showing what portion of that end to end flow is satisfied by existing mechanisms versus what portions require new mechanisms. I guess it might need to show two dimensions: (1) the existing/new portions required to advertise the necessary forwarding between the different components and (2) the new/existing portions required to provision services/state that is separate to the forwarding state in the different components.

Figures 1-3 in draft-so-vdcs-01 start to do that a little bit by showing different physical/logical views with respect to what a PE sees but aren't very specific in where new versus existing functionality is used to achieve the end result.
 
> discussion.

So part of my job is to chair/moderate that discussion and my questions above were meant to dig a little into what it is you want to achieve beyond just discussing some drafts, for example what sorts of questions I might be expected to ask the room to help the ADs gauge if there is consensus for whatever outcome you would ideally like to have.

If your goal is to form a WG then the most important things to present and demonstrate IMO is that you have a well understood and clearly scoped problem statement as well as a draft charter that folks agree fairly reflects the work that needs to be undertaken to address the problem statement and an initial set of milestones that are realistic and that folks agree will achieve the cited aims.

We can then focus the discussion and the available time on ensuring that folks reach a common understanding and (hopefully) consensus on those things, rather than for example letting the discussion get bogged down in the specifics of a particular solution proposal.

That is one of the reasons I suggested you significantly reduce the number of milestones you're proposing to just the most important items required to articulate the problem space, requirements & solutions needed in order to do something meaningful as a first step because I'm highly doubtful that it will be possible for us to have a focussed discussion that results in consensus for a charter that contains 39 milestones... 

Ben

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Tue, 11 Oct 2011 20:21:32 -0500

Ben,

Thanks for the discussion again. 
Appreciate the effort you are making to dig down the problem space and
making many good points. Thanks to Marshall too.

Quite agree on focusing on the requirements, it is under work by several
SP folks and others.

Regarding the diagram, absolutely, give us some time, we are
documenting.

About the milestones, we initially had a shorter list, we had comments
from AD to extend the milestones. May be we gone too far this time. I
checked the milestones of many WGs, they vary a lot, from very short to
very long, depending on the WG style and stage... In any case, we need
to continue refine it with the team, thanks for the input from you and
others.

I think we are largely in agreement. 

Luyuan

> Sent: Tuesday, October 11, 2011 8:03 PM
> To: Luyuan Fang (lufang)
> Cc: [email-masked]
> Thanks for your response. Let me say upfront that my interest in this
> work at this stage is purely that Marshall and I are going to have to
> chair your session in Taipei and so I'm just trying to understand a
bit
> better what it is and the context of any discussion I'm expected to
> moderate.
> 
> More inline.
> 
> One of the things I'm trying to understand is when & how these new
> light weight control protocols running on end systems in data centers
> are expected to interact with the existing L3VPN control protocols.
> 
> > The
> One thing that might help my understanding at least would be a diagram
> or some prose that shows the components (hosts, gateways, CEs, PEs,
> etc.) sitting between a pair of hosts within the same VPN and showing
> what portion of that end to end flow is satisfied by existing
> mechanisms versus what portions require new mechanisms. I guess it
> might need to show two dimensions: (1) the existing/new portions
> required to advertise the necessary forwarding between the different
> components and (2) the new/existing portions required to provision
> services/state that is separate to the forwarding state in the
> different components.
> 
> Figures 1-3 in draft-so-vdcs-01 start to do that a little bit by
> showing different physical/logical views with respect to what a PE
sees
> but aren't very specific in where new versus existing functionality is
> used to achieve the end result.
> 
> >>> BOF Agenda for IETF 82
> >>> November, 2011, Taibei
> So part of my job is to chair/moderate that discussion and my
questions
> above were meant to dig a little into what it is you want to achieve
> beyond just discussing some drafts, for example what sorts of
questions
> I might be expected to ask the room to help the ADs gauge if there is
> consensus for whatever outcome you would ideally like to have.
> 
> If your goal is to form a WG then the most important things to present
> and demonstrate IMO is that you have a well understood and clearly
> scoped problem statement as well as a draft charter that folks agree
> fairly reflects the work that needs to be undertaken to address the
> problem statement and an initial set of milestones that are realistic
> and that folks agree will achieve the cited aims.
> 
> We can then focus the discussion and the available time on ensuring
> that folks reach a common understanding and (hopefully) consensus on
> those things, rather than for example letting the discussion get
bogged
> down in the specifics of a particular solution proposal.
> 
> That is one of the reasons I suggested you significantly reduce the
> number of milestones you're proposing to just the most important items
> required to articulate the problem space, requirements & solutions
> needed in order to do something meaningful as a first step because I'm
> highly doubtful that it will be possible for us to have a focussed
> discussion that results in consensus for a charter that contains 39
> milestones...
> 
> Ben

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 12 Oct 2011 17:12:28 -0500

Absolutely, Jim.
It will an individual draft at first, then moving toward WG doc when
consensus is built...
Thanks,
Luyuan

> Sent: Wednesday, October 12, 2011 6:09 PM
> To: Luyuan Fang (lufang); Ben Niven-Jenkins
> Cc: [email-masked]
> Is the requirements intended as a WG document? I think it should be..
> 
> Jim Uttaro
> 
> Of Luyuan Fang (lufang)
> Sent: Tuesday, October 11, 2011 9:22 PM
> To: Ben Niven-Jenkins
> Cc: [email-masked]
> > >> Today a customer of a VPN service can advertise which IP
addresses
> > are
> > > It has been more 12 years since we first working on it. It is one
> of
> > the
> > > VPN technologies. It is about data center, cloud services, where
> the
> > end
> > > issues. Ning is updating his requirements draft to shade more
light
> > on
> > >>> -	Discuss and agree on charter definitions: problems
space,
> scope,
> > >> - Is the aim to discuss the work in general and receive feedback
> on
> > it
> > >> - Is the aim to determine if the work does/does not fit within
the
> > >> scope of L3VPN?
> > > off-line mails from several folks expressed interests to this
work.
> > Our
> > > goal is to together a group of people who are interested and
> willing
> > to
> > > Regarding charter, ADs/IESG will decide, I'd assume largely based
> on
> > the

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Wed, 12 Oct 2011 17:54:08 -0500

Sure thing.
Luyuan

> Sent: Wednesday, October 12, 2011 6:51 PM
> Pls include me in this effort..
> 
> Jim Uttaro
> 
> From: Luyuan Fang (lufang) [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2011 6:12 PM
> To: UTTARO, JAMES; Ben Niven-Jenkins
> Cc: [email-masked]
> > > >> for your needs and how the current capabilities of L3VPNs map
> (or
> > do
> > > >> switch/router/hypervisor sat behind the access router? Is it
> that
> > > the
> > > > This BOF took a different focus on where and how we want to
apply
> > > what
> > > but aren't very specific in where new versus existing
functionality
> > is
> > > >> - Is the aim to determine if there is consensus that the work
is
> > > work
> > > > work on the requirements and solutions, produce useful work to
> the
> > > end