http://permalink.gmane.org/gmane.ietf.idr hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.idr/9168 <pre> Also, to seed/head off some of the discussion, the justifications in the draft are easy to see as thin in some cases. IMO, we're looking for something that will look historically reasonable but beyond that IANA would rather just have something that says "this doc says they're reserved". Matter of fact, we could simply publish the document and say "they're reserved" and be done with it. Historically, 65535 had been problematic for some implementations. Most of the reason for this to have been problematic was simply bad code and the correspondence of the value with UINT16_MAX/-1 signed int16. One would hope that all such bugs have been banished from the Internet by now. :-) The extension of such thin reasoning to UINT32_MAX is less because bugs have been observed using this value and more from the (these days) typical process of tending to reserve the top and/or bottom code points as magic values for "future extensions". Sometimes such values are never used, sometimes they are. It is, of course, the WG</pre> Jeffrey Haas 2013-05-20T14:32:28 http://permalink.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://permalink.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://permalink.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://permalink.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://permalink.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://permalink.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://permalink.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://permalink.gmane.org/gmane.ietf.idr/9160 <pre> As an alternative to inter-AS TE, one could use BGP-over-TE LSP tunnels (i.e., BGP-signaled LSP over RSVP-TE LSP) in a much scalable way. One application example of such LSP tunnel is inter-AS MPLS-based VPN solution option C (i.e., VPN Label over BGP Label over TE Label). As such, when deploying this performance-based BGP routing mechanism across multiple AS’s which are within a single administrative domain, it’s RECOMMENTED to deliver a packet from a BGP speaker to the BGP NEXT_HOP with each AS via tunnels, especially TE LSP tunnels. Furthermore, it’s strongly RECOMMENDED to use the latency metric carried in Unidirectional Link Delay Sub-TLV [OSPF-TE-EXT] [ISIS-TE-EXT] if possible, rather than the TE metric [RFC3630] [RFC5305] or IGP metric to perform the C-SPF calculation, unless the TE metric or the IGP metric has already been set to the link latency metric. In this way, it would avoid the need for timely measurement of end-to-end latency between IBGP peers by some means. Furthermore, thi</pre> Xuxiaohu 2013-04-12T09:24:08 http://permalink.gmane.org/gmane.ietf.idr/9159 <pre>Hi Xuxiaohu, How does it help to do that on a "limited network scope" ? Customers are even local to ISP (single AS or multi ASes - where AIGP can be used) and then ISP can do whatever they like to please their customers or customers applications cross inter-provider boundary and then you are our of luck. So I guess what you are hearing is that doing it on "limited network scope" is as good as not doing it at all. Again Akamai has it's own overlay they use .. completely different service then hops of ISPs which often fight for the same customers. Rgs, R. _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> Robert Raszuk 2013-04-10T04:20:25 http://permalink.gmane.org/gmane.ietf.idr/9158 <pre> Hi Eric, Thanks a lot for your valuable comments in advance. Akamai Sureroute (http://www.akamai.com/dl/feature_sheets/fs_edgesuite_sureroute.pdf) is a good example that performance-based routing has its buyers. However, Akamai Sureroute is an overlay based approach, and therefore those alternative paths between Akamai edge servers selected based upon Sureroute is still not optimal enough from performance perspective since it could not influence the path selection between any pair of its edge servers, unless the density of its edge servers is large enough, e.g., each physical router in the network is attached with an Akamai edge server to an extreme extent. Why couldn't ISPs who have the full control of their physical network resources do something like what Akamai Sureroute has done, even only in a limited network scope or only for their key customers? By doing so, it would not increase their routing load significantly since there is no need to execute performance-based routing for all BGP pref</pre> Xuxiaohu 2013-04-10T02:20:25 http://permalink.gmane.org/gmane.ietf.idr/9157 <pre> As others have pointed out, using the "least latency" network path does not necessarily remove network latency as an obstacle to adopting this sort of application. But for cases where least latency routing through a set of ASes is desired, AIGP would seem to work perfectly well as long as the metric is agreed. (Though such agreement, as others have pointed out, is highly unlikely among an arbitrary set of SPs.) It could be used to convey any other metric that is agreed upon. If you did something like this, you could attach AIGP to the "performance routes" and not to the "vanilla routes". However, ISPs all around the world are unlikely to increase their routing load so that some particular ISP's customers can reduce their latencies a little bit. _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> Eric Rosen 2013-04-09T14:52:53 http://permalink.gmane.org/gmane.ietf.idr/9156 <pre> It's great to hear that you are actually using that approach in your production network . In fact, we had ever implemented that feature in our router product before by modifying the current BGP standard behaviors as follows: 1) allow the MED to carry the IGP cost which is set to latency metric; 2) allow the MED value to be cumulated; 3) modify the route selection process to compare the MED anyway, no matter the received routes are from the same neighboring AS, and no matter the routes are IBGP or EBGP routes; 4) perform the MED ahead of LOCAL_PREF and AS_PATH length. Unfortunately, feedbacks from a few of our customers show that this modification destroys the vanilla routing paradigm (especially collide with the current MED standard usage as shown below) which is still useful for them. That's why I proposed here to keep the performance-based routing paradigm and vanilla routing paradigm to be able to coexist by using separate SAFI codes. " MULTI_EXIT_DISC is only comparable betwe</pre> Xuxiaohu 2013-04-09T11:27:24 http://permalink.gmane.org/gmane.ietf.idr/9155 <pre>inter-AS TE In our (multi-AS) network latency-based routing is already built into current network architecture (through IGP cost and BGP MED). My feeling is that this is also the case for most other networks (possibly also using AIGP). It's rather not trivial to imagine a case where (IGP, MED, AIGP) would not suffice. And where it would not suffice quite likely only few TE tunnels could complete the solution. Or do you have a practical (rather than theoretical) case where this would not hold? It will get hairy for sure. But is the problem actually there and worth the effort? a That was just an example, and RSVP was mentioned to emphasize the issue - today nobody lets foreign traffic to request resources, so why would that be different with latency-based routing? Kind regards, iLya _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> Ilya Varlashkin 2013-04-09T10:05:10 http://permalink.gmane.org/gmane.ietf.idr/9154 <pre> Yes, inter-AS TE is an alternative way. However, the scalability of inter-AS TE may become a big concern once the amount of TE LSPs is very large. Agree that these issues need further considerations. AFAIK, end-to-end RSVP is not practical anymore in today's large-scale networks. Best regards, Xiaohu _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> Xuxiaohu 2013-04-09T06:52:02 http://permalink.gmane.org/gmane.ietf.idr/9153 <pre> that would be easy. but what it implies is that ALL ASs must have the SAME consistent metric space, which is what i think you meant. and cash should fall from the sky. randy _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> Randy Bush 2013-04-08T23:22:48 http://permalink.gmane.org/gmane.ietf.idr/9152 <pre>Hi, besides what others have already said, there are some more things to take into account. First, if all involved AS's are under single administration we can resort to MPLS-TE (including offline tunnel management). From this perspective latency-based routing becomes unnecessary because we can do much more with TE. Second, if one or more AS's are NOT under single administration, then latency information in BGP becomes irrelevant because chances are nobody is going to trust it. Not only somebody can advertise junk values, but if somebody uses per-class MPLS-TE forwarding then there is no guarantee that advertised BGP latency is the same for all traffic. Third, the problem you're trying to solve is essentially "to build latency-based path between end-points (client-server)". This seems more work for something like RSVP or call-admission-control and not for a routing protocol. Cheers, iLya On Apr 7, 2013, at 10:11 , Xuxiaohu wrote: /iLya _______________________________________________ Idr mailing lis</pre> Ilya Varlashkin 2013-04-08T21:49:33 http://permalink.gmane.org/gmane.ietf.idr/9151 <pre>If there are multiple AS domains under one over-arching authority or a model where there may be many AS domains riding atop the same IGP and services span these AS domains a consistent approach to IGP cost metric is required.. I am not sure of the use case described by Xuxiaohu.. Jim Uttaro From: christopher.morrow&lt; at &gt;gmail.com [mailto:christopher.morrow&lt; at &gt;gmail.com] On Behalf Of Christopher Morrow Sent: Monday, April 08, 2013 3:58 PM To: UTTARO, JAMES Cc: Xuxiaohu; idr&lt; at &gt;ietf.org Subject: Re: [Idr] Performance-based BGP Routing Mechanism On Mon, Apr 8, 2013 at 2:47 PM, UTTARO, JAMES &lt;ju1738&lt; at &gt;att.com&lt;mailto:ju1738&lt; at &gt;att.com&gt;&gt; wrote: Not sure I understand.. You state " How about allowing BGP peers to exchange Network Path Latency as an Doesn't this imply that each AS must use a consistent approach to evaluating the latency information being carried? clearly this will work out well in the real world... _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/list</pre> UTTARO, JAMES 2013-04-08T21:21:41 http://permalink.gmane.org/gmane.ietf.idr/9150 <pre>While latency may be an obstacle to cloud desktop services, BGP is very likely not the place to address that. Consider what you are trying to achieve - are you trying to use the same IP subnet in multiple places ("anycast"), or do you want each location to be independently operated and addressed? Latency is probably much better used as a discriminator, at a higher level than BGP. For instance, "global server load balancers" are pretty much designed for this use case, and can operate independent of what is behind the GSLB, number of locations, etc. Or, client-server applications dedicated to the "cloud desktop" instance, may be better suited to handling all the specific needs, especially for the desktop-specific particulars. Otherwise, you are likely to end up with "yet another VPN over BGP", with all the baggage that goes with it. (The main goal of BGP is interoperability, and multiple non-interoperable VPN frameworks sitting on top of BGP are the antithesis of exactly that interoperability.) But, that</pre> Dickson, Brian 2013-04-08T20:00:12 http://permalink.gmane.org/gmane.ietf.idr/9149 <pre> clearly this will work out well in the real world... _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/idr </pre> Christopher Morrow 2013-04-08T19:57:57 http://permalink.gmane.org/gmane.ietf.idr/9148 <pre>Not sure I understand.. You state " How about allowing BGP peers to exchange Network Path Latency as an Doesn't this imply that each AS must use a consistent approach to evaluating the latency information being carried? Jim Uttaro -----Original Message----- From: idr-bounces&lt; at &gt;ietf.org [mailto:idr-bounces&lt; at &gt;ietf.org] On Behalf Of Xuxiaohu Sent: Sunday, April 07, 2013 11:10 PM To: UTTARO, JAMES; idr&lt; at &gt;ietf.org Subject: Re: [Idr] Performance-based BGP Routing Mechanism [Xiaohu] Thanks a lot for your advice. Yes, it's safer and easier to deploy such technology across multiple AS domains if these ASes are under a single administrative authority. Otherwise, those ASes need to reach an agreement on this usage. By using BGP capability negotiation mechanism for such performance routing specific SAFI, it may be helpful to leverage the deployment of such technology. Best regards, Xiaohu _______________________________________________ Idr mailing list Idr&lt; at &gt;ietf.org https://www.ietf.org/ma</pre> UTTARO, JAMES 2013-04-08T18:47:18 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.idr