Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt
Vishwas Manral <vishwas.ietf@gmail.com> Mon, 03 June 2013 15:56 UTC
Return-Path: <vishwas.ietf@gmail.com>
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 <ipsec@ietfa.amsl.com>; 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 <ipsec@ietfa.amsl.com>; 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 <ipsec@ietf.org>; Mon, 3 Jun 2013 08:56:48 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id at20so10366627iec.7 for <ipsec@ietf.org>; 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: <CAPPa=knYfWjqfGEhXrFNafhfKuOrMKM-VPC8zGJj+FYy64-FHQ@mail.gmail.com> <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> <CAPPa=k=VJNnMeHDHd00G4=U=0oDgwghEM8bQyatJFUx3+F3XmA@mail.gmail.com> <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com>
Date: Mon, 03 Jun 2013 08:56:47 -0700
Message-ID: <CAOyVPHQpj5iKu5VoktaenQPuDiJ77MVzUd-su3h=ENVz=n0NYg@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: multipart/alternative; boundary="089e0111e07016ca1904de4203b1"
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.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: Mon, 03 Jun 2013 15:56:49 -0000
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 <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> wrote: > > > On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <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 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 > >
- [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