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