Re: [spring] [mpls] Fwd: Re: Special purpose labels in draft-hegde-spring-traffic-accounting-for-sr-paths
Stewart Bryant <stewart.bryant@gmail.com> Fri, 17 November 2017 03:25 UTC
Return-Path: <stewart.bryant@gmail.com>
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 91637127843; Thu, 16 Nov 2017 19:25:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pdDdqousDlNV; Thu, 16 Nov 2017 19:25:31 -0800 (PST)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 E37451275F4; Thu, 16 Nov 2017 19:25:30 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id c123so916655pga.11; Thu, 16 Nov 2017 19:25:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=bo1U2pglMior8Sm4/AF7i3QVOK0WibVrVPSMkshk1WI=; b=I1y0tO6KmhDyZydLDu1OW+jwe5QymULaFxmrGUaTM9KdMRcKawIOULCC3m66y61AYo NJjRVx+so4hIubHpx64YvTCvmSWSV2ya3+CzHiPj4LO8DBukk+JZqBvQN3G9vi3mn9Se JI/QIugmQfhLW3hwI6ZjLHmZAM31XOkkNAl0t3ffGfhz0sXcocr9GqnlM3X+weXpYuzO +Yt5e74IslOyJ2TElNYLYdt1uFjum4024EZTqC/C9w/0FbavbVrILXcIWksRPFdzjUI1 Eh3P9rgmvAPc2Ui+0WRjJgt6s3QxpZ4MthHN1ORToQE4EAoW6FM/v9cJcpBxbqx1XhCb SiYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=bo1U2pglMior8Sm4/AF7i3QVOK0WibVrVPSMkshk1WI=; b=lTCJanxUZvujKaqPITy1jAKDEjy8BwQS2CzqMPpQ7cVJjKcDP/vil7LdtEz3vy6mlN 1fxFfrY03q8AtOYSIYD9BE613RGkdXvo7WUdWnMZLXv4F48pZp3CoCXT+sD1qNeNViAi Od4uQZPrMIJnjv8Fy8tBqSD98vah7y10nqB3OWYuvkFGhWrfcA3NQdWwQ08954JZ/m5J /93t9wF0TAqp7gUzeFCiym+UnrCUn3NaIrb0XO0zfjAglGWfOzJjyts2031pqq8vsrT4 MUqIbbOMEcgp4B3UfEPqEIuEoJDRf6NV+bQEExocRKv54YpHuu8emAA6XPsEkzKPV/Tk 1n/w==
X-Gm-Message-State: AJaThX4HrZRk79T+D7OMNGi6NwcILisoXRJ5ROtZq9LEMkIXeuqNLxn3 Y3qQ5hJ2CVgNtCzVoPCqM+I2VCjg
X-Google-Smtp-Source: AGs4zMYVqh7W9snsT12HEVzKkqZVmsiKxO1q2la8Ib6crQIFMssuYY8R9qzvEGJbHGQKuoO9dcHdyA==
X-Received: by 10.84.235.10 with SMTP id o10mr2103153plk.155.1510889130109; Thu, 16 Nov 2017 19:25:30 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:b5a2:236f:3070:7ddd? ([2001:67c:370:128:b5a2:236f:3070:7ddd]) by smtp.gmail.com with ESMTPSA id b11sm4005099pgs.38.2017.11.16.19.25.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 19:25:29 -0800 (PST)
To: Robert Raszuk <robert@raszuk.net>
Cc: mpls@ietf.org, spring@ietf.org
References: <d36c2887-3722-b9ab-76fa-aecca77f0018@gmail.com> <f5a8dedc-a390-cca7-bfa4-e1b39c1c9557@gmail.com> <CA+b+ERm5xp56juAw+qw2jKgw5h8=ybphoAt=1ASm15rgHRYVMg@mail.gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <6104b164-67b5-75c9-238f-c9f351ed6088@gmail.com>
Date: Fri, 17 Nov 2017 03:25:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CA+b+ERm5xp56juAw+qw2jKgw5h8=ybphoAt=1ASm15rgHRYVMg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------E51591B1EFE3F13C9EEE8B25"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/XAaAamsyuiKnILvVzE_q500xwZk>
Subject: Re: [spring] [mpls] Fwd: Re: 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 03:25:36 -0000
On 17/11/2017 03:00, Robert Raszuk wrote: > Stewart, > > Is there any real vendor support and real production deployment of > rfc5586 ? Yes. It is used in PWs and MPLS-TP. But it is only looked at by the egress PE. > > Is there any data on the max label depth such channel may be hidden > under yet still visible to forwarding hardware ? Not that I know, but it was designed to be used only by the receiving PE where the number of labels would normally be 3 or less (normally no more than LSP, PW, GAL). If you are really asking about how far into the packet can we put a path marker that is visible to a p-router, then asking how into the packet can IPFIX work might be an alternative way to gather the information you need. - Stewart On 17/11/2017 03:00, Robert Raszuk wrote: > Stewart, > > Is there any real vendor support and real production deployment of > rfc5586 ? > > Is there any data on the max label depth such channel may be hidden > under yet still visible to forwarding hardware ? > > Thx > R. > > On Nov 17, 2017 03:49, "Stewart Bryant" <stewart.bryant@gmail.com > <mailto:stewart.bryant@gmail.com>> wrote: > > Resenting with fewer names recipients > > S > -------- Forwarded Message -------- > Subject: Re: [mpls] [spring] Special purpose labels in > draft-hegde-spring-traffic-accounting-for-sr-paths > Date: Fri, 17 Nov 2017 02:45:18 +0000 > From: Stewart Bryant <stewart.bryant@gmail.com> > <mailto:stewart.bryant@gmail.com> > To: Mach Chen <mach.chen@huawei.com> > <mailto:mach.chen@huawei.com>, stephane.litkowski@orange.com > <mailto:stephane.litkowski@orange.com> > <stephane.litkowski@orange.com> > <mailto:stephane.litkowski@orange.com>, Robert Raszuk > <robert@raszuk.net> <mailto:robert@raszuk.net>, Alexander > Vainshtein <Alexander.Vainshtein@ecitele.com> > <mailto:Alexander.Vainshtein@ecitele.com> > CC: mpls <mpls@ietf.org> <mailto:mpls@ietf.org>, spring > <spring@ietf.org> <mailto:spring@ietf.org>, Clarence Filsfils > <cfilsfil@cisco.com> <mailto:cfilsfil@cisco.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>, > Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com> > <mailto:Michael.Gorokhovsky@ecitele.com>, > draft-ietf-spring-oam-usecase@ietf.org > <mailto:draft-ietf-spring-oam-usecase@ietf.org> > <draft-ietf-spring-oam-usecase@ietf.org> > <mailto:draft-ietf-spring-oam-usecase@ietf.org>, Zafar Ali (zali) > <zali@cisco.com> <mailto:zali@cisco.com> > > > > > 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 <mailto: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 >> <mailto: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 >> <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 >> <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 <mailto:mpls@ietf.org> >> https://www.ietf.org/mailman/listinfo/mpls >> <https://www.ietf.org/mailman/listinfo/mpls> > > > _______________________________________________ > mpls mailing list > mpls@ietf.org <mailto:mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls > <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)