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