Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
Martin Horneffer <maho@nic.dtag.de> Fri, 17 November 2017 15:44 UTC
Return-Path: <maho@nic.dtag.de>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EF21270A7; Fri, 17 Nov 2017 07:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 1o0t9_YZydB8; Fri, 17 Nov 2017 07:44:43 -0800 (PST)
Received: from owl2.lab.dtag.de (Owl2.lab.DTAG.DE [194.25.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9991243FE; Fri, 17 Nov 2017 07:44:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id D77A2C7E8A; Fri, 17 Nov 2017 16:44:41 +0100 (CET)
Received: from owl2.lab.dtag.de ([127.0.0.1]) by localhost (owl2.lab.dtag.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeCe59QTwEHv; Fri, 17 Nov 2017 16:44:39 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by owl2.lab.dtag.de (Postfix) with ESMTP id 8E0FBC87C0; Fri, 17 Nov 2017 16:44:39 +0100 (CET)
Received: from TSUNAMI-Hippogryff-99.lab.DTAG.de (o-Hippogryff.lab.dtag.de [62.153.176.86]) by owl2.lab.dtag.de (Postfix) with ESMTPSA id 7FE8AC7E8A; Fri, 17 Nov 2017 16:44:39 +0100 (CET)
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: mpls <mpls@ietf.org>, spring <spring@ietf.org>, draft-hegde-spring-traffic-accounting-for-sr-paths <draft-hegde-spring-traffic-accounting-for-sr-paths@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> <AM4PR03MB171328C37B726DE4AFF862D39D2E0@AM4PR03MB1713.eurprd03.prod.outlook.com> <CA+b+ERkYZpdGS90VBH202yXbDeaEcyHk3UWNW+NUKS-WrkHAOg@mail.gmail.com> <25654_1510829327_5A0D6D0F_25654_230_1_9E32478DFA9976438E7A22F69B08FF921EABF115@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2922B1DEF@dggeml510-mbs.china.huawei.com> <d36c2887-3722-b9ab-76fa-aecca77f0018@gmail.com>
From: Martin Horneffer <maho@nic.dtag.de>
Message-ID: <da8ace29-5c6b-8aaa-5feb-3f0ccf65ad95@nic.dtag.de>
Date: Fri, 17 Nov 2017 16:44:38 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <d36c2887-3722-b9ab-76fa-aecca77f0018@gmail.com>
Content-Type: multipart/alternative; boundary="------------5C3D25E66A1D0A9CAFCB2F17"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/HO8AuEGwr3FPu5GFlT6tvJlZVsw>
Subject: Re: [spring] [mpls] Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Nov 2017 15:44:47 -0000
Hi Stewart, a quick comment on this, from an operator's point of view: Yes, we do need the same measurements for LDP as well as for SR. The exact kind of counter may be debatable. From what we have now, per-FEC counters (per-SID for SR) on every node seem like the best practical and existing solution. Best regards, Martin Am 17.11.17 um 03:45 schrieb Stewart Bryant: > > I would like to ask a fundamental question here. > > Do we need transit counters for only MPLS-SR, or do we need it for > MPLS-LDP as well? > > If we need it for both, then we need to have this discussion in a > general MPLS context and not in an MPLS-SR specific context. > > At least some of the methods described here would work for both. > > Also WRT the proposal to do ingress collection, if nodal paths are > used, that only tells us the approximate path, not the hotspot which I > understand to be the original goal. > > - Stewart > > On 16/11/2017 14:46, Mach Chen wrote: >> >> Hi Stephane, >> >> If you want to do transit measurement, you have to pay some cost. The >> difference is how large the cost is, one, two or multiple labels. >> >> For E2E measurement, it could be much easier. A single label (could >> be local or global) is inserted immediately follow the last label of >> the SR path. Since there is only one label, the path label could be >> put into the stack at the beginning, no matter whether the >> measurement is enable or not. With this, it will not affect the entropy. >> >> Best regards, >> >> Mach >> >> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of >> *stephane.litkowski@orange.com >> *Sent:* Thursday, November 16, 2017 6:49 PM >> *To:* Robert Raszuk; Alexander Vainshtein >> *Cc:* mpls; spring; Clarence Filsfils; >> draft-hegde-spring-traffic-accounting-for-sr-paths; Michael >> Gorokhovsky; draft-ietf-spring-oam-usecase@ietf.org; Zafar Ali (zali) >> *Subject:* Re: [mpls] [spring] Special purpose labels in >> draft-hegde-spring-traffic-accounting-for-sr-paths >> >> Hi, >> >> Yes today we do not have any CLI command on any router to get paths >> statistics for LDP (I mean Ingress to Egress) as LDP is based on MP2P >> LSPs, so a transit node does not have the knowledge of the source. >> From an operational point of view, what we do today is that we >> collect netflow statistics on core routers, we project the label >> stack onto the routing with an external tool to get the Ingress to >> Egress LDP traffic including the mapping of the flows on the links. >> >> Now for RSVP, we do have such statistics as the LSP is P2P and has >> states on every node. >> >> Robert mentioned correctly that SR-TE (especially with MPLS >> dataplane) has limited TE features (we cannot mimic all what RSVP >> does in SRTE without adding too much complexity). >> >> Thus, is it a problem (transit node stats) worth to be solved ? If >> yes, where do we accept to put the complexity ? For a stats issue I >> would rather prefer to move the complexity to an external tool that >> can do correlations or whatever operations rather than getting it in >> the forwarding plane… >> >> IMO, that’s a “nice to have” problem to solve getting that we do not >> have this for LDP and we know the limitations of SR-TE MPLS. >> >> However, Ingress stats per SRTE LSP are for sure mandatory to get ! >> >> The main drawback I see with the proposed solution is that it mimics >> what Entropy label does with a solution which is similar and at the >> same time cannot replace entropy label as the provided entropy is far >> from being sufficient (this is not the goal I know, but I was looking >> for potential use case optimizations). So in a network running >> entropy label and this mechanism, a router will need to find the >> ELI/EL and hash, then find another special label to build the stats >> (maybe tomorrow there will be a third one to look at and a fourth >> one…). That starts to be a big overhead for the forwarding plane. >> >> Brgds, >> >> Stephane >> >> *From:*mpls [mailto:mpls-bounces@ietf.org] *On Behalf Of *Robert Raszuk >> *Sent:* Thursday, November 16, 2017 16:23 >> *To:* Alexander Vainshtein >> *Cc:* spring; Clarence Filsfils; mpls; Michael Gorokhovsky; >> draft-ietf-spring-oam-usecase@ietf.org >> <mailto:draft-ietf-spring-oam-usecase@ietf.org>; >> draft-hegde-spring-traffic-accounting-for-sr-paths; Zafar Ali (zali) >> *Subject:* Re: [mpls] [spring] Special purpose labels in >> draft-hegde-spring-traffic-accounting-for-sr-paths >> >> Folks, >> >> This thread started and the requirements reported clearly stated that >> all what we need is the ability to account per path traffic on egress >> nodes. >> >> Now out of the sudden I see requirement popping up to be able to >> measure per path in transit nodes. >> >> Well you can do it today with SRv6 if your hardware allows or you can >> do it with RSVP-TE. >> >> SR-MPLS is replacing LDP and adds ability for limited TE. But SR-MPLS >> never intended to become connection oriented protocol nor architecture. >> >> So I recommend we take a step back here. Or if you like first go and >> fix basic MPLS LDP LSPs to allow per end to end path accounting in >> transit nodes then come back here to ask for the same in SR-MPLS. Not >> the other way around. >> >> Thx >> >> r. >> >> On Nov 16, 2017 16:12, "Alexander Vainshtein" >> <Alexander.Vainshtein@ecitele.com >> <mailto:Alexander.Vainshtein@ecitele.com>> wrote: >> >> Greg, >> >> I concur with your position: let’s first of all agree that ability >> to measure traffic carried by an SR-TE LSP in a specific transit node >> is a require OAM function for SR. >> >> I have looked up the SR OAM Use Cases >> <https://datatracker.ietf.org/doc/draft-ietf-spring-oam-usecase/?include_text=1> >> draft, and I did not find any relevant use cases there. >> >> The only time measurements are mentioned is a reference to an expired >> implementation report >> <https://tools.ietf.org/html/draft-leipnitz-spring-pms-implementation-report-00> >> draft discussing delay measurements. Since delay measurements are in >> any case based on synthetic traffic, and are always end-to-end >> (one-way or two-way), this reference is not relevant, IMHO, for this >> discussion. >> >> I have added the authors of the SR OAM Use Cases draft to tis thread. >> >> Regards, >> >> Sasha >> >> Office: +972-39266302 <tel:+972%203-926-6302> >> >> Cell: +972-549266302 <tel:+972%2054-926-6302> >> >> Email: Alexander.Vainshtein@ecitele.com >> <mailto:Alexander.Vainshtein@ecitele.com> >> >> *From:*mpls [mailto:mpls-bounces@ietf.org >> <mailto:mpls-bounces@ietf.org>] *On Behalf Of *Greg Mirsky >> *Sent:* Thursday, November 16, 2017 4:28 AM >> *To:* Xuxiaohu <xuxiaohu@huawei.com <mailto:xuxiaohu@huawei.com>> >> *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>> >> *Subject:* Re: [mpls] [spring] Special purpose labels in >> draft-hegde-spring-traffic-accounting-for-sr-paths >> >> 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 >> <mailto: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 <tel:+86-13910161692> >> E:xuxiaohu@huawei.com <mailto:xuxiaohu@huawei.com> >> 产品与解决方案-网络战略与业务发展部 >> Products & Solutions-Network Strategy & Business Development Dept >> >> *发件人:***Zafar Ali (zali) >> >> *收件人:***Greg Mirsky<gregimirsky@gmail.com >> <mailto:gregimirsky@gmail.com>>;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>>;mpls<mpls@ietf.org >> <mailto:mpls@ietf.org>>;spring<spring@ietf.org >> <mailto: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 >> <mailto:spring-bounces@ietf.org>> on behalf of Greg Mirsky >> <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> >> *Date: *Wednesday, November 15, 2017 at 11:10 AM >> *To: >> *"draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org >> <mailto:draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>" >> <draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org >> <mailto:draft-hegde-spring-traffic-accounting-for-sr-paths@ietf.org>>, >> "mpls@ietf.org <mailto:mpls@ietf.org>" <mpls@ietf.org >> <mailto:mpls@ietf.org>>, "spring@ietf.org >> <mailto:spring@ietf.org>" <spring@ietf.org <mailto: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 >> >> >> ___________________________________________________________________________ >> >> 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. >> ___________________________________________________________________________ >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org <mailto:mpls@ietf.org> >> https://www.ietf.org/mailman/listinfo/mpls >> >> _________________________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous >> avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, >> deforme ou falsifie. Merci. >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender >> and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls
- [spring] Special purpose labels in draft-hegde-sp… Greg Mirsky
- Re: [spring] Special purpose labels in draft-hegd… Zafar Ali (zali)
- Re: [spring] [mpls] Special purpose labels in dra… Stewart Bryant
- Re: [spring] [mpls] Special purpose labels in dra… Xuxiaohu
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] [mpls] Special purpose labels in dra… ShaoWen Ma
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Jeff Tantsura
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Xuxiaohu
- Re: [spring] [mpls] Special purpose labels in dra… Jeff Tantsura
- Re: [spring] [mpls] Special purpose labels in dra… Shraddha Hegde
- Re: [spring] [mpls] Special purpose labels in dra… David Allan I
- Re: [spring] [mpls] Special purpose labels in dra… Mach Chen
- Re: [spring] [mpls] Special purpose labels in dra… Xuxiaohu
- Re: [spring] Special purpose labels in draft-hegd… Mach Chen
- Re: [spring] Special purpose labels in draft-hegd… Shah, Himanshu
- Re: [spring] Special purpose labels in draft-hegd… Xuxiaohu
- Re: [spring] Special purpose labels in draft-hegd… Mach Chen
- Re: [spring] Special purpose labels in draft-hegd… Mach Chen
- Re: [spring] [mpls] Special purpose labels in dra… Chengli (IP Technology Research)
- Re: [spring] [mpls] Special purpose labels in dra… Jeff Tantsura
- Re: [spring] [mpls] Special purpose labels in dra… Xuxiaohu
- Re: [spring] [mpls] Special purpose labels in dra… Xuxiaohu
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Alexander Vainshtein
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Zafar Ali (zali)
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] [mpls] Special purpose labels in dra… Alexander Vainshtein
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] [mpls] Special purpose labels in dra… Ruediger.Geib
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Alexander Vainshtein
- [spring] Whether both E2E and SPME performance me… Mach Chen
- Re: [spring] [mpls] Special purpose labels in dra… Alexander Vainshtein
- Re: [spring] Whether both E2E and SPME performanc… David Allan I
- Re: [spring] Whether both E2E and SPME performanc… Mach Chen
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] Whether both E2E and SPME performanc… Ruediger.Geib
- Re: [spring] [mpls] Special purpose labels in dra… stephane.litkowski
- Re: [spring] [mpls] Whether both E2E and SPME per… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Alexander Vainshtein
- Re: [spring] [mpls] Whether both E2E and SPME per… John E Drake
- Re: [spring] [mpls] Special purpose labels in dra… John E Drake
- Re: [spring] [mpls] Special purpose labels in dra… John E Drake
- Re: [spring] [mpls] Whether both E2E and SPME per… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Alexander Vainshtein
- Re: [spring] [mpls] Whether both E2E and SPME per… Alexander Vainshtein
- Re: [spring] [mpls] Special purpose labels in dra… John E Drake
- Re: [spring] Special purpose labels in draft-hegd… John E Drake
- Re: [spring] [mpls] Whether both E2E and SPME per… John E Drake
- Re: [spring] [mpls] Whether both E2E and SPME per… John E Drake
- Re: [spring] [mpls] Special purpose labels in dra… John E Drake
- Re: [spring] Special purpose labels in draft-hegd… John E Drake
- Re: [spring] [mpls] Whether both E2E and SPME per… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Mach Chen
- Re: [spring] [mpls] Whether both E2E and SPME per… John E Drake
- Re: [spring] [mpls] Whether both E2E and SPME per… John E Drake
- Re: [spring] [mpls] Whether both E2E and SPME per… Robert Raszuk
- Re: [spring] [mpls] Whether both E2E and SPME per… Alexander Vainshtein
- Re: [spring] [mpls] Whether both E2E and SPME per… Robert Raszuk
- Re: [spring] Whether both E2E and SPME performanc… John E Drake
- Re: [spring] [mpls] Special purpose labels in dra… Mach Chen
- Re: [spring] [mpls] Whether both E2E and SPME per… Greg Mirsky
- Re: [spring] [mpls] Whether both E2E and SPME per… Mach Chen
- Re: [spring] [mpls] Whether both E2E and SPME per… Greg Mirsky
- [spring] Fwd: Re: [mpls] Special purpose labels i… Stewart Bryant
- Re: [spring] [mpls] Special purpose labels in dra… Jeff Tantsura
- Re: [spring] [mpls] Fwd: Re: Special purpose labe… Robert Raszuk
- Re: [spring] [mpls] Fwd: Re: Special purpose labe… Stewart Bryant
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Stewart Bryant
- Re: [spring] [mpls] Special purpose labels in dra… Mach Chen
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… John E Drake
- Re: [spring] [mpls] Fwd: Re: Special purpose labe… Uma Chunduri
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- [spring] measurement requirements (was Re: [mpls]… Martin Horneffer
- Re: [spring] [mpls] Special purpose labels in dra… Martin Horneffer
- Re: [spring] [mpls] Special purpose labels in dra… Zafar Ali (zali)
- Re: [spring] measurement requirements (was Re: [m… Zafar Ali (zali)
- Re: [spring] [mpls] Special purpose labels in dra… Adrian Farrel
- Re: [spring] [mpls] Special purpose labels in dra… John E Drake
- Re: [spring] [mpls] Special purpose labels in dra… Stewart Bryant
- Re: [spring] [mpls] Special purpose labels in dra… Stewart Bryant
- Re: [spring] [mpls] Special purpose labels in dra… Zafar Ali (zali)
- Re: [spring] [mpls] Special purpose labels in dra… Zafar Ali (zali)
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] [mpls] Special purpose labels in dra… Zafar Ali (zali)
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] [mpls] Special purpose labels in dra… Zafar Ali (zali)
- Re: [spring] [mpls] Special purpose labels in dra… Adrian Farrel
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Zafar Ali (zali)
- Re: [spring] [mpls] Special purpose labels in dra… Stewart Bryant
- Re: [spring] [mpls] Special purpose labels in dra… Martin Horneffer
- Re: [spring] [mpls] Special purpose labels in dra… Jeff Tantsura
- Re: [spring] [mpls] Special purpose labels in dra… Robert Raszuk
- Re: [spring] [mpls] Special purpose labels in dra… Carlos Pignataro (cpignata)
- Re: [spring] [mpls] Special purpose labels in dra… Carlos Pignataro (cpignata)
- Re: [spring] [mpls] Special purpose labels in dra… Carlos Pignataro (cpignata)
- Re: [spring] [mpls] Special purpose labels in dra… Greg Mirsky
- Re: [spring] [mpls] Special purpose labels in dra… Carlos Pignataro (cpignata)