Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

From: "Bitar, Nabil N" <[email-masked]>
Date: Tue, 8 Nov 2011 00:41:54 -0500

Hi,
We had submitted the following draft on vpn applicability for data center. Your input on the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.
Here is the link:

http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01

Abstract

   Cloud Computing has been attracting a lot of attention from the
   networking industry. Some of the most publicized requirements are
   related to the evolution of the Cloud Networking Infrastructure to
   accommodate a large number of tenants, efficient network utilization,
   scalable loop avoidance, and Virtual Machine Mobility.

   This draft describes a framework for cloud networking, highlighting
   the applicability of existing work in various IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the gaps and problems that need to
   be further addressed. That is, the goal is to understand what may be
   re-used from the current protocols and call out requirements specific
   to the Cloud space that need to be addressed by new standardization
   work with proposed solutions in certain cases.

Thanks,

Nabil

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 08 Nov 2011 07:53:09 +0000

Hi Nabil,

It’s a very comprehensive doc.

Some commons:

1、  In section 6.1, it said: “As the number of tenants in individual VLAN islands surpasses 4K, the operator could push VPLS deployment deeper in the DC network…. The ToR and DC core elements need to be MPLS enabled with existing VPLS solutions”, IMHO, DC core switches don’t need to be MPLS enabled since IP based tunnel is also available.

2、  Still in section 6.1, it said: ” …However, this model does not solve the MAC explosion issue as ToRs still need to learn VM MAC addresses.” However, in section 6.2.1, it said:”…Alternatively, the PBB encapsulation can be done at the ToR.”  It is confused since performing PBB encapsulation at the ToR would not alleviate the MAC-learning burden on that ToR.

3、  In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:” The procedures from the previous section are used at the VSw: PBB encapsulation and Ethernet BVLANs can be used on the VSw uplink. L2VPN infrastructure is replacing the BVLAN at the ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling.  L2 networking still has the same control plane choices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independently from the tunneling choice.” Since PBB encapsulation has already been done on the VSw, why do we still need to run 802.1aq and PBB-EVPN with another PBB encapsulation layer? Can’t we simply use any L2VPN technology, e.g., VPLS. In addition, note that in Figure 5, it said “intra-DC L2VPN over IP or MPLS tunneling”.

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Bitar, Nabil N
发送时间: 2011年11月8日 13:42
收件人: [email-masked]; [email-masked]
抄送: Sagessi; [email-masked]; Luyuan Fang (lufang); [email-masked]
主题: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi,

Abstract

Thanks,

Nabil

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 08 Nov 2011 09:39:14 +0000

Hi,

Some comments about path optimization:

1．In section 5.5,  it said “IP-based forwarding relies on the destination IP address…However, when VMs, as IP hosts across layer2 virtual
   domains, need to communicate they rely on the underlying IP routing infrastructure.”  Could you explain more about “layer2 virtual domains”?

2.   In section 5.5, it said “optimality in traffic forwarding to a VM will require reachability to the VM host address rather than only the subnet.” IMHO, propagating host routes for VMs is only useful for optimizing the path for VPN access, rather than for Internet access since propagating host route to the Internet will damage the Internet routing scalability seriously.  To optimize the path for Internet access,  IMHO, DNS-based GLSB is a more practical approach instead. With this approach, since the connections established before the VM movement use the old NATed address of the VM, the inbound traffic of those connections will still travel through the old gateway where the VM used to be attached. It’s easy for the old gateway to forward the traffic further to the new location. However, the hard issue is how to guarantee the outbound traffic of those connections travel through the same gateway as the inbound traffic does (i.e., path symmetry) in the scenario where stateful devices such as NATs, firewalls etc. are deployed at the DC exits.

Best regards,
Xiaohu

Hi,

Abstract

Thanks,

Nabil

---

From: Lucy yong <[email-masked]>
Date: Tue, 08 Nov 2011 17:39:52 +0000

Hi Nabil  and other co-authors,

First of all, this is a very good draft to gather DC problem statements and explore VPN applicability for cloud networking.  Good information for the community. Thank you very much.

Some comments:

1)      The document has heavy amount portion to describe all different use cases for PBB but few sentence for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases.

2)      It is very possible that DC use L2VPN and WAN use L3VPN.  It is nice that document this applicability.

3)      Provider DC and enterprise DC may implement different L2VPN or L3VPN technologies, it is valuable to describe what kind of interworking scenarios is allowed or not allowed.

Best Regards,
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bitar, Nabil N
Sent: Monday, November 07, 2011 11:42 PM
To: [email-masked]; [email-masked]
Cc: Sagessi; [email-masked]; Luyuan Fang (lufang); [email-masked]
Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi,

Abstract

Thanks,

Nabil

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Tue, 8 Nov 2011 15:18:48 -0500

Hi,
Thanks. Please see inline.

Thanks,
Nabil

From: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Date: Tue, 8 Nov 2011 02:53:09 -0500
To: "Bitar, Nabil N" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Sagessi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Luyuan Fang (lufang)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi Nabil,

Some commons:

<NB> It is one scenario and it is one deployment choice.

Section 2.1, to handle the MAC scale, and leviating VM MACs from Tors and core switches, PBB would start at the Vsw. Here is the text:

"In a DC environment, PBB maintains traditional Ethernet forwarding
   plane and operational model. For example, a VSw implementation of PBB
   can make use of the 24 bit ISID tag instead of the 12 bit VLAN tag to
   identify the virtual bridging domains associated with different VM
   groups. The VSw uplink towards the ToR in Figure 1 can still be
   treated as an Ethernet backbone interface. A frame originated by a VM
   can be encapsulated with the ISID assigned to the VM VSw interface
   and with the outer DA and SA MACs associated with the respective
   destination and source server blades, and then sent to the ToR
   Switch.

   <snap>

"With PBB encapsulation, ToRs and Core SWs do not have to handle VM MAC addresses so the size of their MAC FIB tables may decrease"

<NB> I agree we need to make this clearer. However, PBB-EVPN is still applicable especially in the WAN as indicated and can be in the LAN as indicated. 802.1aq is less of an issue in this scenario as depicted but can exited in other Dcs/other customer sites communicating to the deicted DC is running or if there is a segment in the same DC running 802.1aq simultaneously.

Best regards,
Xiaohu

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Bitar, Nabil N
发送时间: 2011年11月8日 13:42
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: Sagessi; [email-masked]<mailto:[email-masked]>; Luyuan Fang (lufang); [email-masked]<mailto:[email-masked]>
主题: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi,

Abstract

Thanks,

Nabil

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 8 Nov 2011 15:34:10 -0600

Thanks for the comments, see in-line…

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; [email-masked]; [email-masked]
Cc: Luyuan Fang (lufang); Sagessi; [email-masked]; [email-masked]
Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi Nabil,

Some commons:

FB> You are right we should have said “IP or MPLS enabled” as both cases are possible…

FB> Maybe the phrase location is puzzling. The focus of section 6.2 is the use of an extended 24b PBB I-ISID tag starting at the VSw to identify the ELAN broadcast domain.

This will maximize the benefits. However in reality it is very likely there will be legacy DC regions still running VLANs which require a Gateway function during the migration. See the VLAN Interop discussion in section 6.2.9.

3、  In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:” The procedures from the previous section are used at the VSw: PBB encapsulation and Ethernet BVLANs can be used on the VSw uplink. L2VPN infrastructure is replacing the BVLAN at the ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling.

FB> This is about the tunneling encapsulation options to be used in the core: 24b I-SID tag is the common tenant ID which can be transported over an Ethernet or an IP or an MPLS based DC network. Combinations of these tunneling options are also possible: e.g. one DC may be Ethernet based the other IP based; or the VSw may use Ethernet VLAN tunnels while IP tunnels may start at the ToR.

 L2 networking still has the same control plane choices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independently from the tunneling choice.” Since PBB encapsulation has already been done on the VSw, why do we still need to run 802.1aq and PBB-EVPN with another PBB encapsulation layer?

FB> No need for an additional PBB encapsulation layer! This is strictly about control plane options: IS-IS and BGP are used the same way as in regular IP routing to perform Multipathing, Fast Convergence, service AD, program the core FIBs etc…

 Can’t we simply use any L2VPN technology, e.g., VPLS. In addition, note that in Figure 5, it said “intra-DC L2VPN over IP or MPLS tunneling”.

FB> yes you can. We just focused here on the options that will address the challenges described in the problem statement section. Otherwise the content will have grown too much.

Best regards,
Xiaohu

Hi,

Abstract

Thanks,

Nabil

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 09 Nov 2011 01:54:22 +0000

发件人: Balus, Florin Stelian (Florin) [mailto:[email-masked]]
发送时间: 2011年11月9日 5:34
收件人: Xuxiaohu; Bitar, Nabil N; [email-masked]; [email-masked]
抄送: Luyuan Fang (lufang); Sagessi; [email-masked]; [email-masked]
主题: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi Nabil,

Some commons:

<XXH> Good point.

<XXH> The title of section 6.2.1 is “Addressing VLAN space exhaustion and MAC explosion”. So I think saying more words after that sentence is much helpful in avoiding confusion.

<XXH> Yes, I agree with your statement above. Adding the above text into the draft would be much helpful:)

<XXH> Absolutely agree. Such being the case, why not remove the two specific examples (both of them add another PBB layer) from that sentence so as to eliminate the possible confusion?

<XXH> Thanks for your explanation.

Best regards,
Xiaohu

Hi,

Abstract

Thanks,

Nabil

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 09 Nov 2011 02:50:36 +0000

By the way, it would be better to push the PBB as close to the end-systems as possible from the perspective of MAC forwarding table scalability. However, the unknown unicast flood impact issue would be worsen accordingly. For example, in a normal Layer2 network, if two VMs attached to the given ToR are frequently communicated with each other and hence their MAC address entries on this ToR will not be expired, the traffic destined for any of those two VMs from a remote VM could be flooded as unknown unicast until the traffic reach this ToR which in turn forward the traffic to the destination VM in unicast.  However, once PBB is performed at each VSw, that traffic would be flooded until it reach the final destination physical server.  It’s a hard tradeoff, isn’t it?

Xiaohu

发件人: Xuxiaohu
发送时间: 2011年11月9日 10:08
收件人: 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; [email-masked]; [email-masked]
抄送: Luyuan Fang (lufang); Sagessi; [email-masked]; [email-masked]
主题: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi Nabil,

Some commons:

<XXH> Good point.

Best regards,
Xiaohu

Hi,

Abstract

Thanks,

Nabil

---

From: Vishwas Manral <[email-masked]>
Date: Tue, 8 Nov 2011 19:03:16 -0800

Xiaohu,

For the purpose of reducing unkown unicast/ multicast you could use some
off path learning and then discard the unknowns.

Ofcourse the MAC tables in edge device need to big enough to learn the MAC
addresses of all the end systems.

Thanks,
Vishwas
2011/11/8 Xuxiaohu <[email-masked]>

>  By the way, it would be better to push the PBB as close to the
> end-systems as possible from the perspective of MAC forwarding table
> scalability. However, the unknown unicast flood impact issue would be
> worsen accordingly. For example, in a normal Layer2 network, if two VMs
> attached to the given ToR are frequently communicated with each other and
> hence their MAC address entries on this ToR will not be expired, the
> traffic destined for any of those two VMs from a remote VM could be flooded
> as unknown unicast until the traffic reach this ToR which in turn forward
> the traffic to the destination VM in unicast.  However, once PBB is
> performed at each VSw, that traffic would be flooded until it reach the
> final destination physical server.  It’s a hard tradeoff, isn’t it?****
>
> ** **
>
> Xiaohu****
>
> ** **
>
> ** **
>
> *发件人:* Xuxiaohu
> *发送时间:* 2011年11月9日 10:08
> *收件人:* 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; [email-masked];
> [email-masked]
> *抄送:* Luyuan Fang (lufang); Sagessi; [email-masked];
> [email-masked]
> *主题:* re: Your input on the following draft is appreciated:
> draft-bitar-datacenter-vpn-applicability-01.txt****
>
> ** **
>
> *发件人:* Balus, Florin Stelian (Florin) [mailto:
> [email-masked]]
> *发送时间:* 2011
> 年11月9日 5:34
> *收件人:* Xuxiaohu; Bitar, Nabil N; [email-masked]; [email-masked]
> *抄送:* Luyuan Fang (lufang); Sagessi; [email-masked];
> [email-masked]
> *主题:* RE: Your input on the following draft is appreciated:
> draft-bitar-datacenter-vpn-applicability-01.txt****
>
>  ** **
>
> Thanks for the comments, see in-line…****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Xuxiaohu
> *Sent:* Monday, November 07, 2011 11:53 PM
> *To:* Bitar, Nabil N; [email-masked]; [email-masked]
> *Cc:* Luyuan Fang (lufang); Sagessi; [email-masked];
> [email-masked]
> *Subject:* re: Your input on the following draft is appreciated:
> draft-bitar-datacenter-vpn-applicability-01.txt****
>
> ** **
>
> Hi Nabil,****
>
> ** **
>
> It’s a very comprehensive doc.****
>
> ** **
>
> Some commons:****
>
> **1、  **In section 6.1, it said: “As the number of tenants in individual VLAN islands surpasses 4K, the operator could push VPLS deployment deeper in the DC network…. The ToR and DC core elements need to be MPLS enabled with existing VPLS solutions”, IMHO, DC core switches don’t need to be MPLS enabled since IP based tunnel is also available.****
>
> ** **
>
> FB> You are right we should have said “IP or MPLS enabled” as both cases are possible… ****
>
> ** **
>
> <XXH> Good point.****
>
> ** **
>
> **2、  **Still in section 6.1, it said: ” …However, this model does not solve the MAC explosion issue as ToRs still need to learn VM MAC addresses.” However, in section 6.2.1, it said:”…Alternatively, the PBB encapsulation can be done at the ToR.”  It is confused since performing PBB encapsulation at the ToR would not alleviate the MAC-learning burden on that ToR.****
>
> ** **
>
> FB> Maybe the phrase location is puzzling. The focus of section 6.2 is the use of an extended 24b PBB I-ISID tag starting at the VSw to identify the ELAN broadcast domain. ****
>
> ** **
>
> <XXH> The title of section 6.2.1 is “Addressing VLAN space exhaustion and MAC explosion”. So I think saying more words after that sentence is much helpful in avoiding confusion.****
>
> ** **
>
> ** **
>
> This will maximize the benefits. However in reality it is very likely there will be legacy DC regions still running VLANs which require a Gateway function during the migration. See the VLAN Interop discussion in section 6.2.9. ****
>
>  ****
>
> **3、  **In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:” The procedures from the previous section are used at the VSw: PBB encapsulation and Ethernet BVLANs can be used on the VSw uplink. L2VPN infrastructure is replacing the BVLAN at the ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling. ****
>
> ** **
>
> FB> This is about the tunneling encapsulation options to be used in the core: 24b I-SID tag is the common tenant ID which can be transported over an Ethernet or an IP or an MPLS based DC network. Combinations of these tunneling options are also possible: e.g. one DC may be Ethernet based the other IP based; or the VSw may use Ethernet VLAN tunnels while IP tunnels may start at the ToR.****
>
> ** **
>
> <XXH> Yes, I agree with your statement above. Adding the above text into the draft would be much helpfulJ****
>
> ** **
>
>  L2 networking still has the same control plane choices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independently from the tunneling choice.” Since PBB encapsulation has already been done on the VSw, why do we still need to run 802.1aq and PBB-EVPN with another PBB encapsulation layer?****
>
> ** **
>
> FB> No need for an additional PBB encapsulation layer! This is strictly about control plane options: IS-IS and BGP are used the same way as in regular IP routing to perform Multipathing, Fast Convergence, service AD, program the core FIBs etc…****
>
> ** **
>
> <XXH> Absolutely agree. Such being the case, why not remove the two specific examples (both of them add another PBB layer) from that sentence so as to eliminate the possible confusion?****
>
> ** **
>
>  Can’t we simply use any L2VPN technology, e.g., VPLS. In addition, note that in Figure 5, it said “intra-DC L2VPN over IP or MPLS tunneling”.****
>
>  ** **
>
> FB> yes you can. We just focused here on the options that will address the challenges described in the problem statement section. Otherwise the content will have grown too much.****
>
> ** **
>
> <XXH> Thanks for your explanation.****
>
> ** **
>
> Best regards,****
>
> Xiaohu****
>
> ** **
>
> *发件人:* [email-masked] [mailto:[email-masked]] *代表 *Bitar,
> Nabil N
> *发送时间:* 2011年11月8日 13:42
> *收件人:* [email-masked]; [email-masked]
> *抄送:* Sagessi; [email-masked]; Luyuan Fang (lufang);
> [email-masked]
> *主题:* Your input on the following draft is appreciated:
> draft-bitar-datacenter-vpn-applicability-01.txt****
>
> ** **
>
> Hi,****
>
> We had submitted the following draft on vpn applicability for data center.
> Your input on the draft is appreciated in light of some of the ongoing
> discussion. The draft is targeted for l3vpn and l2vpn.****
>
> Here is the link: ****
>
> ** **
>
> http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01****
>
> ** **
>
> Abstract****
>
> ** **
>
>    Cloud Computing has been attracting a lot of attention from the****
>
>    networking industry. Some of the most publicized requirements are****
>
>    related to the evolution of the Cloud Networking Infrastructure to****
>
>    accommodate a large number of tenants, efficient network utilization,****
>
>    scalable loop avoidance, and Virtual Machine Mobility.****
>
> ** **
>
>    This draft describes a framework for cloud networking, highlighting****
>
>    the applicability of existing work in various IETF Working Groups****
>
>    (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working****
>
>    Groups) to cloud networking, and the gaps and problems that need to****
>
>    be further addressed. That is, the goal is to understand what may be****
>
>    re-used from the current protocols and call out requirements specific****
>
>    to the Cloud space that need to be addressed by new standardization****
>
>    work with proposed solutions in certain cases.****
>
>
> Thanks,****
>
> Nabil****
>
>

---

From: Paul Unbehagen <[email-masked]>
Date: Wed, 9 Nov 2011 14:24:28 +1100

Just to be clear wrt PBB, the MAC tables only need to be large enough to learn the Mac's of the end systems in the same ISID that exist on that edge switch, not all MAC's in the network. This is what makes PBB scale so well in these types of environments. 

--
Paul Unbehagen

Sent from my iPad

On Nov 9, 2011, at 2:03 PM, Vishwas Manral <[email-masked]> wrote:

> Xiaohu,
>  
> For the purpose of reducing unkown unicast/ multicast you could use some off path learning and then discard the unknowns.
>  
> Ofcourse the MAC tables in edge device need to big enough to learn the MAC addresses of all the end systems.
>  
> Thanks,
> Vishwas
> 发送时间: 2011
> <XXH> Yes, I agree with your statement above. Adding the above text into the draft would be much helpfulJ
>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 09 Nov 2011 03:27:47 +0000

发件人: [email-masked] [mailto:[email-masked]] 代表 Lucy yong
发送时间: 2011年11月9日 1:40
收件人: Bitar, Nabil N; [email-masked]; [email-masked]
抄送: Sagessi; [email-masked]; [email-masked]
主题: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Some comments:

<XXH> I guess partial paragraphs in section 5.5. “Optimal traffic forwarding” did mention L3VPN applicability in DC. Specifically, the paragraph starting with “IP-based forwarding relies on the destination IP address… describes a L3VPN application approach like Virtual Subnet (http://tools.ietf.org/html/draft-xu-virtual-subnet-06) and the following paragraph describes another L3VPN application like l3vpn-end-system (http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02). Note that it’s just my guess that has not be confirmed yet by co-authors of draft-bitar-datacenter-vpn-applicability-01:)

<XXH> it’s a good opinion. As for DCI, host route based L3VPN approaches will bring operators more attractive advantages compared to those MAC forwarding based L2VPN approach, such as broadcast/flood impact elimination, MAC table scalability on data center switches, and especially path optimization.

Best regards,
Xiaohu

Best Regards,
Lucy

Hi,

Abstract

Thanks,

Nabil

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 09 Nov 2011 01:32:13 +0000

Hi Nabil,

发件人: Bitar, Nabil N [mailto:[email-masked]]
发送时间: 2011年11月9日 4:19
收件人: Xuxiaohu; Bitar, Nabil N; [email-masked]; [email-masked]
抄送: Sagessi; [email-masked]; Luyuan Fang (lufang); [email-masked]
主题: Re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi,

Thanks,
Nabil

Hi Nabil,

Some commons:

<XXH> Yes, I agree. I just suggest it could be more comprehensive.

   Switch.

   <snap>

<XXH> I totally agree with the above statement. I just suggest whether you could explain more after the sentence of ”…Alternatively, the PBB encapsulation can be done at the ToR.” so as to eliminate the possible confusion.

<XXH> Yes, I agree that PBB-EVPN and SPB can be used here. However, since any other L2VPN technologies could also been used here as well, IMHO, there is absolutely no need to give these two concrete and specific examples here. You just need to say “…L2 networking still has the same control plane choices: IS-IS and/or BGP, independently from the tunneling choice.”  It seems more comprehensive without any confusion.

Best regards,
Xiaohu

Hi,

Abstract

Thanks,

Nabil

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 09 Nov 2011 03:52:59 +0000

I agree that PBB could scale very well if it is performed at proper locations where the MAC table is “large enough”.
Best regards,
Xiaohu
发件人: Paul Unbehagen [mailto:[email-masked]]
发送时间: 2011年11月9日 11:24
收件人: Vishwas Manral
抄送: Xuxiaohu; [email-masked]; Sagessi; [email-masked]; [email-masked]; Luyuan Fang (lufang); [email-masked]
主题: Re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Sent from my iPad

On Nov 9, 2011, at 2:03 PM, Vishwas Manral <[email-masked]<mailto:[email-masked]>> wrote:
Xiaohu,

Thanks,
Vishwas
2011/11/8 Xuxiaohu <[email-masked]<mailto:[email-masked]>>
By the way, it would be better to push the PBB as close to the end-systems as possible from the perspective of MAC forwarding table scalability. However, the unknown unicast flood impact issue would be worsen accordingly. For example, in a normal Layer2 network, if two VMs attached to the given ToR are frequently communicated with each other and hence their MAC address entries on this ToR will not be expired, the traffic destined for any of those two VMs from a remote VM could be flooded as unknown unicast until the traffic reach this ToR which in turn forward the traffic to the destination VM in unicast.  However, once PBB is performed at each VSw, that traffic would be flooded until it reach the final destination physical server.  It’s a hard tradeoff, isn’t it?

Xiaohu

发件人: Xuxiaohu
发送时间: 2011年11月9日 10:08
收件人: 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: Luyuan Fang (lufang); Sagessi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

发件人: Balus, Florin Stelian (Florin) [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2011
年11月9日 5:34
收件人: Xuxiaohu; Bitar, Nabil N; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: Luyuan Fang (lufang); Sagessi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Luyuan Fang (lufang); Sagessi; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi Nabil,

Some commons:

<XXH> Good point.

<XXH> Yes, I agree with your statement above. Adding the above text into the draft would be much helpful☺

Best regards,
Xiaohu

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] 代表 Bitar, Nabil N
发送时间: 2011年11月8日 13:42
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: Sagessi; [email-masked]<mailto:[email-masked]>; Luyuan Fang (lufang); [email-masked]<mailto:[email-masked]>
主题: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi,

Abstract

Thanks,

Nabil

---

From: David Allan I <[email-masked]>
Date: Wed, 9 Nov 2011 10:31:15 -0500

Hi Xuxaohu:

I would object to your suggestion of "as close to the end-systems as possible". PBB is hierarchical summarization, so the number of C-MACs summarized for reachability to B-MACs is a function of how close the BEB is placed to the end system. If it is "co-located" with the end system (a.k.a as close as possible) there is no summarization. 1  B-MAC corresponds to 1 C-MAC and the encapsulation at that point is simply a gratuitous increase in bandwidth consumption. Which tends to suggest there is a natural location for placement of the BEB function which permits some orders of magnitude state improvement in the core switches.

Similarly , both PBB and SPBM bound the broadcast domains for a customer VLAN to the community of interest without simply employing the rather wasteful "egress discard", so the periodic flooding of unknowns IMO is not the issue you think it is. Similarly it is unrelated to how close the BEB is placed to the VM. Flooding is either bounded by S-tag or bounded by per I-SID multicast trees. So I'm not sure what you mean by the "unknown unicast flood impact issue", location of the BEB does not conflate unknown flooding.

To summarize, I'm not understanding your post and am seeking clarification

thanks
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Tuesday, November 08, 2011 6:51 PM
To: Xuxiaohu; Balus, Florin Stelian (Florin); Bitar, Nabil N; [email-masked]; [email-masked]
Cc: [email-masked]; Luyuan Fang (lufang); Sagessi; [email-masked]
Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Xiaohu

发件人: Xuxiaohu
发送时间: 2011年11月9日 10:08

Hi Nabil,

Some commons:

<XXH> Good point.

Best regards,
Xiaohu

Hi,

Abstract

Thanks,

Nabil

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 11 Nov 2011 05:58:12 +0000

Hi Dave,

First, the end-system here means the physical servers, rather than the VMs. In other words, no one had said one B-MAC corresponds to one C-MAC.
Second, the forwarding table scalability here means the switches before the PBB encapsulation entities would have to learn C-MAC addresses of all VLANs. That’s why PBB devices should be done at the locations close to the end-systems, where the switches do not need to attach all VLANs.

Best regards,
Xiaohu

发件人: David Allan I [mailto:[email-masked]]
发送时间: 2011年11月9日 23:31
收件人: Xuxiaohu; Balus, Florin Stelian (Florin); Bitar, Nabil N; [email-masked]; [email-masked]
抄送: [email-masked]; Luyuan Fang (lufang); Sagessi; [email-masked]
主题: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi Xuxaohu:

thanks
Dave

Xiaohu

发件人: Xuxiaohu
发送时间: 2011年11月9日 10:08

Hi Nabil,

Some commons:

<XXH> Good point.

Best regards,
Xiaohu

Hi,

Abstract

Thanks,

Nabil

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Sun, 13 Nov 2011 20:19:59 -0500

Hi Lucy,
Thanks for the input/comments. Please, see inline.

Thanks,
Nabil

From: Lucy yong <[email-masked]<mailto:[email-masked]>>
Date: Tue, 8 Nov 2011 12:39:52 -0500
To: "Bitar, Nabil N" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Sagessi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Luyuan Fang (lufang)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

First of all, this is a very good draft to gather DC problem statements and explore VPN applicability for cloud networking.  Good information for the community. Thank you very much.
<NB> Thanks Lucy. That is one of the purposes of the draft.

Some comments:

<NB> Agree, it is more focused on PBB from layer2 aspect in addition to 802.1aq in terms of the scenarios, but not neglecting TRILL as we state the cases where TRILL also applies as it can be looked at as alternative to 802.1aq/Qbp but  and the co-authors will be adding more on that. L3VPN case is is in section 7.

<NB> These are documented in sections 3, 4, 5, and 7 in addition to some related challenges that need to be addressed in section 8. In particular, we talk about l3vpn within the data center, L3VPN starting at the DC GW with native Ethernet in the lDC where a tenant is identfied by a layer2 service ID that is used also as the interface to the tenant VRF at the DC GW. In addition, we discuss the different models where the WAN service provider and the DC provider are the same entities, and 2 different enetities (Ass) interconnected via multi-AS backbone options A, B or C per RFC 4364. Finally, we talk about the case of Integrated routing and bridging per tenant.

<NB> I am not sure you can say "allowed" or "not allowed". The approach that we took is to dsay: (1) what are the common practices, (2) what are the options, and (3) what are the tradeoffs among the different options.

Best Regards,
Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Bitar, Nabil N
Sent: Monday, November 07, 2011 11:42 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Sagessi; [email-masked]<mailto:[email-masked]>; Luyuan Fang (lufang); [email-masked]<mailto:[email-masked]>
Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

Hi,

Abstract

Thanks,

Nabil