Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Toby Mao <yumao9@gmail.com> Thu, 02 May 2013 15:02 UTC

Return-Path: <yumao9@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 77B1521F8E87 for <ipsec@ietfa.amsl.com>; Thu, 2 May 2013 08:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 vYylvt0iBTGx for <ipsec@ietfa.amsl.com>; Thu, 2 May 2013 08:02:50 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0090721F8E7E for <ipsec@ietf.org>; Thu, 2 May 2013 08:02:49 -0700 (PDT)
Received: by mail-ee0-f44.google.com with SMTP id t10so342135eei.31 for <ipsec@ietf.org>; Thu, 02 May 2013 08:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=d3qKWmH6a2IVuJ8A1J8FtM/d6DbAN72D3F4bpPD2qII=; b=dQBqyPwf7N2RKqlHvQfmi63GrW1G7GrHaCZWIVyHVbek2d8oqyXQpQMFAeXQjQQj89 D/ES8GdCaqpSic2skdQuiKvGajHO/hx4P/ZsBJO8r+YXXqsfCWZRG8hFCKtOIZNPYgaO gzEczQFm2aepDwnMVtCemzSd9GPDLGNZWTTlrEbZeStX4ujcELajTD/qlci9wlpt6SWU Yq2XqM82zeRlhbZlQfSDFaC+xO9fDLgFSPqcE3+pADCF02iHVLSOgRFJCj2b/eK6/Mwe 0eBWmy5M6TCRd9xA/ojKu3aoEXLm7ORzU+CHZTKWM6a77tm2TZXw7mMfR9PKD/QQvTC3 Wdhg==
MIME-Version: 1.0
X-Received: by 10.14.115.131 with SMTP id e3mr20297312eeh.43.1367506968989; Thu, 02 May 2013 08:02:48 -0700 (PDT)
Received: by 10.223.182.8 with HTTP; Thu, 2 May 2013 08:02:48 -0700 (PDT)
In-Reply-To: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org>
References: <CAPPa=knYfWjqfGEhXrFNafhfKuOrMKM-VPC8zGJj+FYy64-FHQ@mail.gmail.com> <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org>
Date: Thu, 02 May 2013 23:02:48 +0800
Message-ID: <CAPPa=k=VJNnMeHDHd00G4=U=0oDgwghEM8bQyatJFUx3+F3XmA@mail.gmail.com>
From: Toby Mao <yumao9@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary="001a11c29c5e1d759004dbbd878d"
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.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: Thu, 02 May 2013 15:02:55 -0000

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