Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
<l.wood@surrey.ac.uk> Wed, 22 January 2014 05:19 UTC
Return-Path: <l.wood@surrey.ac.uk>
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 65A541A0229 for <mpls@ietfa.amsl.com>; Tue, 21 Jan 2014 21:19:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 44o1rA30K7f3 for <mpls@ietfa.amsl.com>; Tue, 21 Jan 2014 21:19:46 -0800 (PST)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.174]) by ietfa.amsl.com (Postfix) with ESMTP id BD1361A0030 for <mpls@ietf.org>; Tue, 21 Jan 2014 21:19:45 -0800 (PST)
Received: from [195.245.230.131:50589] by server-14.bemta-3.messagelabs.com id 3B/B3-06105-0F45FD25; Wed, 22 Jan 2014 05:19:44 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-13.tower-78.messagelabs.com!1390367983!31112089!1
X-Originating-IP: [131.227.200.31]
X-StarScan-Received:
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23711 invoked from network); 22 Jan 2014 05:19:43 -0000
Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-13.tower-78.messagelabs.com with AES128-SHA encrypted SMTP; 22 Jan 2014 05:19:43 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.204]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Wed, 22 Jan 2014 05:19:43 +0000
From: l.wood@surrey.ac.uk
To: akatlas@gmail.com
Date: Wed, 22 Jan 2014 05:19:41 +0000
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard
Thread-Index: Ac8XJwfui6H39/u1QaK+ZOXYu/XW8gABvhBw
Message-ID: <290E20B455C66743BE178C5C84F1240847E63346E1@EXMB01CMS.surrey.ac.uk>
References: <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk> <201401220024.s0M0OwGW068768@maildrop2.v6ds.occnc.com> <290E20B455C66743BE178C5C84F1240847E63346DF@EXMB01CMS.surrey.ac.uk> <CAG4d1rdF=p0BkWuGcmvvA39s3LSidSBVKYYW=ugxgiazVCRXeg@mail.gmail.com> <290E20B455C66743BE178C5C84F1240847E63346E0@EXMB01CMS.surrey.ac.uk>, <CAG4d1rfzCvLAMZr0zU1p0p0xC8AC2+NK8OE=bqUE-s3LfG0C-g@mail.gmail.com>
In-Reply-To: <CAG4d1rfzCvLAMZr0zU1p0p0xC8AC2+NK8OE=bqUE-s3LfG0C-g@mail.gmail.com>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: joelja@bogus.com, mpls@ietf.org, 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: Wed, 22 Jan 2014 05:19:50 -0000
> [Alia] I believe that you have not fully thought through how MPLS works. The top label certainly only has local significance between two adjacent > routers - but there is not merely one but many labels possible in an MPLS label stack. The other labels in the label stack are passed transparently along. > Perhaps this misunderstanding is part of why your insistence that the link-layer FCS is ok for MPLS but not for UDP between routers is not coming > through as a coherent argument. Where did I say FCS is ok for MPLS? The assumption in MPLS is that it is processed in a switch where the stack is modified, or protected across the link. I personally don't view that as particularly okay for MPLS - MPLS headers are not self-checking, if e.g. the end of stack bit gets corrupted, it's toast. But I'm not overly concerned about MPLS networks trashing themselves. with MPLS-in-UDP, it is not processed in the routers, just carried. And without an end-to-end UDP checksum, there is no check for the UDP packet OR ITS HEADERS across the entire scope of carriage. The problem is larger than for MPLS. The desire for fast processing with turning off the UDP checksum makes this an IP problem, not an MPLS problem. To look at it another way, link layer FCS checks MPLS across the link. the UDP checksum checks MPLS across the MPLS-in-UDP path. The proposal is that UDP checksums are not needed across the scope of the path. So, surely by analogy we can run without link-layer checksums across the link! Let's turn off Ethernet CRCs! IF you wouldn't turn off Ethernet CRCs, why would you turn off UDP checksums? > A number of years ago, there was actually a problem with hardware missending MPLS packets; as a result the MPLS working group defined an LSR self-test mechanism ( RFC 4379) which allows checking of the LFIB. Yes, problems happen, and they have to be detected. First the problem is introduced, then it is measured. (MPLS ping is arguably much the same. And wasn't MPLS fun before TTL?) Will we see measurements for MPLS-in-UDP misdeliveries, or no measurements thanks to corruption not being picked up zero UDP checksums? > please explain how the MPLS in UDP as a tunnel (not transport) poses a threat. The desire to use a zero UDP checksum poses a threat to other ports and destinations as explained in RFC 6936 section 3. MPLS is UDP in itself is no threat, if a UDP checksum is used. That it's MPLS being carried only matters to MPLS. It's that it's a zero UDP checksum, which is desired for tunnelling efficiency. (I think this might have been mentioned before.) > In the applicability suggested by Curtis, traffic with the port MPLS-in-UDP would be filtered with a zero UDP checksum, the port could be corrupted to a different port, as described in RFC 6936 section 3. How do you filter on the changed port? The error rate is debatable - no instrumentation, no measurements, even if 0.00000001% or less, at high tunnel rates it adds up. But I can guarantee it's nonzero. > [Alia] Next, for this to happen, the errors must not be detected by either the link-layer FCS or memory chip checksums/validation. Which is why we have the end-to-end principle and end-to-end checks. A good way to not detect errors is to turn off error detection with e.g. turning off the UDP checksum. > If this were going to happen to UDP packets, it would also and already be happening to MPLS label stacks. And it has happened to UDP packets, as described in Jonathan Stone's papers and elsewhere. My bet is that it is already happening to MPLS label stacks, but is simply not monitored or detected. > [Alia] I certainly heard some willingness for a SHOULD on the UDP checksum - but that won't be possible on all hardware. SHOULD implement congestion control and SHOULD implement the UDP checksum if crossing the public internet is likely the best we can hope for at this point. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Alia Atlas [akatlas@gmail.com] Sent: 22 January 2014 04:04 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com; joelja@bogus.com; mpls@ietf.org; Eggert, Lars Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard Lloyd, On Tue, Jan 21, 2014 at 10:38 PM, <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>> wrote: > [Alia] Excellent - so if we can describe filtering on the correct fields to enforce this constrained scope, then the concerns about congestion control may be alleviated. For intended private use within a network, I think you'd be fine;as with congestion, crossing the public Internet poses more of a problem. I don't see how filtering comes in to enforce this. > [Alia] Are you actually suggesting that it is highly likely for both the destination IP and UDP port to be simultaneously corrupted on a significant flow of packets where each link already has a FCS covering the entire packet? It is possible. The FCS only covers the link, and the zero UDP checksum removes any check across the entire path. > [Alia] We have vast existence proof that MPLS label stacks, also covered only by link FCS, that this is not the case. MPLS is scoped within the link between MPLS-aware devices. This tunnelling use is along the entire path. The scope is different. How are MPLS discards or missent packets measured? [Alia] I believe that you have not fully thought through how MPLS works. The top label certainly only has local significance between two adjacent routers - but there is not merely one but many labels possible in an MPLS label stack. The other labels in the label stack are passed transparently along. Perhaps this misunderstanding is part of why your insistence that the link-layer FCS is ok for MPLS but not for UDP between routers is not coming through as a coherent argument. [Alia] For example, in a typical L3VPN deployment, the ingress PE places an MPLS label indicating the VPN or even outgoing prefix. Then the ingress PE adds a second MPLS label that indicates to its next-hop that the packet is destined to the egress PE. The inner label is not seen until the egress PE - and its value is not protected by anything but the link-layer FCS. [Alia] MPLS packets with an unknown label can be counted and discarded. The number of packets sent into an RSVP-TE LSP can be compared to the number received by the egress. A number of years ago, there was actually a problem with hardware missending MPLS packets; as a result the MPLS working group defined an LSR self-test mechanism ( RFC 4379) which allows checking of the LFIB. > [Alia] Can you clearly articulate what you see as the threat scenario and the necessary scale and probability to be meaningful here? 'Threat scenario' is language about mitigating a threat to your traffic. Here, your traffic with a zero UDP checksum poses the threat - to everything else. [Alia] If, to inject a bit of levity and culture, you are playing the Lorax who speaks for the trees, you are speaking for all the other traffic, please explain how the MPLS in UDP as a tunnel (not transport) poses a threat. That is what I would like you to explain. [Alia] In the applicability suggested by Curtis, traffic with the port MPLS-in-UDP would be filtered. If that isn't good enough, then that is because of the error rate you are concerned about. Adding in the destination address or source address would increase the number of errors hitting the same packet that would be of concern. Granted, if one error occurs, I am willing to believe that multiple may happen. But now you are assuming that the error rate is high enough to cause problems. What is that rate and what is the corresponding rate of traffic? [Alia] Next, for this to happen, the errors must not be detected by either the link-layer FCS or memory chip checksums/validation. If this were going to happen to UDP packets, it would also and already be happening to MPLS label stacks. [Alia] I certainly heard some willingness for a SHOULD on the UDP checksum - but that won't be possible on all hardware. IF there were convincing numbers and examples, instead of significant counter-examples for the level of corruption you are suggesting, that might get greater support. Certainly the LFIB problem I mentioned that led to RFC 4379 got a lot of attention at the time! Regards, Alia Probability of threat is non-zero, but unknown, because networks are not instrumented for it. We have discussed Stone's results and other anecdotal evidence in this thread. Lloyd Wood http://about.me/lloydwood ________________________________________ From: Alia Atlas [akatlas@gmail.com<mailto:akatlas@gmail.com>] Sent: 22 January 2014 02:34 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>; joelja@bogus.com<mailto:joelja@bogus.com>; mpls@ietf.org<mailto:mpls@ietf.org>; Eggert, Lars Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard Lloyd, On Tue, Jan 21, 2014 at 8:04 PM, <l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk><mailto:l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>>> wrote: Curtis, the 'intended for use within a service provider' and not for mass use sounds reasonable, and scoping in this way may also alleviate some congestion control concerns. [Alia] Excellent - so if we can describe filtering on the correct fields to enforce this constrained scope, then the concerns about congestion control may be alleviated. But outgoing packet filtering, when you're trying to catch a corrupted port, and the port is not what you think it is? That's going to do a partial job of corrupted addresses in IPv6 at best. (v4 has header checksums, ports in v4 and v6 are open to corruption sans UDP pseudo-header check.) [Alia] Are you actually suggesting that it is highly likely for both the destination IP and UDP port to be simultaneously corrupted on a significant flow of packets where each link already has a FCS covering the entire packet? [Alia] We have vast existence proof that MPLS label stacks, also covered only by link FCS, that this is not the case. Naturally the top label is manipulated but the rest of the label stack is just passed through and not looked at. Not convinced by providers already blocking inbound traffic on a new port - particularly given discussion of handling entropy with varying ports in another thread. [Alia] For defense, isn't it a case of block ports by default and only open the destination ports that are explicitly needed? That's how firewalls that I've seen work; perhaps others have a common counterexample? The entropy is put into the source port, which isn't relevant here. So, I don't think filtering is a useful solution here to the problem posed by zero UDP checksums. (An actual UDP checksum solves it, of course.) [Alia] Can you clearly articulate what you see as the threat scenario and the necessary scale and probability to be meaningful here? Regards, Alia regards Lloyd Wood http://about.me/lloydwood ________________________________________ From: Curtis Villamizar [curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com><mailto:curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>>] Sent: 22 January 2014 00:24 To: Wood L Dr (Electronic Eng) Cc: curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com><mailto:curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>>; lars@netapp.com<mailto:lars@netapp.com><mailto:lars@netapp.com<mailto:lars@netapp.com>>; stbryant@cisco.com<mailto:stbryant@cisco.com><mailto:stbryant@cisco.com<mailto:stbryant@cisco.com>>; joelja@bogus.com<mailto:joelja@bogus.com><mailto:joelja@bogus.com<mailto:joelja@bogus.com>>; mpls@ietf.org<mailto:mpls@ietf.org><mailto:mpls@ietf.org<mailto:mpls@ietf.org>> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard Lloyd, Since MPLS over UDP is intended to be used within a provider, how about if we recommend the following: If no MPLS over UDP is intended to go outside a service provider, then packet filters should be added to block traffic with the UDP port number for MPLS over UDP to prevent misconfiguation or packet error to cause MPLS over UDP packets to escape, If either the IP destination address or the UDP destination port were corrupted, then the packet would not leave. The former because the intended destination within the provider would get the packet. The latter because with the UDP port intact the provider's filter would block it. This would also prevent ordinary users from making use of MPLS over UDP, which with its absense of congestion control is causing some objections. Providers would already be blocking traffic coming into their net with this UDP port, particularly to their own infrastructure. The filters might cover only their own addresses allowing users to make use of MPLS over UDP, or could block it entirely. This is in line with Alia's suggestion that we define a profile of intended use being for service providers internal use. Curtis In message <290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk<mailto:290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk><mailto:290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk<mailto:290E20B455C66743BE178C5C84F1240847E63346DE@EXMB01CMS.surrey.ac.uk>>> l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk><mailto:l.wood@surrey.ac.uk<mailto:l.wood@surrey.ac.uk>> writes: > > > When encapsulating in UDP, the UDP checksum might be zero but the IP > > checksum can still be filled in so the IP destination is checked > > IPv6 doesn't have an IP header checksum. So with an error in the > header the packet can go anywhere. > > > > Lack of UDP checksum should at worst mean that the destination gets a > > packet with a munged payload, pulls off the IP and UDP headers and > > continues to forward > > ... or a munged header, and forwards to a different application on a different port. > > See RFC 6936 section 3, which goes through the scenarios - but plays light > on the side-effects. My beef is with: > > A protocol or application that uses the zero UDP checksum method must > ensure that the lack of checksum does not affect the protocol > operation. This includes being robust to receiving an unintended > packet from another protocol or context following corruption of a > destination or source address and/or port value. It also includes > considering the need for additional implicit protection mechanisms > required when using the payload of a UDP packet received with a zero > checksum. > > Lack of a UDP checksum in one protocol can affect the operation of other > protocols minding their own business, until they receive and try to handle > a corrupted packet from the first protocol because port or address is > corrupted. There are a lot of applications that presume that the data they > are given is error-free, and they presume that rogue data is not injected into > their conversation. > > I mean, if you're going to use a zero UDP checksum, and your application > messes up and gives itself corrupt data, fine. More fool you. By analogy > as a risk, it's like speeding while talking on a cellphone and crashing into a tree. > But if your lack of checksum means you affect other applications who have > to now protect themselves against your data, you're effectively now crashing > into and harming other people. They weren't in armoured cars to protect > against this? They had no right to be on the road! > > Zero UDP checksums are hit-and-run accidents waiting to happen. > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Curtis Villamizar [curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com><mailto:curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>>] > Sent: 21 January 2014 20:14 > To: Eggert, Lars > Cc: Stewart Bryant; Wood L Dr (Electronic Eng); curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com><mailto:curtis@ipv6.occnc.com<mailto:curtis@ipv6.occnc.com>>; Joel Jaeggli; mpls@ietf.org<mailto:mpls@ietf.org><mailto:mpls@ietf.org<mailto:mpls@ietf.org>> > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard > > In message <558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com<mailto:558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com><mailto:558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com<mailto:558A15A9-204A-4447-923C-58DC2A3CED8A@netapp.com>>> > "Eggert, Lars" writes: > > > Hi, > > > > On 2014-1-21, at 12:50, Stewart Bryant <stbryant@cisco.com<mailto:stbryant@cisco.com><mailto:stbryant@cisco.com<mailto:stbryant@cisco.com>>> wrote: > > > In terms of congestion and misdelivery it is interesting looking > > > at the number of horses that are already bounding around > > > in the paddock outside the stable: > > > > > > IP types: 47 (GRE) and 137 (MPLS-in-IP) for example. > > > > there is a big difference between encapsulation in IP and > > encapsulation in UDP. Everything encapsulated with "obscure" IP > > protocol numbers will get dropped by default at NATs and firewalls, > > whereas UDO traffic happily traverses them. The reach of UDP traffic > > is much broader. > > > > Lars > > > Stray UDP packets carrying MPLS getting to grandma's firewall is > really stretching the argument but ... > > When encapsulating in UDP, the UDP checksum might be zero but the IP > checksum can still be filled in so the IP destination is checked and > grandma need not worry about these packets. But ... > > Grandma's firewall would block since there is no state established on > the firewall with the opposite port pair pattern. But ... > > Even if it went through when the packet reached grandma's subnet the > payload is junk bound to an unused port. Maybe it hits grandma's DNS > server and is interpreted as a badly malformed DNS request. > > So grandma seems safe from these bad packets. > > Lack of UDP checksum should at worst mean that the destination gets a > packet with a munged payload, pulls off the IP and UDP headers and > continues to forward. At worst has the wrong MPLS label and gets > blackholed in the provider network somewhere. If it ends up at the > correct MPLS egress, if IP, the IP checksum is checked. If a TCP or > UDP payload carried in that IP got munged the packet could end up at > the destination with a bad TCP or UDP checksum and get dropped. > > Curtis _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org><mailto:mpls@ietf.org<mailto:mpls@ietf.org>> https://www.ietf.org/mailman/listinfo/mpls
- [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