IETF Logo Mail Archive

Re: [mpls] [spring] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

<Ruediger.Geib@telekom.de> Thu, 16 November 2017 09:44 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 CB7381293E0; Thu, 16 Nov 2017 01:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level:
X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=Qzef/x5o; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=EK5422Rt
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 QZZa46c8FlD7; Thu, 16 Nov 2017 01:44:12 -0800 (PST)
Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (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 8F900127275; Thu, 16 Nov 2017 01:44:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1510825451; x=1542361451; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=al588q8elF0z0DNBC5AYJ5s+2N6cCHrwaJDwKIDei9o=; b=Qzef/x5oYIc2n5ptFNYEo0B1GddVHbphBywZUG1EeIDa9gEFMJunjtOz AHzkr2Pqs6mKHC43f+7TBGE6hicFDVUFEsw9FBr989Djqy7B1PoOqhKam 69uowTMZBiY1RBJBLuZlLCVWurmyN1PjCAnS8AEVIxiEoJ1sOB3UOst5d nXiBVxbLMI1WNdc3kuHkUTyO/Tm5HZYrl4XwioPU6QQeQVDWy+ky5mRUE hLpt/qBG/gkzeLecs9Y4vNuiwHw1U45mUbvSQqK2Oc/8R/DACRG4WW/cr qCpsLBI/B6BKlTKG5kJ3rUgp9sXnzO46gqn+Pzb5NoKhLNrVcZF6r0/8n w==;
Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 10:43:54 +0100
X-IronPort-AV: E=Sophos; i="5.44,402,1505772000"; d="scan'208,217"; a="66183308"
Received: from he105789.emea1.cds.t-internal.com ([10.169.118.28]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 16 Nov 2017 10:43:53 +0100
Received: from HE105664.EMEA1.cds.t-internal.com (10.169.118.61) by HE105789.emea1.cds.t-internal.com (10.169.118.28) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Nov 2017 10:43:52 +0100
Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105664.EMEA1.cds.t-internal.com (10.169.118.61) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 16 Nov 2017 10:43:52 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.15) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 16 Nov 2017 10:43:37 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=al588q8elF0z0DNBC5AYJ5s+2N6cCHrwaJDwKIDei9o=; b=EK5422RtJhze0Drvo803yqrcgLSyUxvciA/R4xr/l9BTlWlbBBQ2E6QoyLLFhpZ4jmDTUfWe99hpIIrxcdySy7z5taG4YBWBnMFiTJDcVqyBaiaJH2KryGdjAFkLhZPfD3osTz6RH6E5rqcuUKRLyf52+BKMEubfR4AcLUwdmq8=
Received: from LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.139) by LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 09:43:51 +0000
Received: from LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE ([fe80::7981:1758:a216:9354]) by LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE ([fe80::7981:1758:a216:9354%15]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 09:43:51 +0000
From: Ruediger.Geib@telekom.de
To: adrian@olddog.co.uk
CC: draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org, spring@ietf.org, zali@cisco.com, mpls@ietf.org, mach.chen@huawei.com, jefftant.ietf@gmail.com, robert@raszuk.net
Thread-Topic: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
Thread-Index: AdNei+Ardi16EuikTr2dKgjgCIeCeQAMB2Hg
Date: Thu, 16 Nov 2017 09:43:51 +0000
Message-ID: <LEXPR01MB0094E212D3765DA6BA1AAEC49C2E0@LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE>
References: <12fc01d35e9c$ad540470$07fc0d50$@olddog.co.uk>
In-Reply-To: <12fc01d35e9c$ad540470$07fc0d50$@olddog.co.uk>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.3.155]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; LEXPR01MB0094; 6:43nhP3CYxkRj/UIYDmrDUIGETBGIrDm1AYXacBWamlhipRQy39c+p5OnWxbYOAjNkp0B8JEFip3eLNEwAYOVGa5Yd+Vnc/4cmOcHDe4zlLF1UNxj5umBPh90MYDqcDWwKrl8NxsAr5lv7qz5fkjRlS08IPl902EYNH0AlNbNfbbUfCciR49RnQXO6ta3UJLnG1SlINEv+IgSt2Dl7yGynDqWO83IcFo3X+IEdw8aw5jsT/PKMblKY2jv+Wk20DP/LOBZuF8VqDPbuXR/Sg5SSYJmQ9VRF+G38lyYrIBkKAe2zNBdsV3NLnx682rTJ7u5Ps6DLWoOevLBKMskA1f/XRqYbJry+C+hmQQ05kaRxHU=; 5:KbntQF2wKxuwiT0MVhC5jE3bUDUNgzUN3iuEkU/c93E+B2SVv/w4uc50cRq2syU1E6DRICMrCmj83MfeYg6Aev8mawckA2kEdcX2WhxusjZNXUrDQeGjwvuwMSPjRds1dAUZ+TvFAl9As4Xtms382s/nVO5Wb5xLTpRFdWfmoC0=; 24:PalArxw0qMMjQ520wedDqExx2FyUplXk5LL3gc4VgEmnDjU3JVmL3/TbCtof9KRo65alkbhId/ln1q/56yGoK/P0QLaLjaIsB+/zD+kC6/A=; 7:TvEWgsXvajAZbfBdrBvAX/083OH0lJ2frxFm5PxEXokMVG6zdIZ7HJcmRraTRZQ0+MFdmhlHHl6KIVkzi8ZIEpTXxM/rVparq69YnaVqDyNTN3VIzoJvbcDCv7X2Mw+AgYQXtx8Ri1PcRbE5MD5YWZocLk96mBGm9bgqh8PJG499hkAXtGe7Bl88dsQ9UZrlr7azeGc8xraT4746rMfX8j980lRugQzI8uqZXL+rlpPvWSGaJb+N7nLZNU9h4n6T
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 7df09d1f-0f63-49ea-b384-08d52cd68b74
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:LEXPR01MB0094;
x-ms-traffictypediagnostic: LEXPR01MB0094:
x-microsoft-antispam-prvs: <LEXPR01MB0094991E60C586BDE61D8FCF9C2E0@LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE>
x-exchange-antispam-report-test: UriScan:(50582790962513)(95692535739014)(227612066756510)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LEXPR01MB0094; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LEXPR01MB0094;
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(5250100002)(5640700003)(97736004)(189998001)(85182001)(230783001)(7110500001)(4326008)(316002)(39060400002)(75402003)(7736002)(86362001)(7696004)(54906003)(2950100002)(6916009)(5660300001)(74482002)(2900100001)(2420400007)(15650500001)(33656002)(50986999)(478600001)(53936002)(2906002)(106356001)(76176999)(54356999)(72206003)(3846002)(10710500007)(6116002)(790700001)(105586002)(102836003)(14454004)(2351001)(85202003)(101416001)(66066001)(3280700002)(1730700003)(8676002)(6306002)(81156014)(68736007)(2501003)(55016002)(9686003)(54896002)(8936002)(81166006)(3660700001)(777600001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0094; H:LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_LEXPR01MB0094E212D3765DA6BA1AAEC49C2E0LEXPR01MB0094DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7df09d1f-0f63-49ea-b384-08d52cd68b74
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 09:43:51.6004 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0094
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/qCMC68SCbqN-2avzJA5UVULMn0A>
Subject: Re: [mpls] [spring] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 16 Nov 2017 09:44:16 -0000

Adrian,

to me, there’s no ideal solution. But an analysis may help to find a useful solution. There’s a need to collect traffic statistics also for packets which don’t follow the shortest end to end path. There’s no simple howto, I think.

For the time being, I’d prefer not to add special labels to the stack. What other options are there?

  *   Accounting at the router pushing a relevant label stack only.
  *   Accounting of an n-label stack.
  *   Acoounting of a subset of labels only (e.g. Node-SID Labels and Anycast-SID, but not ADJ-SID). The idea is a compromise to limit the number of counters be maintained. Consider accounting of the top 2 labels carrying global routing information.
  *   A special label. Shradda proposes to put such a label into the stack. The labels present there prior to the addition are maintained. One might think about a single top label which identifies and replaces the label stack carrying routing information relevant for the path. That would simplify accounting, but it requires suitable IGP functionality.

None of the options sounds simple. Are there more (and simpler) ones I didn’t come upon?

Regards, Ruediger

Von: spring [mailto:spring-bounces@ietf.org] Im Auftrag von Adrian Farrel
Gesendet: Donnerstag, 16. November 2017 06:35
An: 'Mach Chen' <mach.chen@huawei.com>; 'Jeff Tantsura' <jefftant.ietf@gmail.com>; 'Robert Raszuk' <robert@raszuk.net>
Cc: 'draft-hegde-spring-traffic-accounting-for-sr-paths' <draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>; 'spring' <spring@ietf.org>; 'Zafar Ali (zali)' <zali@cisco.com>; 'mpls' <mpls@ietf.org>
Betreff: Re: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Let's unpick a couple of things...

1. This work is not talking about per-flow accounting, it is talking about peer SR-path accounting
2. ipfix on its own does not cut it because you still have to put a marker in the packets
3. Yes, SR assumes there is no (i.e. zero) state per SR-path in the network
But this third point causes a tension: we want to use SR because it is good, but we want to do transit node diagnostics because (frankly) they are necessary.
To get the full picture of why they are necessary read the draft, or consider ECMP.

This discussion will not be unfamiliar to those who tried to debug LDP networks.

Adrian

v2.23.0 | Report a Bug | By Email