Hi Martin,
We have just implemented RFC7814 a couple of months before in response to the
demands of some of our customers, and those customers have deployed this
L3-based overlay technology within their hyper-scale cloud data center network
environment recently. We are planning to implement
> -Original Message-
> From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Sent: Friday, December 18, 2015 3:21 PM
> To: Xuxiaohu; Alvaro Retana (aretana); The IESG
> Cc: draft-ietf-bess-virtual-sub...@ietf.org; bess-cha...@ietf.org;
> martin.vigour...@alcate
about
this usage?
Best regards,
Xiaohu
> -Original Message-
> From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Sent: Tuesday, December 15, 2015 5:00 PM
> To: Xuxiaohu; Alvaro Retana (aretana); The IESG
> Cc: draft-ietf-bess-virtual-sub...@ietf.org; bess-
Hi Stephen,
> -Original Message-
> From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Sent: Monday, December 07, 2015 8:00 PM
> To: Xuxiaohu; The IESG
> Cc: draft-ietf-bess-virtual-sub...@ietf.org; bess-cha...@ietf.org;
> martin.vigour...@alcatel-lucent.com; b
Hi Stephen,
Thank a lot for your DISCUSS. I fully agree with you that sensitive traffic
being handled by VMs should be encrypted when traversing across the Internet or
even SP networks. Similarly, I think you would also agree that sensitive
traffic of VPN clients should be encrypted as well in
Hi Ben,
Thanks for your comments. Please see my response inline.
> -Original Message-
> From: Ben Campbell [mailto:b...@nostrum.com]
> Sent: Thursday, December 03, 2015 6:29 AM
> To: The IESG
> Cc: draft-ietf-bess-virtual-sub...@ietf.org; aret...@cisco.com;
> bess-cha...@ietf.org;
I fully agree with Eric's points. In addition to the side-effects Eric had
raised, I think it may intensify the monopolization in specification due to the
implementation requirement before WG LC. For example, some giants could afford
the implementation of whatever specifications they had
Alvaro,
I will update it ASAP.
Best regards,
Xiaohu
From: Alvaro Retana (aretana) [mailto:aret...@cisco.com]
Sent: Wednesday, November 11, 2015 2:27 AM
To: Xuxiaohu; draft-ietf-bess-virtual-sub...@ietf.org
Cc: VIGOUREUX, MARTIN (MARTIN); bess-cha...@ietf.org; bess@ietf.org
Subject: Re: AD
at:
https://tools.ietf.org/html/draft-ietf-bess-virtual-subnet-03
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-virtual-subnet-03
Best regards,
Xiaohu
From: Xuxiaohu
Sent: Monday, November 02, 2015 1:04 PM
To: Alvaro Retana (aretana
How to interconnect DC VPNs with WAN VPNs in a much scalable way is very
important in the hybrid cloud scenario, especially for those SPs who operate
both DC VPNs and WAN VPNs. Therefore, it support the WG adoption of this draft.
Best regards,
Xiaohu
发件人:
Hi Alvaro,
Thanks for your detailed AD review. We will update the draft according to your
comments soon.
Best regards,
Xiaohu (on behalf of all co-authors)
发件人: Alvaro Retana (aretana) [aret...@cisco.com]
发送时间: 2015年10月28日 5:38
收件人:
Hi all,
The major rationale of the BGP Encap SAFI is as follows:
Since the encapsulation information is coded as an attribute, one
could ask whether a new SAFI is really required. After all, a BGP
speaker could simply attach the tunnel encapsulation attribute to
each prefix (like Q
I'm not aware of any relevant IPR.
Best regards,
Xiaohu
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Martin Vigoureux
Sent: Wednesday, May 20, 2015 3:13 AM
To: BESS
Subject: [bess] WG Last Call for draft-ietf-l3vpn-virtual-subnet
Hello
this email
Hi all,
In the hybrid cloud scenario where the private cloud (i.e., the on-premises
data center) is connected to the public cloud via service providers' L3VPN, if
a subnet in the public cloud is extended across multiple DC locations (either
via L3VPN or L2VPN), the L3VPN PE on the private
Hi Adrian,
Thanks a lot for your quick response.
-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Tuesday, March 03, 2015 9:14 PM
To: Xuxiaohu; bess@ietf.org
Subject: RE: [bess] Request for WG adoption of draft-xu-bess-encaps-udp//RE:
Why transform draft-xu
indicated by
the protocol type sub-TLV.
Best regards,
Xiaohu
Adrian
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Xuxiaohu
Sent: 13 February 2015 06:10
To: Xuxiaohu; bess@ietf.org; bess-cha...@tools.ietf.org
Cc: draft-xu-bess-encaps-...@tools.ietf.org
Thanks for making that suggestion. Although RFC5512 (i.e.,
draft-ietf-softwire-encaps-safi) and RFC5566 (i.e.,
draft-ietf-softwire-encaps-ipsec) have been originated from Softwire WG and
the current Softwire WG charter (https://tools.ietf.org/wg/softwire/charters)
still state that BGP and
regards,
Xiaohu
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Friday, February 13, 2015 9:01 AM
To: Nischal Sheth; Xuxiaohu; Rajiv Asati; Xuxiaohu; Nischal Sheth; Rajiv Asati
Subject: New Version Notification for draft-xu-bess-encaps-udp-00
-Original Message-
From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Xuxiaohu
Sent: Friday, February 13, 2015 9:21 AM
To: bess@ietf.org
Cc: Softwires WG
Subject: [bess] Why transform draft-xu-softwire-encaps-udp to
draft-xu-bess-encaps-udp
Hi all,
According to the suggestion from
By the way, this draft is an update of the previous draft
(https://tools.ietf.org/html/draft-xu-l3vpn-prefix-orf-00).
-Original Message-
From: Xuxiaohu
Sent: Monday, February 02, 2015 10:00 AM
To: bess@ietf.org
Subject: FW: New Version Notification for
draft-xu-bess-l3vpn-prefix
Any comments and suggestions are welcome.
Best regards,
Xiaohu
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Saturday, January 31, 2015 5:29 PM
To: Brendan Fee; Xuxiaohu; Brendan Fee; Susan Hares; Yongbing Fan; Xuxiaohu;
Truman Boyes
Support as a co-author. I'm not aware of any IPR related to this doc.
Best regards,
Xiaohu
-Original Message-
From: Martin Vigoureux [mailto:martin.vigour...@alcatel-lucent.com]
Sent: Wednesday, January 07, 2015 7:06 PM
To: bess@ietf.org
Cc:
22 matches
Mail list logo