IETF Logo Mail Archive

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

Toerless Eckert <tte@cs.fau.de> Fri, 16 November 2018 10:50 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCE1130DC3 for <lsr@ietfa.amsl.com>; Fri, 16 Nov 2018 02:50:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 UxVB9U29ViYZ for <lsr@ietfa.amsl.com>; Fri, 16 Nov 2018 02:50:05 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D3A126BED for <lsr@ietf.org>; Fri, 16 Nov 2018 02:50:04 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7B108548136; Fri, 16 Nov 2018 11:49:59 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 6BDFD440210; Fri, 16 Nov 2018 11:49:59 +0100 (CET)
Date: Fri, 16 Nov 2018 11:49:59 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Robert Raszuk <robert@raszuk.net>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, rjs@rob.sh, tony1athome@gmail.com, lsr@ietf.org
Message-ID: <20181116104959.wqzwuikn4kctpppl@faui48f.informatik.uni-erlangen.de>
References: <4085ff6f77b5443ca4de319f9a909a01@XCH-ALN-001.cisco.com> <20181115232222.psroxxfwhxrdscns@faui48f.informatik.uni-erlangen.de> <CAOj+MMHLO+QjjSh-g4QWBqht3RZKrmxMDjtyhTZQhy0SJ3uojQ@mail.gmail.com> <20181116000708.sl6htsevtalu44wx@faui48f.informatik.uni-erlangen.de> <CAHxMRebnhYbwBED8Us2ZR7ikJHHs6VBR6ZLy7cCqfyDJ6XVUAw@mail.gmail.com> <5785DD05-7B7E-4AD5-9B9D-D4DB80B14B16@gmail.com> <AB0CF38C-2372-42A2-BCD0-B3D0E5692E1E@gmail.com> <CAFAzdPUS-+8JKEqfA82Xp9PwgqJ8C2TkZWErf-BH4Kw3Tvkb6g@mail.gmail.com> <CAOj+MMFatF=_E_EqfX4fg8Hgop1G5AcA2Z5SfbU7GU5=jxdjSA@mail.gmail.com> <CAFAzdPWz5DurwxtuAW1vqXft9VovqqmVw1mKif7kM8Z7XzNT5A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAFAzdPWz5DurwxtuAW1vqXft9VovqqmVw1mKif7kM8Z7XzNT5A@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9B99LBPjWpxa0pTVL50mQF0pNok>
Subject: Re: [Lsr] LSR: Using DSCP for path/topology selection Q
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Nov 2018 10:50:07 -0000

On Fri, Nov 16, 2018 at 12:14:45AM -0800, Jeff Tantsura wrote:
> P.S. in my previous life, working on 5G transport slicing (yes, i know :))
> - i needed per slice identity over the common transport, we ended up
> looking at UDP port ranges, rather than DSCP - too few bits

Right. The main issue is when you start requiring new/more DSCP for
a purpose that is not QoS. Which by itself is not a good hard
definition, but at least a starting point.

Cheers
    Toerless

> 
> Cheers,
> Jeff
> On Thu, Nov 15, 2018 at 23:37 Robert Raszuk <robert@raszuk.net> wrote:
> 
> > Jeff,
> >
> > > What architecture?
> > > PBR is a form of:
> > > match DSCP X
> > > set next-hop Y
> > > needs no interoperability...
> >
> > That's pretty narrow view. I could say the worst possible example :)  You
> > would have to either encapsulate or apply your sample config consistently
> > on every hop. Brrrrr.
> >
> > To me DSCP can be used to map packets to different routing context,
> > different plane or can be used as a parameter in flex-algorithm.
> >
> > Thx,
> > R.
> >
> >
> >
> >
> >
> > On Fri, Nov 16, 2018 at 8:19 AM Jeff Tantsura <jefftant.ietf@gmail.com>
> > wrote:
> >
> >> Tony,
> >>
> >> What architecture?
> >> PBR is a form of:
> >> match DSCP X
> >> set next-hop Y
> >> needs no interoperability...
> >> If someone wants to describe how they use a particular vendor feature to
> >> solve a particular problem in a BCP, sure, the more BCPs - the better.
> >>
> >> Wrt using DSCP in routing decision process - it was a bad idea back then,
> >> hasn???t got any better now... besides - now we have got a toolbox that
> >> wasn???t available then.
> >>
> >> Cheers,
> >> Jeff
> >> On Thu, Nov 15, 2018 at 22:56 Tony Li <tony1athome@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> On Nov 15, 2018, at 8:47 PM, Jeff Tantsura <jefftant.ietf@gmail.com>
> >>> wrote:
> >>>
> >>> The question is really - what is here to standardize?
> >>>
> >>>
> >>>
> >>> There???s a fine architectural BCP here: this is how we are solving
> >>> problem XYZ.  Please don???t break this.
> >>>
> >>> Tony
> >>>
> >>>

> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr


-- 
---
tte@cs.fau.de

v2.23.0 | Report a Bug | By Email