Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt
Praveen Sathyanarayan <praveenys@juniper.net> Tue, 04 June 2013 00:56 UTC
Return-Path: <praveenys@juniper.net>
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 F1D4521F8CB5 for <ipsec@ietfa.amsl.com>; Mon, 3 Jun 2013 17:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level:
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 Mc2CVfTHYur3 for <ipsec@ietfa.amsl.com>; Mon, 3 Jun 2013 17:55:54 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6B64E21E80E7 for <ipsec@ietf.org>; Mon, 3 Jun 2013 17:23:14 -0700 (PDT)
Received: from mail13-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE013.bigfish.com (10.3.207.135) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Jun 2013 00:23:13 +0000
Received: from mail13-am1 (localhost [127.0.0.1]) by mail13-am1-R.bigfish.com (Postfix) with ESMTP id 022641600D0 for <ipsec@ietf.org>; Tue, 4 Jun 2013 00:23:13 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI
X-SpamScore: -25
X-BigFish: PS-25(zf7Iz98dI9371Ic85fh1dbaI4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275ch1033IL18c673h8275bh8275dhz31h2a8h683h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1155h)
Received-SPF: softfail (mail13-am1: transitioning domain of juniper.net does not designate 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=praveenys@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ;
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT005.namprd05.prod.outlook.com; R:internal; EFV:INT
Received: from mail13-am1 (localhost.localdomain [127.0.0.1]) by mail13-am1 (MessageSwitch) id 137030539091594_3352; Tue, 4 Jun 2013 00:23:10 +0000 (UTC)
Received: from AM1EHSMHS013.bigfish.com (unknown [10.3.201.243]) by mail13-am1.bigfish.com (Postfix) with ESMTP id 1461EA008E for <ipsec@ietf.org>; Tue, 4 Jun 2013 00:23:10 +0000 (UTC)
Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.54) by AM1EHSMHS013.bigfish.com (10.3.207.151) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Jun 2013 00:23:09 +0000
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 3 Jun 2013 17:23:07 -0700
Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 3 Jun 2013 17:23:07 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 3 Jun 2013 17:34:44 -0700
Received: from mail208-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Jun 2013 00:23:06 +0000
Received: from mail208-va3 (localhost [127.0.0.1]) by mail208-va3-R.bigfish.com (Postfix) with ESMTP id 10480720988 for <ipsec@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Tue, 4 Jun 2013 00:23:06 +0000 (UTC)
Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3 (MessageSwitch) id 1370305383167877_13655; Tue, 4 Jun 2013 00:23:03 +0000 (UTC)
Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.225]) by mail208-va3.bigfish.com (Postfix) with ESMTP id 25EB5D4007F; Tue, 4 Jun 2013 00:23:03 +0000 (UTC)
Received: from BLUPRD0511HT005.namprd05.prod.outlook.com (157.56.232.213) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Jun 2013 00:23:02 +0000
Received: from BLUPRD0511MB413.namprd05.prod.outlook.com ([169.254.6.30]) by BLUPRD0511HT005.namprd05.prod.outlook.com ([10.255.135.168]) with mapi id 14.16.0311.000; Tue, 4 Jun 2013 00:23:02 +0000
From: Praveen Sathyanarayan <praveenys@juniper.net>
To: Vishwas Manral <vishwas.ietf@gmail.com>
Thread-Topic: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt
Thread-Index: AQHOSncSTL2I0J2F6E6l8VJM+XdQ2ZkkTboAgAAbUQA=
Date: Tue, 04 Jun 2013 00:23:02 +0000
Message-ID: <CDD27E30.50B78%praveenys@juniper.net>
In-Reply-To: <CAOyVPHSfsSp=Hp4Kj=LhcY4eSkTQWu6j4h4r9OkTbha8ko5OZA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.0.121105
x-originating-ip: [10.255.135.132]
Content-Type: multipart/alternative; boundary="_000_CDD27E3050B78praveenysjunipernet_"
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
X-OriginatorOrg: juniper.net
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.com>, Yoav Nir <ynir@checkpoint.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Toby Mao <yumao9@gmail.com>
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 <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2013 00:56:12 -0000
HI Vishwas, I understand the use of QOS and I do think it would be a nice feature. But I am trying to see how this is specific to AD-VPN. I feel this is applicable for regular VPN as well (in Hub and Spoke topology or any type of topology). AD-VPN is about auto-discovering spokes/gateway/entity and establishing a direct connectivity. To me AD-VPN is, an extension to existing IPSec solution. So, IMO, QoS requirement should be solved out side of AD-VPN. What do you think? -- Praveen From: Vishwas Manral <vishwas.ietf@gmail.com<mailto:vishwas.ietf@gmail.com>> Date: Monday, June 3, 2013 8:45 AM To: Praveen Sathyanarayan <praveenys@juniper.net<mailto:praveenys@juniper.net>> Cc: Toby Mao <yumao9@gmail.com<mailto:yumao9@gmail.com>>, Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>>, IPsecme WG <ipsec@ietf.org<mailto:ipsec@ietf.org>>, "maoyu@h3c.com<mailto:maoyu@h3c.com>" <maoyu@h3c.com<mailto:maoyu@h3c.com>>, Paul Hoffman <paul.hoffman@vpnc.org<mailto:paul.hoffman@vpnc.org>> Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt Hi Praveen, I think the idea is to be able to have QoS in a way that the traffic from one spoke cannot overwhelm the Hub and lead to issues there. We need to maintain QoS policies per spoke (or spoke type) on the Hub, as well as to be able to push some QoS policies to the spokes from the Hub. Do I make sense? Thanks, Vishwas On Mon, May 6, 2013 at 9:30 AM, Praveen Sathyanarayan <praveenys@juniper.net<mailto:praveenys@juniper.net>> wrote: Hi Toby, When you say QoS policy, could you elaborate what it really means? I mean what kind of information does it need to have or exchanged? -- Praveen From: Toby Mao <yumao9@gmail.com<mailto:yumao9@gmail.com>> Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir <ynir@checkpoint.com<mailto:ynir@checkpoint.com>> Cc: IPsecme WG <ipsec@ietf.org<mailto:ipsec@ietf.org>>, "maoyu@h3c.com<mailto:maoyu@h3c.com>" <maoyu@h3c.com<mailto:maoyu@h3c.com>>, Paul Hoffman <paul.hoffman@vpnc.org<mailto:paul.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 policy is implemented individually for each spoke in the hub, all the traffic through the Hub can be regulated by QoS policy in the hub. 2. In the full mesh topology, when the two 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 device , which has the individual QoS policy for each spoke. I think your understanding 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@checkpoint.com<mailto:ynir@checkpoint.com>> 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 <yumao9@gmail.com<mailto:yumao9@gmail.com>> wrote: On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <paul.hoffman@vpnc.org<mailto: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<mailto: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 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<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org<mailto:IPsec@ietf.org> https://www.ietf.org/mailman/listinfo/ipsec
- [IPsec] One comment to this draft//Fwd: I-D Actio… Toby Mao
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Paul Hoffman
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Vishwas Manral
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Toby Mao
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Toby Mao
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Yoav Nir
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Toby Mao
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Praveen Sathyanarayan
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Vishwas Manral
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Vishwas Manral
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Praveen Sathyanarayan
- Re: [IPsec] One comment to this draft//Fwd: I-D A… Toby Mao