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

David Allan I <david.i.allan@ericsson.com> Fri, 17 November 2017 04:07 UTC

Return-Path: <david.i.allan@ericsson.com>
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 3A9351275F4; Thu, 16 Nov 2017 20:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 M_gcTae_Sgf0; Thu, 16 Nov 2017 20:07:48 -0800 (PST)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 5F04312420B; Thu, 16 Nov 2017 20:07:48 -0800 (PST)
X-AuditID: c6180641-81dff70000007a40-46-5a0e6093dabf
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id B6.24.31296.3906E0A5; Fri, 17 Nov 2017 05:07:47 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0352.000; Thu, 16 Nov 2017 23:07:46 -0500
From: David Allan I <david.i.allan@ericsson.com>
To: John E Drake <jdrake@juniper.net>, "Ext - Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
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>
Thread-Topic: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
Thread-Index: AQHTXr+FrywOr+bAjEyA1uBshIm8aqMW5mOAgAEDcOCAAF41AP//rHyQ
Date: Fri, 17 Nov 2017 04:07:46 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C68FD9074@eusaamb105.ericsson.se>
References: <12fc01d35e9c$ad540470$07fc0d50$@olddog.co.uk> <LEXPR01MB0094E212D3765DA6BA1AAEC49C2E0@LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE> <MWHPR05MB3551B49226876BE7FD0EA584C72E0@MWHPR05MB3551.namprd05.prod.outlook.com> <E6C17D2345AC7A45B7D054D407AA205C68FD8F26@eusaamb105.ericsson.se> <MWHPR05MB3551810B278B964DD7822526C72F0@MWHPR05MB3551.namprd05.prod.outlook.com>
In-Reply-To: <MWHPR05MB3551810B278B964DD7822526C72F0@MWHPR05MB3551.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C68FD9074eusaamb105erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyuXRPoO7kBL4og5e3FCx+9Nxgtth+fA27 xZy7zha3lq5ktWha2MRs8WEah8XxC78ZLV7v+MruwOEx5fdGVo8lS34yeVxvusrusWLzSkaP 3RsXMHm0vVQIYIvisklJzcksSy3St0vgyvjY9pOxYF8jU8X1Ld+ZGxjv/GLsYuTkkBAwkTh1 +T9bFyMXh5DAEUaJq0v3QTnLGSWeHV7GClLFJmAgsef/F0aQhIjARKCq69/BqpgFpjNJXF/4 jB2kSligSOLai71gc0UEiiWWLu9igrDdJG5ve88MYrMIqEocPnoVrJ5XwFfi8M9bLCC2kMA3 JoltW8VBbE6BWImGpZvA6hkFxCS+n1oDNodZQFzi1pP5TBB3C0gs2XOeGcIWlXj5+B8rhK0k MWnpOVaI+nyJKY19bBC7BCVOznzCMoFRZBaSUbOQlM1CUjaLkQMorimxfpc+RImixJTuh+wQ toZE65y57MjiCxjZVzFylBYX5OSmGxluYgTG6DEJNscdjHt7PQ8xCnAwKvHw3ovjixJiTSwr rsw9xCjBwawkwtswkTdKiDclsbIqtSg/vqg0J7X4EKM0B4uSOO85T6CUQHpiSWp2ampBahFM lomDU6qBUT1K4ujigmmvH8tLnLhk9PWD/h0Z+cMfo8taUmf/KFK0KVnZvy+7KuQim8X7Q/v5 7zWH3n/e/Ugw5XRp/WNbHkZ39QOLwqfwvL62Z17gmqS/zD0TVR3ObCu+4HLhzQYW2/Al3f8l GOXOmj/slpaIX/j8pPndNI6FFsfLtJXF7qab6ip/ntQkpsRSnJFoqMVcVJwIABDysePNAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/tgIaDFu4mjW4o2-hTy_5onrzFq4>
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: Fri, 17 Nov 2017 04:07:51 -0000

You’re right, my issue was the semantics of the GAL being that of a termination and not a shim…. Would be strange to change that such that the stack could continue after it.

Dave


From: John E Drake [mailto:jdrake@juniper.net]
Sent: Friday, November 17, 2017 12:02 PM
To: David Allan I <david.i.allan@ericsson.com>; Ext - Ruediger.Geib@telekom.de <Ruediger.Geib@telekom.de>; adrian@olddog.co.uk
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org; spring@ietf.org; zali@cisco.com; robert@raszuk.net; mpls@ietf.org
Subject: RE: [spring] [mpls] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Dave,

I think the EoS bit is set in the GAL.  I.e., there would be a small fixed size identifier between the stack and the payload.  As I indicated it’s just a suggestion.

Yours Irrespectively,

John

From: David Allan I [mailto:david.i.allan@ericsson.com]
Sent: Thursday, November 16, 2017 10:26 PM
To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; 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

Would not the concept of

<forwarding labels><GAL><id>(EOS set)<payload>

Get a bit strange?  We are simply swapping one reserved label for another…

Dave

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of John E Drake
Sent: Thursday, November 16, 2017 8: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