[GROW] Protocol Action: 'Revision to Registration Procedures for Multiple BMP Registries' to Proposed Standard (draft-ietf-grow-bmp-registries-change-04.txt)
The IESG has approved the following document: - 'Revision to Registration Procedures for Multiple BMP Registries' (draft-ietf-grow-bmp-registries-change-04.txt) as Proposed Standard This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-registries-change/ Technical Summary This document updates RFC 7854, BGP Monitoring Protocol (BMP) by making a change to the registration procedures for several registries. Specifically, any BMP registry with a range of 32768-65530 designated "Specification Required" has that range re- designated as "First Come First Served". Working Group Summary This is a very simple document - it simply changes the registration procedures for several registries. Document Quality The document is 3 pages (including boilerplate). It simply changes registration procedures from "Specification Required" to "First Come First Served" for high ranges in some BMP registries. While possible, it would be hard to write this poorly -- and didn't occur here... Personnel Job Snijders is DS. Warren "Ace" Kumari is RAD (and still finds this joke funny...) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Revision to Registration Procedures for Multiple BMP Registries) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Revision to Registration Procedures for Multiple BMP Registries' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-10-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 7854, BGP Monitoring Protocol (BMP) by making a change to the registration procedures for several registries. Specifically, any BMP registry with a range of 32768-65530 designated "Specification Required" has that range re- designated as "First Come First Served". The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-registries-change/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Protocol Action: 'Support for Local RIB in BGP Monitoring Protocol (BMP)' to Proposed Standard (draft-ietf-grow-bmp-local-rib-12.txt)
The IESG has approved the following document: - 'Support for Local RIB in BGP Monitoring Protocol (BMP)' (draft-ietf-grow-bmp-local-rib-12.txt) as Proposed Standard This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/ Technical Summary The BGP Monitoring Protocol (BMP) defines access to various Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. Working Group Summary There was some discussion on what exactly constitutes the Loc-RIB, various vendors have slightly different interpretations of this abstract concept. This has been resolved in Section 3 (“definitions”) which clarifies the contents of the Loc-RIB as received via the BMP protocol potentially are different from what is stored on a BGP node in its local interpretation of Loc-RIB. Document Quality BMP Local RIB has been implemented on the receiver side in Pmacct and OpenBMP, both are widely deployed collectors. On the BMP export side Cisco, Huawei, and Juniper implemented support for Loc-RIB. This indicates broad support and a need for standardization. Personnel Warren Kumari is RAD! Job Snijders is the document shepherd. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Support for Local RIB in BGP Monitoring Protocol (BMP)) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Support for Local RIB in BGP Monitoring Protocol (BMP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-03-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The BGP Monitoring Protocol (BMP) defines access to various Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-local-rib/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Protocol Action: 'Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)' to Proposed Standard (draft-ietf-grow-bmp-adj-rib-out-07.txt)
The IESG has approved the following document: - 'Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)' (draft-ietf-grow-bmp-adj-rib-out-07.txt) as Proposed Standard This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ Technical Summary The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB- In Routing Information Bases (RIBs). This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB- Out RIBs. It adds a new flag to the peer header to distinguish Adj- RIB-In and Adj-RIB-Out. Working Group Summary The document went through several revisions and extensive review at WGLC to include comments/suggestions/changes. The conversation in the WG mail-list and meetings was robust. Document Quality The document is in good shape, there are no nits of consequence in the document. The content is clear and concise. Personnel chris morrow (morr...@ops-netman.net) is Document Shepherd warren kumari (war...@kumari.net) is RAD! ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Protocol Action: 'Well-Known Community Policy Behavior' to Proposed Standard (draft-ietf-grow-wkc-behavior-08.txt)
The IESG has approved the following document: - 'Well-Known Community Policy Behavior' (draft-ietf-grow-wkc-behavior-08.txt) as Proposed Standard This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ Technical Summary Popular BGP implementations manipulate Well-known Communities differently from one another. This results in difficulties for operators. Network operators are encouraged to deploy consistent community handling across their networks, taking the inconsistent behaviors from the various BGP implementations they operate into consideration. This document recommends specific action items to limit future inconsistency, namely BGP implementors are expected to not create any further inconsistencies from this point forward. Working Group Summary Over the course of multiple months a fair representation of the GROW working group community reviewed this document before and during WGLC. There was active discussion and consensus that the documented inconsistency is an operational issue. While there was no controversy, there was decent discussion on how to rigidly and precisely formulate the normative paragraphs to maybe prevent more inconsistent behaviour in implementations. Consensus was solid. Document Quality The document is clear and well written - it describes how different implementations behave, and how to prevent this issue going forward. Personnel Job Snijders is the document shepherd and GROW working group chair. Warren Kumari is the responsible Area Director. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-06-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB- In Routing Information Bases (RIBs). This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB- Out RIBs. It adds a new flag to the peer header to distinguish Adj- RIB-In and Adj-RIB-Out. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Well-Known Community Policy Behavior) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Well-Known Community Policy Behavior' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2019-05-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Well-Known BGP Communities are manipulated inconsistently by current implementations. This results in difficulties for operators. Network operators are encouraged to deploy consistent community handling across their networks, taking the inconsistent behaviors from the various BGP implementations they operate into consideration. Also, BGP implementors are expected to not create any further inconsistencies from this point forward. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Protocol Action: 'Graceful BGP session shutdown' to Proposed Standard (draft-ietf-grow-bgp-gshut-13.txt)
The IESG has approved the following document: - 'Graceful BGP session shutdown' (draft-ietf-grow-bgp-gshut-13.txt) as Proposed Standard This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/ Technical Summary This draft standardizes a new well-known BGP community GRACEFUL_SHUTDOWN to signal the graceful shutdown of paths. This draft also describes operational procedures which use this community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g. for planned maintenance. Working Group Summary This document spent a long time in WG (10 years or so), with progress early on, then awaiting other work to finish, and finally a last surge of call/response/fixes and now we have consensus. Document Quality There are existing platforms which respect the draft community, the document got some last minute cleanup / reorg and is in good shape today. Personnel Shepherd: Christopher Morrow Responsible AD: Warren Kumari ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Graceful BGP session shutdown) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Graceful BGP session shutdown' as Proposed Standard This is a second IETF Last Call. The document had an initial LC as an Informational document, but the IESG felt it was more appropriate to be Standards Track. As the Last Call time will run into the end of the year holiday period, we are requesting a 4-week Last Call. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2018-01-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft standardizes a new well-known BGP community GRACEFUL_SHUTDOWN to signal the graceful shutdown of paths. This draft also describes operational procedures which use this community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g. for planned maintenance. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6198: Requirements for the Graceful Shutdown of BGP Sessions (Informational - IETF stream) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Protocol Action: 'Mitigating Negative Impact of Maintenance through BGP Session Culling' to Best Current Practice (draft-ietf-grow-bgp-session-culling-05.txt)
The IESG has approved the following document: - 'Mitigating Negative Impact of Maintenance through BGP Session Culling' (draft-ietf-grow-bgp-session-culling-05.txt) as Best Current Practice This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-session-culling/ Technical Summary This document outlines an approach to mitigate negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions affected by the maintenance are forcefully torn down before the actual maintenance activities commence. Basically, this suggests tearing down the BGP session (so it can reconverge) before breaking the data-plane. This is documenting a well known, and widely used (but not widely enough!) technique. Working Group Summary Nothing of note in the WG process. Document Quality This is documenting (with examples!) how to perform a operational practice which minimizes breakage. It is a simple, but effective technique. Personnel Shepherd: Chris Morrow (christopher.mor...@gmail.com) Responsible AD: Warren Kumari (war...@kumari.net) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Graceful BGP session shutdown) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Graceful BGP session shutdown' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-10-11. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft standardizes a new well-known BGP community GRACEFUL_SHUTDOWN to signal the graceful shutdown of paths. This draft also describes operational procedures which use this community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g. for planned maintenance. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Mitigating Negative Impact of Maintenance through BGP Session Culling) to Best Current Practice
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Mitigating Negative Impact of Maintenance through BGP Session Culling' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-09-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document outlines an approach to mitigate negative impact on networks resulting from maintenance activities. It includes guidance for both IP networks and Internet Exchange Points (IXPs). The approach is to ensure BGP-4 sessions affected by the maintenance are forcefully torn down before the actual maintenance activities commence. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-session-culling/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-session-culling/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4271: A Border Gateway Protocol 4 (BGP-4) (Draft Standard - IETF stream) ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Protocol Action: 'Default EBGP Route Propagation Behavior Without Policies' to Proposed Standard (draft-ietf-grow-bgp-reject-08.txt)
The IESG has approved the following document: - 'Default EBGP Route Propagation Behavior Without Policies' (draft-ietf-grow-bgp-reject-08.txt) as Proposed Standard This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/ Technical Summary This document defines the default behavior of a BGP speaker when there is no import or export policy associated with an External BGP session. Working Group Summary This document describes a change in default (or a standardization of a default) behavior; no changes in protocols expected. Basically this says that implementations MUST consider a deny-all policy if nothing is explicitly configured / act as though the peer is not fully configured until policy is applied. Document Quality Cisco IOS-XR already has this as the default behavior. Nokia is planning on making this the default. Patches have been submitted to various open-source implementations. This document is a product of the GROW WG. During the IETF LC, Alvaro Retana (RTG AD) noted that this could be interpreted as updating RFC4271, and so IDR should be explicitly included in the LC. IDR was notified, and the IETF LC extended to allow for additional review. A significant discussion (~200 email) then occurred on the IDR list. John Scudder (one of the IDR chairs) provided a useful summary here: https://www.ietf.org/mail-archive/web/idr/current/msg18093.html - this summary confirmed Warren Kumari (OpsAD)'s judgment of consensus (and double-checked by Alvaro, IDR / BESS AD). The authors have updated the document in response to the discussions; Updates: 4271 (if approved), includes a Transition Considerations appendix, has an improved Security Considerations section and multiple other edits. The authors are very grateful for the energy that was invested in making the document a success, and view the changes as improving the document. Personnel Document Shepherd: christopher.mor...@gmail.com Responsible Area Director: war...@kumari.net ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Document Action: 'Use of BGP Large Communities' to Informational RFC (draft-ietf-grow-large-communities-usage-07.txt)
The IESG has approved the following document: - 'Use of BGP Large Communities' (draft-ietf-grow-large-communities-usage-07.txt) as Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-large-communities-usage/ Technical Summary This document presents examples and inspiration for operator's application of BGP Large Communities. Based on operational experience with BGP Communities, this document suggests logical categories of BGP Large Communities and demonstrates an orderly manner of organizing community values within them to achieve typical goals in routing policy. Any operator can consider using the concepts presented as the basis for their own BGP Large Communities repertoire. Working Group Summary Document did not generate a huge amount of discussion, but that is likely because it is simply examples of what can be done with BGP Large Communities, and how operators might choose to deploy / use them. Document Quality Document is clear and well written. It received discussion and review in the WG, and additional feedback (incorporated) during LC / directorate review. This document provides examples and concepts on how operators might choose to layout / use BGP Large Communities. Personnel Document Shepherd - christopher.mor...@gmail.com Responsible Area Director - war...@kumari.net ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Default EBGP Route Propagation Behavior Without Policies' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-05-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the default behavior of a BGP speaker when there is no import or export policy associated with an External BGP session. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-reject/ballot/ This IETF LC, which originally concluded on 2017-04-18, is being extended to allow for additional input to be provided. Ops AD (for GROW) and Routing AD (for IDR) wish to ensure that cross WG discussions have had a chance to occur. No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Use of BGP Large Communities) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Use of BGP Large Communities' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-04-21. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Examples and inspiration for operators to use BGP Large Communities. This is a document about how to use a new BGP feature (large communities); there are BGP implementations today which support this feature. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-large-communities-usage/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-large-communities-usage/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Protocol Action: 'Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Paths Extensions' to Proposed Standard (draft-ietf-grow-mrt-add-paths-03.txt)
The IESG has approved the following document: - 'Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Paths Extensions' (draft-ietf-grow-mrt-add-paths-03.txt) as Proposed Standard This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-mrt-add-paths/ Technical Summary The MRT (RFC6396) record format is used to for archive routing information as it changes over time. BGP is one of the routing protocols supported and MRT needs updates when BGP gets certain new capabilities. The capability for BGP to advisertise multiple paths has been added with RFC7911. This document adds the required functionality to MRT enabling the format to store the new information. Working Group Summary There has been good consensus within the working group. The draft overall is straight forward, and simple. The document is required to ensure that MRT can continue to store BGP routing information that vendors are implementing and end users are deploying. The last call was quiet, but it was clear from the interested parties that the document was ready for publication. Document Quality The feature has been implemented in bird (http://bird.network.cz/) and is waiting to be pulled into an official release. There are two software packages for procesing the MRT data, RIPE NCC's bgpdump, and java-mrt (https://github.com/tking/java-mrt). The document focuses on extending the existing MRT standard, by adding new message subtypes. Personnel Document Shepherd: Peter Schoenmaker Responsible Area Director: Joel Jaeggli ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Paths Extensions) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Paths Extensions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-02-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to support the Advertisement of Multiple Paths in BGP extensions. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-mrt-add-paths/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-mrt-add-paths/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Document Action: 'BLACKHOLE BGP Community for Blackholing' to Informational RFC (draft-ietf-grow-blackholing-03.txt)
The IESG has approved the following document: - 'BLACKHOLE BGP Community for Blackholing' (draft-ietf-grow-blackholing-03.txt) as Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/ Technical Summary This document describes the use of a well-known Border Gateway Protocol (BGP) community for blackholing at IP networks and Internet Exchange Points (IXP). This well-known advisory transitive BGP community, namely BLACKHOLE, allows an origin AS to specify that a neighboring IP network or IXP should blackhole a specific IP prefix. Working Group Summary The working group had decent discussion on this draft and consensus on content/intent. Document Quality The proposal does not include code requirements, but does include use of a standard bgp community 'BLACKHOLE' to accomplish a task (discard traffic inside the connected networks). The IETF Last call resulted in significant changes to the document inclusive of a change to the intended state to informational. Personnel Shepherd: christopher.mor...@gmail.com AD: joe...@bogus.com ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (BLACKHOLE BGP Community for Blackholing) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'BLACKHOLE BGP Community for Blackholing' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2016-07-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of a well-known Border Gateway Protocol (BGP) community for blackholing at IP networks and Internet Exchange Points (IXP). This well-known advisory transitive BGP community, namely BLACKHOLE, allows an origin AS to specify that a neighboring IP network or IXP should blackhole a specific IP prefix. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-blackholing/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Document Action: 'Problem Definition and Classification of BGP Route Leaks' to Informational RFC (draft-ietf-grow-route-leak-problem-definition-06.txt)
The IESG has approved the following document: - 'Problem Definition and Classification of BGP Route Leaks' (draft-ietf-grow-route-leak-problem-definition-06.txt) as Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-route-leak-problem-definition/ Technical Summary A systemic vulnerability of the Border Gateway Protocol routing system, known as 'route leaks', has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled "route leaks", but to date we have lacked a common definition of the term. In this document, we provide a working definition of route leaks, keeping in mind the real occurrences that have received significant attention. Further, we attempt to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. We aim to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to Internet user community as well as the network operator community. Working Group Summary This draft got significant review/discussion in the WG, with 5 revisions and agreement in the group on the focus and direction/content of the draft. Document Quality There are no implementations of a protocol for this, this document is a taxonomy of route leak types/causes/etc. Personnel Shepherd: Chris Morrow AD: Joel Jaeggli ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Document Action: 'IRR & Routing Policy Configuration Considerations' to Informational RFC (draft-ietf-grow-irr-routing-policy-considerations-06.txt)
The IESG has approved the following document: - 'IRR & Routing Policy Configuration Considerations' (draft-ietf-grow-irr-routing-policy-considerations-06.txt) as Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-irr-routing-policy-considerations/ Technical Summary The purpose of this document is to catalog past issues influencing the efficacy of Internet Routing Registries (IRR) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day. Working Group Summary No reporting of note from the working group precess. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Shepherd: Chris Morrow AD: Joel Jaeggli ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: (BGP Monitoring Protocol) to Proposed Standard
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'BGP Monitoring Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-09-15. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a protocol, BMP, that can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to introduction of BMP, screen-scraping was the most commonly-used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bmp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-bmp/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: draft-ietf-grow-filtering-threats-06.txt (Impact of BGP filtering on Inter-Domain Routing Policies) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Impact of BGP filtering on Inter-Domain Routing Policies' draft-ietf-grow-filtering-threats-06.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2015-07-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how unexpected traffic flows can emerge across an autonomous system, as the result of other autonomous systems filtering, or restricting the propagation of more specific prefixes. We provide a review of the techniques to detect the occurrence of this issue and defend against it. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-filtering-threats/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-filtering-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Document Action: 'Internet Exchange Route Server Operations' to Informational RFC (draft-ietf-grow-ix-bgp-route-server-operations-04.txt)
The IESG has approved the following document: - 'Internet Exchange Route Server Operations' (draft-ietf-grow-ix-bgp-route-server-operations-04.txt) as Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-grow-ix-bgp-route-server-operations/ Technical Summary The document discusses the operations of a BGP route server at Internet Exchagne Points (IXPs), including how they are used and what functions they require. Working Group Summary This document was created to upto date documents on how route servers are used today at IXPs. The original document was split between IDR and GROW, with IDR covering the protocol specific points, and GROW covering the requirements and operations. The IDR document is draft-ietf-idr-ix-bgp-route-server-05. Document Quality The document covers the existing implementations and usecases of a route server at an IXP. It has been reviewed sufficiently by those that operate IXPs, and the working group. Personnel Peter Schoenmaker is the document Shepherd. Joel Jaeggli is the AD. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: draft-ietf-grow-ix-bgp-route-server-operations-03.txt (Internet Exchange Route Server Operations) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Internet Exchange Route Server Operations' draft-ietf-grow-ix-bgp-route-server-operations-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2014-09-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The popularity of Internet exchange points (IXPs) brings new challenges to interconnecting networks. While bilateral eBGP sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants. Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead of IXP participation and these systems used by many IXP participants as a preferred means of exchanging routing information. This document describes operational considerations for multilateral interconnections at IXPs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-grow-ix-bgp-route-server-operations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-grow-ix-bgp-route-server-operations/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: draft-ietf-grow-ops-reqs-for-bgp-error-handling-05.txt (Operational Requirements for Enhanced Error Handling Behaviour in BGP-4) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Operational Requirements for Enhanced Error Handling Behaviour in BGP-4' draft-ietf-grow-ops-reqs-for-bgp-error-handling-05.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-09-13. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract BGP-4 is utilised as a key intra- and inter-Autonomous System routing protocol in modern IP networks. The failure modes as defined by the original protocol standards are based on a number of assumptions around the impact of session failure. Numerous incidents both in the global Internet routing table and within Service Provider networks have been caused by strict handling of a single invalid UPDATE message causing large-scale failures in one or more Autonomous Systems. This memo describes the current use of BGP-4 within Service Provider networks, and outlines a set of requirements for further work to enhance the mechanisms available to a BGP-4 implementation when erroneous data is detected. Whilst this document does not provide specification of any standard, it is intended as an overview of a set of enhancements to BGP-4 to improve the protocol's robustness to suit its current deployment. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-grow-ops-reqs-for-bgp-error-handling/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-grow-ops-reqs-for-bgp-error-handling/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Document Action: 'Distribution of diverse BGP paths.' to Informational RFC (draft-ietf-grow-diverse-bgp-path-dist-08.txt)
The IESG has approved the following document: - 'Distribution of diverse BGP paths.' (draft-ietf-grow-diverse-bgp-path-dist-08.txt) as Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-grow-diverse-bgp-path-dist/ Technical Summary The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today BGP has no mechanisms to distribute alternate paths which are not considered best path between its speakers. This behaviour results in number of disadvantages for new applications and services. This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes. Such planes can be built in parallel or they can co-exist on the current route reflection platforms. Document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. Working Group Summary The draft was well supported in the working group, with active conversation on the mailing list. Numerous people contributed and commented on the draft as part of the process. Document Quality The document has had contribution from both vendors, researchers and operators. The proposal does not require any changed to the BGP protocol, but does require an implementation of the functionality specified. Personnel Document Shepherd -- Peter Schoenmaker p...@lugs.com Area Directory -- Ron Bonica rbon...@juniper.net ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Document Action: 'Simple Virtual Aggregation (S-VA)' to Informational RFC (draft-ietf-grow-simple-va-12.txt)
The IESG has approved the following document: - 'Simple Virtual Aggregation (S-VA)' (draft-ietf-grow-simple-va-12.txt) as Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-grow-simple-va/ Technical Summary The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Simple Virtual Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that allows any and all edge routers to shrink their RIB and FIB requirements substantially and therefore increase their useful lifetime. S-VA does not increase FIB requirements for core routers. S-VA is extremely easy to configure considerably more so than the various tricks done today to extend the life of edge routers. S-VA can be deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. Working Group Summary This document was last called in 2011, went dormant for many months, and last called again in May 2012. Last call comments were positive, but resulted in a new draft version. Document Quality The author states that his employer has deployed the draft. Personnel Chris Morrow is shepherd. Ron Bonica is AD. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Document Action: 'Issues with Private IP Addressing in the Internet' to Informational RFC (draft-ietf-grow-private-ip-sp-cores-07.txt)
The IESG has approved the following document: - 'Issues with Private IP Addressing in the Internet' (draft-ietf-grow-private-ip-sp-cores-07.txt) as Informational RFC This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-grow-private-ip-sp-cores/ Technical Summary The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognized within the ISP community, there appears to be no document that collectively describes the issues. Working Group Summary This document had extensive review through the wg process. I believe there was good discussion about merits, improvements and polishing for this document, I believe the WG consensus long ago that this document is ready for publication. Document Quality This document aims to outline the pitfalls with certain implementation choices in building/operating a network which is to be part of the larger public Internet. It is a good, solid document. Personnel The document shepherd is myself (Chris Morrow), the responsible Area Director is: Ron Bonica RFC Editor Note Please removed the unused references to 'RFC1393' and RFC 792 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: draft-ietf-grow-diverse-bgp-path-dist-07.txt (Distribution of diverse BGP paths.) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Distribution of diverse BGP paths.' draft-ietf-grow-diverse-bgp-path-dist-07.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-07-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today BGP has no mechanisms to distribute alternate paths which are not considered best path between its speakers. This behaviour results in number of disadvantages for new applications and services. This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes. Such planes can be built in parallel or they can co-exist on the current route reflection platforms. Document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-grow-diverse-bgp-path-dist/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-grow-diverse-bgp-path-dist/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: draft-ietf-grow-private-ip-sp-cores-05.txt (Issues with Private IP Addressing in the Internet) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Issues with Private IP Addressing in the Internet' draft-ietf-grow-private-ip-sp-cores-05.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-07-17. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-grow-private-ip-sp-cores/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-grow-private-ip-sp-cores/ballot/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Protocol Action: 'Time to Remove Filters for Previously Unallocated IPv4 /8s' to BCP (draft-ietf-grow-no-more-unallocated-slash8s-04.txt)
The IESG has approved the following document: - 'Time to Remove Filters for Previously Unallocated IPv4 /8s' (draft-ietf-grow-no-more-unallocated-slash8s-04.txt) as a BCP This document is the product of the Global Routing Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-grow-no-more-unallocated-slash8s/ Technical Summary It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile and expensive. Network administrators are advised to remove filters based on the registration status of the address space. This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. Working Group Summary There were no standout notes in the WG process for this document. Document Quality This document covers operational guidance, not code. As such there are no implementations and this is not a protocol. RFC Editor Note OLD Network operators who only wish to filter traffic originating from addresses that should never be routed across the Internet, Martians, can deploy a set of packet and prefix filters designed to block traffic from address blocks reserved for special purposes. These are: - 0.0.0.0/8 (Local identification) [RFC1122]; - 10.0.0.0/8 (Private use) [RFC1918]; - 127.0.0.0/8 (Loopback) [RFC1122]; - 169.254.0.0/16 (Link local) [RFC3927]; - 172.16.0.0/12 (Private use) [RFC1918]; - 192.0.2.0/24 (TEST-NET-1) [RFC5737]; - 192.168.0.0/16 (Private use) [RFC1918]; - 198.18.0.0/15 (Benchmark testing) [RFC2544]; - 198.51.100.0/24 (TEST-NET-2) [RFC5737]; - 203.0.113.0/24 (TEST-NET-3) [RFC5737]; - 224.0.0.0/4 (Multicast) [RFC5771]; and - 240.0.0.0/4 (Future use) [RFC1112]. A full set of special use IPv4 addresses can be found in [RFC5735]. It includes prefixes that are intended for Internet use. NEW Network operators may deploy filters that block traffic destined for Martian prefixes. Currently, the Martian prefix table is defined by [RFC 5735] which reserves each Martian prefix for some specific, special-use. If the Martian prefix table ever changes, that change will be documented in an RFC that either updates or obsoletes [RFC 5735]. END ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: draft-ietf-grow-geomrt-01.txt (MRT BGP routing information export format with geo-location extensions) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'MRT BGP routing information export format with geo-location extensions' draft-ietf-grow-geomrt-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-04-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-grow-geomrt/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: draft-ietf-grow-unique-origin-as-00.txt (Unique Per-Node Origin ASNs for Globally Anycasted Services) to BCP
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Unique Per-Node Origin ASNs for Globally Anycasted Services' draft-ietf-grow-unique-origin-as-00.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-04-29. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-grow-unique-origin-as/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-grow-unique-origin-as/ No IPR declarations have been submitted directly on this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] Last Call: draft-ietf-grow-bgp-graceful-shutdown-requirements-04.txt (Requirements for the graceful shutdown of BGP sessions) to Informational RFC
The IESG has received a request from the Global Routing Operations WG (grow) to consider the following document: - 'Requirements for the graceful shutdown of BGP sessions' draft-ietf-grow-bgp-graceful-shutdown-requirements-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2010-09-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-graceful-shutdown-requirements/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-graceful-shutdown-requirements/ No IPR declarations were found that appear related to this I-D. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
