IETF Logo Mail Archive

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

Jeff Tantsura <jefftant.ietf@gmail.com> Fri, 16 November 2018 04:48 UTC

Return-Path: <jefftant.ietf@gmail.com>
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 4E793128CE4 for <lsr@ietfa.amsl.com>; Thu, 15 Nov 2018 20:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 F-T_ayJYEkpO for <lsr@ietfa.amsl.com>; Thu, 15 Nov 2018 20:48:01 -0800 (PST)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4988412777C for <lsr@ietf.org>; Thu, 15 Nov 2018 20:48:01 -0800 (PST)
Received: by mail-pl1-x633.google.com with SMTP id b22-v6so5096100pls.7 for <lsr@ietf.org>; Thu, 15 Nov 2018 20:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U2u86V2hU3N9o8yWgf0O4X0S7FgsNVPq2lOznTY9qd4=; b=teCF5G+uV3Hny0RQTW895Xe8rfAhy4k41itn9KPjvLopo7RU3wZJlPjbbv82DKskkh CSjngA/QIPrdz91Qmj5GoM+HxepfxwqMQQgaANSGbljEgMMNQH/pTq8MRnPkLnMeyry3 CnWgYphBFghlq29Lo8hsrY2pv1Hw8B3zm25zu1SsqZBLsuKdrJUV0GL0FR39dKadLUid rit093ZgO2oYag7i8xCqPcSOKTC5OBnni3WLTiUlkG06p3b/eMATL8PfiTaL+ju46Y9X 9kbma0wqF7Ajjr6jzW288In+0g3vIQid2WVlpqL3155yXdw9uSqKTXdy+MbPLI9EDRSh M6Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U2u86V2hU3N9o8yWgf0O4X0S7FgsNVPq2lOznTY9qd4=; b=embTbop5X0kBpPHAXyZyVYAP/oSAqxT1nZOivYs4KaE/lLxM3j/cXAa0EUHuZCyGzn AgLIYR87bCX4FHAlpa5d5k0PSqsARY9V2bqzLe7sfj+P4RNIZ9D2GkOydfURj3mLo/1q vXfYlHsP6be4SLqOaLUxLpaNBh4Qv10JXy0hbcWFbXHB4tMaAdm9xfUdFIXrVZ/clcs6 6+ztP1dqj9c3RX9elzFhUsDN9HhCx/YA+GjbX2/vaJddgkK5gAf9cEvFtBjvlrxtSJKq JZxZe8g7OIMceWkjs/O1jzbU62qsqLdd8BiFl9m+7m6bp5S3loqtBnuashcS3/H+d0nN 7rlQ==
X-Gm-Message-State: AGRZ1gKCXQIBFbeKm8O3ssSeR+u7nD5cyXfrAyBWi01BK/Kc0fGm4+WD Kjc7CvjaflCejea7bbCIIbo=
X-Google-Smtp-Source: AJdET5eYWt+ilSyuU3Nv/6GHmOr+vN/WyFxLhJou3E6Zvr5/F425i/WID9YGXUXdr4k49PaNyAXDzw==
X-Received: by 2002:a17:902:6848:: with SMTP id f8mr9038855pln.300.1542343680734; Thu, 15 Nov 2018 20:48:00 -0800 (PST)
Received: from [192.168.88.33] (mx-ll-183.89.24-193.dynamic.3bb.co.th. [183.89.24.193]) by smtp.gmail.com with ESMTPSA id s9sm21550305pgl.88.2018.11.15.20.47.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 20:47:59 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-1E6285A8-B74B-423F-9544-4CB5E27BB595"
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura <jefftant.ietf@gmail.com>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <CAHxMRebnhYbwBED8Us2ZR7ikJHHs6VBR6ZLy7cCqfyDJ6XVUAw@mail.gmail.com>
Date: Fri, 16 Nov 2018 11:47:55 +0700
Cc: Toerless Eckert <tte@cs.fau.de>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Robert Raszuk <robert@raszuk.net>, lsr@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <5785DD05-7B7E-4AD5-9B9D-D4DB80B14B16@gmail.com>
References: <20181115022918.pfgcztognsjeb37v@faui48f.informatik.uni-erlangen.de> <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>
To: Rob Shakir <rjs@rob.sh>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/e9F18U1Inpe0oOsbKVnyIEfGTR0>
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 04:48:03 -0000

+1 Rob
I have seen number of MBH networks using DSCP to change forwarding - AKA PBR.

The question is really - what is here to standardize?

RSVP-TE use cases mentioned by Rob (CBTS/PBTS in IOS realm) are classical examples of Policy Based Routing and as such are subject to implementation details, not standardization.

Am I missing something?


Regards,
Jeff

> On Nov 16, 2018, at 07:47, Rob Shakir <rjs@rob.sh> wrote:
> 
>> On Thu, 15 Nov 2018 at 16:07 Toerless Eckert <tte@cs.fau.de> wrote:
>> > And btw I read Peter's note as possibility (or invitation) to define
>> > algorithm which takes into account DSCP rather then a announcement that
>> > this is not there and it should never be.
>> 
>> Sure, i am only talking about the solutions that tried to use DSCP for
>> routing so far. I think those failed. And when other agree and we codify
>> that, then that would not exclude the option for new work (like what
>> Peter may have in mind) to superceed that recommendation. 
> 
> A number of networks on which I have worked have used DSCP-based tunnel selection to choose between RSVP-TE LSPs. This essentially is different routing based on DSCP, which seems to be something that you're trying to cover -- is that correct?
> 
> If so, given that these are running in real networks, I find it hard to conclude that any IETF standard should declare them as failed.
> 
> r.
> 
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email