From idr-bounces@ietf.org Thu Jan 04 15:52:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXo-0002Yl-OW; Thu, 04 Jan 2007 15:50:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2ZXk-0002UD-RK; Thu, 04 Jan 2007 15:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2ZXk-0000oG-I1; Thu, 04 Jan 2007 15:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 780D92AC7B; Thu, 4 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2ZXG-0000eU-84; Thu, 04 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 04 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-multisession-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Multisession BGP Author(s) : J. Scudder, C. Appanna Filename : draft-ietf-idr-bgp-multisession-03.txt Pages : 14 Date : 2007-1-4 This specification augments "Multiprotocol Extensions for BGP-4" [MP- BGP] by proposing a mechanism to allow multiple sessions to be used between a given pair of BGP speakers. Each session is used to transport routes for one or more AFI/SAFI. This provides an alternative to the current [MP-BGP] approach of multiplexing routes for all AFI/SAFI onto a single connection. Use of this approach is expected to increase the robustness of the BGP protocol as it is used to support more and more diverse AFI/SAFI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-multisession-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-multisession-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-multisession-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-4142830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-multisession-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-multisession-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-4142830.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Fri Jan 05 15:52:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w1T-0005UN-M7; Fri, 05 Jan 2007 15:50:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2w1L-0005JM-CY; Fri, 05 Jan 2007 15:50:35 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H2w1J-0004tp-2I; Fri, 05 Jan 2007 15:50:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C39FA176F6; Fri, 5 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H2w0o-0002Mv-Ce; Fri, 05 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-as-pathlimit-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : The AS_PATHLIMIT Path Attribute Author(s) : T. Li, et al. Filename : draft-ietf-idr-as-pathlimit-03.txt Pages : 16 Date : 2007-1-5 This document describes the 'AS path limit' (AS_PATHLIMIT) path attribute for BGP. This is an optional, transitive path attribute that is designed to help limit the distribution of routing information in the Internet. By default, prefixes advertised into the BGP graph are distributed freely, and if not blocked by policy will propagate globally. This is harmful to the scalability of the routing subsystem since information that only has a local effect on routing will cause state creation throughout the default-free zone. This attribute can be attached to a particular path to limit its scope to a subset of the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-pathlimit-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-as-pathlimit-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-as-pathlimit-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-5115227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-as-pathlimit-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-as-pathlimit-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-5115227.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr --NextPart-- From idr-bounces@ietf.org Fri Jan 12 16:38:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U5h-0002Ut-6C; Fri, 12 Jan 2007 16:37:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U5f-0002Uo-Tn for idr@ietf.org; Fri, 12 Jan 2007 16:37:35 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5U5e-0007xH-KD for idr@ietf.org; Fri, 12 Jan 2007 16:37:35 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 12 Jan 2007 13:37:34 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0CLbWrI024217 for ; Fri, 12 Jan 2007 13:37:32 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0CLbWGk022059 for ; Fri, 12 Jan 2007 13:37:32 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 13:37:31 -0800 Received: from [171.71.55.151] ([171.71.55.151]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 13:37:31 -0800 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <09F6A82F-B0BE-4918-B446-6B0B9BCD625C@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: idr@ietf.org From: Tony Li Date: Fri, 12 Jan 2007 13:37:30 -0800 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jan 2007 21:37:31.0582 (UTC) FILETIME=[DD63EDE0:01C73691] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=66; t=1168637852; x=1169501852; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20AS_PATHLIMIT |Sender:=20; bh=ti+MmbgAANIgLFgHMcKdBb2G0osNtMcTHyDS8kc0gb4=; b=MwzkY9WwT8J5LylPoFzxEXNtUTO4N4AQe3sUIhoogrZsgZyAk4htvFSQJXlHHRiOyXGH7NBU 5qpaL+DfsfWGD2JSD7DdJ6KxlV759iCG7/r9hfSgEtcrL9558WpSEP3+; Authentication-Results: sj-dkim-7; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Idr] AS_PATHLIMIT X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, Are there any more comments on AS_PATHLIMIT? Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 19 20:39:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H85Ae-0000ss-NV; Fri, 19 Jan 2007 20:37:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H85Ad-0000qM-LI for idr@ietf.org; Fri, 19 Jan 2007 20:37:27 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H85Ab-0006oa-7C for idr@ietf.org; Fri, 19 Jan 2007 20:37:27 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=A9Hh4XhCqMzT1w7Ya3NlcLYGktS9zbIHRgBzOOI+BLN1DGQQJl7ivn2s2oUovCIZ; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.172.113] (helo=earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1H85Aa-00066M-Pi; Fri, 19 Jan 2007 20:37:25 -0500 Message-ID: <45B16EC0.DFC48562@earthlink.net> Date: Fri, 19 Jan 2007 17:22:08 -0800 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] AS_PATHLIMIT References: <09F6A82F-B0BE-4918-B446-6B0B9BCD625C@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79b78bbc380e05f55f14be1f721b45af4d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.172.113 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Tony Li, I have a few concerns/ questions. 1) I seem to recall in either a non-IETF document of a IETF doc, that AS_PATHLIMIT was already used to determine whether some form of looping was done. With this value the same AS could be added to allow an alternate pathing method. It will limit a non redundant AS looping environment to this LIMIT value. Right? Should a section thne be added for "loop mitigation"? 2) As was mentioned in the draft, AS_PATHLIMIT may be changed by other than the originator. Would it then make sense, if the change was intentionally done, to suggest a parasitic version field. This, COULD then be incremented each time a this value was changed because of policy mechanisms. 3) Of of the reasons for this new value is to restrict the propogation of routing information. However, with this restriction, doesn't it limits the ability of a BGP speaker to quickly alternately find another path if the new AS_PATHLIMIT restricts the less specific prefixes. 4) Can a secondary consequence of this new value lead to more routing information? I can see a router wishing to originate more specific routing information locally and less specific routing information on a non-local basis. 5) How do you / should you consider that a router that is in a chaotic subnet location may periodicly be decrementing the AS_PATHLIMIT because it understands this new attribute. Thus, I can see the reach of the prefixes may be in somewhat of a change? Mitchell Erblich ==================== Tony Li wrote: > > Folks, > > Are there any more comments on AS_PATHLIMIT? > > Tony > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www1.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 19 20:56:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H85Sd-0000NF-ED; Fri, 19 Jan 2007 20:56:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H85Sc-0000NA-2a for idr@ietf.org; Fri, 19 Jan 2007 20:56:02 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H85SZ-0000t4-NA for idr@ietf.org; Fri, 19 Jan 2007 20:56:02 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 19 Jan 2007 17:55:59 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0K1twN6005594; Fri, 19 Jan 2007 17:55:58 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0K1tvhq023414; Fri, 19 Jan 2007 17:55:57 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 17:55:57 -0800 Received: from [171.71.55.219] ([171.71.55.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 17:55:56 -0800 In-Reply-To: <45B16EC0.DFC48562@earthlink.net> References: <09F6A82F-B0BE-4918-B446-6B0B9BCD625C@cisco.com> <45B16EC0.DFC48562@earthlink.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14AE9CA2-6D8C-4A90-B286-4400732D5B9F@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] AS_PATHLIMIT Date: Fri, 19 Jan 2007 17:55:56 -0800 To: Erblichs X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Jan 2007 01:55:56.0913 (UTC) FILETIME=[202DEE10:01C73C36] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2978; t=1169258158; x=1170122158; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20AS_PATHLIMIT |Sender:=20; bh=JrI4voCraE5l6pMEZ2t/he92ufAge6McBIZ/kaw4AMM=; b=CxMXTMFbCgT/nftcJwPACd4LRfnMvAYGmupFUmuUK7ZjacnDM0q9ETFDeelrOQnZYItWS9Ko B+Er571pn2Hm+eQMcnyJ9sG2EoMUn0w3TINr5VOYHiU1onHj30FDwu68; Authentication-Results: sj-dkim-7; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Mitchell, > 1) I seem to recall in either a non-IETF > document of a IETF doc, that AS_PATHLIMIT > was already used to determine whether > some form of looping was done. With this > value the same AS could be added to allow > an alternate pathing method. > > It will limit a non redundant AS looping > environment to this LIMIT value. Right? > > Should a section thne be added for > "loop mitigation"? I'm unaware of any other documents (other than prior revs of this one) that refer to AS_PATHLIMIT. In any case, AS_PATHLIMIT should have no impact whatsoever on BGP's normal loop prevention mechanisms. It should only provide an additional mechanism for prefix filtering. > 2) As was mentioned in the draft, AS_PATHLIMIT > may be changed by other than the originator. More strictly, the AS_PATHLIMIT may be removed by an AS. Another AS_PATHLIMIT can then be added, but it should always include the AS number of the domain that added the attribute. > Would it then make sense, if the change was > intentionally done, to suggest a parasitic > version field. This, COULD then be incremented > each time a this value was changed because of > policy mechanisms. While that's certainly possible, I don't see a vital need for this. Is there one? > 3) Of of the reasons for this new value is to > restrict the propogation of routing information. > > However, with this restriction, doesn't it > limits the ability of a BGP speaker to quickly > alternately find another path if the new AS_PATHLIMIT > restricts the less specific prefixes. Again, as it's only another prefix filtering mechanism, it should have no effect on best path computation. Obviously, if the AS_PATHLIMIT has caused the only working path to be filtered, there will be a problem finding a path. However, you have that today with simple prefix filters already. BTW, my expectation is that AS_PATHLIMIT is primarily applied to more specifics. Of course, I could be wrong. > 4) Can a secondary consequence of this new value lead > to more routing information? > > I can see a router wishing to originate more > specific routing information locally and less > specific routing information on a non-local basis. If an administrator wants to do that today, then they are already doing so, resulting in global propagation of even the more specifics. The goal here is to provide a scoping mechanism. > 5) How do you / should you consider that a router that > is in a chaotic subnet location may periodicly > be decrementing the AS_PATHLIMIT because it > understands this new attribute. > > Thus, I can see the reach of the prefixes may > be in somewhat of a change? Any filtering mechanism is going to implicitly change the reach of the prefixes that it filters. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jan 19 22:40:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H873A-0005IX-Qk; Fri, 19 Jan 2007 22:37:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8739-0005IP-LG for idr@ietf.org; Fri, 19 Jan 2007 22:37:51 -0500 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8739-00076G-6k for idr@ietf.org; Fri, 19 Jan 2007 22:37:51 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jC5tk0L1vFJkq7BnbxqXJkWV98DaxjTyPDTlR1X5+bn+alMIn0hyokDo4m/jdZTm; h=Received:Message-ID:Date:From:X-Sender:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.172.113] (helo=earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1H8736-0007Jj-Lr; Fri, 19 Jan 2007 22:37:50 -0500 Message-ID: <45B1889E.8FDA4CC4@earthlink.net> Date: Fri, 19 Jan 2007 19:12:30 -0800 From: Erblichs X-Sender: "Erblichs" (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Tony Li Subject: Re: [Idr] AS_PATHLIMIT References: <09F6A82F-B0BE-4918-B446-6B0B9BCD625C@cisco.com> <45B16EC0.DFC48562@earthlink.net> <14AE9CA2-6D8C-4A90-B286-4400732D5B9F@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79d6a735d9d857705a8e29e0d1c0e39efe350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.172.113 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Tony Li, I think you missed my points. You were justifying the use of AS_PATHLIMIT to limit the scope of specific/local routing information to the network. 0) NEW: I don't quite see why this new proposed attribute would not be a non-transitive optional category? If the value is unknown by one or more BGP nbrs, shouldn't that restrict the usage to those local BGP spkrs? Without doing so allows the route to be passed along with the result of no AS_PATHLIMIT being set. This clearly was not the intent when the AS-PATHLIMIT was set. Right? 3) Summary: Change "MUST" to "SHOULD". >From the draft: If the number of ASes in the AS_PATH exceeds the value of the AS_PATHLIMIT attribute, then the route MUST be ignored without further processing. Sorry, IMO, the AS_PATHLIMIT is a origination filter, where the normal filters are locally applied based on a number of configurable parameters.... This tells a BGP spkr X+1 ASs distance that you will drop the route!!!!! Some routers may want to cache that alternate route. Why should 1 router tell other routers what to do with the recieved routing information?????? This is so IMPORTANT, I feel that it needs to be mentioned twice in my reply. :( The rest are Inline.. Mitchell Erblich Tony Li wrote: > > Hi Mitchell, > > > 1) I seem to recall in either a non-IETF > > document of a IETF doc, that AS_PATHLIMIT > > was already used to determine whether > > some form of looping was done. With this > > value the same AS could be added to allow > > an alternate pathing method. > > > > It will limit a non redundant AS looping > > environment to this LIMIT value. Right? > > > > Should a section thne be added for > > "loop mitigation"? > > I'm unaware of any other documents (other than prior revs of this > one) that refer to AS_PATHLIMIT. > > In any case, AS_PATHLIMIT should have no impact whatsoever on BGP's > normal loop prevention mechanisms. It should only provide an > additional mechanism for prefix filtering. > If a path preference was to prefer transit the same AS twice, the AS_PATHLIMIT could be used as a alternate path mitigation. I thought this was the original intention for this attribute name.. However, for loop mitigation, it is feasible to know that a specific path isn't longer than X AS's in length and thus, any alternate route that takes a greater number of ASs could be prevented. Thus, it should be stuck on almost every route. > > 2) As was mentioned in the draft, AS_PATHLIMIT > > may be changed by other than the originator. > > More strictly, the AS_PATHLIMIT may be removed by an AS. Another > AS_PATHLIMIT can then be added, but it should always include the AS > number of the domain that added the attribute. > > > Would it then make sense, if the change was > > intentionally done, to suggest a parasitic > > version field. This, COULD then be incremented > > each time a this value was changed because of > > policy mechanisms. > > While that's certainly possible, I don't see a vital need for this. > Is there one? Doesn't knowing that the AS_PATHLIMIT may have been changed multiple times add information?. Secondly, their is/was a course grain Partial bit usage, however, to determine that it was changed multiple times requires a version number. Partial bit set to 1 and version set to 0 specifies that the number of changes done to the attribute exceeded the number of bits available for the version number, IMO. > > 3) Of of the reasons for this new value is to > > restrict the propogation of routing information. > > > > However, with this restriction, doesn't it > > limits the ability of a BGP speaker to quickly > > alternately find another path if the new AS_PATHLIMIT > > restricts the less specific prefixes. > > Again, as it's only another prefix filtering mechanism, it should > have no effect on best path computation. Obviously, if the > AS_PATHLIMIT has caused the only working path to be filtered, there > will be a problem finding a path. However, you have that today with > simple prefix filters already. > Sorry, IMO, the AS_PATHLIMIT is a origination filter, where the normal filters are locally applied based on a number of configurable parameters.... This tells a BGP spkr X+1 ASs distance that you will drop the route!!!!! Some routers may want to cache that alternate route. >From the draft: If the number of ASes in the AS_PATH exceeds the value of the AS_PATHLIMIT attribute, then the route MUST be ignored without further processing. > BTW, my expectation is that AS_PATHLIMIT is primarily applied to more > specifics. Of course, I could be wrong. > > > 4) Can a secondary consequence of this new value lead > > to more routing information? > > > > I can see a router wishing to originate more > > specific routing information locally and less > > specific routing information on a non-local basis. > > If an administrator wants to do that today, then they are already > doing so, resulting in global propagation of even the more > specifics. The goal here is to provide a scoping mechanism. > Yes, but you have just opened the "pandora's box" to justify at least the doubling of routes. To allow low-hop routers to use one path and to force the use of other's to transit a different path for greater bandwidth but also with greater latency. The side effect is to allow the increase of the number of routes. Some routes will have a local scope. Some a med scope. Some a ISP scope. Some a global scope. > > 5) How do you / should you consider that a router that > > is in a chaotic subnet location may periodicly > > be decrementing the AS_PATHLIMIT because it > > understands this new attribute. > > > > Thus, I can see the reach of the prefixes may > > be in somewhat of a change? > > Any filtering mechanism is going to implicitly change the reach of > the prefixes that it filters. I didn't get my full intention with this statement. Since the AS_PATHLIMIT is passed along if unknown (transitive optional), many ASs may be added to the path before the route is finally if ever removed. So, with the understanding that we may set the AS_PATHLIMIT to X, it may be X+Y before the route is removed. Thus, any admin doing #4 above, may not quite realize why his concieved routing domains are unindated with additional routes. Mitchell Erblich > > Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Jan 20 00:51:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H896R-0005qW-S0; Sat, 20 Jan 2007 00:49:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H896Q-0005om-Dc for idr@ietf.org; Sat, 20 Jan 2007 00:49:22 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H896O-0002Zr-Qq for idr@ietf.org; Sat, 20 Jan 2007 00:49:22 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 19 Jan 2007 21:49:20 -0800 X-IronPort-AV: i="4.13,215,1167638400"; d="scan'208"; a="458621361:sNHT54032240" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l0K5nJJG006895; Fri, 19 Jan 2007 21:49:19 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0K5nKGk026662; Fri, 19 Jan 2007 21:49:20 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 21:49:19 -0800 Received: from [192.168.0.101] ([10.21.123.57]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 21:49:19 -0800 In-Reply-To: <45B1889E.8FDA4CC4@earthlink.net> References: <09F6A82F-B0BE-4918-B446-6B0B9BCD625C@cisco.com> <45B16EC0.DFC48562@earthlink.net> <14AE9CA2-6D8C-4A90-B286-4400732D5B9F@cisco.com> <45B1889E.8FDA4CC4@earthlink.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [Idr] AS_PATHLIMIT Date: Fri, 19 Jan 2007 21:49:17 -0800 To: Erblichs X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Jan 2007 05:49:19.0054 (UTC) FILETIME=[BA1B16E0:01C73C56] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5515; t=1169272159; x=1170136159; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[Idr]=20AS_PATHLIMIT |Sender:=20; bh=LlrQTyxgBDxGZCJvhCnxSToQiyOvWpXZiOaxGVyAS+s=; b=PDtA+J+fFpplqul2IcAiTuqy08rrE0SSgCjLMcX//y6/SR9lhkdJ5ampI1ptBwyxKViFzYbS gv78DJ5+B/wgtR7NIWxpbNssaSAnXdoHqsLqT/eihJMWBgIwT4iAIfjT; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Mitchell, > I think you missed my points. Sorry. I'm trying the best that I can. Please feel free to enclose clue. > You were justifying the use of AS_PATHLIMIT > to limit the scope of specific/local routing > information to the network. > > 0) NEW: I don't quite see why this new proposed > attribute would not be a non-transitive > optional category? Well, we want it to be transitive as we want it to cross ASes that don't understand the attribute. > If the value is unknown by one or more BGP > nbrs, shouldn't that restrict the usage to > those local BGP spkrs? Without doing so > allows the route to be passed along with > the result of no AS_PATHLIMIT being set. > This clearly was not the intent when the > AS-PATHLIMIT was set. > Right? If the attribute is not understood by a BGP speaker, then it hopefully will be received by some BGP speaker that recognizes it and can then filter out the prefix. > 3) Summary: Change "MUST" to "SHOULD". > >> From the draft: > If the number of ASes in the AS_PATH exceeds the value of > the AS_PATHLIMIT attribute, then the route MUST be ignored without > further processing. For an implementation that supports AS_PATHLIMIT to be in compliance with this (future) RFC, this is the required behavior. Implementations that choose not to perform this function should not claim compliance with the document. > Sorry, IMO, the AS_PATHLIMIT is a origination filter, > where the normal filters are locally applied based > on a number of configurable parameters.... > > This tells a BGP spkr X+1 ASs distance that you will > drop the route!!!!! Some routers may want to cache that > alternate route. > > Why should 1 router tell other routers > what to do with the recieved routing information?????? The use of AS_PATHLIMIT is not required. It is only there if a router choose to add the attribute. It is purely intended as a mechanism for a router to tell others to drop the prefix. > If a path preference was to prefer transit the same AS twice, > the AS_PATHLIMIT could be used as a alternate path > mitigation. I thought this was the original intention > for this attribute name.. > > However, for loop mitigation, it is feasible to know > that a specific path isn't longer than X AS's in length > and thus, any alternate route that takes a greater > number of ASs could be prevented. I'm sorry, you've definitely lost me here. > Thus, it should be stuck on almost every route. I'd be a bit more conservative and suggest that it should definitely be on every more specific. For less specifics, using the AS_PATHLIMIT could constrain reachability unduly. >> While that's certainly possible, I don't see a vital need for this. >> Is there one? > > Doesn't knowing that the AS_PATHLIMIT may have > been changed multiple times add information?. True it would. The question then becomes a) is it useful information and b) does the benefit outweigh the costs. Again, I'm not finding a significant benefit. >>> I can see a router wishing to originate more >>> specific routing information locally and less >>> specific routing information on a non-local basis. >> >> If an administrator wants to do that today, then they are already >> doing so, resulting in global propagation of even the more >> specifics. The goal here is to provide a scoping mechanism. >> > > Yes, but you have just opened the "pandora's box" > to justify at least the doubling of routes. To allow > low-hop routers to use one path and to force the use > of other's to transit a different path for greater > bandwidth but also with greater latency. > > The side effect is to allow the increase of the number of > routes. Some routes will have a local scope. Some a med > scope. Some a ISP scope. Some a global scope. I'm sorry, I don't see how that justifies anything. Anyone injecting a route into the Internet still will need to justify doing so, with or within AS_PATHLIMIT. >>> 5) How do you / should you consider that a router that >>> is in a chaotic subnet location may periodicly >>> be decrementing the AS_PATHLIMIT because it >>> understands this new attribute. >>> >>> Thus, I can see the reach of the prefixes may >>> be in somewhat of a change? >> >> Any filtering mechanism is going to implicitly change the reach of >> the prefixes that it filters. > > I didn't get my full intention with this statement. > > Since the AS_PATHLIMIT is passed along if unknown > (transitive optional), many ASs may be added to the > path before the route is finally if ever removed. That's unfortunately true. Hopefully as deployment expands, the spread of 'over limit' prefixes will diminish. > So, with the understanding that we may set the AS_PATHLIMIT > to X, it may be X+Y before the route is removed. Thus, any > admin doing #4 above, may not quite realize why his > concieved routing domains are unindated with additional > routes. It's true that those that do not understand how to use the tool may harm themselves or others with it. Of course, BGP had this property on day 1. As this is an extension of BGP, it too has this property. It's unavoidable. Tony _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Mon Jan 22 15:43:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95yK-0003mu-Hd; Mon, 22 Jan 2007 15:40:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H95yJ-0003l1-3h for idr@ietf.org; Mon, 22 Jan 2007 15:40:55 -0500 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H95yG-000632-PA for idr@ietf.org; Mon, 22 Jan 2007 15:40:55 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id l0MKeq1Z000236; Mon, 22 Jan 2007 12:40:52 -0800 (PST) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l0MKeeB26648; Mon, 22 Jan 2007 12:40:40 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200701222040.l0MKeeB26648@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <84381.1169498440.1@juniper.net> Date: Mon, 22 Jan 2007 12:40:40 -0800 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: skh@nexthop.com, yakov@juniper.net Subject: [Idr] IDR WG agenda X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Folks, Its about time to start thinking about agenda items for the next IETF. Please forward any IDR agenda items you might have to Sue and myself. The deadline is Feb 23. And if you plan to make a presentation, please also keep in mind the rule "no Internet Draft - no time slot". Sue & Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr