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

Greg Mirsky <gregimirsky@gmail.com> Thu, 16 November 2017 08:33 UTC

Return-Path: <gregimirsky@gmail.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 3FA28124217; Thu, 16 Nov 2017 00:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 bGmBB027MQZ0; Thu, 16 Nov 2017 00:33:14 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 5F6E0127369; Thu, 16 Nov 2017 00:33:13 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id r135so29191212lfe.5; Thu, 16 Nov 2017 00:33:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JaHYyU3JuEveM15kZBzhxX9RYXj3n+tQBa+Sx+Rl698=; b=kDJ/ZO4FsYaoUkyez6/lkSXGJ0AUegQlvzGethT9vleecL4sk08Ad6y0/g5UqwFBi6 heDj+zFVHWOMyx+HC01yZjZO9uw2EJh63ysB5WeBYwJrHUtW1WsTHoG2bblFqG/yGCHf xzdFd6jUnR5FdtAfdb8XzlPfuufzmS9TIZdGqZnVWUK7r4eFSbdLxlAvshXVAEMmI1Em /oahvS2vOYFKq2nLldFOylZb/excvbeZeATb3g+jn3SpjNg8KdOEvywkHm/2DypW2FBR UHdVqxE961xEzqHLjpM0uXkMUh9YGK/mLhSpBL5e9GYLcKNmpa3nSYQK2mZYRX3zjnFs ddnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JaHYyU3JuEveM15kZBzhxX9RYXj3n+tQBa+Sx+Rl698=; b=iXIJqPdx6sLtmXAE4viezZHxT9aaa0EP5FWiEhLB32vojn/qmIK2YAL0xmWY2hOeGc SWqQx72IiKtL3+kOTPyth4GwoBz8UOTx18YHuL9wxcbrLQ429nYhokGuazB9/e6zmBoZ qfxniwI5hveU1KoZvw5vTf/pRQBlA2Jtgv5Jx4iu1eRhSERqwcoIQjeKh+quDO1xcxP+ kKFFfJrlsKeBz6R2F9AfzyU44bn2oRrNJMswKLt114Peq/CPWsIPSlGEVYL4C05+/Hvs kQNe/k1BHSISs7d99p9APN7WrfENhJVsQdwlx/JQOPkbiesaShgb1RBKzKvidq8ujagz hsAQ==
X-Gm-Message-State: AJaThX7KIOEYzmY7eWtnFJO5Dm0vXKST1yk1b8OGIdr830+dam5WpPhB CLyMpIfc0OljinxLBu53WJvMPT7KDkK+Z5SKhQg=
X-Google-Smtp-Source: AGs4zMbbPjLrLwAXoe6FVrj+lDIYn6g2I6A6bCmERHQoaan58FUNbNH1G+FE+NAiJULn0i6loPsatnTfWL4D1CngtnQ=
X-Received: by 10.46.83.29 with SMTP id h29mr414401ljb.144.1510821191521; Thu, 16 Nov 2017 00:33:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.32.136 with HTTP; Thu, 16 Nov 2017 00:33:10 -0800 (PST)
Received: by 10.46.32.136 with HTTP; Thu, 16 Nov 2017 00:33:10 -0800 (PST)
In-Reply-To: <EF064624-CF4D-4B88-823E-DAB9957B9336@cisco.com>
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>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 16 Nov 2017 16:33:10 +0800
Message-ID: <CA+RyBmWn17jZn5tasoaqHaY2kKLSQBG_9O3nrL7ww7KoapUOVw@mail.gmail.com>
To: "Zafar Ali (zali)" <zali@cisco.com>
Cc: Xiaohu Xu <xuxiaohu@huawei.com>, draft-hegde-spring-traffic-accounting-for-sr-paths <draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>, mpls <mpls@ietf.org>, spring <spring@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1ce7fa709b10055e157872"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/FViAF5up2cIff3YdXcMvpETIYBs>
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: Thu, 16 Nov 2017 08:33:17 -0000

Hi Zafar, et.al,
as I'm the one who have started the thread I'd like to clarify and
reiterate my point Performance measurements are required not only e2e but
on a span, i.e. SPME, using MPLS-TO lingo. If we agree on that, then we are
ready to discuss how to support these measurements in SR-MPLS.

Regards, Greg

On Nov 16, 2017 4:25 PM, "Zafar Ali (zali)" <zali@cisco.com> wrote:

> Hi Folks,
>
>
>
> I also agree that it’s not a question on requirement but about a procedure
> (in draft-hegde-spring-traffic-accounting-for-sr-paths) that breaks SR
> Architecture, highly unscalable and complicated to implement. We can solve
> this problem without breaking the SR architecture. We plan to write a draft
> before the next IETF.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *Xuxiaohu <xuxiaohu@huawei.com>
> *Date: *Wednesday, November 15, 2017 at 9:54 PM
> *To: *Greg Mirsky <gregimirsky@gmail.com>
> *Cc: *"Zafar Ali (zali)" <zali@cisco.com>, draft-hegde-spring-traffic-accounting-for-sr-paths
> <draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>, "
> mpls@ietf.org" <mpls@ietf.org>, spring <spring@ietf.org>
> *Subject: *RE: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
>
>
> I fully agree with you that OAM tools are important.
>
> I just felt that the approach as proposed in the draft would enconter the
> same terrible issues as those associated with the MPLS-SR entropy label
> usage due to RLD and MSD hardware limitations.
>
> Best regards,
> Xiaohu
>
>
>
> ------------------------------
>
> 徐小虎 Xuxiaohu
> M:+86-13910161692
> E:xuxiaohu@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人:* Greg Mirsky
>
> *收件人:* Xuxiaohu<xuxiaohu@huawei.com>
>
> *抄送:* Zafar Ali (zali)<zali@cisco.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths<draft-hegde-spring-traffic-
> accounting-for-sr-paths@ietf.org>;mpls<mpls@ietf.org>;spring<
> spring@ietf.org>
>
> *主**题**:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
> *时间:* 2017-11-16 10:27:55
>
>
>
> Dear All,
>
> I cannot imagine that operators will agree to deploy network that lacks
> critical OAM tools to monitor performance and troubleshoot the network.
> True, some will brave the challenge and be the early adopters but even they
> will likely request that the OAM toolbox be sufficient to support their
> operational needs. I see that this work clearly describes the problem and
> why ability to quantify the flow behavior at internal nodes is important
> for efficient network operation. First let's discuss whether the case and
> requirement towards OAM is real and valid. Then we can continue to
> discussion of what measurement method to use.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Nov 16, 2017 at 10:05 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
>
> Concur. Although it has some values, it's not cost-efficient from my point
> of view. Network simplicity should be the first priority object. Hence we
> would have to make some compromise.
>
> Best regards,
> Xiaohu
>
>
>
> ------------------------------
>
> 徐小虎 Xuxiaohu
> M:+86-13910161692
> E:xuxiaohu@huawei.com
> 产品与解决方案-网络战略与业务发展部
> Products & Solutions-Network Strategy & Business Development Dept
>
> *发件人:* Zafar Ali (zali)
>
> *收件人:* Greg Mirsky<gregimirsky@gmail.com>;draft-hegde-spring-traffic-
> accounting-for-sr-paths<draft-hegde-spring-traffic-
> accounting-for-sr-paths@ietf.org>;mpls<mpls@ietf.org>;spring<
> spring@ietf.org>
>
> *主**题**:* Re: [mpls] [spring] Special purpose labels in
> draft-hegde-spring-traffic-accounting-for-sr-paths
>
> *时间:* 2017-11-16 02:24:10
>
>
>
> Hi,
>
>
>
> This draft breaks the SR architecture. I am quoting a snippet from
> abstract of SR Architecture document https://tools.ietf.org/html/
> draft-ietf-spring-segment-routing-13, which states:
>
> “SR allows to enforce a flow through any topological path while
> maintaining per-flow state only at the ingress nodes to the SR domain.”
>
>
>
> In addition to creating states at transit and egress nodes, the procedure
> also affects the data plane and makes it unscalable. It also makes
> controller job much harder and error prune. In summary, I find the
> procedure very complex and unscalable.
>
>
>
> Thanks
>
>
>
> Regards … Zafar
>
>
>
>
>
> *From: *spring <spring-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Wednesday, November 15, 2017 at 11:10 AM
> *To: *"draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org" <
> draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>, "
> mpls@ietf.org" <mpls@ietf.org>, "spring@ietf.org" <spring@ietf.org>
> *Subject: *[spring] Special purpose labels in draft-hegde-spring-traffic-
> accounting-for-sr-paths
>
>
>
> Hi Shraddha,
>
> thank you for very well written and thought through draft. I have these
> questions I'd like to discuss:
>
>    - Have you thought of using not one special purpose label for both SR
>    Path Identifier and SR Path Identifier+Source SID cases but request two
>    special purpose labels, one for each case. Then the SR Path Identifier
>    would not have to lose the bit for C flag.
>    - And how you envision to collect the counters along the path? Of
>    course, a Controller may query LSR for all counters or counters for the
>    particular flow (SR Path Identifier+Source SID). But in addition I'd
>    propose to use in-band mechanism, perhaps another special purpose label, to
>    trigger the LSR to send counters of the same flow with the timestamp
>    out-band to the predefined Collector.
>    - And the last, have you considered ability to flush counters per
>    flow. In Scalability Considerations you've stated that counters are
>    maintained as long as collection of statistics is enabled. If that is on
>    the node scope, you may have to turn off/on the collection to flush off
>    some old counters. I think that finer granularity, per flow granularity
>    would be useful for operators. Again, perhaps the flow itself may be used
>    to signal the end of the measurement and trigger release of counters.
>
> Regards,
>
> Greg
>
>
>