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

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 18 November 2017 14:08 UTC

Return-Path: <adrian@olddog.co.uk>
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 9A016126E01; Sat, 18 Nov 2017 06:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level:
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 5EPLXRpZSjV8; Sat, 18 Nov 2017 06:08:18 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C0E120726; Sat, 18 Nov 2017 06:08:16 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id vAIE8BQr021686; Sat, 18 Nov 2017 14:08:11 GMT
Received: from 950129200 (116.133.112.87.dyn.plus.net [87.112.133.116]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id vAIE8AYk021676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Nov 2017 14:08:11 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Zafar Ali (zali)'" <zali@cisco.com>
Cc: 'spring' <spring@ietf.org>, 'mpls' <mpls@ietf.org>
References: <CA+RyBmUHAkuA3o-LpHhMwCbkh0k+emt9OZ3B8Njj2h=jaasTZw@mail.gmail.com> <3B1EE673-044F-4E47-9C56-6FF360905C58@cisco.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE3047CEC9@NKGEML515-MBS.china.huawei.com> <CA+RyBmVC2OjEs-=1WsL13eBmycZtnYnM8ybSdmWhGPByLKNQfA@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE3047D106@NKGEML515-MBS.china.huawei.com> <EF064624-CF4D-4B88-823E-DAB9957B9336@cisco.com> <MWHPR05MB35512AD68B9CE96E8A5E7255C72E0@MWHPR05MB3551.namprd05.prod.outlook.com> <A9BFDECC-84A4-42E6-83CD-D09A2D48BA75@cisco.com>
In-Reply-To: <A9BFDECC-84A4-42E6-83CD-D09A2D48BA75@cisco.com>
Date: Sat, 18 Nov 2017 14:08:09 -0000
Message-ID: <189901d36076$aa76b4b0$ff641e10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKCLzcezLFzycQcb8h8DRqUvfGasQJkLxdxAb1HjzgCP7kbUAMFGCAPAe/FRzkB86F9RwGpWyeroUTuxIA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23472.007
X-TM-AS-Result: No--7.413-10.0-31-10
X-imss-scan-details: No--7.413-10.0-31-10
X-TMASE-MatchedRID: PL66URbwWA9xtRSiTWsxteYAh37ZsBDCC/ExpXrHizzQm9uphg9oy60u pf0BBILrHXR921VXCAzkFpC4bGxef9wrRLDk2cbi4bl1FkKDELfk1ikmy0JzSMu4R0wGfYgMyQg 5cQhcgqQ9/eO3YQitxLEDNZ8PJWi/nVzTgrSv7skER9Ta+6BEXbtq3FNsoMQgtmLuz8q7MDJh1u 55e0+dbhcJnrZPV0zkrJZlgXlznQKjvOPOp1fATYzb2GR6Ttd3BsHfMFGPbjO67Q3uPo9KI6vJN kBKhOMlUTYCdnH20WfkAOn8zTy8vJZXoz438mm1HcQQBuf4ZFu/yN2q8U674tnu97SXKBPYv3qC Xu3Bzx4SKrHO5P8Uig2L9bVdQhOrzHHspLFLQhd/TWpwlAOFXr4X/8yfdrbDVfOB6z8Qn2xBRkV 8tCUvg6rTmxXu7ddXplNMTNUYjvZthJ7IXRIqNsNrWpY804TGf7rvXBvEkWkwplGJ7NxS07nxJD WGehd2B8MPcT5elBXiBiWevqr/K79ZdlL8eonaC24oEZ6SpSlsZUSYh+N/ewPoc15oP/Ol2zJWo cbutoLiCvdfTQBsrJmq2RUokPvfjXIyUgEW6JQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/hduMRemKQT8Y4X7KVaBt2Hf6-RI>
Subject: Re: [mpls] [spring] 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: Sat, 18 Nov 2017 14:08:19 -0000

Thanks for helping me break my resolution to leave this thread alone :-(

>>> procedure (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR
>>> Architecture, highly unscalable and complicated to implement. 
>>
>> [JD]  Do you have any evidence to justify any of your assertions, above? 
>
> Please note that in draft-hegde-spring-traffic-accounting-for-sr-paths: 
>
> •    The transit node needs to be able to recognize the special label, read
>        the SR Path Identification label and update the counter against such
>        “states”. 

Possibly worth noting that existing devices are capable of maintaining many counters and updating them at line speed.

Several people have noted that ipfix is a process used for accounting in networks. That approach may have to find the bottom of stack and then match the packet that follows. 

Other approaches (e.g., to ECMP) involve finding the bottom of stack and hashing on the header of the payload.

Some hardware cannot perform either mechanism. This usually results from a trade between low cost, high performance, and features. Generally you can't have all three.
That hardware can't perform transit accounting with fine granularity (although you have promised us a solution within the next four months).

> •    The draft proposes to push (up to) 3 Labels for each segment in the SR
>        Path. That means that label stack is increased up to 3x times! This is a 
>        serious a scaling issue.  

John asked for evidence and you provided a misunderstanding or misreading of our draft. 
The document proposes adding 2 or 3 labels per SR Path (noting as John did, that this is our own term). 
That is not what you say, so perhaps you could retract or provide a pointer to the text.

Thus, "increased up to 3x times" applies only with the single case where the imposed label stack has exactly one label *and* the three label option is applied. So, while what you say is true, it is clearly (and wilfully?) exaggerating the severity of impact, and it is doubtful that  4-label stack is actually a problem.

> •    The controller needs to keep track of transit node capability and
>       push the additional per-path labels, accordingly. I.e., the controller
>       also needs to maintain such information for the transit nodes. 

In most cases, the controller/ingress only needs to care about the capabilities of the egress nodes. That is, if the special purpose label reaches the top of the stack it has to be able to handle it.

The only time when the transit node issue arises is when there is a small RLD. That information may need to be known by the controller to enable correct ECMP behavior, and it is distributed in the IGP. 
If there is a desire to enable accounting at transit nodes with a small RLD then the Path ID can be inserted higher up the stack and *that* means that the controller has to be sensitive as to where in the network the special purpose label will rise to the top of the stack.

It seems to me that:
- Controllers are not particularly resource constrained: adding a flag per node
   (or even per link!) would not break any scaling behavior.
- Adding another flag to the IGP alongside the RLD is not significant scaling issue.

Cheer,
Adrian