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 38C9A21F9798 for ; Mon, 3 Jun 2013 08:56:49 -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 9fB8MQkTkufs for ; Mon, 3 Jun 2013 08:56:48 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3D69D21F973A for ; Mon, 3 Jun 2013 08:56:48 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id at20so10366627iec.7 for ; Mon, 03 Jun 2013 08:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q+ubG1n1U1LasWtaCC5gMx0NQFCMf2WnVZujv+JwICA=; b=C+hvVjmbHHSKnHk5MeZB/pX1TYMiNIlx1empX+m8yKWmhiSiScxVqtSbpsj7GBoCFn u+r3LMhXOQcxkwRLANIzT8hb+Ejc6HuYczHeS6PaC2mxldPZYI+PlkLkuEVniJ6csk+C R6eidHNitwY4+9+ryO31Bif902gvHQTX4foPns/QlGGmHBj+sV1KS9wAmthYQ3OON0Lh xuE7e4yQibpIoU6ufZe3OPmE6TQTB9QyQIAH+Dhn4N/KiLh1BAvOYoQ4lBxm5k7LDmaQ FAqBiADtF5lBk7TyPXUCikMR/FmRKZOqSGwR1mWAh9RFgmxKpjrnX5htLifwOKZKKG49 iCgg== MIME-Version: 1.0 X-Received: by 10.50.78.129 with SMTP id b1mr8412102igx.59.1370275007872; Mon, 03 Jun 2013 08:56:47 -0700 (PDT) Received: by 10.50.56.107 with HTTP; Mon, 3 Jun 2013 08:56:47 -0700 (PDT) In-Reply-To: <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com> References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com> Date: Mon, 3 Jun 2013 08:56:47 -0700 Message-ID: From: Vishwas Manral To: Yoav Nir Content-Type: multipart/alternative; boundary=089e0111e07016ca1904de4203b1 Cc: IPsecme WG , "maoyu@h3c.com" , Paul Hoffman , Toby Mao 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: Mon, 03 Jun 2013 15:56:49 -0000 --089e0111e07016ca1904de4203b1 Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav, Do we see a conclusion on the QoS requirement and if we want to include it as part of the ADVPN solution or keep it seperate? Thanks, Vishwas On Thu, May 2, 2013 at 1:11 PM, Yoav Nir wrote: > Hi Toby. > > Let's see if I understand the issue. I'll describe this with an example. > Please let me know if I got it. > > Suppose we have satellite gateways A, B, C, D, and E. A through D each > have a bandwidth of 10 Mb/s, while E has 20 Mb/s. > > The center gateway, Z, has plenty of bandwidth and the appropriate QoS > policy. So if A, B, and C are simultaneously sending traffic to E through > Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP > ACKs) to make sure the QoS goals are met. > > Now add ADVPN to the mix. A and E discover each other, and are able to > bypass Z. Initially A had no IPsec policy about E. There's no reason to > think it had a QoS policy about E, and the same is true in the other > direction. Unless the QoS policy from Z somehow gets transmitted to the > satellites, they may reach congestion and have the QoS targets miss. > > So whereas before ADVPN the center gateway could be counted on to handle > the QoS (because everything goes through it), as soon as you add ADVPN, > that policy has to be enforced on the spokes, or not at all. > > I'm not sure whether we can or should solve this issue as part of > AD-VPN, but I want to make sure that we understand the issue. > > Yoav > > On May 2, 2013, at 6:02 PM, Toby Mao wrote: > > > On Sat, Apr 27, 2013 at 10:57 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? >> > > [Toby]: There is no situation that ADVPN solution could be prevented > from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing > network bandwidth, meeting the application latency requirement. Especially > in the Hub, for each spoke, the Qos policy should be implemented > individually , because different spoke has different link speed and data > processing capability. Thus, in the ADVPN solution, the small spoke can not > be overrun by hub by sending too much traffic, also the spoke which has > large bandwidth cannot hog the hub's resources and starve other spokes. In > addition, a unique Qos policy for each spoke in the hub could be cumbersome > for administrator, some improvement could be implemented, such as the > spokes with the same bandwidth can belong to the same group, the Qos policy > can be implemented on a basis of group. > >> >> > ADVPN peer SHOULD NOT send excessive traffic to the other members of >> ADVPN. >> >> How would you define "excessive"? Where would that measurement be done? > > > [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth > can be defined as "excessive". To solve this problem, the other ADVPN peer > should apply Qos policy for this ADVPN peer. > > > 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? > > > [Toby] The reason is explained in the first answer. > >> >> --Paul Hoffman > > > > > Email secured by Check Point > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --089e0111e07016ca1904de4203b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yoav,
=A0
Do we see a conclusi= on on the QoS requirement and if we want to include it as part of the ADVPN= solution or keep it seperate?
=A0
Thanks,
Vi= shwas


On Thu,= May 2, 2013 at 1:11 PM, Yoav Nir <ynir@checkpoint.com> wr= ote:
Hi Toby.

Let's see if I understand the issue. I'll describe this with a= n example. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each= have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS= policy. So if A, B, and C are simultaneously sending traffic to E through = Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP A= CKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to= bypass Z. Initially A had no IPsec policy about E. There's no reason t= o think it had a QoS policy about E, and the same is true in the other dire= ction. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and = have the QoS targets miss.=A0

So whereas before ADVPN the center gateway could be counted on to hand= le the QoS (because everything goes through it), as soon as you add ADVPN, = that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of = AD-VPN, but I want to make sure that we understand the issue.

Yoav
=A0
On May 2, 2013, at 6:02 PM, Toby Mao <yumao9@gmail.com> wrote:


On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <= span dir=3D"ltr"> <paul.hoffman= @vpnc.org> 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 <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 solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN?

=A0[Toby]:=A0There is no situation that ADVPN solution could be prevented from implem= enting Qos. Actually, Qos is crucial on ADVPN, such as sharing network band= width, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy= should be implemented individually , because different spoke has different= link speed and data processing capability. Thus, in the ADVPN solution, th= e small spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwid= th cannot hog the hub's resources and starve other spokes. In addition,= a unique Qos policy for each spoke in the hub could be cumbersome for admi= nistrator, some improvement could be implemented, such as the spokes with the same bandwidth can belong to the = same group, the Qos policy can be implemented on a basis of group.

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

How would you define "excessive"? Where would that measurement be= done?
=A0
[Toby] =A0= The traffic to the ADVPN peer exceeding the actual peer bandwidth can be de= fined as "excessive". To solve this problem, the other ADVPN peer= should apply Qos policy for this ADVPN peer.=A0

> 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?
=A0
[Toby] =A0= The reason is explained in the first answer.=A0

--Paul Hoffman



Email secured by Check Point

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


--089e0111e07016ca1904de4203b1--