Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Xuxiaohu <xuxiaohu@huawei.com> Sun, 26 January 2014 03:48 UTC
Return-Path: <xuxiaohu@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E461A00E8 for <mpls@ietfa.amsl.com>; Sat, 25 Jan 2014 19:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.947
X-Spam-Level:
X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
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 0_KMt3i9Xg93 for <mpls@ietfa.amsl.com>; Sat, 25 Jan 2014 19:48:19 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1F84A1A00E2 for <mpls@ietf.org>; Sat, 25 Jan 2014 19:48:14 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAK63834; Sun, 26 Jan 2014 03:48:12 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 03:47:46 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 26 Jan 2014 03:48:09 +0000
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Sun, 26 Jan 2014 11:48:06 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "curtis@ipv6.occnc.com" <curtis@ipv6.occnc.com>, "l.wood@surrey.ac.uk" <l.wood@surrey.ac.uk>
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: AQHPGguRVpx4VpP9lE+4fynfG27EApqWW65Q
Date: Sun, 26 Jan 2014 03:48:06 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082480D2@NKGEML512-MBS.china.huawei.com>
References: Your message of "Fri, 24 Jan 2014 05:04:55 +0000." <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.ac.uk> <201401252025.s0PKPKtn048651@maildrop2.v6ds.occnc.com>
In-Reply-To: <201401252025.s0PKPKtn048651@maildrop2.v6ds.occnc.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "joelja@bogus.com" <joelja@bogus.com>, "mpls@ietf.org" <mpls@ietf.org>, "lars@netapp.com" <lars@netapp.com>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 26 Jan 2014 03:48:22 -0000
> -----邮件原件----- > 发件人: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > 发送时间: 2014年1月26日 4:25 > 收件人: l.wood@surrey.ac.uk > 抄送: Xuxiaohu; curtis@ipv6.occnc.com; Alexander.Vainshtein@ecitele.com; > lars@netapp.com; joelja@bogus.com; mpls@ietf.org > 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS > in UDP) to Proposed Standard > > > In message > <290E20B455C66743BE178C5C84F1240847E63346EE@EXMB01CMS.surrey.a > c.uk> > l.wood@surrey.ac.uk writes: > > > Ah, make that: > > > > "Generally speaking, a UDP checksum SHOULD be used. The > > considerations described in detail in [RFC6935] [RFC6936] MUST be > > examined if UDP checksums need to be disabled for performance or > > implementation reasons for traffic across private networks. The use > > of a zero UDP checksum is NOT RECOMMENDED." > > > > ie if you're even thinking of turning off checksums, go read those > > RFCs first. > > > > Lloyd Wood > > http://about.me/lloydwood > > This is fine with me but Xuxiaohu is the author. > > I would go a little further with the wording: > > Except in extroidinary cases, UDP checksum SHOULD be used. The > considerations described in detail in [RFC6935] [RFC6936] MUST be > examined if UDP checksums need to be disabled for performance or > implementation reasons. UDP checksum should only be disabled on > private networks or where MPLS in UDP encapsualation is added by a > service provider with MPLS in UDP traffic entirely confined to the > network of that service provider or cooperating service providers > with explicit permission. > > Where it is not possible to use full UDP checksum, and if using > UDP-Lite [RFC3828] is feasible, UDP-Lite SHOULD be used rather than > UDP with disabled checksums. > > Is this better? > > Xuxiaohu - is this OK with you? Hi Curtis, Most of the above text looks fine to me. However, I just wonder whether it is feasible to use UDP-lite tunnel for improving load-balancing in practice. Best regards, Xiaohu > Curtis > > > > From: Wood L Dr (Electronic Eng) > > Sent: 24 January 2014 05:00 > > To: Xuxiaohu; curtis@ipv6.occnc.com > > Cc: Alexander.Vainshtein@ecitele.com; lars@netapp.com; > > joelja@bogus.com; mpls@ietf.org > > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > I would be good with: > > > > "Generally speaking, a UDP checksum SHOULD be used. The considerations > described in [RFC6935] [RFC6936] SHOULD be examined if UDP checksums > need to be disabled for performance or implementation reasons for traffic > across private networks. The use of a zero UDP checksum is NOT > RECOMMENDED." > > > > I wouldn't make this IPv6 specific - IPv4 still has problems (UDP port demux), > IPv6's problems are just worse. > > > > Lloyd Wood > > http://about.me/lloydwood > > ________________________________________ > > From: Xuxiaohu [xuxiaohu@huawei.com] > > Sent: 24 January 2014 04:00 > > To: curtis@ipv6.occnc.com; Wood L Dr (Electronic Eng) > > Cc: Alexander.Vainshtein@ecitele.com; lars@netapp.com; > > joelja@bogus.com; mpls@ietf.org > > Subject: re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > Hi, > > > > Please check whether the following text is OK. > > > > In the IPv6 UDP encapsulation case, as for whether or not it is suitable to use > the zero-checksum node, the requirements defined in [RFC6935] [RFC6936] > SHOULD be strictly followed. Generally speaking, the use of a zero UDP > checksum is NOT RECOMMENDED. Note that other IP encapsulations for MPLS > do not have a checksum in the tunnel header. > > > > Best regards, > > Xiaohu > > > > > -----邮件原件----- > > > 发件人: Curtis Villamizar [mailto:curtis@ipv6.occnc.com] > > > 发送时间: 2014年1月24日 11:53 > > > 收件人: l.wood@surrey.ac.uk > > > 抄送: Xuxiaohu; Alexander.Vainshtein@ecitele.com; lars@netapp.com; > > > joelja@bogus.com; mpls@ietf.org > > > 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > In message > > > > <290E20B455C66743BE178C5C84F1240847E63346E3@EXMB01CMS.surrey.a > > > c.uk> > > > l.wood@surrey.ac.uk writes: > > > > > > > the text is not satisfactory. never recommend setting to zero, as > > > > that poses a risk to your and to other traffic. Suggested text: > > > > *** > > > > The UDP checksum SHOULD be used to protect the payload and ensure > > > > correct demultiplexing and delivery to the tunnel, and not to > > > > other UDP destinations, by protecting the UDP pseudoheader. > > > > Use of a zero UDP checksum is NOT RECOMMENDED, even when desired > > > > for performance or necessitated by implementation reasons, for the > > > > reasons outlined in [RFC6936] section 3. > > > > > > I agree that UDP checksums SHOULD be used (ie: SHOULD NOT be set to > zero). > > > There are cases where it is impossible so it can't be MUST. > > > > > > > UDP-Lite [RFC3828] can provide a demultiplexing check and MPLS > > > > stack integrity check while avoiding the overhead of computing an > > > > integrity check over a tunnelled frame that has its own integrity check. > > > > > > UDP-List doesn't solve the ECMP problems because most of the older > > > LSR that are forcing the use of MPLS over UDP to get ECMP don't look > > > at the port numbers if the protocol is not 6 or 17. But this has > > > only been said three or four times so maybe you missed it. > > > > > > > *** > > > > > > > > Lloyd Wood > > > > http://about.me/lloydwood > > > > ________________________________________ > > > > From: Xuxiaohu [xuxiaohu@huawei.com] > > > > Sent: 23 January 2014 12:35 > > > > To: Wood L Dr (Electronic Eng); Alexander.Vainshtein@ecitele.com; > > > > lars@netapp.com > > > > Cc: joelja@bogus.com; mpls@ietf.org > > > > Subject: re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > -----邮件原件----- > > > > > 发件人: l.wood@surrey.ac.uk [mailto:l.wood@surrey.ac.uk] > > > > > 发送时间: 2014年1月23日 12:44 > > > > > 收件人: Xuxiaohu; Alexander.Vainshtein@ecitele.com; > lars@netapp.com > > > > > 抄送: joelja@bogus.com; mpls@ietf.org > > > > > 主题: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Sasha > > > > > > > > > > > - UDP checksums (or lack thereof) is a non-issue because > > > > > > native MPLS does not have anything like that. And yes, there > > > > > > are cases where packets are corrupted within the routers) > > > > > > > > > > So you admit that packets can be corrupted within the routers - > > > > > a check that can only be caught by an end-to-end check, a > > > > > corruption that can lead to the problems detailed in RFC 6936 > > > > > section 3 - and then you say it's a non-issue because this > > > > > doesn't affect native MPLS. But > > > we're not doing native MPLS here. > > > > > We're doing MPLS over UDP. > > > > > > > > > > draft-ietf-mpls-in-udp-04.txt is about tunnelling MPLS in UDP. It's an > issue. > > > > > Please read the other 150 messages that you refer to. > > > > > > > > Hi Lloyd, > > > > > > > > The draft doesn't require the IPv6 UDP checksum to be set to zero > regardless. > > > See the following text quoted from that draft: > > > > > > > > UDP Checksum > > > > > > > > The usage of this field is in accordance with the current UDP > > > > specification > > > [RFC768]. To simplify the operation on the decapsulator, this field > > > is RECOMMENDED to be set to zero in IPv4 UDP encapsulation case. In > > > the IPv6 UDP encapsulation case, if appropriate according to the > > > requirements defined in [RFC6935] [RFC6936], this field is also > RECOMMENDED to be set to zero. > > > Specifically, if the MPLS payload is Internet Protocol (IPv4 or > > > IPv6) packets, it is RECOMMENDED to be set to zero when the inner > > > packet integrity checks is available. In addition, if the MPLS > > > payload is non-IP packet which is specifically designed for > > > transmission over a lower layer that does not provide a packet > > > integrity guarantee, it is RECOMMENDED to be set to zero as well. > > > Otherwise, using zero checksum is NOT RECOMMENDED. Note that other IP > encapsulations for MPLS do not have a checksum in the tunnel header. > > > > > > > > If you still believe the above text is not satisfactory, please provide your > text. > > > > > > > > Best regards, > > > > Xiaohu > > > > > > > > > Lloyd Wood > > > > > http://about.me/lloydwood > > > > > ________________________________________ > > > > > From: mpls [mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > > [xuxiaohu@huawei.com] > > > > > Sent: 23 January 2014 03:16 > > > > > To: Alexander Vainshtein; Eggert, Lars > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > Hi > > > > > > > > > > > -----邮件原件----- > > > > > > 发件人: Alexander Vainshtein > > > > > > [mailto:Alexander.Vainshtein@ecitele.com] > > > > > > 发送时间: 2014年1月22日 19:05 > > > > > > 收件人: Eggert, Lars > > > > > > 抄送: Joel Jaeggli; mpls@ietf.org; Xuxiaohu > > > > > > 主题: RE: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> > > > > > > (Encapsulating MPLS in UDP) to Proposed Standard > > > > > > > > > > > > Lars and all, > > > > > > Last time I've counted the IETF LC thread on this draft has > > > > > > more than > > > > > > 150 messages in it, and it seems that on some issues > > > > > > (congestion control and UDP > > > > > > checksums) we are going round the mulberry bush. > > > > > > > > > > > > IMHO and FWIW: > > > > > > - UDP checksums (or lack thereof) is a non-issue because > > > > > > native MPLS does not have anything like that. And yes, there > > > > > > are cases where packets are corrupted within the routers), but > > > > > > so far it did not prevent MPLS deployment. There is, e.g., RFC > > > > > > 4720 for FCS retention in PWs, but I doubt it is widely > > > > > > implemented and deployed (would be nice to > > > > > know). > > > > > > - E2E congestion control (regardless of its implications) > > > > > > simply cannot be added to this protocol without some major > > > > > > changes. A short applicability statement explaining that should suffice > IMO. > > > > > > > > > > Hi Sasha, > > > > > > > > > > I fully agree with your points. > > > > > > > > > > Best regards, > > > > > Xiaohu > > > > > > > > > > > My 2c, > > > > > > Sasha > > > > > > Email: Alexander.Vainshtein@ecitele.com > > > > > > Mobile: 054-9266302 > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of > > > > > > > Eggert, Lars > > > > > > > Sent: Wednesday, January 22, 2014 12:23 PM > > > > > > > To: Xuxiaohu > > > > > > > Cc: Joel Jaeggli; mpls@ietf.org > > > > > > > Subject: Re: [mpls] Last Call: > > > > > > > <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) > > > > > > > to Proposed Standard > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On 2014-1-22, at 11:12, Xuxiaohu <xuxiaohu@huawei.com> wrote: > > > > > > > > I wonder whether the following text is OK to you: > > > > > > > > > > > > > > > > Since the MPLS-in-UDP encapsulation causes MPLS packets to > > > > > > > > be > > > > > > > forwarded through "UDP tunnels", the congestion control > > > > > > > guidelines for UDP tunnels as defined in Section 3.1.3 of > > > > > > > [RFC5405] SHOULD be > > > > > followed. > > > > > > > Specifically, MPLS can carry a number of different protocols as > payloads. > > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > > known at configuration time to be IP-based and > > > > > > > congestion-controlled, the UDP tunnel SHOULD NOT employ its > > > > > > > own congestion control mechanism, because congestion losses > > > > > > > of tunneled traffic will trigger an congestion response at > > > > > > > the original > > > senders of the tunneled traffic. > > > > > > > When an UDP tunnel is used for MPLS payload traffic that is > > > > > > > known at configuration time not to be IP-based and > > > > > > > congestion-controlled, the UDP tunnel SHOULD employ an > > > > > > > appropriate congestion control mechanism as described in > > > > > > > [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such > > > > > > > encapsulation technology only within a SP network or > > > > > > > networks of an adjacent set of co-operating SPs, rather than > > > > > > > over the > > > > > Internet. > > > > > > > Furthermore, packet filters should be added to block traffic > > > > > > > with the UDP port number for MPLS over UDP to prevent MPLS > > > > > > > over UDP packets to escape from the service provider > > > > > > > networks due to misconfiguation or packet > > > > > > errors. > > > > > > > > > > > > > > I think it would be better to describe the OAM control loop > > > > > > > in > > > > > > > (some) more detail, rather than pointing to RFC3985, which > > > > > > > doesn't have a whole lot of detail either. Also because the > > > > > > > adding of firewall rules requires an OAM hook. > > > > > > > > > > > > > > Since STRONGLY RECOMMENDED is not an RFC2119 term and > > > > > > RECOMMENDED is > > > > > > > too weak, I'd suggest to change this to MUST. > > > > > > > > > > > > > > Finally, the applicability statement should be prominently > > > > > > > made in the abstract, introduction, etc. > > > > > > > > > > > > > > Lars
- [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>… The IESG
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joel M. Halpern
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Gregory Mirsky
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joel M. Halpern
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alexander Vainshtein
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Mark Tinka
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Mark Tinka
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Gregory Mirsky
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Mark Tinka
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joel M. Halpern
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Mark Tinka
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Mark Tinka
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joel M. Halpern
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joel M. Halpern
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alexander Vainshtein
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alexander Vainshtein
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Wesley Eddy
- Re: ´ð¸´: [mpls] Last Call: <draft-ietf-mpls-in-u… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Mark Tinka
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… joel jaeggli
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Ross Callon
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… joel jaeggli
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… joel jaeggli
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alia Atlas
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alia Atlas
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Ross Callon
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alia Atlas
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alexander Vainshtein
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: ´ð¸´: [mpls] Last Call: <draft-ietf-mpls-in-u… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Gregory Mirsky
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Spencer Dawkins
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Martin Stiemerling
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Noel Chiappa
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Noel Chiappa
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Noel Chiappa
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alia Atlas
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Alia Atlas
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joel M. Halpern
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Eggert, Lars
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Greg Daley
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… John E Drake
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Spencer Dawkins
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- [mpls] 答复: Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Xuxiaohu
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… joel jaeggli
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joel M. Halpern
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Mark Tinka
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Greg Daley
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Edward Crabbe
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Curtis Villamizar
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Ross Callon
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Noel Chiappa
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Scott Brim
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Joe Touch
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Greg Daley
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Stewart Bryant
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… l.wood
- Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.… Greg Daley