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

John E Drake <jdrake@juniper.net> Thu, 16 November 2017 12:47 UTC

Return-Path: <jdrake@juniper.net>
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 530D21294F5; Thu, 16 Nov 2017 04:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 zypQT60QQz20; Thu, 16 Nov 2017 04:47:39 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 1A1D1129504; Thu, 16 Nov 2017 04:47:34 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAGChmfv011679; Thu, 16 Nov 2017 04:44:17 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=SZxV9m7lreC+jaMNi0FRRvxhVobM8V5hNPNzlDBH7q8=; b=Iq3hVSXv2OCUS5o08lLXKnpHkDuc3MbunduY8nxC8sg3cZhfRS8yvaRA4wnhKWKUX4HH nXyUgypIMQFYMEKFvrToSmOqXtGrC7A5u8KE2ITWIdQ37o3UOvHzllDGgsKYSJHqAgeS hZmnFNDFU7le/intH2yfhAXmRKB6+2nBBNFd2F9PwYVq5s1813gT26cRC/SvdoMUhTcp JS9GWZCq7P/URHQgpPazeiel58YP2lU58GwF4PEy4vBBjlzWbQu+vZBNueTV35MhPmql Gn5vYyvGmo694p73SOCCpEUQdiK6E6jMbDIR1rolA9cU5SIdMsjKF0eJjAtsTpH3qNLD bw==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0052.outbound.protection.outlook.com [207.46.163.52]) by mx0a-00273201.pphosted.com with ESMTP id 2e97y8rb42-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 16 Nov 2017 04:44:16 -0800
Received: from DM5PR05MB3545.namprd05.prod.outlook.com (10.174.242.150) by DM5PR05MB3548.namprd05.prod.outlook.com (10.174.242.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Thu, 16 Nov 2017 12:44:14 +0000
Received: from DM5PR05MB3545.namprd05.prod.outlook.com ([10.174.242.150]) by DM5PR05MB3545.namprd05.prod.outlook.com ([10.174.242.150]) with mapi id 15.20.0239.004; Thu, 16 Nov 2017 12:44:14 +0000
From: John E Drake <jdrake@juniper.net>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
CC: "draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org" <draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "zali@cisco.com" <zali@cisco.com>, "robert@raszuk.net" <robert@raszuk.net>, "mpls@ietf.org" <mpls@ietf.org>, "Ext - Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>
Thread-Topic: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
Thread-Index: AQHTXtZb1OxBMQVeZkyhGDQhBg5gA6MW8shw
Date: Thu, 16 Nov 2017 12:44:14 +0000
Message-ID: <DM5PR05MB35450890EA6780DEA1D8FC07C72E0@DM5PR05MB3545.namprd05.prod.outlook.com>
References: <12fc01d35e9c$ad540470$07fc0d50$@olddog.co.uk> <LEXPR01MB0094E212D3765DA6BA1AAEC49C2E0@LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE> <MWHPR05MB3551B49226876BE7FD0EA584C72E0@MWHPR05MB3551.namprd05.prod.outlook.com> <AM4PR03MB1713A8DA647754374CB281029D2E0@AM4PR03MB1713.eurprd03.prod.outlook.com>
In-Reply-To: <AM4PR03MB1713A8DA647754374CB281029D2E0@AM4PR03MB1713.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3548; 6:WqhoIz+BITHN10ldiYyUjOgDqovLmxQiRkLhXKcSgRz3PEda6luVKa36xBo0i93q5tnbTdRrmmb8xen1Ln7scjKHo44mAecgBkV4TyzTHi3WtwijltbppmAqJ7z40g4i2kRn+PUykq73oCvdOR/F6FA/4KUp/oNxfrG+h1v7EmBXzc9w/DA9cA6xippSRk+GI37vCEe0lOxrQIVKnlKfS4pjU0VnCNaZ20O70Z2BOfRbvOEB+4TjzvNz51NsGOd0pyKG3q0jXCdl55fiYuqrAnvKLJtGEtJhU+BhHXHSZAR1Vez/8vWWogEezSLvEgnfHInSLli9+LpCzwBCbp70e/qUqpsVxduqosTAejuzzGE=; 5:O+RzMcpy2S0/BYlsrkGdmr+l7xO5Ndjn29nxE/wylXE3RmMdX4Y8Kdmg36WuxxXx0Dq8JcAZ2M80sZBU1tqGjvlw1NdRUQ+EE95kId0EQfPJdfC+ojfZqPVR0lBhOKhUYNwC1W9E69PuOAD5KvejBPNQPi2+TCfefjXWhnOcdVk=; 24:CXtxrKhCsodOuuTECkqC0/lOHblquMiocu6u3qxD3xYP5S+rbrcN1LRWYabxEhXcD1MzetfAIwySq5oznMJCc251gxjr1fd9oaubQbf8tJ0=; 7:gveIaGiAcO+vVGcDK1vgiNkbh8J/imia/9sM+ON/DNFbNHjevBnd2ja4IsfjRzo9ROPPk0T42hxqJTv1KhDawzfTn5v3nudIPQMJ39WMZh3Qz1xUgw/j6qzexQBQUFcf7ocVCD0miVH1a60vV/v7OCCprgOVrmYeVNLEtX+RUfR/6VoNmkPm70DKHIIKkRiFCTlg4aF2hjnXjwk+ny8kQcijsaRvS/wxwmsfzT+Uho65kiC1WmxzkArgtw/M8tzT
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: fb611d9b-5535-42bd-ae52-08d52cefbe59
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:DM5PR05MB3548;
x-ms-traffictypediagnostic: DM5PR05MB3548:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <DM5PR05MB3548484E0B6DE64372AF5F9CC72E0@DM5PR05MB3548.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(227612066756510)(21748063052155)(279101305709854)(50582790962513);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3231022)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3548; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3548;
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(199003)(252514010)(189002)(8936002)(6506006)(55016002)(68736007)(6436002)(236005)(81166006)(230783001)(76176999)(66066001)(478600001)(93886005)(4326008)(53546010)(8676002)(10710500007)(2900100001)(6246003)(81156014)(2950100002)(54896002)(9686003)(101416001)(50986999)(14454004)(54356999)(6916009)(6306002)(561944003)(33656002)(53936002)(7736002)(3660700001)(3280700002)(86362001)(77096006)(7110500001)(15650500001)(74316002)(2906002)(97736004)(54906003)(106356001)(25786009)(5660300001)(790700001)(189998001)(229853002)(99286004)(2420400007)(7696004)(316002)(105586002)(3846002)(6116002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3548; H:DM5PR05MB3545.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR05MB35450890EA6780DEA1D8FC07C72E0DM5PR05MB3545namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: fb611d9b-5535-42bd-ae52-08d52cefbe59
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 12:44:14.4522 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3548
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160174
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/gQ1fK3e6H1L71LWORvfLLgAu1OY>
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 12:47:43 -0000

Sasha,

That’s a very good point.  Including the SR Segment List Ids could have the effect of disturbing the traffic flows away from the link in question.

Yours Irrespectively,

John

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Thursday, November 16, 2017 7:28 AM
To: John E Drake <jdrake@juniper.net>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org; spring@ietf.org; zali@cisco.com; robert@raszuk.net; mpls@ietf.org; Ext - Ruediger.Geib@telekom.de <Ruediger.Geib@telekom.de>; adrian@olddog.co.uk; Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>
Subject: RE: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

John,
Looks like a very interesting proposal.
Please note that GAL and GACH would not (hopefully) affect ECMP (if it is used on the label stack hashing) while the proposal in draft-hegde by and of itself does not guarantee that: the reserved label would be skipped, but the ID “labels” could be taken for real labels by the hashing function...

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of John E Drake
Sent: Thursday, November 16, 2017 2:00 PM
To: Ext - Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de> <Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>>; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; zali@cisco.com<mailto:zali@cisco.com>; robert@raszuk.net<mailto:robert@raszuk.net>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Ruediger,

There is also the possibility of using a GAL w/ a new fixed size GACH containing the SR Segment List Id.  This is similar to Robert’s suggestion of using a VXLAN header.

Yours Irrespectively,

John

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>
Sent: Thursday, November 16, 2017 4:44 AM
To: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; robert@raszuk.net<mailto:robert@raszuk.net>; mpls@ietf.org<mailto:mpls@ietf.org>; zali@cisco.com<mailto:zali@cisco.com>
Subject: Re: [mpls] [spring] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

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<mailto:mach.chen@huawei.com>>; 'Jeff Tantsura' <jefftant.ietf@gmail.com<mailto:jefftant.ietf@gmail.com>>; 'Robert Raszuk' <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: 'draft-hegde-spring-traffic-accounting-for-sr-paths' <draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org<mailto:draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>>; 'spring' <spring@ietf.org<mailto:spring@ietf.org>>; 'Zafar Ali (zali)' <zali@cisco.com<mailto:zali@cisco.com>>; 'mpls' <mpls@ietf.org<mailto: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


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________