http://blog.gmane.org/gmane.ietf.idr hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.idr/9175 <pre> 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 : North-Bound Distribution of Link-State and TE Information using BGP Author(s) : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-03.txt Pages : 43 Date : 2013-05-21 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networ</pre> internet-drafts< at >ietf.org 2013-05-21T09:41:47 http://comments.gmane.org/gmane.ietf.idr/9174 <pre> 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 : Assigned BGP extended communities Author(s) : Bruno Decraene Pierre Francois Filename : draft-ietf-idr-reserved-extended-communities-05.txt Pages : 6 Date : 2013-05-21 Abstract: This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. The IETF datatracker status page for this draft is: https://datatra</pre> internet-drafts< at >ietf.org 2013-05-21T08:42:48 http://comments.gmane.org/gmane.ietf.idr/9169 <pre> 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 : BGP Custom Decision Process Author(s) : Alvaro Retana Russ White Filename : draft-ietf-idr-custom-decision-03.txt Pages : 8 Date : 2013-05-20 Abstract: The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a loca</pre> internet-drafts< at >ietf.org 2013-05-20T18:47:08 http://comments.gmane.org/gmane.ietf.idr/9167 <pre> IDR - During the private asn draft process, several times it was recommended that proper documentation of the EXISTING reservations for 65535 and 4294967295 be done, so have posted a draft to try and rectify that. Wanted to get some initial feedback on this draft and add any additional reasoning the group has for these reservations before asking for WG acceptance. Thanks, Jon A new version of I-D, draft-jhjm-idr-last-as-reservations-00.txt has been successfully submitted by Jeffrey Haas and posted to the IETF repository. Filename: draft-jhjm-idr-last-as-reservations Revision: 00 Title: Last Autonomous System (AS) Reservations Creation date: 2013-05-16 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-jhjm-idr-last-as-reservations-00.txt Status: http://datatracker.ietf.org/doc/draft-jhjm-idr-last-as-reservations Htmlized: http://tools.ietf.org/html/draft-jhjm-idr-last-as-reservations-00 Abstract: This document reserves two Autonomous System numbe</pre> Jon Mitchell 2013-05-20T13:02:13 http://comments.gmane.org/gmane.ietf.idr/9166 <pre>A new Request for Comments is now available in online RFC libraries. RFC 6938 Title: Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID Author: J. Scudder Status: Standards Track Stream: IETF Date: May 2013 Mailbox: jgs&lt; at &gt;juniper.net Pages: 3 Characters: 3875 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idr-deprecate-dpa-etal-00.txt URL: http://www.rfc-editor.org/rfc/rfc6938.txt This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC. This document is a product of the Inter-Domain Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion </pre> rfc-editor< at >rfc-editor.org 2013-05-14T21:12:06 http://comments.gmane.org/gmane.ietf.idr/9165 <pre> Hi, Reading RFC5575, I have one question regarding "6-byte Route Target" value of redirect ext-comm. Are we assuming one particular RT type? Or should we consider all possible types (0x0002, 0x0102, 0x0202) with the 6-byte RT value? Thanks, Hyojeong _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> Hyojeong Kim (hyojekim 2013-05-03T22:31:25 http://comments.gmane.org/gmane.ietf.idr/9164 <pre>The following errata report has been submitted for RFC5575, "Dissemination of Flow Specification Rules". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5575&amp;eid=3610 -------------------------------------- Type: Editorial Reported by: Sergey Antipov &lt;sergey.antipov&lt; at &gt;nsn.com&gt; Section: 4 Original Text ------------- If a given component type within a prefix in unknown, the prefix in question cannot be used for traffic filtering purposes by the receiver. Since a flow specification has the semantics of a logical AND of all components, if a component is FALSE, by definition it cannot be applied. However, for the purposes of BGP route propagation, this prefix should still be transmitted since BGP route distribution is independent on NLRI semantics. Corrected Text -------------- If a given component type within a prefix is unknown, the prefix in question cannot be used for traffic filtering purposes by the</pre> RFC Errata System 2013-04-30T21:13:36 http://comments.gmane.org/gmane.ietf.idr/9163 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:55:27 http://comments.gmane.org/gmane.ietf.idr/9162 <pre> 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 : Notification Message support for BGP Graceful Restart Author(s) : Keyur Patel Rex Fernando John Scudder Jeff Haas Filename : draft-ietf-idr-bgp-gr-notification-01.txt Pages : 7 Date : 2013-04-25 Abstract: The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a G</pre> internet-drafts< at >ietf.org 2013-04-25T19:35:09 http://comments.gmane.org/gmane.ietf.idr/9161 <pre> 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 : Autonomous System (AS) Reservation for Private Use Author(s) : Jon Mitchell Filename : draft-ietf-idr-as-private-reservation-04.txt Pages : 4 Date : 2013-04-12 Abstract: This document describes the reservation of Autonomous System numbers (ASNs) that are for Private Use only and MUST NOT be advertised to the Internet, known as Private Use ASNs. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-04 A diff from the previ</pre> internet-drafts< at >ietf.org 2013-04-12T21:07:46 http://comments.gmane.org/gmane.ietf.idr/9143 <pre>Hi all, Network latency is widely recognized as one of major obstacles in adopting public cloud services (e.g., cloud desktop service) especially in the scenario where the network path between cloud end-users and cloud data centers may traverse multiple Autonomous Systems (ASes). However, the current Border Gateway Protocol (BGP) specification [RFC4271] doesn't take the network latency into account for the best route selection. In other words, the best route selected according to the existing BGP route selection criteria may not be the best from the end-user experience perspective. How about allowing BGP peers to exchange Network Path Latency as an additional path attribute of the Network Layer Reachability Information (NLRI) and then take it as one of route selection criteria? To avoid BGP route flapping issue caused by network latency frequent change, the network latency could only reflect the line transport latency by neglecting the latency occurred within routers. To make the performance routing paradi</pre> Xuxiaohu 2013-04-07T08:11:17 http://comments.gmane.org/gmane.ietf.idr/9142 <pre>Minutes from our last meeting are at http://www.ietf.org/proceedings/86/minutes/minutes-86-idr Please send any corrections. Thanks, --John _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> John Scudder 2013-03-27T21:49:28 http://comments.gmane.org/gmane.ietf.idr/9128 <pre>Dear all, I write this e-mail for you because I knew you were working in draft http://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selection-criteria/ and the technology group I work in is very interested in these kinds of features as we consider them an important improvement when selecting next-hops that will become eligible, removing those that do not meet needed rules to become a best path. Let me explain some historical data about our network: - Since 2001, the main vendor deployed in our network has been Juniper (close to 95% of routers) and the another 5% were Cisco 7600 acting as PE routers. But from last year, Cisco CRS-3 (in the core) and ASR9000 (in the edge) are being deployed, allowing this vendor to increase its presence in our network at the expense of Juniper. - Historically, Juniper routers have developed mechanisms to check if next-hops are valid, and if so they become as "eligible" as a previous step to become the "best". If they are not valid they beco</pre> Antonio Huete 2013-03-12T22:10:56 http://comments.gmane.org/gmane.ietf.idr/9109 <pre> 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 : Automatic Route Target Filtering for legacy PEs Author(s) : Pradosh Mohapatra Arjun Sreekantiah Keyur Patel Burjiz Pithawala Alton Lo Filename : draft-ietf-idr-legacy-rtc-01.txt Pages : 9 Date : 2013-03-13 Abstract: This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-legacy-rtc There's also a htmlized version available at: ht</pre> internet-drafts< at >ietf.org 2013-03-13T18:37:59 http://comments.gmane.org/gmane.ietf.idr/9108 <pre>In parallel to the call for adoption I'd like to encourage discussion on the following, in hopes of moving this through the rest of the process as fast as possible -- 1. There appears to me to be a consensus that we should set the low attribute flag bits to be zero at all times. (Basically, declare them to be "toxic" and sanitize them aggressively.) The show of hands at today's in-person meeting (and on Jabber) seemed to confirm this. Q: Does the WG agree? In particular, if you don't agree, please speak up. 2. Must-be-zero is what the current (-01) version of the draft says, or intends to say. There's also the question of whether -01 says it in the most useful, unambiguous way. There is probably room for improvement. Q: Please send text! Thanks, --John_______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> John G. Scudder 2013-03-13T17:43:13 http://comments.gmane.org/gmane.ietf.idr/9103 <pre>Folks, The authors (i.e., Sue and me) have requested IDR adopt draft-hares-idr-update-attrib-low-bits-fix-01 as a working group document. Please send any comments to the list by March 27. Thanks, --John &amp; Sue _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> John Scudder 2013-03-13T17:43:11 http://comments.gmane.org/gmane.ietf.idr/9100 <pre>Hi, For some reason IDR slides are not posted even just few hours to the actual session ... http://tools.ietf.org/wg/idr/agenda?item=agenda-86-idr.html http://tools.ietf.org/wg/idr/agenda does not contain any pointer to the pdf/ppt (to be presented) slides. Other working groups chairs at the same time slot did much better well in advance ... Examples just to check out very few: http://tools.ietf.org/wg/nvo3/agenda http://tools.ietf.org/wg/softwire/agenda http://tools.ietf.org/wg/dime/agenda http://tools.ietf.org/wg/jose/agenda http://tools.ietf.org/wg/multimob/agenda http://tools.ietf.org/wg/siprec/agenda and pretty much all others .. IDR is also not subscribed to Meetecho nor IETF webex: - http://ietf86.conf.meetecho.com/ - http://www.ietf.org/meeting/86/remote-participation.html This is very bad for anyone with cultural diversity who would like to follow this WG remotely from any continent including even west coast of US. I hope chairs of this WG (I am not sure who was the one responsible &lt; at &gt; this </pre> Robert Raszuk 2013-03-13T07:52:25 http://comments.gmane.org/gmane.ietf.idr/9099 <pre> In preparation for WG last call of this draft, our L2VPN chairs have asked us to solicit comments on the BGP section of this document (section 8). http://www.ietf.org/id/draft-ietf-l2vpn-evpn-03.txt Please kindly review this draft and post your comments by Friday March/29. Thanks, Ali _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> Ali Sajassi (sajassi 2013-03-12T14:53:51 http://comments.gmane.org/gmane.ietf.idr/9096 <pre>(+idr mailing list in the hope of finding more carriers) This question is specifically whether a Network Control (CS6) interconnect traffic class is needed in addition to a Priority (EF) traffic class for effective support of BGP traffic across carrier network interconnections. The slide that Sue is referring to takes the position (for discussion) that it is not needed: http://www.ietf.org/proceedings/86/slides/slides-86-tsvwg-5.pptx Easy does it on the dead cats and rotten tomatoes, please ... Thanks, --David (tsvwg co-chair) From: tsvwg-bounces&lt; at &gt;ietf.org [mailto:tsvwg-bounces&lt; at &gt;ietf.org] On Behalf Of Susan Hares Sent: Monday, March 11, 2013 5:14 PM To: tsvwg&lt; at &gt;ietf.org Subject: [tsvwg] draft-geib-tsvwg-diffserv-intercon-02.txt - does BGP need To follow-up on the proposal in the RFC5127 changes proposed in the draft draft-geib-tswf-diffserv-intercon-02.txt, I ask do the carriers need the RFC5127 network control (CS6 DSCP) to run BGP? Sue Hares _______________________________________________ Idr mailing</pre> Black, David 2013-03-11T22:56:27 http://comments.gmane.org/gmane.ietf.idr/9095 <pre> 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 : Making Route Flap Damping Usable Author(s) : Cristel Pelsser Randy Bush Keyur Patel Pradosh Mohapatra Olaf Maennel Filename : draft-ietf-idr-rfd-usable-02.txt Pages : 7 Date : 2013-03-11 Abstract: Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount </pre> internet-drafts< at >ietf.org 2013-03-11T17:04:20 http://comments.gmane.org/gmane.ietf.idr/9094 <pre>The IESG has approved the following document: - 'Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID' (draft-ietf-idr-deprecate-dpa-etal-00.txt) as Proposed Standard This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ Technical Summary This document requests IANA to deprecate the BGP path attributes DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet Draft and a Historic RFC, respectively. Note that CLUSTER_ID is not the same as, and should not be confused with, CLUSTER_LIST. Working Group Summary Consensus was clear and there was no dissent. This is not surprising considering the draft is very short (substantive content: six sentences). The chairs did take the unusual step of running adoption and WGLC in parallel, with the proviso that if there was any</pre> The IESG 2013-03-11T14:08:27 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.idr