Subject: Poll for adoption: draft-xu-l3vpn-virtual-subnet

From: Thomas Morin <[email-masked]>
Date: Tue, 04 Feb 2014 14:35:48 +0100

Hello working group,

This email starts a two-week poll on adopting
draft-xu-l3vpn-virtual-subnet [1] as a working group item.

Please send comments to the list and state if you support adoption or
not (in the later case, please also state the reasons).

This poll runs until February 9th.

*Coincidentally*, we are also polling for knowledge of any IPR that
applies to this draft, to ensure that IPR has been disclosed in
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669
and 5378 for more details).

==> *If you are listed as a document author or contributor* please
respond to this email and indicate whether or not you are aware of any 
relevant IPR.

The draft will not be adopted until a response has been received from
each author and contributor.

If you are on the L3VPN WG mailing list but are not listed as an author
or contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

Thank you,

Martin & Thomas
l3vpn chairs

[1] http://tools.ietf.org/html/draft-xu-l3vpn-virtual-subnet

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 14:38:21 +0100

WG,

I'm in favor of adopting draft-xu-l3vpn-virtual-subnet as a l3vpn WG document. As one of the co-authors, I'm not aware of any IPR pertaining to this draft.

Cheers,

Christian.

-----Message d'origine-----
De : Thomas Morin [mailto:[email-masked]] 
Envoyé : mardi 4 février 2014 14:36
À : [email-masked]
Cc : [email-masked]; Martin Vigoureux
Objet : Poll for adoption: draft-xu-l3vpn-virtual-subnet

Hello working group,

This email starts a two-week poll on adopting draft-xu-l3vpn-virtual-subnet [1] as a working group item.

Please send comments to the list and state if you support adoption or not (in the later case, please also state the reasons).

*Coincidentally*, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

==> *If you are listed as a document author or contributor* please respond to this email and indicate whether or not you are aware of any relevant IPR.

The draft will not be adopted until a response has been received from each author and contributor.

If you are on the L3VPN WG mailing list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Thank you,

Martin & Thomas
l3vpn chairs

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Tue, 4 Feb 2014 14:41:15 +0100

WG,

Cheers,

Christian.

-----Message d'origine-----

Hello working group,

Thank you,

Martin & Thomas
l3vpn chairs

---

From: Lucy yong <[email-masked]>
Date: Wed, 5 Feb 2014 22:44:06 +0000

Support!
Lucy

-----Original Message-----
From: L3VPN [mailto:[email-masked]] On Behalf Of Thomas Morin
Sent: Tuesday, February 04, 2014 7:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: Poll for adoption: draft-xu-l3vpn-virtual-subnet

Hello working group,

Thank you,

Martin & Thomas
l3vpn chairs

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 6 Feb 2014 00:15:57 +0100

Support (as co-author)
Null level of awareness of any IPR.

r.

---

From: Brendan Fee <[email-masked]>
Date: Wed, 5 Feb 2014 19:00:28 -0500

I support the adoption of the draft as a WG document. As a co-author I am also unaware of any IPR.

Thanks

Brendan
 
On Feb 5, 2014, at 6:15 PM, Robert Raszuk <[email-masked]> wrote:

> On Tue, Feb 4, 2014 at 2:35 PM, Thomas Morin <[email-masked]> wrote:
> Hello working group,
> 
> respond to this email and indicate whether or not you are aware of any relevant IPR.
>

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 7 Feb 2014 01:45:33 +0000

Support as a co-author. I'm not aware of any IPR pertaining to this draft.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Thomas Morin [mailto:[email-masked]]
> 发送时间: 2014年2月4日 21:36
> 收件人: [email-masked]
> 抄送: [email-masked]; Martin Vigoureux
> 主题: Poll for adoption: draft-xu-l3vpn-virtual-subnet
> 
> Hello working group,
> 
> Please send comments to the list and state if you support adoption or not (in the
> later case, please also state the reasons).
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that applies to
> this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> ==> *If you are listed as a document author or contributor* please respond to
> this email and indicate whether or not you are aware of any relevant IPR.
> 
> If you are on the L3VPN WG mailing list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any IPR that
> has not yet been disclosed in conformance with IETF rules.
> 
> Thank you,
> 
> Martin & Thomas
> l3vpn chairs
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 6 Feb 2014 21:32:17 -0500

Best regards,
Sue 

> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
> 
> If you are on the L3VPN WG mailing list but are not listed as an 
> author or contributor, then please explicitly respond only if you are 
> aware of any IPR that has not yet been disclosed in conformance with IETF rules.
> 
> Thank you,
> 
> Martin & Thomas
> l3vpn chairs
>

---

From: Mach Chen <[email-masked]>
Date: Sat, 8 Feb 2014 01:53:02 +0000

Support.

Best regards,
Mach

> Sent: Tuesday, February 04, 2014 9:36 PM
> To: [email-masked]
> *Coincidentally*, we are also polling for knowledge of any IPR that applies to this
> draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see
> RFCs 3979, 4879, 3669 and 5378 for more details).
>

---

From: Giles Heron <[email-masked]>
Date: Mon, 10 Feb 2014 19:29:44 +0000

I don't support adoption of this draft as a WG item (speaking as a non-author but name-checked commenter).

The draft has a major limitation (no support for interconnecting routers, but only for interconnecting hosts), and I'm unconvinced that passing /32 host routes around in BGP will scale.

sorry - just spotted the poll has already closed.

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 10 Feb 2014 21:03:30 -0500

Thomas, 

	I too object to it's adoption based on the /32 point Giles made. I think I raised this point when the draft was first presented a while back, and the numerous other times it has been proposed. This original issue appears to still exist at the heart of this solution.

	Perhaps I am missing something, but I also don't see a direct WG charter item that this document satisfies at the present time.

	--Tom

---

From: Lizhenbin <[email-masked]>
Date: Tue, 11 Feb 2014 02:40:26 +0000

Support.

We implemented the feature and it works well.

Best Regards,
Zhenbin Li

-----邮件原件-----
发件人: L3VPN [mailto:[email-masked]] 代表 Thomas Morin
发送时间: 2014年2月4日 21:36
收件人: [email-masked]
抄送: [email-masked]
主题: Poll for adoption: draft-xu-l3vpn-virtual-subnet

Hello working group,

Thank you,

Martin & Thomas
l3vpn chairs

---

From: Haoweiguo <[email-masked]>
Date: Tue, 11 Feb 2014 03:09:19 +0000

Support!
Weiguo
________________________________________
发件人: L3VPN [[email-masked]] 代表 Lucy yong [[email-masked]]
发送时间: 2014年2月6日 6:44
收件人: Thomas Morin
抄送: [email-masked]
主题: RE: Poll for adoption: draft-xu-l3vpn-virtual-subnet

Support!
Lucy

-----Original Message-----
From: L3VPN [mailto:[email-masked]] On Behalf Of Thomas Morin
Sent: Tuesday, February 04, 2014 7:36 AM
To: [email-masked]
Cc: [email-masked]
Subject: Poll for adoption: draft-xu-l3vpn-virtual-subnet

Hello working group,

Thank you,

Martin & Thomas
l3vpn chairs

---

From: Thomas Morin <[email-masked]>
Date: Tue, 11 Feb 2014 09:55:46 +0100

Hi working group,

I mistakenly set the closing date for this call for adoption to Feb 9th.
It should have been February *19th* (two week delay, as usual).

-- This poll is running through February **19th** --

Sorry for the confusion,

-Thomas

---

From: Thomas Morin <[email-masked]>
Date: Tue, 11 Feb 2014 11:06:41 +0100

Hi Giles,

2014-02-10, Giles Heron:
> The draft has a major limitation (no support for interconnecting
> routers, but only for interconnecting hosts) [...]

That would indeed be an issue if the document was aiming standard track 
to address a specific use case including router interconnections, or if 
the limitation was not documented.  But, the document is not aiming 
standard track, and has a section to document limitations to which the 
working group may contribute text for this particular limitation.

> sorry - just spotted the poll has already closed.

The date had been mistakenly set 10 days too early.
The poll is not closed yet.

-Thomas

>> Please send comments to the list and state if you support adoption
>> or not (in the later case, please also state the reasons).
>>
>> *Coincidentally*, we are also polling for knowledge of any IPR
>> that applies to this draft, to ensure that IPR has been disclosed
>> in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and
>> 5378 for more details).
>>
>> author or contributor, then please explicitly respond only if you
>> are aware of any IPR that has not yet been disclosed in conformance
>> with IETF rules.
>>
>> Thank you,
>>
>> Martin & Thomas l3vpn chairs
>>

---

From: Giles Heron <[email-masked]>
Date: Tue, 11 Feb 2014 11:31:58 +0000

Hi Thomas

I guess the way I see it is that this is such a big limitation that I find it hard to imagine anyone deploying this solution.

is there any way we could get feedback from some data center operators?  Perhaps we should ask NVO3 for comments?

Giles

On 11 Feb 2014, at 10:06, Thomas Morin <[email-masked]> wrote:

> That would indeed be an issue if the document was aiming standard track to address a specific use case including router interconnections, or if the limitation was not documented.  But, the document is not aiming standard track, and has a section to document limitations to which the working group may contribute text for this particular limitation.
> 
> 
>>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 11 Feb 2014 11:52:11 +0000

Does the draft insist that all connections from the DC for all VPNs are using Option A? From the reading of the draft this would seem to be a hard requirement to get the needed ARP resolution for a given context. 

The scalability in terms of number of paths allowed into the VRF/Context is generally limited across the set of PEs servicing a given PE. This is not small but represents the aggregate across all VRF sites.  If all paths are host routes on the WAN PE wont we blow past the routing limit and forwarding limits? . I think it is important to remember that virtualization is an extension of the traditional WAN VPN, customers want to place apps in their own and third party DCs,. This does not mean that the traditional WAN links are no longer there.

Jim Uttaro

-----Original Message-----
From: L3VPN [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Monday, February 10, 2014 9:04 PM
To: Giles Heron
Cc: Thomas Morin; [email-masked]; L3VPN
Subject: Re: Poll for adoption: draft-xu-l3vpn-virtual-subnet

	Thomas, 

	--Tom

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Feb 2014 14:16:09 +0100

Hi Giles,

> 
> The draft has a major limitation (no support for interconnecting routers,
> but only for interconnecting hosts),

What routers are you talking about ?

Common DC topology is as follows:

                    |                  |
VM - compute_node - |   IP Fabric      |
VM - compute_node - | Transport only   |
          Gateway - |       +          |
  Storage Cluster - | Only when needed |
Appliance Cluster - |  PE function     |
                    |                  |

This draft only provides additional flexibility of connecting VMs together.
It does not mandate that entire tenant VPN must use concept of virtual
subnet as it is 100% compliant with current L3VPN RFC - it's an add-on not
substitute.

Of course one may say that I can use L3VPN or L2VPN no need for something
in the middle - fair point. But in the same time this is different from
prohibiting one to inject some host routes and do proxy arp for pair of VMs
which like to talk on the same subnet but happen to be sitting on different
compute nodes.

And while some vendors do fight hard against overlays for tenant
virtualization and would rather see all smartness of the networks in TOR I
am afraid that this ship has already left the harbor .... In the above VMs
are virtualized in the compute's node kernel eliminating any need for big
fat and expensive PEs acting as TOR.

Those can be just plain ODMs or OCP blades with pure IPv4 and/or IPv6
transport support running BGP 1/1 or 2/1 or IGP if one prefers it.

Cheers,
R.

---

From: Giles Heron <[email-masked]>
Date: Tue, 11 Feb 2014 13:46:26 +0000

Hi Robert,

On 11 Feb 2014, at 13:16, Robert Raszuk <[email-masked]> wrote:

> Hi Giles,
>  
> The draft has a major limitation (no support for interconnecting routers, but only for interconnecting hosts), 
> 

any routers you might want on the subnet other than the default gateways.  For example a customer might want to put a virtual network behind a pair of VMs.  In a L2 overlay (or in any other normal subnet) those could communicate directly with any other routers on the subnet.

> This draft only provides additional flexibility of connecting VMs together. It does not mandate that entire tenant VPN must use concept of virtual subnet as it is 100% compliant with current L3VPN RFC - it's an add-on not substitute. 
> 
> Of course one may say that I can use L3VPN or L2VPN no need for something in the middle - fair point. But in the same time this is different from prohibiting one to inject some host routes and do proxy arp for pair of VMs which like to talk on the same subnet but happen to be sitting on different compute nodes. 

but as you yourself have said - if there's no need for it then why add it?  There are many different ways those two VMs can communicate already.  I'm not sure we need to invent another (though sure, it's fun to invent new stuff).

> And while some vendors do fight hard against overlays for tenant virtualization and would rather see all smartness of the networks in TOR I am afraid that this ship has already left the harbor .... In the above VMs are virtualized in the compute's node kernel eliminating any need for big fat and expensive PEs acting as TOR. 

thanks for putting words in my mouth Robert.  I appreciate it ;)

Giles

> Those can be just plain ODMs or OCP blades with pure IPv4 and/or IPv6 transport support running BGP 1/1 or 2/1 or IGP if one prefers it. 
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Feb 2014 15:22:27 +0100

Giles,

> > Of course one may say that I can use L3VPN or L2VPN no need for
> something in the middle - fair point. But in the same time this is
> different from prohibiting one to inject some host routes and do proxy arp
> for pair of VMs which like to talk on the same subnet but happen to be
> sitting on different compute nodes.
>
> but as you yourself have said - if there's no need for it then why add it?
>  There are many different ways those two VMs can communicate already.  I'm
> not sure we need to invent another
>

And that is reasonable discussion to have here rather then argue that BGP
does not scale without providing pain points or that routers behind VM need
to talk L2 to other routers behind VM (the latter is in fact possible via
overlay over overlay today anyway if someone would desire so).

You may be of opinion that current EVPN or PBB EVPN solve the problem. I
agree they solve the problem, but the price is much higher - new
development and new protocol extensions are needed to support it. Operating
one more protocol is not free too.

Here we just have a informational draft illustrating much cheaper option to
allow hosts talk on the same subnet cross overlay boundary. I do see this
as interesting tool to some of VMs communication requirements.

> thanks for putting words in my mouth Robert.  I appreciate it ;)

You are more then welcome ;-)

r.

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Feb 2014 09:47:35 -0500

On Feb 11, 2014:9:22 AM, at 9:22 AM, Robert Raszuk <[email-masked]> wrote:

> but as you yourself have said - if there's no need for it then why add it?  There are many different ways those two VMs can communicate already.  I'm not sure we need to invent another 
> 
> And that is reasonable discussion to have here rather then argue that BGP does not scale without providing pain points or that routers behind VM need to talk L2 to other routers behind VM (the latter is in fact possible via overlay over overlay today anyway if someone would desire so). 

	This is indeed the discussion we want to have here. I don't think Giles or I were claiming BGP doesn't scale; again, its a matter of whether or not you would want to send /32s around as prescribed.

	--Tom

> You may be of opinion that current EVPN or PBB EVPN solve the problem. I agree they solve the problem, but the price is much higher - new development and new protocol extensions are needed to support it. Operating one more protocol is not free too. 
> 
> Here we just have a informational draft illustrating much cheaper option to allow hosts talk on the same subnet cross overlay boundary. I do see this as interesting tool to some of VMs communication requirements. 
> 
>

---

From: Thomas Morin <[email-masked]>
Date: Tue, 11 Feb 2014 15:58:02 +0100

Hi,

Again, please keep in mind the intended status and the content of the 
document: adopting it and progressing it as an *informational* RFC does 
not mean that there is consensus that this approach is the best way, or 
even a right way, to address a particular use case.  As currently 
shaped, the document does a pretty good job of making this clear. This 
is a place to document an approach, including its limitations.

My take is that we're better off documenting all this, rather than just 
have this approach deployed with no documentation.

-Thomas

2014-02-11, Thomas Nadeau:
>
> On Feb 11, 2014:9:22 AM, at 9:22 AM, Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Giles,
>>
>>     something in the middle - fair point. But in the same time this
>>     is different from prohibiting one to inject some host routes and
>>     do proxy arp for pair of VMs which like to talk on the same
>>     subnet but happen to be sitting on different compute nodes.
>>
>>     but as you yourself have said - if there's no need for it then
>>     why add it?  There are many different ways those two VMs can
>>     communicate already.  I'm not sure we need to invent another
>>
>>
>> And that is reasonable discussion to have here rather then argue that 
>> BGP does not scale without providing pain points or that routers 
>> behind VM need to talk L2 to other routers behind VM (the latter is 
>> in fact possible via overlay over overlay today anyway if someone 
>> would desire so).
>
> This is indeed the discussion we want to have here. I don't think 
> Giles or I were claiming BGP doesn't scale; again, its a matter of 
> whether or not you would want to send /32s around as prescribed.
>
> --Tom
>
>
>> You may be of opinion that current EVPN or PBB EVPN solve the 
>> problem. I agree they solve the problem, but the price is much higher 
>> - new development and new protocol extensions are needed to support 
>> it. Operating one more protocol is not free too.
>>
>> Here we just have a informational draft illustrating much cheaper 
>> option to allow hosts talk on the same subnet cross overlay boundary. 
>> I do see this as interesting tool to some of VMs communication 
>> requirements.
>>
>>     > And while some vendors do fight hard against overlays for
>>     tenant virtualization and would rather see all smartness of the
>>     networks in TOR I am afraid that this ship has already left the
>>     harbor .... In the above VMs are virtualized in the compute's
>>     node kernel eliminating any need for big fat and expensive PEs
>>     acting as TOR.
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Feb 2014 10:17:32 -0500

> Hi,
> 
> Again, please keep in mind the intended status and the content of the document: adopting it and progressing it as an *informational* RFC does not mean that there is consensus that this approach is the best way, or even a right way, to address a particular use case.  As currently shaped, the document does a pretty good job of making this clear. This is a place to document an approach, including its limitations. 
> 
> My take is that we're better off documenting all this, rather than just have this approach deployed with no documentation.

	Documentation is fine, but if it comes from a WG isn't it then an endorsed approach unless some language is explicitly added to the draft? 

	--Tom

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 11 Feb 2014 13:54:53 -0500

Tom,

> Documentation is fine, but if it comes from a WG isn't it then an endorsed
> approach unless some language is explicitly added to the draft?

Remember, this poll is for WG adoption, not publication. Once the
draft has been adopted by the WG, the WG can then add whatever caveat
language it wishes to the draft so that it's very clear that this
approach has limitations (already in the last paragraph of section 1
and all over section 4), the purpose of the draft is to document a
particular usage of the existing L3VPN protocol set, and that there
are other standards-based approaches that are/will be standardized by
the WG.

So I'm in favor of WG adoption, so that the WG can make sure that
these caveats are clear in the informational draft.

Cheers,
Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Feb 2014 14:29:35 -0500

My point is that its not worth adopting as a WG item; instead, it is more appropriate as a person informational.  The question that I am asking (and I think the other responders to the thread that are not in favor of adoption) is whether or not it makes sense for the WG (and IETF) to endorse such a solution.  I am happy for this to progress as a personal information draft.

	--Tom

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 Feb 2014 14:34:47 -0500

Andy:

+ 1 - I feel this type of document does better with group review. 

Sue 

-----Original Message-----
From: L3VPN [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, February 11, 2014 2:30 PM
To: Andrew G. Malis
Cc: Thomas Morin; [email-masked]; L3VPN
Subject: Re: Poll for adoption: draft-xu-l3vpn-virtual-subnet

	My point is that its not worth adopting as a WG item; instead, it is
more appropriate as a person informational.  The question that I am asking
(and I think the other responders to the thread that are not in favor of
adoption) is whether or not it makes sense for the WG (and IETF) to endorse
such a solution.  I am happy for this to progress as a personal information
draft.

	--Tom

On Feb 11, 2014:1:54 PM, at 1:54 PM, Andrew G. Malis <[email-masked]>
wrote:

> Tom,
> 
>> Documentation is fine, but if it comes from a WG isn't it then an 
>> endorsed approach unless some language is explicitly added to the draft?
>

---

From: Richard Li <[email-masked]>
Date: Tue, 11 Feb 2014 21:47:25 +0000

Andy,

You are right! It makes sense to have it as a WG doc.

This draft really solves a real and significant problem, and it is perfectly in line with the current L3VPN framework. On the other hand, it may not be applicable to other scenarios as argued by other folks in this list, but which draft has solved all the problems cleanly once and for all?

Having said that, I believe it is beneficial to both vendors and operators for WG to document this approach with explicit clarifications on its applicability. And therefore I am in favor of its WG adoption.

Regards,

Richard 

-----Original Message-----
From: L3VPN [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Tuesday, February 11, 2014 10:55 AM
To: Thomas Nadeau
Cc: Thomas Morin; [email-masked]; L3VPN; Robert Raszuk
Subject: Re: Poll for adoption: draft-xu-l3vpn-virtual-subnet

Tom,

> endorsed approach unless some language is explicitly added to the draft?

Remember, this poll is for WG adoption, not publication. Once the draft has been adopted by the WG, the WG can then add whatever caveat language it wishes to the draft so that it's very clear that this approach has limitations (already in the last paragraph of section 1 and all over section 4), the purpose of the draft is to document a particular usage of the existing L3VPN protocol set, and that there are other standards-based approaches that are/will be standardized by the WG.

So I'm in favor of WG adoption, so that the WG can make sure that these caveats are clear in the informational draft.

Cheers,
Andy

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 12 Feb 2014 01:45:50 +0000

> -----邮件原件-----
> 发件人: Giles Heron [mailto:[email-masked]]
> 发送时间: 2014年2月11日 19:32
> 收件人: Thomas Morin
> 抄送: [email-masked]; [email-masked]
> 主题: Re: Poll for adoption: draft-xu-l3vpn-virtual-subnet
> 
> Hi Thomas
> 

Hi Giles,

I suggest you google with the following keywords "Dynamic Fabric Automation (DFA) host route" and have a look at how host routes are used in the DFA, and then come back to confirm the above assertion. If you couldn't find it, feel free to tell me and I will provide you a link.

> Perhaps we should ask NVO3 for comments?

I think the most efficient and simple way is to ask some feedback from your colleagues who knows about DFA.

Best regards,
Xiaohu

> > That would indeed be an issue if the document was aiming standard track to
> address a specific use case including router interconnections, or if the limitation
> was not documented.  But, the document is not aiming standard track, and has
> a section to document limitations to which the working group may contribute
> text for this particular limitation.
> >
> >
> >>

---

From: Boris Zhang <[email-masked]>
Date: Tue, 11 Feb 2014 21:35:06 -0500

I support the WG adoption simply base on the fact that Cisco DFA has  already implemented host route based anycast gateway  in very similar manner.

I can also share some points base on my considerations in building real telecom big data center.

1 it is generally agreed virtual servers should never be directly visible to physical network devices. /32 or /128 host route 1:1 maps to virtual server or physical server,need some explanation to justify the exception of rule for proposed draft.
2 physical gateway is usually second or third potential route hop in highly consolidate server environment,it is de facto aggregate rather than access. Need justify the applicability of host route in actual aggregate node.
3 intentionally put less intelligence to network devices that implicate the implementation of virtual subnet is ideally in hypervisor rather than physical router. 

Boris zhang

Sent from my iPad

---

From: Giles Heron <[email-masked]>
Date: Wed, 12 Feb 2014 11:39:23 +0000

Hi Xiaohu,

> I suggest you google with the following keywords "Dynamic Fabric Automation (DFA) host route" and have a look at how host routes are used in the DFA, and then come back to confirm the above asserti…

I'll leave it to those who know more about how DFA works than I do to comment.

> I think the most efficient and simple way is to ask some feedback from your colleagues who knows about DFA.

sure.  hopefully some of them read this list.

Giles

---

From: Thomas Morin <[email-masked]>
Date: Tue, 25 Feb 2014 09:57:15 +0100

Hello,

This call for adoption is closed and we consider that there is consensus 
to adopt draft-xu-l3vpn-virtual-subnet as a working group  document 
aiming Informational status.

We have taken note of comments about limitations of the approach: the 
document, now a WG item, will have to document these. All working group 
contributors are welcome to propose text in this perspective.

Authors, can you first resubmit the document as-is, as 
draft-ietf-l3vpn-virtual-subnet-00 ?

Thanks,

Martin & Thomas
l3vpn co-chairs

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 26 Feb 2014 01:30:29 +0000

Hi Thomas and Martin,

> 发送时间: 2014年2月25日 16:57
> 主题: Re: Poll for adoption: draft-xu-l3vpn-virtual-subnet --> adopted
> 
> Hello,
> 
> This call for adoption is closed and we consider that there is consensus to adopt
> draft-xu-l3vpn-virtual-subnet as a working group  document aiming
> Informational status.
> 

We will submit it once the submission tool is reopened.

Best regards,
Xiaohu (on behalf of co-authors)