From adrian@olddog.co.uk Tue Sep 4 08:43:48 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D1E21F8694 for ; Tue, 4 Sep 2012 08:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 ILCeEh3U12W4 for ; Tue, 4 Sep 2012 08:43:27 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 885D521F8526 for ; Tue, 4 Sep 2012 08:43:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q84FhKTo025134 for ; Tue, 4 Sep 2012 16:43:20 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q84FhJAI025127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Sep 2012 16:43:19 +0100 From: "Adrian Farrel" To: References: <20120904153225.18409.22793.idtracker@ietfa.amsl.com> In-Reply-To: <20120904153225.18409.22793.idtracker@ietfa.amsl.com> Subject: FW: I-D Action: draft-mcpherson-irr-routing-policy-considerations-01.txt Date: Tue, 4 Sep 2012 16:43:19 +0100 Message-ID: <021101cd8ab4$029ecb80$07dc6280$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFkKXeX+V9wJ2UZGyh0Jj5B43tjDphNFQKw Content-Language: en-gb X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 15:43:48 -0000 FYI > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 04 September 2012 16:32 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-mcpherson-irr-routing-policy-considerations-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IRR & Routing Policy Configuration Considerations > Author(s) : Danny McPherson > Shane Amante > Eric Osterweil > Larry J. Blunk > Filename : draft-mcpherson-irr-routing-policy-considerations-01.txt > Pages : 15 > Date : 2012-09-04 > > Abstract: > The purpose of this document is to catalog past issues influencing > the efficacy of Internet Routing Registries (IRR) for inter-domain > routing policy specification and application in the global routing > system over the past two decades. Additionally, it provides a > discussion regarding which of these issues are still problematic in > practice, and which are simply artifacts that are no longer > applicable but continue to stifle inter-provider policy-based > filtering adoption and IRR utility to this day. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-mcpherson-irr-routing-policy- > considerations > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-mcpherson-irr-routing-policy-considerations-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-mcpherson-irr-routing-policy- > considerations-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From tom.taylor.stds@gmail.com Tue Sep 4 10:24:35 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C5411E80A3; Tue, 4 Sep 2012 10:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] 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 zAjvvTDIyOBd; Tue, 4 Sep 2012 10:24:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61611E809A; Tue, 4 Sep 2012 10:24:33 -0700 (PDT) Received: by iabz21 with SMTP id z21so10593730iab.31 for ; Tue, 04 Sep 2012 10:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=uInKgck3rHPNGRoCS4vJxra2J+OfJAqw7AxL06kepwk=; b=C/IjW9lbEf+zQ0pGHzerPdDcwfL3B15bztgF9SoFGcc3gaC0yy8RNFeewKlf+jSxKL oRVNjyQ+AoFr+Pm98AV/KfYJaRKsPQDGypjfDCSHm1QdC7qORZCmcrwxiRoOvxJ9d6Pq bS7WwbWngcD8pM6ow3NyLWvwzonVbOpfPYmfGPVLXDv5/lAjno4TM2CTkdSc2vBkO7Py oESImdLmccSEnxvK3ZjbwrTaBrM5woYrBMVs+TZUxFOsBE2iS3qn5VgAsb3nf92QH9W4 TE4XpTwPkaRPX9nUtmCuYwBHF1FLY2fa3YwAzqMIb+IHl1SmJkb385KcsPSGAo35v3Cv uVQA== Received: by 10.50.194.138 with SMTP id hw10mr14959891igc.60.1346779472876; Tue, 04 Sep 2012 10:24:32 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-40-163.tor.primus.ca. [173.206.40.163]) by mx.google.com with ESMTPS id ce6sm13005034igb.1.2012.09.04.10.24.31 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 10:24:32 -0700 (PDT) Message-ID: <5046394E.7090805@gmail.com> Date: Tue, 04 Sep 2012 13:24:30 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: routing-discussion@ietf.org Subject: MTU mismatches and routing hangups Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120904-0, 04/09/2012), Outbound message X-Antivirus-Status: Clean X-Mailman-Approved-At: Tue, 04 Sep 2012 10:27:08 -0700 Cc: "Cathy Zhou\(Qian\)" , pim@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:24:35 -0000 PLEASE NOTE THE CROSS-POSTING when responding. Please direct responses to the authors and the PIM WG only, so the broader community doesn't get bombarded with responses. This message is also being sent to the OSPF and ISIS WGs. draft-lts-pim-hello-mtu-00.txt was inspired by customer reports of multicast routing hangups caused by MTU mismatches at the two ends of a link. The end with the larger MTU sends a message within its MTU size that is discarded at the other end because it is larger than that end's MTU size. The proposal in draft-lts-pim-hello-mtu-00.txt was for adjacent routers to exchange information on their MTUs on each link, then restrict message sizes to the smaller of the MTUs. Working Group discussion in Vancouver raised the obvious question: do MTU mismatches cause problems for other routing protocols? And do any of these protocols have a solution to the problem? I raised the issue of the effect of MTU mismatches on the NANOG list. There were quite a few responses. Amongst other comments: - OSPF hangs at a particular point in the state machine and fails to come up. Debugging can take a while if you don't think of MTU mismatch as a possible cause. - Cisco has published a note on the subject, to be found at http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0d.shtml (sorry about the wrapping). - BGP can hang after a link flap when two specific products [identities omitted] are at the two ends of the link and the configured MTUs are identical, because one end includes the ethernet overhead and the other doesn't. - a good MTU debugging tool can be found at http://www.elifulkerson.com/projects/mturoute.php This message is written to ask the broader routing community what, if anything, routing protocols should do about identifying MTU mismatches, and beyond that, accommodating them. As requested above, please direct responses to the authors and the PIM WG only. Tom Taylor From iljitsch@muada.com Thu Sep 6 06:47:49 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA3921F84FC for ; Thu, 6 Sep 2012 06:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aH072F1Q6-T for ; Thu, 6 Sep 2012 06:47:49 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id C8A2121F84FA for ; Thu, 6 Sep 2012 06:47:48 -0700 (PDT) Received: from [192.168.178.12] (5ED31AEE.cm-7-4a.dynamic.ziggo.nl [94.211.26.238]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id q86DjM6W043775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2012 15:45:22 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Subject: Re: MTU mismatches and routing hangups From: Iljitsch van Beijnum In-Reply-To: <5046394E.7090805@gmail.com> Date: Thu, 6 Sep 2012 15:47:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> References: <5046394E.7090805@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1486) Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:47:49 -0000 On 4 Sep 2012, at 19:24 , Tom Taylor wrote: > - BGP can hang after a link flap when two specific products = [identities omitted] are at the two ends of the link and the configured = MTUs are identical, because one end includes the ethernet overhead and = the other doesn't. Huh? BGP runs over TCP and TCP has the maximum segment size option that helps = the sender to keep its packets to a size that the receiver can handle. = As such there shouldn't be any problems unless the MSS option is = incorrectly implemented.= From tony.li@tony.li Thu Sep 6 08:08:13 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C328D21F8567 for ; Thu, 6 Sep 2012 08:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.477 X-Spam-Level: X-Spam-Status: No, score=-98.477 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnP1BPJW-iiw for ; Thu, 6 Sep 2012 08:08:13 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by ietfa.amsl.com (Postfix) with ESMTP id 1D95F21F854E for ; Thu, 6 Sep 2012 08:08:13 -0700 (PDT) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta04.emeryville.ca.mail.comcast.net with comcast id vqzf1j0020FhH24A4r8CQH; Thu, 06 Sep 2012 15:08:12 +0000 Received: from sjc-vpn5-1951.cisco.com ([128.107.239.233]) by omta08.emeryville.ca.mail.comcast.net with comcast id vr7g1j00a52qHCY8Ur7mi8; Thu, 06 Sep 2012 15:08:07 +0000 Subject: Re: MTU mismatches and routing hangups Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> Date: Thu, 6 Sep 2012 08:07:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1278) Cc: routing-discussion@ietf.org, Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:08:13 -0000 On Sep 6, 2012, at 6:47 AM, Iljitsch van Beijnum wrote: > On 4 Sep 2012, at 19:24 , Tom Taylor = wrote: >=20 >> - BGP can hang after a link flap when two specific products = [identities omitted] are at the two ends of the link and the configured = MTUs are identical, because one end includes the ethernet overhead and = the other doesn't. >=20 > Huh? >=20 > BGP runs over TCP and TCP has the maximum segment size option that = helps the sender to keep its packets to a size that the receiver can = handle. As such there shouldn't be any problems unless the MSS option is = incorrectly implemented. This is generally a symptom of a path MTU implementation problem and is = not a real protocol issue. Regards, Tony From iljitsch@muada.com Thu Sep 6 08:29:57 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9A021F8722 for ; Thu, 6 Sep 2012 08:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI112XjXKzpL for ; Thu, 6 Sep 2012 08:29:57 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id B89D521F84E1 for ; Thu, 6 Sep 2012 08:29:56 -0700 (PDT) Received: from [IPv6:2001:470:1f0b:1289:6df0:c7a7:b5cf:9845] ([IPv6:2001:470:1f0b:1289:6df0:c7a7:b5cf:9845]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id q86FRQ0u044626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2012 17:27:28 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Subject: Re: MTU mismatches and routing hangups From: Iljitsch van Beijnum In-Reply-To: <5048AF51.5000005@gmail.com> Date: Thu, 6 Sep 2012 17:29:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D578DD9-4985-4360-B6BA-67D42B05C377@muada.com> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <5048AF51.5000005@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1486) Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:29:57 -0000 On 6 Sep 2012, at 16:12 , Tom Taylor wrote: > The original message reporting this condition is at > http://mailman.nanog.org/pipermail/nanog/2012-August/051374.html Some people think an ethernet frame/packet is 1500 bytes, others 1514, = and a third group 1518. There is no substitute for RTFM. But like I = said, the MSS option is supposed to take care of that for TCP. I have an old draft to allow nodes with different MTUs on the same = subnet, I'm interested to hear if anyone thinks this would be useful = here: http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-03= From jie.dong@huawei.com Sun Sep 9 20:32:08 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA1221F8533 for ; Sun, 9 Sep 2012 20:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2AYscPGvi0Is for ; Sun, 9 Sep 2012 20:32:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA7B21F852B for ; Sun, 9 Sep 2012 20:32:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKM77386; Mon, 10 Sep 2012 03:32:06 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 04:32:02 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 11:32:05 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 11:32:00 +0800 From: Jie Dong To: Tony Li , Iljitsch van Beijnum Subject: RE: MTU mismatches and routing hangups Thread-Topic: MTU mismatches and routing hangups Thread-Index: AQHNjDZBjuczJrjuNkWpLOj4zcO5tpd85C4AgAYFx8A= Date: Mon, 10 Sep 2012 03:31:59 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> In-Reply-To: <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 03:32:08 -0000 > This is generally a symptom of a path MTU implementation problem and is n= ot a > real protocol issue. Agreed. And my question here is that can the path MTU always be obtained th= rough data plane probing? Or do we need control plane mtu discovery mechani= sm for some cases, e.g. mpls lsps?=20 Some related documents:=20 rfc3988: MTU Signalling Extensions for LDP rfc3209 (RSVP-TE), sec 2.6: Path MTU draft-zeng-idr-bgp-mtu-extension: MTU ext-community for BGP-4 Regards, Jie > -----Original Message----- > From: routing-discussion-bounces@ietf.org > [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Tony Li > Sent: Thursday, September 06, 2012 11:08 PM > To: Iljitsch van Beijnum > Cc: routing-discussion@ietf.org; Tom Taylor > Subject: Re: MTU mismatches and routing hangups >=20 >=20 > On Sep 6, 2012, at 6:47 AM, Iljitsch van Beijnum wrote: >=20 > > On 4 Sep 2012, at 19:24 , Tom Taylor wrote: > > > >> - BGP can hang after a link flap when two specific products [identitie= s > omitted] are at the two ends of the link and the configured MTUs are iden= tical, > because one end includes the ethernet overhead and the other doesn't. > > > > Huh? > > > > BGP runs over TCP and TCP has the maximum segment size option that help= s > the sender to keep its packets to a size that the receiver can handle. As= such > there shouldn't be any problems unless the MSS option is incorrectly > implemented. >=20 >=20 >=20 > Regards, > Tony >=20 >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion From tony.li@tony.li Sun Sep 9 23:19:27 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DBE21F8581 for ; Sun, 9 Sep 2012 23:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.602 X-Spam-Level: X-Spam-Status: No, score=-99.602 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGlJFtHmYSED for ; Sun, 9 Sep 2012 23:19:27 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 033C021F8578 for ; Sun, 9 Sep 2012 23:19:24 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta02.emeryville.ca.mail.comcast.net with comcast id xJAT1j0010S2fkCA2JKQWC; Mon, 10 Sep 2012 06:19:24 +0000 Received: from sjc-vpn7-148.cisco.com ([128.107.239.233]) by omta09.emeryville.ca.mail.comcast.net with comcast id xJJl1j00K52qHCY8VJJrqo; Mon, 10 Sep 2012 06:19:19 +0000 Subject: Re: MTU mismatches and routing hangups Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> Date: Sun, 9 Sep 2012 23:18:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> To: Jie Dong X-Mailer: Apple Mail (2.1278) Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 06:19:27 -0000 ??? PMTUD already specifies data plane probing. Adding control plane = infra on it would be a major step backwards. Tony On Sep 9, 2012, at 8:31 PM, Jie Dong wrote: >> This is generally a symptom of a path MTU implementation problem and = is not a >> real protocol issue. >=20 > Agreed. And my question here is that can the path MTU always be = obtained through data plane probing? Or do we need control plane mtu = discovery mechanism for some cases, e.g. mpls lsps?=20 >=20 > Some related documents:=20 >=20 > rfc3988: MTU Signalling Extensions for LDP > rfc3209 (RSVP-TE), sec 2.6: Path MTU > draft-zeng-idr-bgp-mtu-extension: MTU ext-community for BGP-4 >=20 >=20 > Regards, > Jie >=20 >> -----Original Message----- >> From: routing-discussion-bounces@ietf.org >> [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Tony Li >> Sent: Thursday, September 06, 2012 11:08 PM >> To: Iljitsch van Beijnum >> Cc: routing-discussion@ietf.org; Tom Taylor >> Subject: Re: MTU mismatches and routing hangups >>=20 >>=20 >> On Sep 6, 2012, at 6:47 AM, Iljitsch van Beijnum wrote: >>=20 >>> On 4 Sep 2012, at 19:24 , Tom Taylor = wrote: >>>=20 >>>> - BGP can hang after a link flap when two specific products = [identities >> omitted] are at the two ends of the link and the configured MTUs are = identical, >> because one end includes the ethernet overhead and the other doesn't. >>>=20 >>> Huh? >>>=20 >>> BGP runs over TCP and TCP has the maximum segment size option that = helps >> the sender to keep its packets to a size that the receiver can = handle. As such >> there shouldn't be any problems unless the MSS option is incorrectly >> implemented. >>=20 >>=20 >>=20 >> Regards, >> Tony >>=20 >>=20 >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www.ietf.org/mailman/listinfo/routing-discussion From jie.dong@huawei.com Sun Sep 9 23:38:06 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836E421F8534 for ; Sun, 9 Sep 2012 23:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 aq--Mqk6lh3S for ; Sun, 9 Sep 2012 23:38:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F47921F852A for ; Sun, 9 Sep 2012 23:38:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKM89202; Mon, 10 Sep 2012 06:38:03 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 07:37:01 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 07:38:00 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 14:37:57 +0800 From: Jie Dong To: Tony Li Subject: RE: MTU mismatches and routing hangups Thread-Topic: MTU mismatches and routing hangups Thread-Index: AQHNjDZBjuczJrjuNkWpLOj4zcO5tpd85C4AgAYFx8D//6/FgIAAhnzQ Date: Mon, 10 Sep 2012 06:37:56 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256B2F7@szxeml504-mbs.china.huawei.com> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> In-Reply-To: <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 06:38:06 -0000 Yes PMTUD defines the data plane probing procedure. What I want to ask is t= hat is the data plane probing applicable in all the cases?=20 As quoted in my previous email, control plane MTU discovery mechanisms alre= ady exist for lsps, such as rfc3988 for LDP and sec 2.6 of rfc3209 for RSVP= -TE. This is probably because the intermediate nodes of the lsps may not kn= ow how to send the "Datagram Too Big" message back to the source of the pro= bing packet. Regards, Jie > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: Monday, September 10, 2012 2:19 PM > To: Jie Dong > Cc: Iljitsch van Beijnum; routing-discussion@ietf.org; Tom Taylor > Subject: Re: MTU mismatches and routing hangups >=20 >=20 > ??? PMTUD already specifies data plane probing. Adding control plane in= fra > on it would be a major step backwards. >=20 > Tony >=20 >=20 > On Sep 9, 2012, at 8:31 PM, Jie Dong wrote: >=20 > >> This is generally a symptom of a path MTU implementation problem and i= s > not a > >> real protocol issue. > > > > Agreed. And my question here is that can the path MTU always be obtaine= d > through data plane probing? Or do we need control plane mtu discovery > mechanism for some cases, e.g. mpls lsps? > > > > Some related documents: > > > > rfc3988: MTU Signalling Extensions for LDP > > rfc3209 (RSVP-TE), sec 2.6: Path MTU > > draft-zeng-idr-bgp-mtu-extension: MTU ext-community for BGP-4 > > > > > > Regards, > > Jie > > > >> -----Original Message----- > >> From: routing-discussion-bounces@ietf.org > >> [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Tony Li > >> Sent: Thursday, September 06, 2012 11:08 PM > >> To: Iljitsch van Beijnum > >> Cc: routing-discussion@ietf.org; Tom Taylor > >> Subject: Re: MTU mismatches and routing hangups > >> > >> > >> On Sep 6, 2012, at 6:47 AM, Iljitsch van Beijnum wrote: > >> > >>> On 4 Sep 2012, at 19:24 , Tom Taylor wrot= e: > >>> > >>>> - BGP can hang after a link flap when two specific products [identit= ies > >> omitted] are at the two ends of the link and the configured MTUs are > identical, > >> because one end includes the ethernet overhead and the other doesn't. > >>> > >>> Huh? > >>> > >>> BGP runs over TCP and TCP has the maximum segment size option that > helps > >> the sender to keep its packets to a size that the receiver can handle.= As such > >> there shouldn't be any problems unless the MSS option is incorrectly > >> implemented. > >> > >> > >> > >> Regards, > >> Tony > >> > >> > >> _______________________________________________ > >> routing-discussion mailing list > >> routing-discussion@ietf.org > >> https://www.ietf.org/mailman/listinfo/routing-discussion From tony.li@tony.li Mon Sep 10 00:56:58 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7FF21F84CD for ; Mon, 10 Sep 2012 00:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.769 X-Spam-Level: X-Spam-Status: No, score=-99.769 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ4GlPRz75zg for ; Mon, 10 Sep 2012 00:56:58 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF4521F849C for ; Mon, 10 Sep 2012 00:56:56 -0700 (PDT) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta12.emeryville.ca.mail.comcast.net with comcast id xKww1j0071wfjNsACKwwgd; Mon, 10 Sep 2012 07:56:56 +0000 Received: from sjc-vpn7-148.cisco.com ([128.107.239.233]) by omta23.emeryville.ca.mail.comcast.net with comcast id xKwK1j00H52qHCY8jKwR6b; Mon, 10 Sep 2012 07:56:51 +0000 Subject: Re: MTU mismatches and routing hangups Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273256B2F7@szxeml504-mbs.china.huawei.com> Date: Mon, 10 Sep 2012 00:56:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B2F7@szxeml504-mbs.china.huawei.com> To: Jie Dong X-Mailer: Apple Mail (2.1278) Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 07:56:58 -0000 On Sep 9, 2012, at 11:37 PM, Jie Dong wrote: > Yes PMTUD defines the data plane probing procedure. What I want to ask = is that is the data plane probing applicable in all the cases?=20 By definition, data plane probing is the ONLY mechanism that we have = that can follow the entire path of a TCP connection. It is effective = even in cases where protocols are not in use, such as when someone is = doing static routes. It is (somewhat) effective through firewalls. > As quoted in my previous email, control plane MTU discovery mechanisms = already exist for lsps, such as rfc3988 for LDP and sec 2.6 of rfc3209 = for RSVP-TE. This is probably because the intermediate nodes of the lsps = may not know how to send the "Datagram Too Big" message back to the = source of the probing packet. True enough, but BGP doesn't require MPLS. Nor should it. Tony From jie.dong@huawei.com Mon Sep 10 01:40:21 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE721F851B for ; Mon, 10 Sep 2012 01:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 trEiHAX4hqsD for ; Mon, 10 Sep 2012 01:40:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 93D3F21F8464 for ; Mon, 10 Sep 2012 01:40:20 -0700 (PDT) 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 AJM93501; Mon, 10 Sep 2012 08:40:19 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 09:39:06 +0100 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 09:40:05 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 16:39:56 +0800 From: Jie Dong To: Tony Li Subject: RE: MTU mismatches and routing hangups Thread-Topic: MTU mismatches and routing hangups Thread-Index: AQHNjDZBjuczJrjuNkWpLOj4zcO5tpd85C4AgAYFx8D//6/FgIAAhnzQ//+Ux4CAAJFo0A== Date: Mon, 10 Sep 2012 08:39:55 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256B3C4@szxeml504-mbs.china.huawei.com> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B2F7@szxeml504-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 08:40:21 -0000 Hi Tony,=20 > True enough, but BGP doesn't require MPLS. Nor should it. The BGP extension is defined for RFC3107, in which BGP is used to advertise= MPLS labels.=20 Regards, Jie > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: Monday, September 10, 2012 3:56 PM > To: Jie Dong > Cc: Iljitsch van Beijnum; routing-discussion@ietf.org; Tom Taylor > Subject: Re: MTU mismatches and routing hangups >=20 >=20 > On Sep 9, 2012, at 11:37 PM, Jie Dong wrote: >=20 > > Yes PMTUD defines the data plane probing procedure. What I want to ask = is > that is the data plane probing applicable in all the cases? >=20 >=20 > By definition, data plane probing is the ONLY mechanism that we have that= can > follow the entire path of a TCP connection. It is effective even in case= s where > protocols are not in use, such as when someone is doing static routes. I= t is > (somewhat) effective through firewalls. >=20 >=20 >=20 > > As quoted in my previous email, control plane MTU discovery mechanisms > already exist for lsps, such as rfc3988 for LDP and sec 2.6 of rfc3209 fo= r > RSVP-TE. This is probably because the intermediate nodes of the lsps may = not > know how to send the "Datagram Too Big" message back to the source of the > probing packet. >=20 >=20 > True enough, but BGP doesn't require MPLS. Nor should it. >=20 > Tony From tony.li@tony.li Mon Sep 10 07:28:30 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E85C21F8682 for ; Mon, 10 Sep 2012 07:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.88 X-Spam-Level: X-Spam-Status: No, score=-99.88 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jifJuE7fqTUH for ; Mon, 10 Sep 2012 07:28:30 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB1521F867E for ; Mon, 10 Sep 2012 07:28:28 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta10.emeryville.ca.mail.comcast.net with comcast id xRaE1j0021u4NiLAASUUQl; Mon, 10 Sep 2012 14:28:28 +0000 Received: from sjc-vpn7-148.cisco.com ([128.107.239.233]) by omta21.emeryville.ca.mail.comcast.net with comcast id xSTq1j00952qHCY8hSTx90; Mon, 10 Sep 2012 14:28:23 +0000 Subject: Re: MTU mismatches and routing hangups Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273256B3C4@szxeml504-mbs.china.huawei.com> Date: Mon, 10 Sep 2012 07:27:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B2F7@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256B3C4@szxeml504-mbs.china.huawei.com> To: Jie Dong X-Mailer: Apple Mail (2.1278) Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:28:30 -0000 On Sep 10, 2012, at 1:39 AM, Jie Dong wrote: >> True enough, but BGP doesn't require MPLS. Nor should it. >=20 > The BGP extension is defined for RFC3107, in which BGP is used to = advertise MPLS labels.=20 ??? Yes, but how does that help? The point at issue is MTU of the full = path, including such things as L2 switches, for BGP in the general case. = =20 Tony From jie.dong@huawei.com Mon Sep 10 18:24:55 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DA321F8682 for ; Mon, 10 Sep 2012 18:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NYfQ0aJIuVZu for ; Mon, 10 Sep 2012 18:24:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A59521F861F for ; Mon, 10 Sep 2012 18:24:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKN66847; Tue, 11 Sep 2012 01:24:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Sep 2012 02:24:35 +0100 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Sep 2012 02:24:41 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Tue, 11 Sep 2012 09:24:35 +0800 From: Jie Dong To: Tony Li Subject: RE: MTU mismatches and routing hangups Thread-Topic: MTU mismatches and routing hangups Thread-Index: AQHNjDZBjuczJrjuNkWpLOj4zcO5tpd85C4AgAYFx8D//6/FgIAAhnzQ//+Ux4CAAJFo0P//2/sAACcwD0A= Date: Tue, 11 Sep 2012 01:24:34 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256BB43@szxeml504-mbs.china.huawei.com> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B2F7@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256B3C4@szxeml504-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 01:24:55 -0000 Tony,=20 Sorry for the confusions caused. I admit that the control plane MTU discove= ry is not directly related to the issue Tom mentioned.=20 The control plane MTU discovery is for MTU discovery of LSPs which could be= used to transport both data packets and control messages. As I saw your co= mments on PMTU implementation, I just want to know your opinions if for LSP= s (signaled by LDP, RSVP-TE or BGP), control plane MTU discovery would be h= elpful. Regards, Jie > -----Original Message----- > From: Tony Li [mailto:tony.li@tony.li] > Sent: Monday, September 10, 2012 10:28 PM > To: Jie Dong > Cc: Iljitsch van Beijnum; routing-discussion@ietf.org; Tom Taylor > Subject: Re: MTU mismatches and routing hangups >=20 >=20 > On Sep 10, 2012, at 1:39 AM, Jie Dong wrote: >=20 > >> True enough, but BGP doesn't require MPLS. Nor should it. > > > > The BGP extension is defined for RFC3107, in which BGP is used to adver= tise > MPLS labels. >=20 >=20 > ??? Yes, but how does that help? The point at issue is MTU of the full = path, > including such things as L2 switches, for BGP in the general case. >=20 > Tony From tony.li@tony.li Mon Sep 10 18:44:10 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1608D21F86EF for ; Mon, 10 Sep 2012 18:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.96 X-Spam-Level: X-Spam-Status: No, score=-99.96 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddZ0LsHwf8pi for ; Mon, 10 Sep 2012 18:44:09 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4C66821F8643 for ; Mon, 10 Sep 2012 18:44:06 -0700 (PDT) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta01.emeryville.ca.mail.comcast.net with comcast id xZvg1j0040FhH24A1dk64c; Tue, 11 Sep 2012 01:44:06 +0000 Received: from sjc-vpn4-913.cisco.com ([128.107.239.233]) by omta08.emeryville.ca.mail.comcast.net with comcast id xdjV1j00752qHCY8UdjbLA; Tue, 11 Sep 2012 01:44:01 +0000 Subject: Re: MTU mismatches and routing hangups Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <76CD132C3ADEF848BD84D028D243C9273256BB43@szxeml504-mbs.china.huawei.com> Date: Mon, 10 Sep 2012 18:43:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E9DF617-0E41-4F49-8EDB-4B10C2742058@tony.li> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B2F7@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256B3C4@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256BB43@szxeml504-mbs.china.huawei.com> To: Jie Dong X-Mailer: Apple Mail (2.1278) Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 01:44:10 -0000 Hi Jie, Again, the control plane path is fine for distributing the information = that you know. But it is insufficient because there are always = restrictions that do not (and will not) participate in the control = plane. Ergo, data plane processes are always going to be necessary. What is truly unfortunate is that we didn't get this right back in 4.2 = BSD. Then more stacks would have done the right thing. Regards, Tony On Sep 10, 2012, at 6:24 PM, Jie Dong wrote: > Tony,=20 >=20 > Sorry for the confusions caused. I admit that the control plane MTU = discovery is not directly related to the issue Tom mentioned.=20 >=20 > The control plane MTU discovery is for MTU discovery of LSPs which = could be used to transport both data packets and control messages. As I = saw your comments on PMTU implementation, I just want to know your = opinions if for LSPs (signaled by LDP, RSVP-TE or BGP), control plane = MTU discovery would be helpful. >=20 > Regards, > Jie >=20 >> -----Original Message----- >> From: Tony Li [mailto:tony.li@tony.li] >> Sent: Monday, September 10, 2012 10:28 PM >> To: Jie Dong >> Cc: Iljitsch van Beijnum; routing-discussion@ietf.org; Tom Taylor >> Subject: Re: MTU mismatches and routing hangups >>=20 >>=20 >> On Sep 10, 2012, at 1:39 AM, Jie Dong wrote: >>=20 >>>> True enough, but BGP doesn't require MPLS. Nor should it. >>>=20 >>> The BGP extension is defined for RFC3107, in which BGP is used to = advertise >> MPLS labels. >>=20 >>=20 >> ??? Yes, but how does that help? The point at issue is MTU of the = full path, >> including such things as L2 switches, for BGP in the general case. >>=20 >> Tony >=20 From jie.dong@huawei.com Wed Sep 12 05:37:35 2012 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709A921F84EB for ; Wed, 12 Sep 2012 05:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9tzApMxFwc-M for ; Wed, 12 Sep 2012 05:37:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4693521F8518 for ; Wed, 12 Sep 2012 05:37:34 -0700 (PDT) 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 AJP21139; Wed, 12 Sep 2012 12:37:32 +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; Wed, 12 Sep 2012 13:37:15 +0100 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Sep 2012 13:37:18 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Wed, 12 Sep 2012 20:37:12 +0800 From: Jie Dong To: Tony Li Subject: RE: MTU mismatches and routing hangups Thread-Topic: MTU mismatches and routing hangups Thread-Index: AQHNjDZBjuczJrjuNkWpLOj4zcO5tpd85C4AgAYFx8D//6/FgIAAhnzQ//+Ux4CAAJFo0P//2/sAACcwD0D//4NGgP/9NzCQ Date: Wed, 12 Sep 2012 12:37:12 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273256C296@szxeml504-mbs.china.huawei.com> References: <5046394E.7090805@gmail.com> <716B15CD-5690-4B91-81BC-9B6FDC64B5DD@muada.com> <987F9C77-76C4-41C3-8E6B-D032B04C8A6A@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B056@szxeml504-mbs.china.huawei.com> <565D3C75-4037-4692-8083-1AED17B781C4@tony.li> <76CD132C3ADEF848BD84D028D243C9273256B2F7@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256B3C4@szxeml504-mbs.china.huawei.com> <76CD132C3ADEF848BD84D028D243C9273256BB43@szxeml504-mbs.china.huawei.com> <0E9DF617-0E41-4F49-8EDB-4B10C2742058@tony.li> In-Reply-To: <0E9DF617-0E41-4F49-8EDB-4B10C2742058@tony.li> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "routing-discussion@ietf.org" , Tom Taylor X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:37:35 -0000 Hi Tony,=20 Agree that for end-to-end PMTU discovery, data plane mechanism would be nec= essary. The control plane mechanisms are not to replace data plane probing,= but trying to be complementary. Control plane mechanisms defined in those RFCs/drafts are to help the MTU d= iscovery of LSPs, so the end-to-end data plane discovery can treat the whol= e LSP as one-hop link, and the PMTU problem with intermediate LSRs is solve= d.=20 And with control plane mechanism, the ingress can dynamically learn the PMT= U without the need of frequently probing. Best regards, Jie > -----Original Message----- > From: routing-discussion-bounces@ietf.org > [mailto:routing-discussion-bounces@ietf.org] On Behalf Of Tony Li > Sent: Tuesday, September 11, 2012 9:43 AM > To: Jie Dong > Cc: routing-discussion@ietf.org; Tom Taylor > Subject: Re: MTU mismatches and routing hangups >=20 >=20 > Hi Jie, >=20 > Again, the control plane path is fine for distributing the information th= at you > know. But it is insufficient because there are always restrictions that = do not > (and will not) participate in the control plane. Ergo, data plane proces= ses are > always going to be necessary. >=20 > What is truly unfortunate is that we didn't get this right back in 4.2 BS= D. Then > more stacks would have done the right thing. >=20 > Regards, > Tony >=20 >=20 > On Sep 10, 2012, at 6:24 PM, Jie Dong wrote: >=20 > > Tony, > > > > Sorry for the confusions caused. I admit that the control plane MTU dis= covery > is not directly related to the issue Tom mentioned. > > > > The control plane MTU discovery is for MTU discovery of LSPs which coul= d be > used to transport both data packets and control messages. As I saw your > comments on PMTU implementation, I just want to know your opinions if for > LSPs (signaled by LDP, RSVP-TE or BGP), control plane MTU discovery would= be > helpful. > > > > Regards, > > Jie > > > >> -----Original Message----- > >> From: Tony Li [mailto:tony.li@tony.li] > >> Sent: Monday, September 10, 2012 10:28 PM > >> To: Jie Dong > >> Cc: Iljitsch van Beijnum; routing-discussion@ietf.org; Tom Taylor > >> Subject: Re: MTU mismatches and routing hangups > >> > >> > >> On Sep 10, 2012, at 1:39 AM, Jie Dong wrote: > >> > >>>> True enough, but BGP doesn't require MPLS. Nor should it. > >>> > >>> The BGP extension is defined for RFC3107, in which BGP is used to adv= ertise > >> MPLS labels. > >> > >> > >> ??? Yes, but how does that help? The point at issue is MTU of the fu= ll > path, > >> including such things as L2 switches, for BGP in the general case. > >> > >> Tony > > >=20 > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion