Subject: [nvo3] 答复: Response to some comments on IS-IS VPLS

From: Xuxiaohu <[email-masked]>
Date: Thu, 29 Mar 2012 18:58:30 +0000

As for whether the BGP-based L2VPN solution is acceptable for most cloud DC operators, I think different people would have different opinions.

Since the above topic may be interesting to NVo3 BoF and be worthwhile for further discussion before the IESG approval of NVo3, I copy this email to NVo3 for further discussion.

Best regards,
Xiaohu
________________________________
发件人: UTTARO, JAMES [[email-masked]]
发送时间: 2012年3月30日 2:29
到: Xuxiaohu; [email-masked]
主题: RE: Response to some comments on IS-IS VPLS

IMHO… I am at a bit of a loss as to the notion that BGP is so overwhelmingly difficult to deal with in a data center environment.. Why is that??  BGP is being used across a wide spectrum of applications and is proven. I believe that the data center is becoming more and more a dynamic extension of a customer’s network. I also think it would be wise to anticipate the world of tomorrow where customers may expect their network may span multiple operators DCs.  The right approach is to leverage what has been done BGP and extend it where needed.. This provides maximum flexibility and simplicity..

To build solutions based on the notion that “I don’t like protocol X” is invalid..

Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, March 29, 2012 2:59 PM
To: [email-masked]
Subject: Response to some comments on IS-IS VPLS

Hi all,

VPLS (Virtual Private LAN Service) has different understandings for different people, some people think it as a service while others  think it as a concrete technology, especially using PWs. Here, the "VPLS" is deemed as a VPLS service. If the WG consensus is that "VPLS" should be taken as a concrete technology,  I have no objection to using another term.

As said in the IS-IS VPLS draft, IS-IS VPLS is intended to be a light-weight VPLS solution which can meet some DC operators' requirements for simplicity. I don't want to argue in this mailing-list whether BGP-based L2VPN solutions could meet well the requirements from all DC operators. I personally believe that it would be better to ask this question to NVo3. In addition, according to today's presentation of E-VPN, I think E-VPN co-authors also admit that the exiting EVPN solution seems complex to some DC operators. If my understanding is wrong, pls correct me.

If I remembered correctly, L1VPN also has two RFCs using IS-IS and OSPF for L1VPN auto-discovery, although there has been one solution using BGP. Hence I don't know why can't we have a light-weight L2VPN using IS-IS.

Best regards,

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 30 Mar 2012 06:52:09 +0000

________________________________________
发件人: Robert Raszuk [[email-masked]]
发送时间: 2012年3月30日 5:33
到: John E Drake
Cc: UTTARO, JAMES; Xuxiaohu; [email-masked]
主题: Re: Response to some comments on IS-IS VPLS

Hi John,

I think you took it a little bit too far.

I have not heard anyone stating that current VPLS solutions suck. I also
did not hear anyone claiming that BGP is difficult. The claim I have
heard is that in some environments one may not like to use BGP for VPLS.

[Xiaohu] I fully agree with Robert's points. There are two BGP-based VPLS (as a service): BGP/PW-based VPLS [RFC4761] and E-VPN. If somebody wonders why BGP/PW-based VPLS is not suitable for cloud data center networks, I suggest you read some related BBF tutorials talking about cloud data center network interconnect. If somebody wonders why not E-VPN, I think it'd better to ask this question to NVo3 and also ask E-VPN co-authors why they want to simplify E-VPN.

Best regards,
Xiaohu

Ali's point is that current PEs will have problem supporting it as this
is effectively TRILL over IP is valid from Ali's point of view.

However one could ask a question if IETF is still an organization to
promote open innovation and consider new ideas (even if only in
experimental mode) or is it just a forum to lock customers to limited
set of solutions ? If it is the latter the trend to seek alternatives to
IETF standardization process will continue to evolve. Especially now
when control plane separation from data plane becomes reality.

I see nothing wrong to allocate perhaps in experimental mode VPLS Info
TLV codepoint for VPLS over ISIS or for that matter well known
destination port for STT from IANA and let companies who are asking for
it develop the solutions, deploy it then report back the results to the
community.

Best,
R.

> Jim,
>
> You are completely correct , but let’s not overlook the fun factor.
> I.e., it’s **fun** to say that everything that has gone before sucks and
> that the current initiative will be “practically perfect” (c.f. ‘Mary
> Poppins’).
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *UTTARO, JAMES
> *Sent:* Thursday, March 29, 2012 11:30 AM
> *To:* 'Xuxiaohu'; [email-masked]
> *Subject:* RE: Response to some comments on IS-IS VPLS
>
> IMHO… I am at a bit of a loss as to the notion that BGP is so
> overwhelmingly difficult to deal with in a data center environment.. Why
> is that?? BGP is being used across a wide spectrum of applications and
> is proven. I believe that the data center is becoming more and more a
> dynamic extension of a customer’s network. I also think it would be wise
> to anticipate the world of tomorrow where customers may expect their
> network may span multiple operators DCs. The right approach is to
> leverage what has been done BGP and extend it where needed.. This
> provides maximum flexibility and simplicity..
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Xuxiaohu
> *Sent:* Thursday, March 29, 2012 2:59 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Response to some comments on IS-IS VPLS
>
> Hi all,
>
> VPLS (Virtual Private LAN Service) has different understandings for
> different people, some people think it as a service while others think
> it as a concrete technology, especially using PWs. Here, the "VPLS" is
> deemed as a VPLS service. If the WG consensus is that "VPLS" should be
> taken as a concrete technology, I have no objection to using another term.
>
> As said in the IS-IS VPLS draft, IS-IS VPLS is intended to be a
> light-weight VPLS solution which can meet some DC operators'
> requirements for simplicity. I don't want to argue in this mailing-list
> whether BGP-based L2VPN solutions could meet well the requirements from
> all DC operators. I personally believe that it would be better to ask
> this question to NVo3. In addition, according to today's presentation of
> E-VPN, I think E-VPN co-authors also admit that the exiting EVPN
> solution seems complex to some DC operators. If my understanding is
> wrong, pls correct me.
>
> If I remembered correctly, L1VPN also has two RFCs using IS-IS and OSPF
> for L1VPN auto-discovery, although there has been one solution using
> BGP. Hence I don't know why can't we have a light-weight L2VPN using IS-IS.
>
> Best regards,
>
> Xiaohu
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 30 Mar 2012 11:48:25 +0200

Ali,

> Third, before bashing E-VPN/PBB-EVPN, I would recommend that you
> understand what it is.

Great point indeed.

Could you share a pointer to the list which describes VM 1 on Host A's 
hypervisor to VM 2 on host B's hypervisor interconnect model for both 
above solutions just assuming that you have IP or MPLS reachability 
between such hosts ?

The requirement of my question is that any encapsulation/decapsulation 
required for such interconnection should happen on the end hosts 
(kernel, OVS, NIC etc ...) and not on the "network".

Best regards,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 30 Mar 2012 09:53:02 +0000

Hi Ali,

please see my comments inline.

________________________________________
发件人: sajassi [[email-masked]]
发送时间: 2012年3月30日 17:01
到: Xuxiaohu; [email-masked]; John E Drake
Cc: [email-masked]; [email-masked]; UTTARO, JAMES
主题: Re: Response to some comments on IS-IS VPLS

Xiaohu,

First, thanks for enlightening us on the definition of VPLS! I wrote the RFC
that describes the differences between VPLS as a service, VPLS as a network,
and VPLS as a LAN emulation (RFC 6136)

Second, Before talking about why BGP is not suitable for DC, I would
recommend you differentiate between different types of DC and their
requirements (e.g., EDC v.s. SPDC v.s. MSDC). Jim Uttaro is from ATT and he
is very much involved in their SPDC project.

[Xiaohu] IS-IS VPLS is intended to be used in multi-tenant data centers, IMHO, which can be run either by traditional service providers or those cloud providers such as Amazon. BTW, could you please explain what MSDC means? thanks.

Xiaohu

Third, before bashing E-VPN/PBB-EVPN, I would recommend that you understand
what it is. The reason for simplification is not because of BGP !! As I
explained during the session, the reason is because when Rahul and I did the
merge between R-VPLS and MAC-VPN, the resultant draft had multiple options
of doing the same thing and we decided that over time, we will do our
due-diligence and narrow it down.

Cheers,
Ali

On 3/29/12 11:52 PM, "Xuxiaohu" <[email-masked]> wrote:

>
> [Xiaohu] I fully agree with Robert's points. There are two BGP-based VPLS (as
> a service): BGP/PW-based VPLS [RFC4761] and E-VPN. If somebody wonders why
> BGP/PW-based VPLS is not suitable for cloud data center networks, I suggest
> you read some related BBF tutorials talking about cloud data center network
> interconnect. If somebody wonders why not E-VPN, I think it'd better to ask
> this question to NVo3 and also ask E-VPN co-authors why they want to simplify
> E-VPN.
>
> Best regards,
> Xiaohu
>
>
>> You are completely correct , but let¹s not overlook the fun factor.
>> I.e., it¹s **fun** to say that everything that has gone before sucks and
>> that the current initiative will be ³practically perfect² (c.f. ŒMary
>> Poppins¹).
>>
>> Thanks,
>>
>> John
>>
>> Sent from my iPhone
>>
>> IMHOŠ I am at a bit of a loss as to the notion that BGP is so
>> dynamic extension of a customer¹s network. I also think it would be wise
>> To build solutions based on the notion that ³I don¹t like protocol X² is
>> invalid..
>>
>> Jim Uttaro
>>