Re: [mpls] MPLS client layer over an IGP underlying network

Lucy yong <lucy.yong@huawei.com> Thu, 20 December 2012 19:14 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D868D21F8A45 for <mpls@ietfa.amsl.com>; Thu, 20 Dec 2012 11:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.771
X-Spam-Level:
X-Spam-Status: No, score=-3.771 tagged_above=-999 required=5 tests=[AWL=-2.314, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
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 MnnfBmPiTPcZ for <mpls@ietfa.amsl.com>; Thu, 20 Dec 2012 11:14:56 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C892621F88C4 for <mpls@ietf.org>; Thu, 20 Dec 2012 11:14:54 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR59095; Thu, 20 Dec 2012 19:14:53 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 19:13:59 +0000
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 19:14:05 +0000
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Thu, 20 Dec 2012 11:14:02 -0800
From: Lucy yong <lucy.yong@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: [mpls] MPLS client layer over an IGP underlying network
Thread-Index: AQHN3sgbyhIdKl1gO0Cwxxs6MwX9npgiisKA//98ebA=
Date: Thu, 20 Dec 2012 19:14:01 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44864890@dfweml505-mbx>
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> <2691CE0099834E4A9C5044EEC662BB9D4486466A@dfweml505-mbx> <02c401cddee1$1bc3b130$534b1390$@olddog.co.uk>
In-Reply-To: <02c401cddee1$1bc3b130$534b1390$@olddog.co.uk>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.82.202]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "draft-xu-mpls-in-udp@tools.ietf.org" <draft-xu-mpls-in-udp@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] MPLS client layer over an IGP underlying network
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 19:14:58 -0000

Hi Adrian,

Personally, I do not see that DC interconnection is an application of this yet. To me, using MPLS client layer (e.g. EVPN, IPVPN) inside DC (e.g. IGP) for network virtualization overlay is the potential application of this.

Personally, I have not seen a request from service provider who want MPLS over WAN IP in general. Other co-authors may have. Whether this is applicable for DC interconnection, I first ask why do it, if Service providers have deployed IP/MPLS transport networks in WAN, what is wrong to use it for DC interconnection? In fact, this is what SPs do today. 

Something I can foresee is that a service provider may also have Data Centers, or DC providers have some a WAN network, in this case, if they want both networks use the same underlying network and overlay network mechanism. This can provide a general solution for this area. Again, this is my view, not from a service provider or DC provider.

In short, the potential application I think is different from two you point out here (or the draft state). I'll work with co-authors on that.

Thanks,
Lucy 

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Thursday, December 20, 2012 12:38 PM
> To: Lucy yong
> Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org
> Subject: RE: [mpls] MPLS client layer over an IGP underlying network
> 
> Hi Lucy,
> 
> Can you clarify something for me.
> The I-D is pretty open about the use cases. It cites DC interconnect as
> an
> example, but focuses the main motivation as providing entropy in a non-
> MPLS IP
> network that carries MPLS traffic through encapsulation.
> Yet in your email below you say:
> > Such application is for DC. You may argue why not use the
> > GRE which is for MPLS layer over an IGP underling network.
> > We have pointed out in the draft that current routers in DC
> > barely support GRE based load balancing and MPLS-in-GRE
> > are barely used in SP networks too. Most of routers in DC
> > perform upd port based load balancing now.
> 
> Now, it is important, in my opinion to understand whether you are
> attempting to
> solve a general MPLS-in-IP entropy problem, or attempting to solve a
> specific DC
> interconnect problem for connectivity over non-MPLS cores. In the
> former case,
> it would not be unreasonable for us to try to work out what the demand
> is: the
> problem is understandable from an academic point of view, but are
> people
> carrying MPLS over IP today, and if so, do they see this problem? In
> the latter
> case, it is sensible to discuss with NVO3 whether this is addressing
> the DC
> interconnect (L3 overlay) problem in a meaningful way.
> 
> Thanks,
> Adrian
> 
> > -----Original Message-----
> > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
> Of Lucy
> > yong
> > Sent: 20 December 2012 15:39
> > To: Shane Amante
> > Cc: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org; mpls-
> > chairs@tools.ietf.org
> > Subject: [mpls] MPLS client layer over an IGP underlying network
> >
> > Hi Shane,
> >
> > I understand operator concern on a new encapsulation to an existing
> network.
> >
> > However, MPLS-in-UDP does not aim on changing existing SP IP/MPLS
> network at
> > all.
> > MPLS-in-UDP is to enable MPLS client layer to be decoupled from MPLS
> server
> > layer and use MPLS client layer as overlay network and an IGP as a
> underlying
> > network for transport. Such application is for DC. You may argue why
> not use
> the
> > GRE which is for MPLS layer over an IGP underling network. We have
> pointed out
> > in the draft that current routers in DC barely support GRE based load
> balancing
> > and MPLS-in-GRE are barely used in SP networks too. Most of routers
> in DC
> > perform upd port based load balancing now.
> >
> > From the architecture perspective, the UDP encapsulation has
> advantage over
> > GRE encapsulation too. In UDP encapsulation, the frame header
> decouples the
> > overlay and underlying network clearly, i.e. outer header and overlay
> header.
> > UDP belongs to outer header, which underlying network uses only.
> However,
> > GRE header has the fields for the overlay network and uses the key
> field for
> flow
> > entropy. For load balancing, it requires the underlying network uses
> GRE
> header
> > too. In short, GRE ties the overlay and underlying networks together.
> Since it
> has
> > not used a lot, people are not aware of the disadvantage of such
> coupling.
> >
> > As the industry moves toward network virtualization overlay and
> decouples
> > overlay networks from the underlying network. A clear separation of
> overlay
> > header and underlying header is a "MUST" in my opinion. If we count
> GRE as the
> > overlay header, then for IPv4 underlying network, there is no field
> for the
> flow
> > entropy. This is the reason we propose the UDP encapsulation: for an
> IGP based
> > underlying network. In fact, it can support any overlay network
> beside MPLS
> > client layer (e.g. VXLAN, L2TP-in-UDP, etc).
> >
> > You point out using MPLS-in-L2TP-in-UDP instead. Yes, MPLS-in-L2TP-
> in-UDP
> > schema also provides a overlay (L2TP) and underlying (IP) network
> decoupling.
> > L2TP protocol (rfc3931) provides good security mechanism and has the
> > embedded control function too. Therefore, someone can use it for MPLS
> client
> > layer over Internet. To have MPLS client layer over an IGP underling
> network,
> > IMO: MPLS-in-L2TP-in-UDP is a overkill and too complex. Here we need
> a schema
> > to support IGP underlying transport without touching a overlay header.
> UDP
> > encapsulation is the best choice to accomplish that and minimize the
> changes
> on
> > existing routers, e.g. change at edge routers, no change on transit
> routers.
> >
> > Regards,
> > Lucy
> >
> >
> >
> > > -----Original Message-----
> > > From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
> > > Sent: Thursday, December 20, 2012 4:14 AM
> > > To: Shane Amante
> > > Cc: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> udp@tools.ietf.org;
> > > mpls@ietf.org; mpls-chairs@tools.ietf.org
> > > Subject: Discussion on how to transport MPLS over UDP tunnels
> > >
> > > 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]
> > > > 发送时间: 2012年12月19日 22:38
> > > > 收件人: Xuxiaohu
> > > > 抄送: Rogers, Josh; Shahram Davari; draft-xu-mpls-in-
> > > udp@tools.ietf.org;
> > > > mpls@ietf.org; 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>
> wrote:
> > > > -----邮件原件-----
> > > > >> 发件人: Shane Amante [mailto:shane@castlepoint.net]
> > > > >> 发送时间: 2012年12月19日 11:58
> > > > >> 收件人: Rogers, Josh
> > > > >> 抄送: Shahram Davari; Xuxiaohu; draft-xu-mpls-in-
> > > udp@tools.ietf.org;
> > > > >> mpls@ietf.org; 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>
> > > > >> 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?
> > >
> > > > > 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?
> > >
> > > > 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.  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.
> > > >
> > > > 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.
> > >
> > > > 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?
> > >
> > > 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>
> > > > 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>
> > > > 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]
> 代
> > > 表
> > > > >> S.
> > > > >>>>>> Davari
> > > > >>>>>> 发送时间: 2012年12月15日 13:34
> > > > >>>>>> 收件人: Loa Andersson
> > > > >>>>>> 抄送: draft-xu-mpls-in-udp@tools.ietf.org; mpls@ietf.org;
> > > > >>>>>> 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>
> 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) 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
> > > > >>>>>>> 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
> > > > >>>>> https://www.ietf.org/mailman/listinfo/mpls
> > > > >>>> _______________________________________________
> > > > >>>> mpls mailing list
> > > > >>>> 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
> > > > >>> https://www.ietf.org/mailman/listinfo/mpls
> > > > >>
> > > > >
> > > >
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls