Re: [Idr] New Draft Notification draft-knoll-idr-qos-attribute-00.txt

Robert Raszuk <raszuk@juniper.net> Mon, 09 June 2008 18:52 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0F93A69F7; Mon, 9 Jun 2008 11:52:06 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20EA53A69F7 for <idr@core3.amsl.com>; Mon, 9 Jun 2008 11:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Deblh6znSzN for <idr@core3.amsl.com>; Mon, 9 Jun 2008 11:52:05 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id 1B9D13A6944 for <idr@ietf.org>; Mon, 9 Jun 2008 11:51:55 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 09 Jun 2008 11:52:14 PDT
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 11:47:03 -0700
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 11:47:02 -0700
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 11:47:02 -0700
Received: from [172.26.250.98] ([172.26.250.98]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m59Ikpx91391; Mon, 9 Jun 2008 11:46:51 -0700 (PDT) (envelope-from raszuk@juniper.net)
Message-ID: <484D7A99.4060009@juniper.net>
Date: Mon, 09 Jun 2008 11:46:49 -0700
From: Robert Raszuk <raszuk@juniper.net>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "Thomas M. Knoll" <knoll@etit.tu-chemnitz.de>
References: <alpine.LRH.1.10.0806091642180.32755@tor.hrz.tu-chemnitz.de>
In-Reply-To: <alpine.LRH.1.10.0806091642180.32755@tor.hrz.tu-chemnitz.de>
X-OriginalArrivalTime: 09 Jun 2008 18:47:02.0111 (UTC) FILETIME=[347A06F0:01C8CA61]
Cc: idr@ietf.org
Subject: Re: [Idr] New Draft Notification draft-knoll-idr-qos-attribute-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: raszuk@juniper.net
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Hi Thomas,

I would like to clarify one point this draft is suggesting ...

If I understand it correctly it proposes to propagate QoS marking within 
BGP across domain boundaries. The least granularity I could see this 
used with is /32 (mostly unroutable in the internet). But even that .. 
even if this is to work only across two peering ASes which allow to send 
to each other number of /32s it assumes that this entire destination 
uses the same QoS marking. So if this is a server with voice, video and 
httpd running everything to it would use voice qos marking. IMHO this is 
already non starter.

Now section 3.3 goes even further ... if we are sending an aggregate in 
BGP (/24 /20 /16 etc ...) and if even a single member of an aggregate 
uses qos marking (for example for voice) all packets going this entire 
aggregate should be marked as voice ? I think this would be a mistake.

Marking is usually done on packet content inspection on ingress (up to 
application layer) and not on it's destination.

IMHO BGP is too course to carry qos marking in the single SAFI. Note 
that some time back there was an attempt to make context address family 
to allow to achieve very similar goal to yours but at more controllable 
and granular fashion. That included the ability to send those separate 
classes of traffic via different next hops and map them to different 
forwarding paradigms in peering ASes (one could use TE-LSPs, one MTR 
etc.). Your proposal does not have any reference to it.

Thx,
R.


> Dear WG members,
> 
> a new draft has been uploaded, which suggests the definition of a new 
> extended community attribute for QoS marking.
> It is available at 
> http://tools.ietf.org/html/draft-knoll-idr-qos-attribute-00 and I would 
> kindly ask you for comments to it.
> I would like the IDR to consider the proposed mechanism for further study 
> within the WG.
> 
> Regards,
> Thomas M. Knoll
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr