Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt

Mark Tinka <mark.tinka@seacom.mu> Wed, 14 September 2016 12:45 UTC

Return-Path: <mark.tinka@seacom.mu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5926A12B769 for <mpls@ietfa.amsl.com>; Wed, 14 Sep 2016 05:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRF6ywIqNhFJ for <mpls@ietfa.amsl.com>; Wed, 14 Sep 2016 05:45:00 -0700 (PDT)
Received: from the-host.seacom.mu (ge-1.ln-01-jnb.za.seacomnet.com [105.28.96.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C78612B334 for <mpls@ietf.org>; Wed, 14 Sep 2016 05:39:32 -0700 (PDT)
Received: from [127.0.0.1] (helo=Mark-Tinkas-MacBook.local) by the-host.seacom.mu with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <mark.tinka@seacom.mu>) id ODHV5R-00019S-KB; Wed, 14 Sep 2016 14:39:27 +0200
To: Umut Keten <umut.keten@turktelekom.com.tr>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
References: <cvuifsybtov39macfmufuc5f.1473802811888@email.android.com> <0ea601d20e6b$47d77dc0$d7867940$@olddog.co.uk> <B81700F985BE844B8DD45271EF5E1524A369092D@S000MBX06.turktelekom.intra> <26a707263d8e4464a827013b4eea0f33@HE105662.emea1.cds.t-internal.com> <HE1PR0301MB2266BA8A6A7CE3FDDE15BA539DF10@HE1PR0301MB2266.eurprd03.prod.outlook.com> <B81700F985BE844B8DD45271EF5E1524A3690B58@S000MBX06.turktelekom.intra> <B81700F985BE844B8DD45271EF5E1524A3690B79@S000MBX06.turktelekom.intra> <HE1PR0301MB226630CA8E33F952F33701BD9DF10@HE1PR0301MB2266.eurprd03.prod.outlook.com> <iw6roctx047qs1yor3brv0f1.1473855687767@email.android.com>
From: Mark Tinka <mark.tinka@seacom.mu>
Message-ID: <ebbbd14e-f7a2-9185-65e6-869d341e3f03@seacom.mu>
Date: Wed, 14 Sep 2016 14:39:27 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Thunderbird/49.0
MIME-Version: 1.0
In-Reply-To: <iw6roctx047qs1yor3brv0f1.1473855687767@email.android.com>
Content-Type: multipart/alternative; boundary="------------911C4D30687C120388A9746B"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/7VpMmFuQkl6mhxv44ajh65cHaZs>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] FW: New Version Notification for draft-keten-mpls-expbit-00.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Sep 2016 12:45:03 -0000


On 14/Sep/16 14:27, Umut Keten wrote:

> Alexander hi,
>
> I don't agree. I think we need more QoS classes. I personally could do
> with a lower class then BE, something like a trash class.
>
> I can map the lowest to BE and thats it, but some services I would
> like to map lower.
> Mapping the more important BE one higher then BE is no option, it
> would affect other services.
>
> Saying we don't need more QoS, surely you can't mean that.

I don't think we need more QoS.

We run 4 classes, 1 of which is reserved for NC. So effectively, we run
3 classes for actual service (BE, AF and EF). We've struggled to use
anything more, not that we are trying.

The issue with QoS is not the number of classes you have, but how much
classification you realistically do. This is a lot more difficult in a
service provider network compared to the enterprise. The fact that MPLS
is protocol-independent also means adding more classes to it somewhat
defeats the purpose.

But, YMMV.

Mark.