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 977BC21F8E6B for ; Thu, 2 May 2013 13:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 NE-2qkp89ehk for ; Thu, 2 May 2013 13:12:00 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 379E821F8E87 for ; Thu, 2 May 2013 13:11:59 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r42KBhQU032160; Thu, 2 May 2013 23:11:43 +0300 X-CheckPoint: {5182C731-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 2 May 2013 23:11:42 +0300 From: Yoav Nir To: Toby Mao Thread-Topic: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt Thread-Index: AQHOQvTSzCtJfIFl80iVCJ3Hf4wLpZjp9voAgAfdCQCAAFZMAA== Date: Thu, 2 May 2013 20:11:42 +0000 Message-ID: <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com> References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.112] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 114b53c25ca129f0f5be5da2b91437cb0f8f49137e Content-Type: multipart/alternative; boundary="_000_33E02A330EA14D48BCA4F436C6023423checkpointcom_" MIME-Version: 1.0 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 20:12:05 -0000 --_000_33E02A330EA14D48BCA4F436C6023423checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Toby. Let's see if I understand the issue. I'll describe this with an example. Pl= ease 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 poli= cy. 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 bypa= ss Z. Initially A had no IPsec policy about E. There's no reason to think i= t had a QoS policy about E, and the same is true in the other direction. Un= less 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 th= e 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, b= ut 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) t= o 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 networ= k bandwidth, meeting the application latency requirement. Especially in the= Hub, for each spoke, the Qos policy should be implemented individually , b= ecause different spoke has different link speed and data processing capabil= ity. 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 cann= ot hog the hub's resources and starve other spokes. In addition, a unique Q= os policy for each spoke in the hub could be cumbersome for administrator, = some improvement could be implemented, such as the spokes with the same ban= dwidth 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 ADVP= N. How would you define "excessive"? Where would that measurement be done? [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth c= an be defined as "excessive". To solve this problem, the other ADVPN peer s= hould 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 --_000_33E02A330EA14D48BCA4F436C6023423checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4FE417CA9533F7448C23FA59D3198F4D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi Toby.

Let's see if I understand the issue. I'll describe this with an exampl= e. 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 to th= ink it had a QoS policy about E, and the same is true in the other directio= n. 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 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-V= PN, but I want to make sure that we understand the issue.

Yoav
 
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?

 [Toby]: There is no situation that ADVPN solution could be prev= ented from implementing Qos. Actually, Qos is crucial on ADVPN, such as sha= ring 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, 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 u= nique Qos policy for each spoke in the hub could be cumbersome for administ= rator, 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?
 
[Toby] &nb= sp;The traffic to the ADVPN peer exceeding the actual peer bandwidth can be= defined as "excessive". To solve this problem, the other ADVPN p= eer should apply Qos policy for this ADVPN peer. 

> The traffic for each ADVPN peer CAN be measured indi= vidually for shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually?
 
[Toby] &nb= sp;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

--_000_33E02A330EA14D48BCA4F436C6023423checkpointcom_--