Revised Validation Procedure for BGP Flow Specifications
draft-ietf-idr-bgp-flowspec-oid-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-08-20
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-08-02
|
15 | (System) | RFC Editor state changed to AUTH48 |
2021-07-29
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-06-23
|
15 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2021-06-22
|
15 | (System) | RFC Editor state changed to EDIT |
2021-06-22
|
15 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-06-22
|
15 | (System) | Announcement was received by RFC Editor |
2021-06-22
|
15 | (System) | IANA Action state changed to In Progress |
2021-06-22
|
15 | (System) | Removed all action holders (IESG state changed) |
2021-06-22
|
15 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-06-22
|
15 | Cindy Morgan | IESG has approved the document |
2021-06-22
|
15 | Cindy Morgan | Closed "Approve" ballot |
2021-06-22
|
15 | Cindy Morgan | Ballot approval text was generated |
2021-06-22
|
15 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2021-06-03
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-06-03
|
15 | Juan Alcaide | New version available: draft-ietf-idr-bgp-flowspec-oid-15.txt |
2021-06-03
|
15 | (System) | New version approved |
2021-06-03
|
15 | (System) | Request for posting confirmation emailed to previous authors: Clarence Filsfils , David Smith , Jim Uttaro , Juan Alcaide , Prodosh Mohapatra |
2021-06-03
|
15 | Juan Alcaide | Uploaded new revision |
2021-05-21
|
14 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Overtaken by Events' |
2021-05-21
|
14 | Jean Mahoney | Assignment of request for Last Call review by GENART to Suresh Krishnan was marked no-response |
2021-05-20
|
14 | (System) | Changed action holders to Clarence Filsfils, Jim Uttaro, David Smith, Juan Alcaide, Prodosh Mohapatra (IESG state changed) |
2021-05-20
|
14 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2021-05-20
|
14 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-05-20
|
14 | Murray Kucherawy | [Ballot comment] Section 6 refers to this draft as "this memo", while all other self-references are "this document". I suggest changing this section to match, … [Ballot comment] Section 6 refers to this draft as "this memo", while all other self-references are "this document". I suggest changing this section to match, or, in the alternative, leave a note to the RFC Editor to remove the section. In Section 7, the "SHOULD not" probably ought to be "SHOULD NOT". |
2021-05-20
|
14 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2021-05-19
|
14 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2021-05-19
|
14 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2021-05-18
|
14 | Robert Wilton | [Ballot comment] Hi, Thanks for this document. My nits have already been pointed out by other ADs, hence my only non-blocking comment is on this … [Ballot comment] Hi, Thanks for this document. My nits have already been pointed out by other ADs, hence my only non-blocking comment is on this text in section 4.1. 1. This condition SHOULD be enabled by default (it may be disabled by explicit configuration as described on the next list item (b.2.2)). 2. This condition MAY be disabled by explicit configuration on a BGP speaker. I felt that the text "(it may be disabled by explicit configuration as described on the next list item (b.2.2))." is repetitive and unnecessary, and obvious by the next list item. However, I'm happy to leave the handling of this comment to the authors discretion. Regards, Rob |
2021-05-18
|
14 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2021-05-17
|
14 | Magnus Nyström | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Magnus Nystrom. Sent review to list. |
2021-05-17
|
14 | Roman Danyliw | [Ballot comment] Thank you Magnus Nystrom for the SECDIR review and for the subsequent updates by the authors. ** Section 2. Editorial. s/same autonomous system … [Ballot comment] Thank you Magnus Nystrom for the SECDIR review and for the subsequent updates by the authors. ** Section 2. Editorial. s/same autonomous system than/same autonomous system as/ ** Section 2. While the proposed modification cannot be used for inter-domain coordination of traffic filtering, it greatly simplifies distribution of intra-domain traffic filtering policies within an autonomous system which has a large number of border routers having complex BGP policies. Should the above key detail be explicitly framed in an applicability statement? ** Section 4.1. Editorial + normative guidance which frames the text on the intent of the designed network, not the operator “knowing something”. OLD Disabling the new condition above (b.2.2) could be a good practice if the operator knew with certainty that a Flow Specification would not be originated inside the local domain. An additional case would be if it was known for a fact that only the right egress border routers (i.e. those that were also egress border routers for the best routes) were originating a Flow Specification NLRI. NEW Disabling the new condition above (b.2.2) is RECOMMENDED in networks where policy prohibits Flow Specification from originating inside the local domain or where configuration dictates that only the egress border routers (i.e. those that were also egress border routers for the best routes) will originating a Flow Specification NLRI. |
2021-05-17
|
14 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2021-05-16
|
14 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2021-05-15
|
14 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2021-05-14
|
14 | Benjamin Kaduk | [Ballot comment] John had some good editorial comments; thank you to him for spotting them, and to the authors for pulling in the fixes. It … [Ballot comment] John had some good editorial comments; thank you to him for spotting them, and to the authors for pulling in the fixes. It seems to me that the revision to the validation procedures that we describe here may be broader than needed to satisfy the stated use case, and that such broadness has a corresponding weakening of the security properties of the system as a whole. My understanding is that when central controllers or route-reflectors are used, they tend to be in some sense "more trusted" than peer routers in the domain (and, correspondingly, more tightly secured). So it seems like the system as a whole would be less fragile/more secure if "off-path" flow specs were allowed only from the trusted source, versus from any peer in the same AS [confederation]. Is there a reason why such a procedure is infeasible? (It seems like all peers in the AS could be marked as "trusted" in this way, if appropriate, which allows for recovering the current semantics of this draft if needed.) This is, in essence, the same topic raised by the secdir reviewer and relates to "fail-closed" vs "fail-open". I think it gives a clearer picture on what the safe and recommended behavior is, if we say to only accept these routes from "trusted peers in the local domain" (but allow all peers in the local domain to be trusted if appropriate) than to say to always accept these routes from peers in the local domain and optionally do strict enforcement if we know that the peer advertising the route is not a route server. Abstract This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. [...] I'd suggest adding a couple words about "prior to this document requires" or "as specified in RFC 8955 requires", since that's exactly what we're changing with this document. However, the validation procedure will fail in this scenario. [...] Similarly, this could also say "the RFC 8955 validation procedure". Section 4.1 2. The AS_PATH attribute of the Flow Specification is empty or contains only an AS_CONFED_SEQUENCE segment [RFC5065]. Would there ever be cause to have a knob that allows this condition only for the empty AS_PATH (and denies this condition when AS_CONFED_SEQUENCE is present)? From skimming RFC 5065 I mostly assume not, but have to ask... Section 4.2 For clarity, the AS in the left-most position of the AS_PATH means the AS that was last added to the AS_SEQUENCE. Thank you for including this; it is a big help for readability. Using the new rule to validate a Flow Specification route received from an External Border Gateway Protocol (eBGP) peer belonging to the same local domain (in the case of a confederation) is out of the scope of this document. Note that although it's possible, its utility is dubious. Although it is conceivable that a router in the same local domain (both iBGP and eBGP within the same local domain) could send a rogue update, only eBGP (outside the local domain) risk is considered within this document (in the same spirit of the mentioned beforehand AS_PATH validation in [RFC4271]). I'm having (I think) the same trouble John did reading this paragraph. I'll watch his ballot thread and chime in there if needed; no need to specifically reply here. Section 7 We could mention again (per §3) that having this mechanism allows central SOC or controller systems to be able to propagate flowspecs more readily during attacks and improves the stability/security of the network. This document updates the route feasibility validation procedures for Flow Specifications learned from iBGP peers and through route servers. This change is in line with the procedures described in [RFC8955] and, thus, the security characteristics equivalent to the existing security properties of BGP unicast routing are maintained. I would argue that the security characteristics are not (strictly) "equivalent", but only "roughly equivalent". With the new procedures, a malicious or compromised node in the local AS can (e.g.) cause traffic to be discarded without steering that traffic to/through itself. There are plenty of other ways that such a malicious node can cause harm, not least announcing that prefix and dropping the traffic as it passes through, so the overall properties of the system are roughly equivalent, but there are clear differences of the particulars. route servers may suppose an operational challenge. If the condition of the peer is unknown, the rule SHOULD not be enforced. In light of my top-level comment (and the secdir review), I'm uncomfortable with a SHOULD-level "fail-open" behavior. Could the default behavior when the condition of the peer is unkonwn be subject to a configuration knob? BGP updates learned from iBGP peers are considered trusted, so the Traffic Flow Specifications contained in BGP updates are also considered trusted. Therefore, it is not required to validate that the originator of an intra-domain Traffic Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in that Flow Specification. Note that this trustworthy consideration is not absolute and the new possibility than an iBGP speaker could send a rogue Flow Specification is introduced. Also in light of my toplevel comment, it's not clear that this paragraph adds much value. Specifically, as we note in the last sentence, the level of trust in a route server is not (in the general case) the same level of trust in a generic peer in the iBGP domain, even if both peers are trusted in a general sense. So it seems that the core sentiment here is that when we get the flowspec from a trusted source, it's trusted, and we don't need to be as strict about validating that it's the same source that we would send the traffic to in the absence of a flowspec. Section 9.1 It seems that RFC 7947 is reference in only one location, and not in a manner that strongly implies a normative relationship. NITS Abstract For an iBGP received route, the originator is "IBGP" (with that capitalization) appears on the RFC Editor's list at https://www.rfc-editor.org/materials/abbrev.expansion.txt but is not marked as "well-known". So we should probably use the expanded version in the abstract and define it on first use in the body. Section 2 the same forwarding path as the dest-route. For the case where AS1 has thousands of ASBRs, it becomes impractical to originate different Flow Specification rules on each ASBR in AS1 based on which ASBR each dest-route is learned from. The objective is to advertise all the Flow Specifications from the same route-controller. "it becomes impractical" does not flow directly to "the objective is"; I'd put some transition phrase in, like "to make the situation more tenable". Section 3 can direct border routers within their AS with specific attack mitigation actions (drop the traffic, forward to a clean-pipe center, etc.). Maybe "clean-pipe center" is a term of art I'm not familiar with, but the natural reading would be that a clean pipe is something that is the output of a scrubbing center, and that pipe-cleaning is the operation performed there. This would suggest rewording to something like "forward to a scrubbing center", "forward to a pipe-cleaning location", etc. In addition, an operator may extend the requirements above for a group of ASes via policy. This is described in section (b.2.3) of the validation procedure. I suggest a forward reference ("below" or "in Section 4.1") to contrast to the RFC 8955 procedure. Section 5 If the latter applies, a network should be designed so it has a congruent topology amongst unicast routes and Flow Specification routes. [...] This "should" does not give any indication of why the network should be designed in this manner (e.g., that failing to do so would result in (b.1) failing). Flow Specifications originated in a different local domain sill need a congruent topology. The reason is that the second condition (b.2) evaluates to false and only the first condition (b.1) is evaluated. I suggest s/different local domain/different domain/ -- my first reading of "different local domain" was "a different AS but the same confederation", and only by contrasting this statement to the previous paragraph did I realize the intended meaning. Alternately (or additionally?), this could be clarified by noting that this scenario will result in an AS_PATH that contains non-AS_CONFED_SEQUENCE segments. |
2021-05-14
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-05-14
|
14 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Special thanks to Susan Hares for her recent and detailed shepherd's write up. Please … [Ballot comment] Thank you for the work put into this document. Special thanks to Susan Hares for her recent and detailed shepherd's write up. Please find below some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric == COMMENTS == Is there any reason why the shepherd is not acknowledged in the document ? -- Section 2 -- Strongly suggest s/protocol port numbers/protocol or port numbers/ Please expand "RR" at first use. -- Section 4.2 -- Suggest to add also a reference to section 4 of RFC 8955 rather than "[RFC8955] states:" |
2021-05-14
|
14 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2021-05-13
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Magnus Nystrom |
2021-05-13
|
14 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Magnus Nystrom |
2021-05-13
|
14 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2021-05-13
|
14 | Juan Alcaide | New version available: draft-ietf-idr-bgp-flowspec-oid-14.txt |
2021-05-13
|
14 | (System) | New version approved |
2021-05-13
|
14 | (System) | Request for posting confirmation emailed to previous authors: Clarence Filsfils , David Smith , Jim Uttaro , Juan Alcaide , Prodosh Mohapatra |
2021-05-13
|
14 | Juan Alcaide | Uploaded new revision |
2021-05-10
|
13 | Lars Eggert | [Ballot comment] Section 7, paragraph 4, comment: > from a route server peer. If that peer is known for a fact not to be … [Ballot comment] Section 7, paragraph 4, comment: > from a route server peer. If that peer is known for a fact not to be > a route server, that optional rule SHOULD be enforced for Flow > Specification routes. The phrasing here seems complicated. Would it be easier to say that the rule MUST NOT be enforced if the peer is known to be a route server? ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 5, paragraph 2, nit: - it has a congruent topology amongst ipv4 unicast routes and Flow - ^^ + it has a congruent topology amongst IPv4 unicast routes and Flow + ^^ Section 5, paragraph 2, nit: - for the two equivalent routes (i.e. the Flow Specification route and - its best-match unicast route) are learned from the same peer accross - - + for the two equivalent routes (i.e., the Flow Specification route and + + + its best-match unicast route) are learned from the same peer across Section 7, paragraph 2, nit: - servers. This change is in line with the procedures in [rfc8955] and - ^^^ + servers. This change is in line with the procedures in [RFC8955] and + ^^^ Section 7, paragraph 4, nit: - hereby optional (section 4.2). If that original rule is actually not - ^^^^^^^^ - enforced it may introduce some security risks. A peer (or a client + hereby OPTIONAL (section 4.2). If that original rule is actually not + ^^^^^^^^ + enforced, it may introduce some security risks. A peer (or a client + + Section 2, paragraph 3, nit: > e in an autonomous system with a large number of border routers having compl > ^^^^^^^^^^^^^^^^^ Specify a number, remove phrase, or simply use "many" or "numerous" Section 2, paragraph 7, nit: > n autonomous system which has a large number of border routers having complex > ^^^^^^^^^^^^^^^^^^^^ Specify a number, remove phrase, or simply use "many" or "numerous" Section 3, paragraph 8, nit: > ms exist to protect each AS independently from network security attacks using > ^^^^^^^^^^^^^^^^^^ The usual collocation for "independently" is "of", not "from". Did you mean "independently of"? Section 4.1, paragraph 2, nit: > tion 6 is redefined as follows: b) One of the following conditions MUST ho > ^ Unpaired symbol: '(' seems to be missing Section 4.1, paragraph 6, nit: > he next list item (b.2.1)).. an empty AS_PATH. 2. This > ^^ Two consecutive dots Section 4.2, paragraph 12, nit: > bious. Although it is conceivable that an router in the same local domain ( > ^^ Use "a" instead of 'an' if the following word doesn't start with a vowel sound, e.g. 'a sentence', 'a university'. Section 5, paragraph 2, nit: > tter applies, a network should be designed so it has a congruent topology am > ^^^^^^^^^^^ Use a comma before 'so' if it connects two independent clauses (unless they are closely connected and short). "MUST", paragraph 2, nit: > tes are also considered trusted. Therefore it is not required to validate th > ^^^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Uncited references: [RFC6793]. |
2021-05-10
|
13 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2021-05-08
|
13 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom. Submission of review completed at an earlier date. |
2021-05-07
|
13 | John Scudder | [Ballot comment] Thanks for this document, I'm glad to see it finally close to publication. I have a few comments I hope will help improve … [Ballot comment] Thanks for this document, I'm glad to see it finally close to publication. I have a few comments I hope will help improve it, below. 1. Section 2 [RFC8955] defines a BGP NLRI [RFC4271] that can be used to distribute RFC 4271 is the right citation for “BGP” but for “BGP NLRI” other than IPv4 unicast you want RFC 4760. the Flow Specification. The aim is making sure that only speakers on making -> to make originated in any location within the same autonomous system than the than -> as Flow Specification received from an iBGP peer, it could be possible to disseminate such Flow Specification NLRIs directly from the “It could be possible”? Or “it would be necessary”? validated when received by RR and R1. Sometimes the Flow Specification needs to be originated on AS1. ASBR1 could originate on -> within 2. Section 4.1 1. This condition SHOULD be enabled by default (it may be disabled by explicit configuration as described on the next list item (b.2.1)).. an empty AS_PATH. Looks as though “an empty AS_PATH” is a cut-n-paste error that should be deleted? 3. As an extension to this rule, a given non-empty AS_PATHs AS_PATHs -> AS_PATH (agreement in number) AS_CONFED_SET segments), MAY be validated by policy. A I think “permitted” would be clearer than “validated”. Also, policy may be useful to validate a specific set of non-empty AS_PATHs (b.2.3). For example, it could validate a Flow Specification whose AS_PATH contains only an AS_SEQUENCE with ASes that are all known to belong to the same administrative domain. Same point, I suggest “permit”. 3. Section 4.2 This rule prevents the exchange of BGP Flow Specification NLRIs at Internet exchanges with BGP route servers [RFC7947]. Since it may not be common knowledge that route servers don’t insert their own AS number, I suggest a change something like this, for clarity: This rule prevents the exchange of BGP Flow Specification NLRIs at Internet exchanges with BGP route servers, which by design don’t insert their own AS number into the AS_PATH ([RFC7947] Section 2.2.2.1). 4. Section 4.2 For clarity, the AS in the left-most position of the AS_PATH means the AS that was last added to the AS_SEQUENCE. I suggest changing “last” to “most recently”. This is just personal preference, though. I also suggest changing “AS_SEQUENCE” somehow, probably to “AS_PATH”. The reason for this is there could be more than one AS_SEQUENCE in the AS_PATH so the definite article isn’t quite correct. There is however only one AS_PATH, and you can make the change without loss of generality or correctness. So, the full suggested rewrite is: For clarity, the AS in the left-most position of the AS_PATH means the AS that was most recently added to the AS_PATH. 5. Section 4.2 Specifications. This is a security BGP threat, but out of the “Security BGP threat” -> “security threat” (or “BGP security threat” if you prefer) 6. Section 4.2 Using the new rule to validate a Flow Specification route received from an External Border Gateway Protocol (eBGP) peer belonging to the same local domain (in the case of a confederation) is out of the scope of this document. Note that although it's possible, its utility is dubious. Although it is conceivable that an router in the same local domain (both iBGP and eBGP within the same local domain) could send a rogue update, only eBGP (outside the local domain) risk is considered within this document (in the same spirit of the mentioned beforehand AS_PATH validation in [RFC4271]). I’m having a hard time understanding this paragraph. This is at least partly due to the use of “local domain“, which isn’t a well-defined term of art. You could try something like “under the same administration“? But, even if I make that change in my head as I read the paragraph, I still don’t get your point. :-( Is the whole paragraph strictly about confederations, and what you’re talking about is a BGP session between a router in one member-AS and a router in another member-AS of the confederation? If that’s it, I can probably propose some new text. Also, “an router” -> “a router”. Also, you should cite RFC 5065 when you mention confederations. 7. Section 5 its best-match unicast route) are learned from the same peer accross accross-> across 8. Section 5 Consider the validation procedure preceding this document. The I think what you mean here is “consider the validation procedure defined in RFC 8955“. If that’s correct, I suggest saying it that way. (If that’s not correct, what did you mean?) 9. Section 7 thus maintain security characteristics equivalent to the existing Maintain -> maintains 10. Section 7 The original AS_PATH validation rule ([RFC4271] section 6.3) becomes hereby optional (section 4.2). I don’t think you’re actually updating RFC 4271, are you? The way you’ve written this makes it sound as though you are. You’re relaxing the rule in RFC 8955, but as you point out in section 4.2, RFC 4271 makes AS_PATH neighbor AS insertion enforcement optional to begin with: If the UPDATE message is received from an external peer, the local system MAY check whether the leftmost (with respect to the position of octets in the protocol message) AS in the AS_PATH attribute is equal to the autonomous system number of the peer that sent the message. If the check determines this is not the case, the Error Subcode MUST be set to Malformed AS_PATH. Maybe you could rewrite something like this: “As per section 4.2, it is becomes optional to enforce that the AS_PATH attribute of a route received via the External Border Gateway Protocol (eBGP) contains the neighboring AS in the leftmost position of the AS_PATH attribute. Then we continue: If that original rule is actually not enforced it may introduce some security risks. A peer (or a client of a route server peer) in AS X could advertise a rogue Flow Specification route whose first AS in AS_PATH was Y (assume Y is the first AS in the AS_PATH of the best-match unicast route). This risk is impossible to prevent if the Flow Specification route is received from a route server peer. I think you’ve missed out on the opportunity to point out that the risk can also be mitigated if the route server itself enforces the optional rule of RFC 4271 section 6.3.. I think it’s fair to say that at an exchange point, the administrator of the route server enjoys more trust then the administrators of other routers at the exchange point. If that peer is known for a fact not to be a route server, that optional rule SHOULD be enforced for Flow Specification routes. It may be necessary to say a little more about how you would get this knowledge about the peer not being a route server. Possibly a rewrite could be something like: "Unless configuration (or other means beyond the scope of this document) indicates that the peer is a route server, that optional rule SHOULD be enforced for Flow Specification routes from EBGP peers." 11. Section 7 absolute and the new possibility than an iBGP speaker could send a Than -> that |
2021-05-07
|
13 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2021-05-07
|
13 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2021-05-07
|
13 | Susan Hares | Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies a standard document (RFC8955) (2) The IESG approval announcement includes a Document … Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies a standard document (RFC8955) (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in RFC8955 for the dissemination of BGP Flow Specifications. RFC8955 requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC8955 author (besides the shepherd) c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. RTG-DIR review: (Geoff Houston): Suggests that RFC8955 and RFC8956 draft-ietf-idr-bgp-flowspec-oid-12.txt should be merged into 1 document. The idr wg-chairs took the approach of splitting the work into pieces. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. Strong desires for deployment from operators. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. a) NITs that AD indicated should be fixed b) AD concerns should be fixed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. All references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Updates RFC8955. This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2021-05-05
|
13 | Cindy Morgan | Placed on agenda for telechat - 2021-05-20 |
2021-05-05
|
13 | Alvaro Retana | Ballot has been issued |
2021-05-05
|
13 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2021-05-05
|
13 | Alvaro Retana | Created "Approve" ballot |
2021-05-05
|
13 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for Writeup |
2021-05-05
|
13 | Alvaro Retana | Ballot writeup was changed |
2021-05-05
|
13 | Ron Bonica | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Ron Bonica. Sent review to list. |
2021-05-05
|
13 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-05-02
|
13 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Magnus Nystrom. |
2021-04-30
|
13 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2021-04-30
|
13 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-idr-bgp-flowspec-oid-13, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-idr-bgp-flowspec-oid-13, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2021-04-29
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ron Bonica |
2021-04-29
|
13 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ron Bonica |
2021-04-22
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2021-04-22
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2021-04-22
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2021-04-22
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2021-04-20
|
13 | Alvaro Retana | Requested Last Call review by RTGDIR |
2021-04-20
|
13 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-04-20
|
13 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-05-05): From: The IESG To: IETF-Announce CC: Susan Hares , aretana.ietf@gmail.com, draft-ietf-idr-bgp-flowspec-oid@ietf.org, idr-chairs@ietf.org, … The following Last Call announcement was sent out (ends 2021-05-05): From: The IESG To: IETF-Announce CC: Susan Hares , aretana.ietf@gmail.com, draft-ietf-idr-bgp-flowspec-oid@ietf.org, idr-chairs@ietf.org, idr@ietf.org, shares@ndzh.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Revised Validation Procedure for BGP Flow Specifications) to Proposed Standard The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Revised Validation Procedure for BGP Flow Specifications' 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-call@ietf.org mailing lists by 2021-05-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an iBGP received route, the originator is typically a border router within the same autonomous system. The objective is to allow only BGP speakers within the data forwarding path to originate BGP Flow Specifications. Sometimes it is desirable to originate the BGP Flow Specification any place within the autonomous system itself, for example, from a centralized BGP route controller. However, the validation procedure will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises AS_PATH validation rules so Flow Specifications received from an eBGP peer can be validated when such peer is a BGP route server. This document updates the validation procedure in RFC8955. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-flowspec-oid/ No IPR declarations have been submitted directly on this I-D. |
2021-04-20
|
13 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-04-20
|
13 | Alvaro Retana | Last call was requested |
2021-04-20
|
13 | Alvaro Retana | Ballot approval text was generated |
2021-04-20
|
13 | Alvaro Retana | Ballot writeup was generated |
2021-04-20
|
13 | (System) | Changed action holders to Alvaro Retana (IESG state changed) |
2021-04-20
|
13 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-04-20
|
13 | Alvaro Retana | Last call announcement was changed |
2021-04-20
|
13 | Alvaro Retana | Last call announcement was generated |
2021-04-12
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-04-12
|
13 | Juan Alcaide | New version available: draft-ietf-idr-bgp-flowspec-oid-13.txt |
2021-04-12
|
13 | (System) | New version approved |
2021-04-12
|
13 | (System) | Request for posting confirmation emailed to previous authors: Clarence Filsfils , David Smith , Jim Uttaro , Juan Alcaide , Prodosh Mohapatra |
2021-04-12
|
13 | Juan Alcaide | Uploaded new revision |
2021-02-04
|
12 | Susan Hares | Shepherd's todo before sending back to AD: 1) Address ADs comments 2) Fix the references to RFC8895 and RFC8896. Template version: 11/1/2019 (1) Type … Shepherd's todo before sending back to AD: 1) Address ADs comments 2) Fix the references to RFC8895 and RFC8896. Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies a standard document (RFC8955) (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in RFC8955 for the dissemination of BGP Flow Specifications. RFC8955 requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC8955 and RFC8956 document. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle this document into RFC8955. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC8955 author (besides the shepherd) c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. RTG-DIR review: (Geoff Houston): Suggests that RFC8955 and RFC8956 draft-ietf-idr-bgp-flowspec-oid-12.txt should be merged into 1 document. The idr wg-chairs regrettably took the approach of splitting the work into pieces. If the IESG agrees with Geoff Houston, the IDR chairs will work toward merging RFCs for all 3 documents into one revised document. Feedback to the IDR chairs would help during this process. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. a) NITs that AD indicated should be fixed b) AD concerns should be fixed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. All references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Updates RFC8955. This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2021-02-04
|
12 | Susan Hares | Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies a standard document (RFC8955) (2) The IESG approval announcement includes a Document … Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies a standard document (RFC8955) (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in RFC8955 for the dissemination of BGP Flow Specifications. RFC8955 requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC8955 and RFC8956 document. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle this document into RFC8955. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC5575bis author c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. RTG-DIR review: (Geoff Houston): Suggests that RFC5575bis, draft-ietf-idr-flow-spec-v6, and draft-ietf-idr-bgp-flowspec-oid-12.txt should be merged into 1 document. The idr wg-chairs regrettably took the approach of splitting the work into pieces. If the IESG agrees with Geoff Houston, the IDR chairs will work toward merging RFCs for all 3 documents into one revised docvuement. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-11.txt a) Editorial errors: page 5, section 4.1 Old /a. one of the following conditions MUST hold true:" New /b. one of the following conditions MUST hold true:" Old:/(this is the unicast route/ New: (This is the unicast route/ b) Fix the NITS warnings. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. [draft-ietf-idr-rfc5575bis] has been approved by the IESG for publication. All other references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates RFC5575bis (approved for RFC publication). This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2021-01-27
|
12 | Alvaro Retana | === AD Review of draft-ietf-idr-bgp-flowspec-oid-12 === https://mailarchive.ietf.org/arch/msg/idr/9hOqHq0KdnX-fda-zsoT8QPULhg/ |
2021-01-27
|
12 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2021-01-11
|
12 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2021-01-11
|
12 | Alvaro Retana | Notification list changed to Susan Hares <shares@ndzh.com>, aretana.ietf@gmail.com from Susan Hares <shares@ndzh.com> |
2020-07-16
|
12 | Gunter Van de Velde | Closed request for Early review by OPSDIR with state 'Overtaken by Events' |
2020-07-08
|
12 | Susan Hares | Changed consensus to Yes from Unknown |
2020-07-08
|
12 | Susan Hares | Intended Status changed to Proposed Standard from None |
2020-07-08
|
12 | Susan Hares | Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a … Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in [RFC5575bis] for the dissemination of BGP Flow Specifications. [RFC5575bis] requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC5575bis document which took over 3 years to provide a bis document that addressed the documentation errors in RFC5575. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle into RFC5575bis this document and draft-ietf-idr-ietf-flow-spec-v6 since all three are needed within their networks. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC5575bis author c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. RTG-DIR review: (Geoff Houston): Suggests that RFC5575bis, draft-ietf-idr-flow-spec-v6, and draft-ietf-idr-bgp-flowspec-oid-12.txt should be merged into 1 document. The idr wg-chairs regrettably took the approach of splitting the work into pieces. If the IESG agrees with Geoff Houston, the IDR chairs will work toward merging RFCs for all 3 documents into one revised docvuement. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-11.txt a) Editorial errors: page 5, section 4.1 Old /a. one of the following conditions MUST hold true:" New /b. one of the following conditions MUST hold true:" Old:/(this is the unicast route/ New: (This is the unicast route/ b) Fix the NITS warnings. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. [draft-ietf-idr-rfc5575bis] has been approved by the IESG for publication. All other references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates RFC5575bis (approved for RFC publication). This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2020-07-08
|
12 | Susan Hares | Responsible AD changed to Alvaro Retana |
2020-07-08
|
12 | Susan Hares | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2020-07-08
|
12 | Susan Hares | IESG state changed to Publication Requested from I-D Exists |
2020-07-08
|
12 | Susan Hares | IESG process started in state Publication Requested |
2020-07-08
|
12 | Susan Hares | Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a … Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in [RFC5575bis] for the dissemination of BGP Flow Specifications. [RFC5575bis] requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC5575bis document which took over 3 years to provide a bis document that addressed the documentation errors in RFC5575. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle into RFC5575bis this document and draft-ietf-idr-ietf-flow-spec-v6 since all three are needed within their networks. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC5575bis author c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. RTG-DIR review: (Geoff Houston): Suggests that RFC5575bis, draft-ietf-idr-flow-spec-v6, and draft-ietf-idr-bgp-flowspec-oid-12.txt should be merged into 1 document. The idr wg-chairs regrettably took the approach of splitting the work into pieces. If the IESG agrees with Geoff Houston, the IDR chairs will work toward merging RFCs for all 3 documents into one revised docvuement. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-11.txt a) Editorial errors: page 5, section 4.1 Old /a. one of the following conditions MUST hold true:" New /b. one of the following conditions MUST hold true:" Old:/(this is the unicast route/ New: (This is the unicast route/ b) Fix the NITS warnings. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. [draft-ietf-idr-rfc5575bis] has been approved by the IESG for publication. All other references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates RFC5575bis (approved for RFC publication). This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2020-07-08
|
12 | Susan Hares | Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a … Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in [RFC5575bis] for the dissemination of BGP Flow Specifications. [RFC5575bis] requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC5575bis document which took over 3 years to provide a bis document that addressed the documentation errors in RFC5575. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle into RFC5575bis this document and draft-ietf-idr-ietf-flow-spec-v6 since all three are needed within their networks. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC5575bis author c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. If (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-11.txt a) Editorial errors: page 5, section 4.1 Old /a. one of the following conditions MUST hold true:" New /b. one of the following conditions MUST hold true:" Old:/(this is the unicast route/ New: (This is the unicast route/ b) Fix the NITS warnings. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. [draft-ietf-idr-rfc5575bis] has been approved by the IESG for publication. All other references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates RFC5575bis (approved for RFC publication). This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2020-07-08
|
12 | Susan Hares | Template version: 11/1/2019 6/24/2020: Changes needed: 1) page 5 section 4.1 - two editorial nits: 2) Nits fixed for publication (1) Type of RFC: Proposed … Template version: 11/1/2019 6/24/2020: Changes needed: 1) page 5 section 4.1 - two editorial nits: 2) Nits fixed for publication (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in [RFC5575bis] for the dissemination of BGP Flow Specifications. [RFC5575bis] requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC5575bis document which took over 3 years to provide a bis document that addressed the documentation errors in RFC5575. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle into RFC5575bis this document and draft-ietf-idr-ietf-flow-spec-v6 since all three are needed within their networks. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC5575bis author c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. If (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-11.txt a) Editorial errors: page 5, section 4.1 Old /a. one of the following conditions MUST hold true:" New /b. one of the following conditions MUST hold true:" Old:/(this is the unicast route/ New: (This is the unicast route/ b) Fix the NITS warnings. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. [draft-ietf-idr-rfc5575bis] has been approved by the IESG for publication. All other references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates RFC5575bis (approved for RFC publication). This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2020-07-08
|
12 | Juan Alcaide | New version available: draft-ietf-idr-bgp-flowspec-oid-12.txt |
2020-07-08
|
12 | (System) | New version approved |
2020-07-08
|
12 | (System) | Request for posting confirmation emailed to previous authors: David Smith , Prodosh Mohapatra , Jim Uttaro , Juan Alcaide , Clarence Filsfils |
2020-07-08
|
12 | Juan Alcaide | Uploaded new revision |
2020-07-06
|
11 | Min Ye | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Geoff Huston. Submission of review completed at an earlier date. |
2020-07-05
|
11 | Carlos Pignataro | Assignment of request for Early review by OPSDIR to Carlos Pignataro was rejected |
2020-07-02
|
11 | Min Ye | Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Geoff Huston. |
2020-07-02
|
11 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Carlos Pignataro |
2020-07-02
|
11 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Carlos Pignataro |
2020-06-29
|
11 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Geoff Huston |
2020-06-29
|
11 | Luc André Burdet | Request for Early review by RTGDIR is assigned to Geoff Huston |
2020-06-24
|
11 | Susan Hares | Template version: 11/1/2019 6/24/2020: Changes needed: 1) page 5 section 4.1 - two editorial nits: 2) Nits fixed for publication (1) Type of RFC: Proposed … Template version: 11/1/2019 6/24/2020: Changes needed: 1) page 5 section 4.1 - two editorial nits: 2) Nits fixed for publication (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in [RFC5575bis] for the dissemination of BGP Flow Specifications. [RFC5575bis] requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC5575bis document which took over 3 years to provide a bis document that addressed the documentation errors in RFC5575. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle into RFC5575bis this document and draft-ietf-idr-ietf-flow-spec-v6 since all three are needed within their networks. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC5575bis author c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. If (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-11.txt a) Editorial errors: page 5, section 4.1 Old /a. one of the following conditions MUST hold true:" New /b. one of the following conditions MUST hold true:" Old:/(this is the unicast route/ New: (This is the unicast route/ b) Fix the NITS warnings. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. [draft-ietf-idr-rfc5575bis] has been approved by the IESG for publication. All other references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates RFC5575bis (approved for RFC publication). This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2020-06-24
|
11 | Susan Hares | Requested Early review by RTGDIR |
2020-06-24
|
11 | Susan Hares | Requested Early review by OPSDIR |
2020-06-24
|
11 | Susan Hares | Template version: 11/1/2019 6/24/2020: Changes needed: 1) page 5 section 4.1 - two editorial nits: 2) Nits fixed for publication (1) Type of RFC: Proposed … Template version: 11/1/2019 6/24/2020: Changes needed: 1) page 5 section 4.1 - two editorial nits: 2) Nits fixed for publication (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in [RFC5575bis] for the dissemination of BGP Flow Specifications. [RFC5575bis] requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC5575bis document which took over 3 years to provide a bis document that addressed the documentation errors in RFC5575. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle into RFC5575bis this document and draft-ietf-idr-ietf-flow-spec-v6 since all three are needed within their networks. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC5575bis author c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. If (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-11.txt a) Editorial errors: page 5, section 4.1 Old /a. one of the following conditions MUST hold true:" New /b. one of the following conditions MUST hold true:" Old:/(this is the unicast route/ New: (This is the unicast route/ (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. [draft-ietf-idr-rfc5575bis] has been approved by the IESG for publication. All other references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates RFC5575bis (approved for RFC publication). This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2020-06-24
|
11 | Susan Hares | Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a … Template version: 11/1/2019 (1) Type of RFC: Proposed standard Why: Modifies an proposed standard document (draft-ietf-idr-rfc5575bis). (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a modification to the validation procedure defined in [RFC5575bis] for the dissemination of BGP Flow Specifications. [RFC5575bis] requires that the originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP Flow Specifications. Though it is possible to disseminate such Flow Specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables Flow Specifications to be originated from a centralized BGP route controller. Working Group Summary: The WG had strong approval and strong request to "get this standardized soon.". This document depends on the RFC5575bis document which took over 3 years to provide a bis document that addressed the documentation errors in RFC5575. There are 4 interoperable vendor implementations (cisco, Huawei, Juniper, Nokia), and deployments in a wide range of networks (large carriers to small enterprise networks) to aid in denial of service protection. Some operators wished the IDR WG would bundle into RFC5575bis this document and draft-ietf-idr-ietf-flow-spec-v6 since all three are needed within their networks. Document Quality: Are there existing implementations of the protocol? 5 implementations, 4 vendors see https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-flowspec-oid%20implementations Personnel: Document Shepherd: Susan Hares AD: Alvaro Retana (3) Briefly describe the review of this document that was performed by the Document Shepherd. a) 4 rounds of document review and editing. b) targetted review by an RFC5575bis author c) Discussion on the mail list https://mailarchive.ietf.org/arch/msg/idr/hm5MyHemDZpSR-stTpWnxB81Jt0/ (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The RTG-DIR and OPS-DIR have been asked to do early reviews. This reviews are being requested in parallel with IESG publication. If (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other additional reviews (RTG-DIR, OPS-DIR early reviews). (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? My introduction indicates the operator community believes they have waited too long for this draft to turn into an RFC. The additional review in the WG have tightened the text, but the key point to the operators is 4 vendors with 5 interoperable implementations. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? James Uttaro: https://mailarchive.ietf.org/arch/msg/idr/yYX9bhbeV68ckYrqV_G0gk9AlMY/ David Smith: https://mailarchive.ietf.org/arch/msg/idr/Xap8H10MBkHXr-tqdUnC2MeHX64/ Juan Alcaide https://mailarchive.ietf.org/arch/msg/idr/whOmzyVhWJrTz9O3_30nsKX8A0A/ Clarence Filsfils https://mailarchive.ietf.org/arch/msg/idr/apEj5VGyWs7OZIiXe1HPMT3p4Qw/ Pradosh Mohapatra Sproute Networks (Email: mpradosh@yahoo.com) https://mailarchive.ietf.org/arch/msg/idr/OhO4yk4fEd7ihmjZEtlcRgx9GM0/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Solid consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeal. Only an urgent desire to get this document published as RFC. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Nits: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-bgp-flowspec-oid-11.txt a) Editorial errors: page 5, section 4.1 Old /a. one of the following conditions MUST hold true:" New /b. one of the following conditions MUST hold true:" Old:/(this is the unicast route/ New: (This is the unicast route/ (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No requirement for formal review. (13) Have all references within this document been identified as either normative or informative? All referenances are normative. [draft-ietf-idr-rfc5575bis] has been approved by the IESG for publication. All other references are published RFCs. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Updates RFC5575bis (approved for RFC publication). This document points to this draft. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). No IANA considerations are necessary. The change is within the protocol and does not require registration. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. No automated check required. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? No Yang modules. This draft will require draft which augmentation of the base BGP model - after that BGP model is approved. |
2020-04-24
|
11 | Susan Hares | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2020-03-30
|
11 | Susan Hares | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2020-03-30
|
11 | Susan Hares | IETF WG state changed to In WG Last Call from WG Document |
2020-03-08
|
11 | Juan Alcaide | New version available: draft-ietf-idr-bgp-flowspec-oid-11.txt |
2020-03-08
|
11 | (System) | New version approved |
2020-03-08
|
11 | (System) | Request for posting confirmation emailed to previous authors: Juan Alcaide , Clarence Filsfils , Jim Uttaro , David Smith , Prodosh Mohapatra |
2020-03-08
|
11 | Juan Alcaide | Uploaded new revision |
2020-02-10
|
10 | (System) | Document has expired |
2019-09-12
|
10 | Susan Hares | Tag Revised I-D Needed - Issue raised by WGLC set. Tag Other - see Comment Log cleared. |
2019-09-12
|
10 | Susan Hares | IETF WG state changed to WG Document from In WG Last Call |
2019-08-09
|
10 | Susan Hares | WG last call ends on 8/24/2019 |
2019-08-09
|
10 | Susan Hares | Tag Doc Shepherd Follow-up Underway cleared. |
2019-08-09
|
10 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-10.txt |
2019-08-09
|
10 | (System) | New version approved |
2019-08-09
|
10 | (System) | Request for posting confirmation emailed to previous authors: David Smith , Clarence Filsfils , Juan Alcaide , Prodosh Mohapatra , Jim Uttaro |
2019-08-09
|
10 | David Smith | Uploaded new revision |
2019-07-08
|
09 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-09.txt |
2019-07-08
|
09 | (System) | New version approved |
2019-07-08
|
09 | (System) | Request for posting confirmation emailed to previous authors: David Smith , Clarence Filsfils , Juan Alcaide , Prodosh Mohapatra , Jim Uttaro |
2019-07-08
|
09 | David Smith | Uploaded new revision |
2019-06-10
|
08 | Susan Hares | Document needs editorial revision prior to WG LC. IPR poll completed |
2019-06-10
|
08 | Susan Hares | Tags Other - see Comment Log, Doc Shepherd Follow-up Underway set. |
2019-06-10
|
08 | Susan Hares | IETF WG state changed to In WG Last Call from WG Document |
2019-05-09
|
08 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-08.txt |
2019-05-09
|
08 | (System) | New version approved |
2019-05-09
|
08 | (System) | Request for posting confirmation emailed to previous authors: David Smith , Clarence Filsfils , Juan Alcaide , Prodosh Mohapatra , Jim Uttaro |
2019-05-09
|
08 | David Smith | Uploaded new revision |
2019-05-09
|
07 | (System) | Document has expired |
2018-11-05
|
07 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-07.txt |
2018-11-05
|
07 | (System) | New version approved |
2018-11-05
|
07 | (System) | Request for posting confirmation emailed to previous authors: David Smith , Clarence Filsfils , Juan Alcaide , Prodosh Mohapatra , Jim Uttaro |
2018-11-05
|
07 | David Smith | Uploaded new revision |
2018-11-05
|
06 | (System) | Document has expired |
2018-10-03
|
06 | Susan Hares | IETF WG state changed to WG Document from In WG Last Call |
2018-05-04
|
06 | Susan Hares | Notification list changed to Susan Hares <shares@ndzh.com> |
2018-05-04
|
06 | Susan Hares | Document shepherd changed to Susan Hares |
2018-04-26
|
06 | John Scudder | IETF WG state changed to In WG Last Call from WG Document |
2018-04-26
|
06 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-06.txt |
2018-04-26
|
06 | (System) | New version approved |
2018-04-26
|
06 | (System) | Request for posting confirmation emailed to previous authors: David Smith , Clarence Filsfils , Juan Alcaide , Prodosh Mohapatra , Jim Uttaro |
2018-04-26
|
06 | David Smith | Uploaded new revision |
2018-04-26
|
05 | (System) | Document has expired |
2017-10-23
|
05 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-05.txt |
2017-10-23
|
05 | (System) | New version approved |
2017-10-23
|
05 | (System) | Request for posting confirmation emailed to previous authors: David Smith , Clarence Filsfils , Juan Alcaide , Prodosh Mohapatra , Jim Uttaro |
2017-10-23
|
05 | David Smith | Uploaded new revision |
2017-09-14
|
04 | (System) | Document has expired |
2017-03-13
|
04 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-04.txt |
2017-03-13
|
04 | (System) | New version approved |
2017-03-13
|
04 | (System) | Request for posting confirmation emailed to previous authors: Juan Alcaide , idr-chairs@ietf.org, Jim Uttaro , Pradosh Mohapatra , Clarence Filsfils , David Smith |
2017-03-13
|
04 | David Smith | Uploaded new revision |
2016-09-22
|
03 | (System) | Document has expired |
2016-03-21
|
03 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-03.txt |
2014-01-17
|
02 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-02.txt |
2013-01-22
|
01 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-01.txt |
2012-06-25
|
00 | David Smith | New version available: draft-ietf-idr-bgp-flowspec-oid-00.txt |