IETF Logo Mail Archive

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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 16 November 2017 15:26 UTC

Return-Path: <jie.dong@huawei.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 AE77B12944C; Thu, 16 Nov 2017 07:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 IX_mCigUYGDi; Thu, 16 Nov 2017 07:26:27 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6FD12711D; Thu, 16 Nov 2017 07:26:27 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 72244B6601ABD; Thu, 16 Nov 2017 15:26:24 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 16 Nov 2017 15:26:25 +0000
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.148]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 23:26:19 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Robert Raszuk <robert@raszuk.net>, Adrian Farrel <adrian@olddog.co.uk>
CC: draft-hegde-spring-traffic-accounting-for-sr-paths <draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>, spring <spring@ietf.org>, mpls <mpls@ietf.org>, "Zafar Ali (zali)" <zali@cisco.com>
Thread-Topic: [mpls] [spring] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
Thread-Index: AQHTXqmh1BL4RvEEP0attq9Cf0P/haMXFqFw
Date: Thu, 16 Nov 2017 15:26:19 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C92798132403@NKGEML515-MBS.china.huawei.com>
References: <12fc01d35e9c$ad540470$07fc0d50$@olddog.co.uk> <CA+b+ER=k6XJ-gWL1qLO80S=g7ir=q8YJC8jhgsTb_P7tgYcP0A@mail.gmail.com>
In-Reply-To: <CA+b+ER=k6XJ-gWL1qLO80S=g7ir=q8YJC8jhgsTb_P7tgYcP0A@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.37.243]
Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92798132403NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/sYaMh7CHWlSBPFgpFo5KiSwAAYI>
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 15:26:30 -0000

Hi Robert,

When you say “no marker of any sort is needed”,  I think actually you mean to use the markers in another layer, e.g. the IP layer.

In a layered network, IMO each layer (Ethernet, MPLS, IP, etc.) needs its own OAM mechanisms. For example, we cannot use Ethernet OAM to replace IP OAM☺

Best regards,
Jie

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, November 16, 2017 3:08 PM
To: Adrian Farrel
Cc: draft-hegde-spring-traffic-accounting-for-sr-paths; spring; mpls; Zafar Ali (zali)
Subject: Re: [mpls] [spring] redux: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths

Adrian

I do not agree with with #2 .. no marker of any sort is needed.

And debugging LDP networks is no different then debugging IP networks so sure some who are used to ATM/Frame Relay find it very hard to troubleshoot.

Best
r.


On Nov 16, 2017 13:35, "Adrian Farrel" <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:
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