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 8BD3D21F9133 for ; Mon, 6 May 2013 09:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 6enB3w8CVn-1 for ; Mon, 6 May 2013 09:33:10 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8E21F888C for ; Mon, 6 May 2013 09:33:10 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUYfbRpMh8gNXLPEJs4KVYyd8K5wGBy2z@postini.com; Mon, 06 May 2013 09:33:10 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 May 2013 09:31:22 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 6 May 2013 09:31:21 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.209) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 May 2013 09:34:38 -0700 Received: from mail78-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 May 2013 16:31:19 +0000 Received: from mail78-am1 (localhost [127.0.0.1]) by mail78-am1-R.bigfish.com (Postfix) with ESMTP id A1BDF40455 for ; Mon, 6 May 2013 16:31:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zf7Iz98dI9371Ic85fhzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL18c673h8275bh8275dhz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1155h) Received: from mail78-am1 (localhost.localdomain [127.0.0.1]) by mail78-am1 (MessageSwitch) id 1367857867595120_31465; Mon, 6 May 2013 16:31:07 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.253]) by mail78-am1.bigfish.com (Postfix) with ESMTP id 7E558120058; Mon, 6 May 2013 16:31:07 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 May 2013 16:31:05 +0000 Received: from BLUPRD0511MB413.namprd05.prod.outlook.com ([169.254.6.83]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0305.001; Mon, 6 May 2013 16:30:51 +0000 From: Praveen Sathyanarayan To: Toby Mao , Yoav Nir Thread-Topic: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt Thread-Index: AQHOSncSTL2I0J2F6E6l8VJM+XdQ2Q== Date: Mon, 6 May 2013 16:30:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.135.132] Content-Type: multipart/alternative; boundary="_000_CDAD284818B87Fpraveenysjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CHECKPOINT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%H3C.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%VPNC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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: Mon, 06 May 2013 16:33:16 -0000 --_000_CDAD284818B87Fpraveenysjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Toby, When you say QoS policy, could you elaborate what it really means? I mean w= hat kind of information does it need to have or exchanged? -- Praveen From: Toby Mao > Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir > 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 Hi Yoav. The QoS implementations in ADVPN are : 1. In the star topology, the QoS policy is implemented individually= for each spoke in the hub, all the traffic through the Hub can be regulate= d by QoS policy in the hub. 2. In the full mesh topology, when the two spokes establish the dire= ct connection, each spoke should also have the QoS policy for each other. T= he QoS policy can be obtained from the Hub, or other control device , whic= h has the individual QoS policy for each spoke. I think your understanding is the same as the QoS implementation in the ful= l mesh topology. Toby On Fri, May 3, 2013 at 4:11 AM, Yoav Nir > wrote: 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_CDAD284818B87Fpraveenysjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <257511755B999941BB6F3651F1B22AE3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Toby,

When you say QoS policy, could you elaborate what it really means? I m= ean what kind of information does it need to have or exchanged? 

-- Praveen

From: Toby Mao <yumao9@gmail.com>
Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir <ynir@checkpoint.com>
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3= c.com>, Paul Hoffman <pa= ul.hoffman@vpnc.org>
Subject: Re: [IPsec] One comment to= this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Hi Yoav.

      = ;   The QoS implementations in ADVPN are :

1.=         In the star topology,  the QoS p= olicy is implemented individually for each spoke in the hub, all the traffic through the Hub ca= n be regulated by QoS policy in the hub.

2.=        In the full mesh topology,  when the t= wo spokes establish the direct connection, each spoke should also have the QoS policy for each= other. The QoS policy can be obtained from the Hub, or other control devic= e ,  which has the individual QoS policy for each spoke.=

I think your under= standing is the same as the QoS implementation in the full mesh topology.

Toby



On Fri, May 3, 2013 at 4:11 AM, Yoav Nir <ynir@checkpoin= t.com> wrote:
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 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 sp= eed 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 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 bandwidth can belong to the same group, t= he 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?
 
[Tob= y]  The traffic to the ADVPN peer exceeding the actual peer bandwidth = can be defined as "excessive". To solve this problem, the other A= DVPN 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?
 
[Tob= y]  The reason is explained in the first answer. 

--Paul Hoffman



Email secured by Check Point

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


 --_000_CDAD284818B87Fpraveenysjunipernet_--