Re: [mpls] Discussion on how to transport MPLS over UDP tunnels
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Thu, 20 December 2012 18:29 UTC
Return-Path: <cpignata@cisco.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 A65AC21F8906 for <mpls@ietfa.amsl.com>; Thu, 20 Dec 2012 10:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.823
X-Spam-Level:
X-Spam-Status: No, score=-106.823 tagged_above=-999 required=5 tests=[AWL=-3.667, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MANGLED_BELOW=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01d3L0RHkTXX for <mpls@ietfa.amsl.com>; Thu, 20 Dec 2012 10:29:40 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 09EFD21F88E1 for <mpls@ietf.org>; Thu, 20 Dec 2012 10:29:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59356; q=dns/txt; s=iport; t=1356028180; x=1357237780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UnB/EyDKKJir69oo45qNDhAPDBhkjVPIw+0D2AsvGno=; b=mlZ1mXnmAZLIUXe4iKUsFstaZ3fCr3FXat16BJ8QEQVDzC6biVZb0WYP veqzeXxRamYA2/IDGOYuZZierXPs6n0lkpk9lwDIFLXiaHdPXs1aDfOYn SqlQ6iSv1uqVN02xDhN95a0UpZQ8sZyvNS3eLBN8DWu7ZUyAbSOr3wa0/ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQGANNX01CtJV2b/2dsb2JhbABFhjqCX6tIAYZTgU9uFnOCHwEBBAEBARcBDEAHBAIFDgICAQYCEhAWAQYFAgIZDAsUAw4CBAENBQgBEod4DItPmm8IkxcEjE4LCgYNgwQ2YQOSHjqET48sgS+BRYFkAgcXHg
X-IronPort-AV: E=Sophos; i="4.84,326,1355097600"; d="scan'208,217"; a="155188320"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 20 Dec 2012 18:29:38 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBKITctR009734 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 18:29:38 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.159]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 12:29:38 -0600
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Shane Amante <shane@castlepoint.net>, Xuxiaohu <xuxiaohu@huawei.com>
Thread-Topic: Discussion on how to transport MPLS over UDP tunnels
Thread-Index: AQHN3praOrGtZ2VkdEWwxZAmFPQPvZgiRR4AgAAiL4A=
Date: Thu, 20 Dec 2012 18:29:37 +0000
Message-ID: <95067C434CE250468B77282634C96ED32281143B@xmb-aln-x02.cisco.com>
References: <CCF5EC8E.2A183%josh.rogers@twcable.com> <E4CD1048-4DB1-4F78-880B-9E62626E370A@castlepoint.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE075891EB@szxeml525-mbs.china.huawei.com> <D3780485-FC2B-4B85-BA87-2BAC24C53B9F@castlepoint.net> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0758953D@szxeml525-mbs.china.huawei.com> <F598812C-DB88-493A-8D42-FE72483647E1@castlepoint.net>
In-Reply-To: <F598812C-DB88-493A-8D42-FE72483647E1@castlepoint.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.150.52.103]
Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED32281143Bxmbalnx02ciscoc_"
MIME-Version: 1.0
Cc: "draft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] Discussion on how to transport MPLS over UDP tunnels
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 20 Dec 2012 18:29:43 -0000
Please find inline a couple of technical comments on this additional proposal. On Dec 20, 2012, at 11:27 AM, Shane Amante <shane@castlepoint.net<mailto:shane@castlepoint.net>> wrote: Hi Xiaohu, On Dec 20, 2012, at 3:13 AM, Xuxiaohu <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> wrote: Hi Shane, Thanks for your further comments and please see my response inline. Note: I changed the subject line according to Loa's suggestion. -----邮件原件----- 发件人: Shane Amante [mailto:shane@castlepoint.net<mailto:shane@castlepoint.net>] 发送时间: 2012年12月19日 22:38 收件人: Xuxiaohu 抄送: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-udp@tools.ietf.org<mailto:draft-xu-mpls-in-udp@tools.ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org> 主题: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document Xiaohu, On Dec 18, 2012, at 11:50 PM, Xuxiaohu <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> wrote: -----邮件原件----- 发件人: Shane Amante [mailto:shane@castlepoint.net<mailto:shane@castlepoint.net>] 发送时间: 2012年12月19日 11:58 收件人: Rogers, Josh 抄送: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-udp@tools.ietf.org<mailto:draft-xu-mpls-in-udp@tools.ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org> 主题: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document On Dec 18, 2012, at 8:50 AM, "Rogers, Josh" <josh.rogers@twcable.com<mailto:josh.rogers@twcable.com>> wrote: I share your SP perspective, and do not see the problem this solution addresses in practice any longer. +1. Please do not define yet another MPLS-over-IP encapsulation. The IETF already standardized MPLS over GRE. The IETF has also standardized MPLS over L2TPv3/UDP/IP, which had seen some deployment in at least one, very large operator network that I'm aware of to support carriage of L3VPN over an IP-only network. Hi Shane, Thank you for telling us there are actual deployments of MPLS over IP in at least one, very large operator network. This fact must be very valuable to those people who had believed there is no application of MPLS over IP in today's SP networks. See: RFC's 4454, 4719, 4591, 4349 for PWE3 over L2TPv3 [NOTE: the dates the above were published was back in the 2006 timeframe!] RFC 4665 for requirements related to VPLS that say that VPLS may be carried over L2TPv3 And, here's evidence showing that at least one vendor has implemented IPVPN's over L2TPv3: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/csgl3vpn.html Thanks again for sharing the above information. As mentioned in this draft AND other drafts, the mechanism of performing hash calculation on the Session ID field in the L2TPv3 header or the Key field in the GRE header as defined in [RFC 5640] is not widely supported by existing core routers so far. FWIW, I have had success, in the relatively recent past, in requesting a core router vendor to support changes to the input-keys used in hash calculations in _existing_ hardware, already deployed (extensively) throughout my network. Further, I suspect that most large network operators are savvy folks and understand the internal architecture of their HW fairly well. As a result, those same operators know what is and is not technically possible in this regard. Thus, it may be a question of "methods" necessary to convince their HW supplier(s) to make appropriate changes in their equipment to achieve their business goals. :-) However, this may not even be necessary ... see below. Could you please briefly explain how to make the above change in EXISTING hardware of already deployed core routers? Firmware upgrades? In contrast, most existing core routers are already capable of balancing IP traffic flows based on the hash of the five-tuple of UDP packets. By using the MPLS-in-UDP encapsulation, the already available load-balancing capability of most existing core routers can be leveraged without requiring any change to them. That is the major motivation of this draft. If this is a concern, then why not encapsulate the traffic in MPLS/L2TPv3, which uses UDP/IP, in the first place? If I understand it correctly, you prefer to use MPLS-in-L2TPv3-in-UDP instead of MPLS-in-UDP, right? Actually, my first preference would be native MPLS switching edge-to-edge, (which means enabling MPLS throughout the network). My second preference would be that for the cases where that's impractical to use native MPLS switching end-to-end, then (edge) devices -- not necessarily routers, (see below) -- would have to perform MPLS-in-L2TPv3-in-UDP encapsulation/de-encapsulation. IMHO, a better proposal may be to consider a [minor] (?) change to RFC 3931, which would allow the connection used for data packets (not control packets) to use a varying set of source ports (or, source IP addresses), based on a hash calculation, to achieve better load-balancing over existing equipment in an IP-only core. You mention RFC 3931 -- L2TPv3 defines L2TP directly over IP (IP Protocol number 115) as a MUST, and L2TP over UDP as a SHOULD. Implementations might not support L2TPv3 over UDP. http://tools.ietf.org/html/rfc3931#section-4.1 L2TP may operate over a variety of PSNs. There are two modes described for operation over IP, L2TP directly over IP (see Section<http://tools.ietf.org/html/rfc3931#section-4.1.1> 4.1.1<http://tools.ietf.org/html/rfc3931#section-4.1.1>) and L2TP over UDP (see Section 4.1.2<http://tools.ietf.org/html/rfc3931#section-4.1.2>) L2TPv3 implementations MUST support L2TP over IP and SHOULD support L2TP over UDP for better NAT and firewall traversal, and for easier migration from L2TPv2. L2TP end-system implementations would be better off just using the "Session ID" (and "Cookie") fields as the demultiplexor to associate incoming packets with the associated L2TP Control Channel. In fact, it's not clear to me that existing implementations may /already/ do this, making any "check" on the incoming source port unnecessary for L2TP end-system implementations. Also, L2TPv3 (over any PSN) uses the Session ID as the session demultiplexer (the Cookie is not a demux): http://tools.ietf.org/html/rfc3931#page-27 It is important for implementers to note that the Cookie field check occurs after looking up the session context by the Session ID, and as such, consists merely of a value match of the Cookie field and that stored in the retrieved context. There is no need to perform a lookup across the Session ID and Cookie as a single value. And the Session ID associates context with a Session, not with a Control Channel. THe UDP "connection" associates with the Control Connection: http://tools.ietf.org/html/rfc3931#section-4.1.2.2 The beauty of the above approach is: 1) I would think that the above is most likely a change that is limited to the "control channel" (software) of existing L2TP end-system implementations. Heck, it may even be backwards compatible with existing L2TPv3 implementations. (L2TPv3 implementors would need to comment on that). IMHO, no matter MPLS-in-L2TPv3-in-UDP or MPLS-in-UDP, the hardware of PE routers needs to be upgraded, e.g., ingress PE routers need to fill in an entropy value in the source port field of UDP headers. I suppose the answer is "it depends" on the HW architecture of PE's -- NPU vs. ASIC -- and whether one needs "PE's" in the traditional sense, as well. As one example, there is the following open source implementation of L2TP: http://www.openl2tp.org Note that the OpenL2TP project implements L2TPv2, RFC2661. As that Web page notes, OpenL2TP has been integrated into the Linux 2.6.23 kernel. FWIW, I am aware that Microsoft -- and, other Operating Systems -- have an L2TP stack for several years now, (to support L2TP/IPSec for VPN's), as well. Regardless, if the main desire for MPLS-over-IP encapsulation is for DataCenters and/or NVO3 ... then, I would think it would be possible to consider /enabling/ OpenL2TP within the Hypervisor of the existing servers, (since they likely already run Linux), and you likely get the best of all worlds: no need to upgrade any "hardware" in the network, just upgrade software (if necessary!) on your servers. If I were in this situation, that is the direction I would look at, since it seems that such Hypervisor upgrades may be necessary anyway, depending of course on the outcome of the work in NVO3, both in it's choice(s) for data plane encapsulations and "control plane" signaling, as well. 2) There is a substantial added security one gets by using "Session ID" and "Cookie" fields to ensure the received L2TPv3 packet is intended for the identified session. Quoting from Section 8.2 of RFC 3931: ---snip--- L2TPv3 provides traffic separation for its VPNs via a 32-bit Session ID in the L2TPv3 data header. When present, the L2TPv3 Cookie (described in Section 4.1), provides an additional check to ensure that an arriving packet is intended for the identified session. Thus, use of a Cookie with the Session ID provides an extra guarantee that the Session ID lookup was performed properly and that the Session ID itself was not corrupted in transit. ---snip--- ... in regard to this question alone, I know the Security Area folks have, in the past, had /substantial/ concerns about encapsulation of MPLS over IP transport. In fact, this is why you see text in Section 7.6, "Security", of RFC 4665. (There's likely similar language in other drafts that use MPLS for transport). While I'm not sure that Security Area folks pay much attention to daily traffic on the MPLS WG mailing list, I'm fairly confident this concern will arise if/when this draft goes to the IESG ... If I understand it correctly, the reason for your preference of MPLS-in-L2TPv3-in-UDP is that it has an added security feature. If that is so concerned, can you explain why MPLS-in-GRE is far more popular than MPLS-in-L2TP in practice? Would you care to cite a source for the above assertion that MPLS-in-GRE is far more popular in _deployments_ than MPLS-in-L2TP? +1. Regardless, I would note that IETF specifications are only recommendations, based on the knowledge and experience of its participants. The IETF does not enforce what operators actually deploy in their network. Operators may make (and, often do make) different choices than what the IETF recommends, because operators understand their networks, services and applications better and the trade-offs and the risks involved. Specifically, in the context of this discussion, it may be that MPLS-in-GRE is more widely used due to a number of factors. However, one potential reason that they may use MPLS-in-GRE is it is only used within the confines of a private network (Enterprise LAN/WAN?, IPVPN?), thus the _perception_ of risk of MiTM attacks -- which is the main concern of using MPLS-in-GRE without GRE keys -- is considered by the operator to be "low". For better or worse, IETF recommendations /need/ to consider all types of networks, e.g.: public and private networks, and thus ha! ve a tendency to recommend more, rather than less, "security" in those recommendations. Thus, *if* this WG draft is adopted (and, before it gets sent to the IESG) I think the co-authors should spend some time with the Security Area to understand the concerns they would most certainly raise during the development of this draft or, worse, during the final stages of its publication (IESG review). :-) Namely: 1) In my past experience merely saying that a given protocol is only /supposed to/ be deployed a given environment has not been successful, given the reason I stated above -- you can't predict where a given technology will get deployed due to operators (like me :-) "disobeying" (or, not reading) advice in IETF drafts/RFCs. 2) The current "Security Considerations" section recommends using IPSec Transport Mode, but lacks sufficient details beyond that, namely: a) IPSec Transport Mode with AH and/or ESP? b) More concerning in the context of this draft is that the way IPSec works will kill the effectiveness of this draft. Specifically, you may wish to review RFCs 4302 and 4303 (AH and ESP, respectively). Namely, the way and IPSec Transport Mode packet will look on the wire is as follows, (from Sections 3.1.1 of both RFCs): AFTER APPLYING AH ------------------------------------------------------- IPv4 |original IP hdr (any options) | AH | TCP | Data | ------------------------------------------------------- |<- mutable field processing ->|<- immutable fields ->| |<----- authenticated except for mutable fields ----->| AFTER APPLYING ESP ------------------------------------------------- IPv4 |orig IP hdr | ESP | | | ESP | ESP| |(any options)| Hdr | TCP | Data | Trailer | ICV| ------------------------------------------------- |<---- encryption ---->| |<-------- integrity ------->| In summary, *when* IPSec Transport Mode is applied, only the outermost 2-tuple {src_ip, dst_ip} will be "readily" visible to intermediate nodes. Unfortunately, the original (outermost) IP header will have IP protocol 50 or 51 (AH or ESP, respectively) pointing that what immediately follows the IP header is an AH or ESP header ... thus, I would bet (better yet, I *know*) that "existing core routers" will **NOT** inspect the IP header further by attempting to 'skip' past the AH/ESP header and find a TCP/UDP or other Layer-4 header in which it could extract {src_port, dst_port} input-keys to use in it's hash algorithm for LAG/ECMP component-link determination. Given the whole point of this draft is to allow core routers to inspect the UDP src_port in order to provide substantial 'entropy' to such hash-algorithms and, thus, even distribution of flows over component-links in LAG/ECMP paths ... that's not possible when IPSec (even, Transport mode) will be required to mitigate Se! curity concerns. Thanks, -shane Thanks, -- Carlos. Best regards, Xiaohu 3) Finally, this approach only affects the end-systems that implement L2TP, for tunneling of MPLS/IP, and does not require an entire industry to support MPLS/UDP encapsulation in their product lines. -shane Best regards, Xiaohu If there was market demand for MPLS over IP, then clearly it would have been more widely implemented by equipment vendors, with either MPLS over GRE or MPLS over L2TPv3. (Where there's a will, there's a way). I would note that the most likely reasons this did not pan out was there are several, practical operational benefits one gets from going with native MPLS encapsulation/switching within the data plane, namely: - MPLS Fast Re-Route - MPLS Traffic Engineering ... to name, but a few. Those have tended to be quite compelling arguments to 'upgrade' network HW to support MPLS encapsulation/switching. -shane -Josh On 12/18/12 12:31 AM, "Shahram Davari" <davari@broadcom.com<mailto:davari@broadcom.com>> wrote: For service provider domain, MPLS over IP is legacy and there is no need to improve it. Regards, Shahram On Dec 17, 2012, at 8:02 PM, "Xuxiaohu" <xuxiaohu@huawei.com<mailto:xuxiaohu@huawei.com>> wrote: Shahram, This draft is ONLY intended to provide a MPLS-over-IP encapsulation method with a better load-balancing applicability so far to those operators who happen to require transporting MPLS application traffic across IP networks. I believe MPLS-based VPN over IP, NVGRE and VXLAN each have their own advocators and use cases. If you absolutely believe it's meaningless of transporting MPLS application traffic across IP networks and therefore those existing RFCs related to MPLS over IP tunneling mechanisms should be moved to Historic status, please say so. By the way, it seems this (http://www.ietf.org/mail-archive/web/nvo3/current/msg01864.html) is just the right thread suitable for you to make the following argument (i.e., whether or not MPLS-based VPN is applicable to data centers). I had thought you would speak up at that time. Sadly, surprisingly silent till now. Sigh, I didn't intend to say the above otherwise. Xiaohu -----邮件原件----- 发件人: mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org> [mailto:mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>] 代表 S. Davari 发送时间: 2012年12月15日 13:34 收件人: Loa Andersson 抄送: draft-xu-mpls-in-udp@tools.ietf.org<mailto:draft-xu-mpls-in-udp@tools.ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org> 主题: Re: [mpls] poll to see if we have support to make draft-xu-mpls-in-udp an mpls working group document I don't support this draft since it has no application in today's modern metro and core, where MPLS is dominant, and its only practical application in in data center, which already is crowded with other solutions such as NVGRE and VXLAN. It seems the authors are trying to bypass the NVO3 solution selection process by advancing the draft in MPLS WG. Regards, Shahram On Dec 14, 2012, at 1:01 AM, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>> wrote: Working group, This is to start a "two week" poll on adopting draft-xu-mpls-in-udp-06 as an MPLS working group document. Due to the holiday season this poll has been extended with one week. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org<http://ietf.org>). Please give an technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends January 07, 2013. There is one IPR claim against this document - https://datatracker.ietf.org/ipr/1941/ . All the active co-authors has stated on the working group mailing list that they are not aware of any other IPR claims than those already disclosed. However, up to version -03 (the document that we used for the IPR poll) Marshall Eubanks was listed as one of the authors. Marshall has discontinued all interactions with the IETF, including the author team of draft-xu-mpls-in-udp-06. The working group chairs has tried to contact Marshall by other means, to try get a response on the IPR poll. We have had no success in this. From version -04 the authors decided to remove Marshall as a co-author. /Loa (mpls wg co-chair) -- Loa Andersson email: loa.andersson@ericsson.com<mailto:loa.andersson@ericsson.com> Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ 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 _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls
- [mpls] poll to see if we have support to make dra… Loa Andersson
- Re: [mpls] poll to see if we have support to make… Lucy yong
- Re: [mpls] poll to see if we have support to make… Vivek Kumar
- Re: [mpls] poll to see if we have support to make… S. Davari
- Re: [mpls] poll to see if we have support to make… Kireeti Kompella
- Re: [mpls] poll to see if we have support to make… Sam Aldrin
- Re: [mpls] poll to see if we have support to make… Mach Chen
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Dhruv Dhody
- Re: [mpls] poll to see if we have support to make… Nischal Sheth
- Re: [mpls] poll to see if we have support to make… Puneet Agarwal
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Shahram Davari
- Re: [mpls] poll to see if we have support to make… Rogers, Josh
- Re: [mpls] poll to see if we have support to make… Linda Dunbar
- Re: [mpls] poll to see if we have support to make… Shane Amante
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Loa Andersson
- Re: [mpls] poll to see if we have support to make… Shane Amante
- [mpls] Discussion on how to transport MPLS over U… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… Adrian Farrel
- [mpls] MPLS client layer over an IGP underlying n… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Shahram Davari
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Shahram Davari
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] Discussion on how to transport MPLS ov… Carlos Pignataro (cpignata)
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… S. Davari
- Re: [mpls] poll to see if we have support to make… Andrew G. Malis
- Re: [mpls] poll to see if we have support to make… Lucy yong
- Re: [mpls] poll to see if we have support to make… Andrew G. Malis
- Re: [mpls] poll to see if we have support to make… Pat Thaler
- Re: [mpls] poll to see if we have support to make… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… S. Davari
- Re: [mpls] poll to see if we have support to make… Lizhenbin
- Re: [mpls] poll to see if we have support to make… Lizhong Jin
- Re: [mpls] MPLS client layer over an IGP underlyi… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… Shahram Davari
- Re: [mpls] poll to see if we have support to make… Xuxiaohu
- Re: [mpls] MPLS client layer over an IGP underlyi… Xuxiaohu
- [mpls] MPLS over L2TP over UDP//re: poll to see i… Xuxiaohu
- Re: [mpls] poll to see if we have support to make… Lucy yong
- Re: [mpls] MPLS client layer over an IGP underlyi… Lucy yong
- Re: [mpls] poll to see if we have support to make… Pat Thaler
- Re: [mpls] poll to see if we have support to make… Pat Thaler
- [mpls] Poll ended - poll to see if we have suppor… Loa Andersson