Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F10321F8EC1 for ; Thu, 2 May 2013 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgyNewuK2mE5 for ; Thu, 2 May 2013 08:08:15 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDBB21F8BE4 for ; Thu, 2 May 2013 08:08:15 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id z16so335094ead.41 for ; Thu, 02 May 2013 08:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QRNxJXEbVjs1pApAEw/3TONEFmccSa7uXbgOkIa61co=; b=k3cP78j0IB/obTDRIfYMFq0yb5bSmruL+IYVF/7EuAY87L4BzBq2hDsLLQrVxUEoio pRdqu63J7Hpod6Y7zqDsz3bUMd5L2Rctr2W+qh2rP7qE79SbexImFEKPL8BI9fisitA3 AioqcFWWt6lojDdlD7vPBC+mgvGGSpJ2ZHADUPJiLb1fQbKtKXg9jVEPdB9mKUn3hB2r cav1MtagFFLU/qji5/mkqPr0z2VkSNvFbrb2NCklwyf7EIppi3M2V8gQmX7xidHlGHqA DRGizjIWooqfsnBZXJOPuZ1mIuZXLViO6OpeahDCw1ysEK0DRF3qeNRlwlRDxBARh1+Y NVeg== MIME-Version: 1.0 X-Received: by 10.14.213.67 with SMTP id z43mr20579922eeo.16.1367507294419; Thu, 02 May 2013 08:08:14 -0700 (PDT) Received: by 10.223.182.8 with HTTP; Thu, 2 May 2013 08:08:14 -0700 (PDT) In-Reply-To: References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> Date: Thu, 2 May 2013 23:08:14 +0800 Message-ID: From: Toby Mao To: Vishwas Manral Content-Type: multipart/alternative; boundary=047d7b603bac831fa504dbbd9abc Cc: IPsecme WG , "maoyu@h3c.com" , Paul Hoffman Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 15:08:16 -0000 --047d7b603bac831fa504dbbd9abc Content-Type: text/plain; charset=ISO-8859-1 Hi Vishwas: I agree with you. The Qos implementation in ADVPN is not different with traditional IPsec VPN at all, and this requirement is to specify Qos policy for each ADVPN peer in the hub. Best regards, Toby On Mon, Apr 29, 2013 at 12:00 PM, Vishwas Manral wrote: > Hi Toby, > > I absolutely understand the rational of where you are coming from. I agree > with questions raised by Paul - we need to be characterize the requirement > a bit further. > > I know QoS is important especially if there is an overload of traffic with > multiple different use cases. However do we see it any different from any > other VPN we currently run? I agree policing, shaping, marking etc are > mechanisms to implement QoS and are important. May be the requirement would > be to specify the capability to do fine grained QoS on a per peer basis on > the Hub. Sounds reasonable? > > Thanks, > Vishwas > > > On Sat, Apr 27, 2013 at 8:27 PM, Paul Hoffman wrote: > >> These requirements might be useful to add in the next draft, but they >> need to be refined. >> >> On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: >> >> > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) >> to regulate the traffic in the ADVPN topology. >> >> Why is this statement needed? Do you see situations where an ADVPN >> solution would be *prevented* from implementing some sort of QoS because it >> was an ADVPN? >> >> > ADVPN peer SHOULD NOT send excessive traffic to the other members of >> ADVPN. >> >> How would you define "excessive"? Where would that measurement be done? >> >> > The traffic for each ADVPN peer CAN be measured individually for >> shaping and policing. >> >> Why is this statement needed? Do you see situations where an ADVPN >> solution would be *prevented* from measuring individually? >> >> --Paul Hoffman >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > --047d7b603bac831fa504dbbd9abc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Vishwas:

I ag= ree with you. =A0The Qos implementation in ADVPN is not different with trad= itional IPsec VPN at all, and this requirement is to specify Qos policy for= each ADVPN peer in the hub.

Best regards,

Toby


On Mon, Apr 29, 2013 at 12:00 P= M, Vishwas Manral <vishwas.ietf@gmail.com> wrote:
Hi Toby,
=A0=
I absolutely understand the rational of where you are coming fro= m. I agree with questions raised by Paul - we need to be characterize the r= equirement a bit further.=A0
=A0
I know=A0QoS is important especially if there is an over= load of traffic with multiple different use cases. However do we see it any= different from any other VPN we currently run? I agree policing, shaping, = marking etc=A0are mechanisms to implement QoS and are important. May be the= requirement would be to specify the capability to do fine grained QoS on a= per peer basis on the Hub. Sounds reasonable?
=A0
Thanks,
Vishwas


On Sat, A= pr 27, 2013 at 8:27 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
These req= uirements might be useful to add in the next draft, but they need to be ref= ined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN so= lution would be *prevented* from implementing some sort of QoS because it w= as an ADVPN?

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurem= ent be done?

> The traffic for each ADVPN peer CAN be measured individually for shapi= ng and policing.

Why is this statement needed? Do you see situations where an ADVPN so= lution would be *prevented* from measuring individually?

--Paul Hoffman
_____________________= __________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


--047d7b603bac831fa504dbbd9abc--