From idr-bounces@ietf.org Wed Jul 05 10:06:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy81M-00063p-0R; Wed, 05 Jul 2006 10:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy81J-0005un-NX; Wed, 05 Jul 2006 10:06:25 -0400 Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy81I-0004wj-CI; Wed, 05 Jul 2006 10:06:25 -0400 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 k65E6N1Z092851; Wed, 5 Jul 2006 07:06:23 -0700 (PDT) (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 k65E6M510822; Wed, 5 Jul 2006 07:06:23 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200607051406.k65E6M510822@merlot.juniper.net> To: Bill Fenner MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <51742.1152108382.1@juniper.net> Date: Wed, 05 Jul 2006 07:06:22 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: skh@nexthop.com, idr@ietf.org, iesg@ietf.org Subject: [Idr] BGP ORF and Prefix-ORF to Proposed Standard 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 Bill, The IDR WG asks to advance the following Internet Drafts to Proposed Standard: draft-ietf-idr-route-filter-14.txt draft-ietf-idr-bgp-prefix-orf-03.txt Implementation report is draft-chen-bgp-orf-survey-00.txt (it covers both of the above drafts). Yakov. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Tue Jul 11 19:10:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RMc-0003pP-13; Tue, 11 Jul 2006 19:09:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0RMa-0003pC-U2 for idr@ietf.org; Tue, 11 Jul 2006 19:09:56 -0400 Received: from gate.alliedtelesyn.co.nz ([202.49.72.33]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0RMZ-0005d7-91 for idr@ietf.org; Tue, 11 Jul 2006 19:09:56 -0400 Received: (qmail 25981 invoked from network); 11 Jul 2006 23:09:53 -0000 Received: from mailmarshall.alliedtelesyn.co.nz (10.32.18.40) by gate-int.alliedtelesyn.co.nz with SMTP; 11 Jul 2006 23:09:53 -0000 Received: from aslan.alliedtelesyn.co.nz (Not Verified[10.32.18.53]) by mailmarshall.alliedtelesyn.co.nz with NetIQ MailMarshal (v5.5.6.7) id ; Wed, 12 Jul 2006 11:09:03 +1200 Received: from CHCDOM1-MTA by aslan.alliedtelesyn.co.nz with Novell_GroupWise; Wed, 12 Jul 2006 11:09:53 +1200 Message-Id: <44B4D861.E0D5.005D.0@alliedtelesyn.co.nz> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 12 Jul 2006 11:09:22 +1200 From: "gregory hoggarth" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Idr] Clarification on RFC4271 section 5.1.5 - is LOCAL-PREF mandatory or discretionary 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 Hello everyone, I've been working on a BGP implementation which is currently failing a third-party test that is assuming that the LOCAL-PREF attribute is a well-known mandatory attribute while the implementation is assuming that it is discretionary. RFC4271 does not make the definition 100% clear, especially because in RFC1771 this attribute is described as being well-known discretionary. Section 5.1.5 from RFC4271 states: LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers. A BGP speaker SHALL calculate the degree of preference for each external route based on the locally-configured policy, and include the degree of preference when advertising a route to its internal peers. The SHALLs seem to make this fairly clear, however note that it merely says "well-known attribute". Other attributes, such as ORIGIN say "well-known mandatory attribute". Also, in the table at the top of page 25, LOCAL_PREF is listed as being "required" for IBGP, but this is never actually defined anywhere as to what this means. Again in section 4.3 e) on page 19, it only says "well-known attribute", whereas on the same page NEXT_HOP is described as "well-known mandatory" and ATOMIC_AGGREGATE is described as "well-known discretionary". In RFC1771 LOCAL_PREF is defined on pages 15 and 23 as being "well-known discretionary". The current way the implementation works is based on RFC1771, but as RFC4271 is ambiguous as to how LOCAL_PREF should be handled, I am unsure as to whether the implementation needs to be changed. Currently, if an update message that does not include the LOCAL_PREF attribute arrives from an iBGP neighbour, the default or administratively-defined LOCAL_PREF value for the receiving router is assigned to the advertised route. This seems like a good compromise in my opinion. The third-party test suite is expecting that in this situation, the device will return a notification message that incidates the attribute was not included in the update. So, according to RFC4271, is LOCAL_PREF a mandatory attribute, at least for iBGP peer communication? Is my current approach to the lack of this attribute in an update sensible and acceptable? Thanks, Greg NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesis Labs Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesis Labs. _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jul 12 00:22:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0WEn-0005G0-8A; Wed, 12 Jul 2006 00:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0WEl-0005Fs-UA for idr@ietf.org; Wed, 12 Jul 2006 00:22:11 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0WEj-0006TR-8K for idr@ietf.org; Wed, 12 Jul 2006 00:22:11 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 11 Jul 2006 21:22:09 -0700 X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="1837598230:sNHT35214372" 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.20060308/8.12.11) with ESMTP id k6C4M84p029437; Tue, 11 Jul 2006 21:22:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k6C4M8nc025980; Tue, 11 Jul 2006 21:22:08 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 21:22:08 -0700 Received: from [10.21.96.203] ([10.21.96.203]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 21:22:05 -0700 Message-ID: <44B478E6.2080201@cisco.com> Date: Tue, 11 Jul 2006 21:21:58 -0700 From: Robert Raszuk Organization: http://raszuk.net/ User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: gregory hoggarth Subject: Re: [Idr] Clarification on RFC4271 section 5.1.5 - is LOCAL-PREF mandatory or discretionary References: <44B4D861.E0D5.005D.0@alliedtelesyn.co.nz> In-Reply-To: <44B4D861.E0D5.005D.0@alliedtelesyn.co.nz> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2006 04:22:05.0979 (UTC) FILETIME=[BBA336B0:01C6A56A] DKIM-Signature: a=rsa-sha1; q=dns; l=4004; t=1152678128; x=1153542128; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=raszuk@cisco.com; z=From:Robert=20Raszuk=20 |Subject:Re=3A=20[Idr]=20Clarification=20on=20RFC4271=20section=205.1.5=20-=20is= 20LOCAL-PREF=0A=20mandatory=20or=20discretionary; X=v=3Dcisco.com=3B=20h=3DFpDo/XzCEaNjELDBEAZKXrJyt88=3D; b=ccLw6lGD39lvvIfW673OSjkcKq8fxAOgmirCt+QYwFXU3ejFYNdFYAw3RefXJ2zxcEc8M/0M Lz6EEJe7FgorCFSQLRm7A/07VMfrdsOCJatpr78dOwDMGYCP3KbBylbi; Authentication-Results: sj-dkim-7.cisco.com; header.From=raszuk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: idr@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: raszuk@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org Hi Gregory, It all depends what you goal here is ... * If you are deep into finding semantical and syntactical specification wording traps resulting in reasons to not implement Local_Pref as a mandatory attribute you may find all possible mismatches between BGP specs and perhaps get away with it. * If on the other hand your goal is to come up with to some extend at least interoperable BGP implementation I would highly recommend to look at section 3.14 of BGP-4 implementation report http://www.ietf.org/rfc/rfc4276.txt where the answer to your question is clear. Local_Pref is send to all IBGP peers and is a mandatory bgp attribute. It is part of best path so while one could assume missing local_pref is equal to def value it is not the case in well known bgp implementations I am aware of. Cheers, R. > Hello everyone, > > I've been working on a BGP implementation which is currently failing a > third-party test that is assuming that the LOCAL-PREF attribute is a > well-known mandatory attribute while the implementation is assuming that > it is discretionary. RFC4271 does not make the definition 100% clear, > especially because in RFC1771 this attribute is described as being > well-known discretionary. > > Section 5.1.5 from RFC4271 states: > > LOCAL_PREF is a well-known attribute that SHALL be included in all > UPDATE messages that a given BGP speaker sends to other internal > peers. A BGP speaker SHALL calculate the degree of preference for > each external route based on the locally-configured policy, and > include the degree of preference when advertising a route to its > internal peers. > > The SHALLs seem to make this fairly clear, however note that it merely > says "well-known attribute". Other attributes, such as ORIGIN say > "well-known mandatory attribute". Also, in the table at the top of page > 25, LOCAL_PREF is listed as being "required" for IBGP, but this is never > actually defined anywhere as to what this means. Again in section 4.3 e) > on page 19, it only says "well-known attribute", whereas on the same > page NEXT_HOP is described as "well-known mandatory" and > ATOMIC_AGGREGATE is described as "well-known discretionary". > > In RFC1771 LOCAL_PREF is defined on pages 15 and 23 as being > "well-known discretionary". > > The current way the implementation works is based on RFC1771, but as > RFC4271 is ambiguous as to how LOCAL_PREF should be handled, I am unsure > as to whether the implementation needs to be changed. > > Currently, if an update message that does not include the LOCAL_PREF > attribute arrives from an iBGP neighbour, the default or > administratively-defined LOCAL_PREF value for the receiving router is > assigned to the advertised route. This seems like a good compromise in > my opinion. The third-party test suite is expecting that in this > situation, the device will return a notification message that incidates > the attribute was not included in the update. > > So, according to RFC4271, is LOCAL_PREF a mandatory attribute, at least > for iBGP peer communication? Is my current approach to the lack of this > attribute in an update sensible and acceptable? > > > Thanks, > Greg > > NOTICE: This message contains privileged and confidential > information intended only for the use of the addressee > named above. If you are not the intended recipient of > this message you are hereby notified that you must not > disseminate, copy or take any action in reliance on it. > If you have received this message in error please > notify Allied Telesis Labs Ltd immediately. > Any views expressed in this message are those of the > individual sender, except where the sender has the > authority to issue and specifically states them to > be the views of Allied Telesis Labs. > > _______________________________________________ > 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 Wed Jul 12 13:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ii0-00016L-Ut; Wed, 12 Jul 2006 13:41:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ihz-00016B-3e for idr@ietf.org; Wed, 12 Jul 2006 13:41:11 -0400 Received: from webmail.tropos.com ([12.108.168.187] helo=iceblock01.tropos.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0ihx-00019F-MV for idr@ietf.org; Wed, 12 Jul 2006 13:41:11 -0400 Received: (qmail 17902 invoked from network); 12 Jul 2006 17:35:42 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on iceblock01 X-Spam-Level: X-Spam-Status: No, score=-104.3 required=6.0 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 Received: from ca-bay-exch-01.tropos.com (192.168.1.49) by iceblock01.tropos.com with SMTP; 12 Jul 2006 17:35:39 -0000 Received: from LIPC ([192.168.1.154]) by ca-bay-exch-01.tropos.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 10:43:44 -0700 From: "Tony Li" To: "'gregory hoggarth'" , Subject: RE: [Idr] Clarification on RFC4271 section 5.1.5 - is LOCAL-PREFmandatory or discretionary Date: Wed, 12 Jul 2006 10:41:02 -0700 Message-ID: <003d01c6a5da$57fbef60$9a01a8c0@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <44B4D861.E0D5.005D.0@alliedtelesyn.co.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcalPybav2SagnYsTjKLnDctcXr6XQAmwHKw X-OriginalArrivalTime: 12 Jul 2006 17:43:44.0507 (UTC) FILETIME=[B89824B0:01C6A5DA] X-Antivirus: Scanned by Tropos Antivirus 1.0.4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tony.li@tony.li List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: idr-bounces@ietf.org IIRC, making LOCAL_PREF mandatory would have implied that LOCAL_PREF appear in EBGP updates. Tony > -----Original Message----- > From: gregory hoggarth [mailto:gregory.hoggarth@alliedtelesyn.co.nz] > Sent: Tuesday, July 11, 2006 4:09 PM > To: idr@ietf.org > Subject: [Idr] Clarification on RFC4271 section 5.1.5 - is > LOCAL-PREFmandatory or discretionary > > Hello everyone, > > I've been working on a BGP implementation which is currently failing a > third-party test that is assuming that the LOCAL-PREF attribute is a > well-known mandatory attribute while the implementation is > assuming that > it is discretionary. RFC4271 does not make the definition 100% clear, > especially because in RFC1771 this attribute is described as being > well-known discretionary. > > Section 5.1.5 from RFC4271 states: > > LOCAL_PREF is a well-known attribute that SHALL be included in all > UPDATE messages that a given BGP speaker sends to other internal > peers. A BGP speaker SHALL calculate the degree of preference for > each external route based on the locally-configured policy, and > include the degree of preference when advertising a route to its > internal peers. > > The SHALLs seem to make this fairly clear, however note that it merely > says "well-known attribute". Other attributes, such as ORIGIN say > "well-known mandatory attribute". Also, in the table at the > top of page > 25, LOCAL_PREF is listed as being "required" for IBGP, but > this is never > actually defined anywhere as to what this means. Again in > section 4.3 e) > on page 19, it only says "well-known attribute", whereas on the same > page NEXT_HOP is described as "well-known mandatory" and > ATOMIC_AGGREGATE is described as "well-known discretionary". > > In RFC1771 LOCAL_PREF is defined on pages 15 and 23 as being > "well-known discretionary". > > The current way the implementation works is based on RFC1771, but as > RFC4271 is ambiguous as to how LOCAL_PREF should be handled, > I am unsure > as to whether the implementation needs to be changed. > > Currently, if an update message that does not include the LOCAL_PREF > attribute arrives from an iBGP neighbour, the default or > administratively-defined LOCAL_PREF value for the receiving router is > assigned to the advertised route. This seems like a good compromise in > my opinion. The third-party test suite is expecting that in this > situation, the device will return a notification message that > incidates > the attribute was not included in the update. > > So, according to RFC4271, is LOCAL_PREF a mandatory > attribute, at least > for iBGP peer communication? Is my current approach to the > lack of this > attribute in an update sensible and acceptable? > > > Thanks, > Greg > > NOTICE: This message contains privileged and confidential > information intended only for the use of the addressee > named above. If you are not the intended recipient of > this message you are hereby notified that you must not > disseminate, copy or take any action in reliance on it. > If you have received this message in error please > notify Allied Telesis Labs Ltd immediately. > Any views expressed in this message are those of the > individual sender, except where the sender has the > authority to issue and specifically states them to > be the views of Allied Telesis Labs. > > _______________________________________________ > 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 Tue Jul 18 09:41:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pp7-0001bE-9J; Tue, 18 Jul 2006 09:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pp5-0001XS-5f for idr@ietf.org; Tue, 18 Jul 2006 09:41:15 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2pp3-0001TX-Ol for idr@ietf.org; Tue, 18 Jul 2006 09:41:15 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k6IDfBX73654 for ; Tue, 18 Jul 2006 06:41:13 -0700 (PDT) (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 k6IDf2g18840 for ; Tue, 18 Jul 2006 06:41:06 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200607181341.k6IDf2g18840@merlot.juniper.net> To: idr@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99549.1153230062.1@juniper.net> Date: Tue, 18 Jul 2006 06:41:02 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [Idr] IDR WG minutes 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, Please review the minutes (attached). If any names have been misspelled, please send me corrections. The deadline for review/corrections is July 25, 2006 Yakov. ------- Forwarded Message Date: Tue, 11 Jul 2006 13:39:29 -0400 From: Dave McDysan To: "'Yakov Rekhter'" Subject: Draft idr Meeting Minutes Yakov - WG/ Document Status Update - See Slides. (To be uploaded to IETF web site?) draft-ietf-idr-rfc258bis-10.txt (Multiprotocol Extensions) Graceful Restart Mechanisms - Implemented, interoperable, need to make edits to satisfy IESG requirements - Loa? - This is holding up MPLS document. - Yakov - Yes, hopefully revision addresses IESG comments. Submitted to IESG: bgp-prefix-orf idr-route-filter No new progress - list of documents ============================================================================ =========================== QoS Support in BGP - Andreas Terzis draft-liang-bgp-qos-00.txt Authors made a few updates to presentation on the IETF web site. Updated presentation to be posted to the IETF web sie after the meeting. Preliminary idea. Reason for presentation is to solicit comments & questions. Zandra pala (?). Is there one set of metrics for each AS? A: Propose a standard set of metrics. Larry Dennison: Set of metrics per AS-Path to tag different latencies and bandwidths. A: QoS metrics need to be updated in the AS as the BGP update message is propagated. Tony Tauber: Update is touched multiple times in the AS? A: Performance needs to be measured. Includes not only inter-domain links, but also the QoS within the domain. QoS metrics can be dynamic (queuing delay) or static (e.g., propagation delay). Initally, the plan is to support static metrics. Would need to extend IGP to support multiple paths across the AS. This has not been addressed yet. In order to force packet to traverse the advertised path MPLS could be used. Sabhi (?): What happens if path goes through route reflector? Normally, a RR does not modify updates? A: Internal components of the QoS metric could be updated by the RR bassed upon configuration. In this approach, the RR would need to update the message. The RR would also need to generate multiple paths. Sabhi (?): What happens if there are multiple links to the upstream AS? A: After DPSA, potentially multiple links would be advertised. Yakov: In order to achieve routing system scalability, a tradeoff is made by losing information. For example, in BGP to lose much of the IGP information at the AS boundaries. These are not trivial questions, which have been attempted to be addressed for the past 15 years. Before getting to specific coding, the abstraction of information should first be considered. Discussion on the mailing list is invited. ------- End of Forwarded Message _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Wed Jul 19 16:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Ium-0005fj-SS; Wed, 19 Jul 2006 16:45:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Iul-0005cS-RA; Wed, 19 Jul 2006 16:45:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3IQk-00007f-Oj; Wed, 19 Jul 2006 16:14:02 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3I3Y-0001uz-KH; Wed, 19 Jul 2006 15:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6JJo19R016811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jul 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G3I3V-0006Gh-V8; Wed, 19 Jul 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Jul 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-13.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 : Graceful Restart Mechanism for BGP Author(s) : S. Sangli, et al. Filename : draft-ietf-idr-restart-13.txt Pages : 11 Date : 2006-7-19 This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-13.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-restart-13.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-restart-13.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: <2006-7-19144910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-restart-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-restart-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-19144910.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 Jul 21 10:20:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrH-0006d7-Nh; Fri, 21 Jul 2006 10:20:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3vrG-0006bj-E6 for idr@ietf.org; Fri, 21 Jul 2006 10:20:02 -0400 Received: from nz-out-0102.google.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3vYx-0003OE-3t for idr@ietf.org; Fri, 21 Jul 2006 10:01:07 -0400 Received: by nz-out-0102.google.com with SMTP id r28so298761nza for ; Fri, 21 Jul 2006 07:01:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B3LxvmPXi04sPDM0OqeeigjxgrDftVO2iFit360L809tQOpyKmC/4xKrfE+EEJ7dlhiEnCkV7dDqwEule5gL4ohpRbDBsYG1pb8V8pb3WVVBwjEdBsTb4ZqxKa8TG9mW3kOgTKs4IA6fJ4XVuo6aWKBKPTA99EBmFD7+0Ej217o= Received: by 10.65.228.5 with SMTP id f5mr716775qbr; Fri, 21 Jul 2006 07:01:06 -0700 (PDT) Received: by 10.36.120.16 with HTTP; Fri, 21 Jul 2006 07:01:06 -0700 (PDT) Message-ID: <92c950310607210701l51a6cf67md73eb6c3eeb35cd7@mail.gmail.com> Date: Fri, 21 Jul 2006 19:31:06 +0530 From: "Glen Kent" To: "Inter-Domain Routing List" Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-restart-13.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 A small nit from Section 4 (when explaining the Restart Flags). The text says "The remaining bits are reserved, and MUST be set to zero by the sender and ignored by the receiver." I prefer to be more strict and would perhaps recommend erroring out if the reserved bits are NOT Zero, as opposed to ignoring them. The same comment goes for the Flags for the address family. Glen On 7/20/06, Internet-Drafts@ietf.org wrote: > 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 : Graceful Restart Mechanism for BGP > Author(s) : S. Sangli, et al. > Filename : draft-ietf-idr-restart-13.txt > Pages : 11 > Date : 2006-7-19 > > This document describes a mechanism for BGP that would help minimize > the negative effects on routing caused by BGP restart. An End-of-RIB > marker is specified and can be used to convey routing convergence > information. A new BGP capability, termed "Graceful Restart > Capability", is defined which would allow a BGP speaker to express > its ability to preserve forwarding state during BGP restart. Finally, > procedures are outlined for temporarily retaining routing information > across a TCP session termination/re-establishment. > > The mechanisms described in this document are applicable to all > routers, both those with the ability to preserve forwarding state > during BGP restart and those without (although the latter need to > implement only a subset of the mechanisms described in this > document). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-13.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-restart-13.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-restart-13.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. > > > > > _______________________________________________ > 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 Jul 21 11:18:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wla-0001wK-5D; Fri, 21 Jul 2006 11:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wlY-0001vC-2c for idr@ietf.org; Fri, 21 Jul 2006 11:18:12 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3wbP-0004FY-BN for idr@ietf.org; Fri, 21 Jul 2006 11:07:44 -0400 Received: from yxu1a16.hopcount.ca ([199.212.90.16]) by monster.hopcount.ca with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G3wbN-0002ON-MZ; Fri, 21 Jul 2006 15:07:42 +0000 In-Reply-To: <92c950310607210701l51a6cf67md73eb6c3eeb35cd7@mail.gmail.com> References: <92c950310607210701l51a6cf67md73eb6c3eeb35cd7@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <02508B09-DBB6-4F6C-A37D-FF36FFA6292E@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-restart-13.txt Date: Fri, 21 Jul 2006 11:07:37 -0400 To: Glen Kent X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Inter-Domain Routing List 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 On 21-Jul-2006, at 10:01, Glen Kent wrote: > A small nit from Section 4 (when explaining the Restart Flags). > > The text says "The remaining bits are reserved, and MUST be set to > zero by the sender and ignored by the receiver." > > I prefer to be more strict and would perhaps recommend erroring out if > the reserved bits are NOT Zero, as opposed to ignoring them. Ignoring them in the receiver allows implementations of some future revision of the spec which makes use of those bits a better chance to interoperate with implementations of this revision. Joe _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Fri Jul 21 15:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G417N-0002C9-DH; Fri, 21 Jul 2006 15:57:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G416d-0001t5-K3; Fri, 21 Jul 2006 15:56:15 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G410c-0001uB-2O; Fri, 21 Jul 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6LJo1p0005446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G410b-00039o-Fl; Fri, 21 Jul 2006 15:50:01 -0400 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, 21 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-prefix-orf-04.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 : Address Prefix Based Outbound Route Filter for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-bgp-prefix-orf-04.txt Pages : 6 Date : 2006-7-21 This document defines a new Outbound Router Filter type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-prefix-orf-04.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-prefix-orf-04.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-prefix-orf-04.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: <2006-7-21105403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-prefix-orf-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-prefix-orf-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-21105403.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 Jul 21 16:57:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G423f-0000GS-W0; Fri, 21 Jul 2006 16:57:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G423e-0000CO-D1; Fri, 21 Jul 2006 16:57:14 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4174-0002x3-Vz; Fri, 21 Jul 2006 15:56:43 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G410c-000556-Ay; Fri, 21 Jul 2006 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6LJo1p0005456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G410b-0003AI-Le; Fri, 21 Jul 2006 15:50:01 -0400 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, 21 Jul 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-route-filter-15.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 : Outbound Route Filtering Capability for BGP-4 Author(s) : E. Chen, Y. Rekhter Filename : draft-ietf-idr-route-filter-15.txt Pages : 11 Date : 2006-7-21 By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-15.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-route-filter-15.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-route-filter-15.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: <2006-7-21130512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-filter-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-filter-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-21130512.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 Jul 21 21:22:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G46CJ-0005l2-Ao; Fri, 21 Jul 2006 21:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G46CI-0005kx-UQ for idr@ietf.org; Fri, 21 Jul 2006 21:22:26 -0400 Received: from nz-out-0102.google.com ([64.233.162.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G46CI-0004H0-JK for idr@ietf.org; Fri, 21 Jul 2006 21:22:26 -0400 Received: by nz-out-0102.google.com with SMTP id r28so342196nza for ; Fri, 21 Jul 2006 18:22:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B0bcyEFH9oeTfIoSlPI5lK2EYEnxbIHNHTE6xbUzy6fvpGypJIlg1aLL/s/LJNbDOxmlFE48crEjRLlVaRxvXVk4S7YL5RFKS3VZ+ELGnEk1ONXOFLYa1NGTQVGOul+LUo7Upu7vso21jZ6W9F20QRA2hpkS25CA0PMrcI1tQzw= Received: by 10.64.84.7 with SMTP id h7mr1510540qbb; Fri, 21 Jul 2006 18:22:26 -0700 (PDT) Received: by 10.36.120.16 with HTTP; Fri, 21 Jul 2006 18:22:26 -0700 (PDT) Message-ID: <92c950310607211822n780d3f3bp8bd09c87e39e1fef@mail.gmail.com> Date: Sat, 22 Jul 2006 06:52:26 +0530 From: "Glen Kent" To: tony.li@tony.li Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-restart-13.txt In-Reply-To: <004701c6ace6$fb8d8810$837d14ac@tropos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92c950310607210701l51a6cf67md73eb6c3eeb35cd7@mail.gmail.com> <004701c6ace6$fb8d8810$837d14ac@tropos.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: Inter-Domain Routing List 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 Very True. I missed this point. Affably, Glen On 7/21/06, Tony Li wrote: > > Glen, > > The current wording is intentional and is a time tested approach for > dealing with reserved fields. Testing their actual content on a > receiver that does not understand the future usage of the reserved bits > makes incremental upgrades problematic. It's far better for > implementations to simply ignore bits that they don't care about. > > Tony > > > > -----Original Message----- > > From: Glen Kent [mailto:glen.kent@gmail.com] > > Sent: Friday, July 21, 2006 7:01 AM > > To: Inter-Domain Routing List > > Subject: Re: [Idr] I-D ACTION:draft-ietf-idr-restart-13.txt > > > > A small nit from Section 4 (when explaining the Restart Flags). > > > > The text says "The remaining bits are reserved, and MUST be set to > > zero by the sender and ignored by the receiver." > > > > I prefer to be more strict and would perhaps recommend erroring out if > > the reserved bits are NOT Zero, as opposed to ignoring them. > > > > The same comment goes for the Flags for the address family. > > > > Glen > > > > On 7/20/06, Internet-Drafts@ietf.org wrote: > > > 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 : Graceful Restart Mechanism for BGP > > > Author(s) : S. Sangli, et al. > > > Filename : draft-ietf-idr-restart-13.txt > > > Pages : 11 > > > Date : 2006-7-19 > > > > > > This document describes a mechanism for BGP that would help minimize > > > the negative effects on routing caused by BGP restart. An End-of-RIB > > > marker is specified and can be used to convey routing convergence > > > information. A new BGP capability, termed "Graceful Restart > > > Capability", is defined which would allow a BGP speaker to express > > > its ability to preserve forwarding state during BGP > > restart. Finally, > > > procedures are outlined for temporarily retaining routing > > information > > > across a TCP session termination/re-establishment. > > > > > > The mechanisms described in this document are applicable to all > > > routers, both those with the ability to preserve forwarding state > > > during BGP restart and those without (although the latter need to > > > implement only a subset of the mechanisms described in this > > > document). > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-13.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-restart-13.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-restart-13.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. > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > > _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr From idr-bounces@ietf.org Sat Jul 22 08:24:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4GWH-00070c-J3; Sat, 22 Jul 2006 08:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4GWF-00070U-Up; Sat, 22 Jul 2006 08:23:43 -0400 Received: from mail1.tieto.com ([194.110.47.24] helo=datnt07.tieto.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4GWD-0002QA-Ou; Sat, 22 Jul 2006 08:23:43 -0400 Received: from camaro.eu.tieto.com ([192.176.143.43]) by datnt07.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 22 Jul 2006 15:23:11 +0300 Received: from mail pickup service by camaro.eu.tieto.com with Microsoft SMTPSVC; Sat, 22 Jul 2006 13:54:36 +0200 Received: from veyron.eu.tieto.com ([194.110.47.230]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 21:59:06 +0200 Received: from viper.eu.tieto.com ([194.110.47.167]) by veyron.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 22:59:04 +0300 Received: from ebb03.tieto.com ([194.142.141.100]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 22:59:04 +0300 Received: from megatron.ietf.org ([156.154.16.145]) by ebb03.tieto.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 22:59:04 +0300 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G417O-0002CE-Lj; Fri, 21 Jul 2006 15:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G416d-0001t5-K3; Fri, 21 Jul 2006 15:56:15 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G410c-0001uB-2O; Fri, 21 Jul 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k6LJo1p0005446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jul 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G410b-00039o-Fl; Fri, 21 Jul 2006 15:50:01 -0400 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, 21 Jul 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 21 Jul 2006 19:59:04.0791 (UTC) FILETIME=[1E60E670:01C6AD00] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: idr@ietf.org Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-prefix-orf-04.txt X-BeenThere: idr@ietf.org Reply-To: internet-drafts@ietf.org 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 : Address Prefix Based Outbound Route Filter for BGP-4 Author(s) : E. Chen, S. Sangli Filename : draft-ietf-idr-bgp-prefix-orf-04.txt Pages : 6 Date : 2006-7-21 This document defines a new Outbound Router Filter type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-prefix-orf-04.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-prefix-orf-04.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-prefix-orf-04.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: <2006-7-21105403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-prefix-orf-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-prefix-orf-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-21105403.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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--