Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
draft-ietf-idr-bgp-open-policy-24

Closed request for Telechat review by INTDIR with state 'Withdrawn': Telechat deadline has passed... The document has been approved by the IESG. Please next time, be explicit and refuse to review the document. Thank you. -éric

(1) What type of RFC is being requested  (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Type: Proposed Standard
Why proper: Adds a capability to the BGP OPEN and a BGP attribute for Only to the customer
Listed in title page: Yes


(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:
  Route leaks are the propagation of BGP prefixes which violate
  assumptions of BGP topology relationships; e.g. passing a route
  learned from one lateral peer to another lateral peer or a transit
  provider, passing a route learned from one transit provider to
  another transit provider or a lateral peer.  Existing approaches to
  leak prevention rely on marking routes by operator configuration,
  with no check that the configuration corresponds to that of the eBGP
  neighbor, or enforcement that the two eBGP speakers agree on the
  relationship. 

 
  This document enhances BGP OPEN to establish agreement
  of the (peer, customer, provider, Route Server, Route Server client)
  relationship of two neighboring eBGP speakers to enforce appropriate
  configuration on both sides.  Propagated routes are then marked with
  an Only to Customer (OTC) attribute according to the agreed
  relationship, allowing both prevention and detection of route leaks.

Working Group Summary:
Route leaks are a problem that plague the operational Internet for over 20 years.
The WG group consensus for this draft goes across two WGs (GROW and IDR)
with both working group lending their support to define the problem
and design a series of fixes that can be deployed in operational networks.
While the discussions have been lengthy, there is solid support between
operators, researchers, and the membesrs of 2 WGs (GROW and IDR).
standardize the changs to the OPEN and the additions of an "only
to customer" (OTC) flag.

Document Quality:
The shepherd has been an active part of guiding this discussion in IDR and
grow for over 5 years.  The work from NIST (Doug Montgomery and  K. Sriram)
Brian Dickson, Randy Bush (IIJ, Arrcus), Keyur Patel (Arrcus), and
Alexander Azimov and Eugene Bogomazov has investigated
the technology from many angles.  The operators and the authors
have word smithed in the last editions to the shepherd's
satisfaction.

Existing implementations:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy

No MIB, Yang, or Media review: none needed.
Key review:  Cross-review with Grow WG that depends on this work
Reviews in Progress: RTG-IDR, OPS-DIR, and IANA early reviews called for
[requested as anticipated document will be in ADs for at least
  3 weeks.]

Personnel:
Document Shepherd:  Susan Hares
AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Review done of technology (5+ years)
Review of the write-ups and web-sites of the implementator
NITS:  a) MUST NOT, b) RFC8126 must replace RFC5226

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No see above write-up for reason.

Early OPS-DIR, RTG-DIR, SEC-DIR, IANA reviews done while in queue.

(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.

(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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.  See discussion above.

(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?
Authors:
Alexander Azimov
https://mailarchive.ietf.org/arch/msg/idr/8uUHqSwjk3AyunpqfkNdtqRL2Yg/

Eugene Bogomazon
https://mailarchive.ietf.org/arch/msg/idr/4261qgyVYEIWcXPFkPruT1w4Xbk/

Randy Bush
https://mailarchive.ietf.org/arch/msg/idr/iEeTEjuq7p4WTrSsfrfPMIilqoQ/

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/elvK3DVaNlxfEWBu66csafbjiIs/

Kotikalapudi Sriram
https://mailarchive.ietf.org/arch/msg/idr/tKgKf-MHP65-VhiVgYAmB3yGoNk/

Contributors:
Brian Dickson
https://mailarchive.ietf.org/arch/msg/idr/EOhETCY7qTEQ4zFdzukVI80Zob0/

Doug Mongomery
https://mailarchive.ietf.org/arch/msg/idr/Q2st99-q2TA22uMuc6iJjedtVQI/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
no

(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?

Strong consensus with broad support from operators, researches, and 2 WGs (IDR, GROW).

The consensus is strong and it links to the following operational documents from the Grow WG:
RFC7908
draft-ietf-grow-route-leak-detection-mitigation-04.txt

The problem and various idea has discussed for over 15 years.
The increasing problem makes the operators push for a resolution.

(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.
none

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
yes

(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?

No changes to existing RFCs.  Existing technolgooy.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Pre-allocation for this draft was already done:

1) capability code  (value 9)
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
9 BGP Role (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy] IETF

2) Error code
8 Role Mismatch (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy[

3) New Transitive Attribute - OTC
35 Only to Customer (OTC) (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy]

These allocation should be made permanent.

(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.

BGP Role Reigstry needs to be IETF Review.

(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.
Only NITs needed

(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?

none

[Ballot comment]
DOWNREF [RFC7908] from this Proposed Standard to Informational RFC7908.
It doesn't look like RFC7908 needs to be a normative reference, so
citing this informationally should address this.

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

Thanks to Gyan S. Mishra for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/bnQ6_d1J8TSN6zw-579JvK8bxkQ).

-------------------------------------------------------------------------------
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 (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1. , paragraph 4, nit:
-    This document specifies a means of replacing the operator driven
-                                                            ^
+    This document specifies a means of replacing the operator-driven
+                                                            ^

Section 4. , paragraph 11, nit:
-    the ingress of the local AS, i.e., if the remote AS is noncompliant
+    the ingress of the local AS, i.e., if the remote AS is non-compliant
+                                                              +

Section 3.1. , paragraph 7, nit:
> , if the BGP Role Capability is sent but one is not received, the BGP Speake
>                                    ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Section 4. , paragraph 8, nit:
> fied in this document are NOT RECOMMENDED to be used between autonomous syste
>                              ^^^^^^^^^^^^^^^^^
The verb "RECOMMENDED" is used with the gerund form.

Section 4. , paragraph 13, nit:
> epresent itself as any one of several different ASes. This should not be a p
>                              ^^^^^^^^^^^^^^^^^
Consider using "several".

Section 7. , paragraph 2, nit:
> will limit route propagation in an unpredictable way. 8. References 8.1. Norm
>                              ^^^^^^^^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "unpredictably" to avoid
wordiness.

These URLs in the document can probably be converted to HTTPS:
* http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-2

[Ballot comment]
Nice work on this.

The shepherd writeup says this document creates a new Expert Review registry and suggests some experts, but the document doesn't actually create any registry as far as I can tell.  Is there something missing in the document, or is the shepherd writeup in error?

[Ballot comment]
Thank you to Alexey Melnikov for the SECDIR review.

I agree with Warren that the following text is too strong:

* Section 4

  The purpose of this attribute is to guarantee
  that once a route is sent to a Customer, Peer, or RS-Client, it will
  subsequently go only to Customers.

Maybe "The purpose of this attribute is to convey ..."

[Ballot comment]
Firstly, thank you for this document -- if deployed, I think it will go a very long way towards reducing accidental leaks.

I have a few comments, feel free to address or not.

1: It seems like there should also be a code-point for "Complex" - I guess that something similar could be inferred if this is negotiated and one of the other codepoints isn't sent, but having it explicit seems cleaner.

2: The document says things like "It **prevents** ASes from creating leaks,..." and "The purpose of this attribute is to **guarantee** the once a route is sent, ..." - it feels like this is overselling things. As an example, the OTC attribute could be stripped (unintentionally or maliciously) and it would be included in a leak, etc. Again, this is only a comment, but it seems like more weasel words would make the document stronger.

3: "If a route with the OTC Attribute is received from a Customer or RS-Client, then it is a route leak and MUST be considered ineligible" - fine, but it seems like there should be a bit more than just "considered ineligible", for example, this should be logged somewhere, or implementations should allow the operator to do the conceptual equivalent of "show route leaked" or similar....

Again, thank you for a really useful document,

[Ballot comment]
Hi,

Thanks for this document.  I'm no expect on BGP, but I found this document pretty easy to read and understand.  Not surprisingly, I'm always supportive of drafts that aim to minimize configuration errors and operational problems.

I have a a few comments though:

(1) Did you consider explicitly defining a code point for the "complex" role?  Today, because of the desire for backwards compatibility, it is not possible for a peer to distinguish between the case that (i) no role has been provided by the peer because it doesn't support roles, and (ii) no role has been provided by the peer because it thinks that it has a "complex" peering relationship.  Unless I'm missing something, adding an explicit role for "complex" would allow the peer to distinguish between these two cases and potentially capture more errors (e.g., complex role is only valid with peer's complex role).  In theory, enabling "strict" checking might also be able to cover this case, it is feels less intuitive (i.e., enable strict, but don't advertise a role to indicate and enforce a complex relationship).

(2) The obvious OPS/Mgmt AD question: Is the associated configuration for this feature covered in the IETF BGP YANG module, or extension/augmentation that is being worked on?  If so, then an informational reference to the configuration leaves associated with this feature might be helpful to readers, although one could perhaps argue that this would end up being a forward reference, and any associated YANG module configuration should have references back to this draft anyhow.

(3) As a nit, I notice that the sender can only include a single role but the receiver must tolerate multiple roles if they have the same value.  Perhaps everything else in BGP is tolerant of receiving malformed packets, and hence this is done for consistency, but I do wonder whether it isn't better to return an error to the peer instead.

Regards,
Rob

[Ballot comment]
Thank you for the work put into this document. The technique could indeed be useful, let's simply hope that not only the well-configured BGP speakers will use it ;-)

Please find below some non-blocking minor COMMENT points (no need to reply).

Special thanks to Susan Hares for the shepherd's write-up including the section about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

Is RFC 7908 really a normative reference ?

-- Section 3.1 --
"An eBGP speaker MUST NOT advertise multiple versions of the BGP Role Capability" Should there be a description of what to do when a eBGP speaker receives multiple conflicting roles on a session ? Or hint to section 3.2 for more details ?

[Ballot comment]
Thanks to Alexey Melnikov for the secdir review and re-review; I echo
his comments about the usefulness of the mechanism and the quality of
the security considerations section.  Thank you for this document!

I'm rather sympathetic to John's remarks about "policy" vs (e.g.)
"procedures".

This document establishes the generic-sounding "BGP Role" capability and
a registry for the corresponding values, but the focus of the technical
mechanisms presented here is to avoid route leakage.  Might there be
other future consumers of BGP Role (perhaps including use of Role for
iBGP to get in-band confirmation of the relationship between peers) that
are unrelated to avoiding route leakage?  Is there anything in this
document we might change to facilitate such future extensions?

Section 6

Subsections for the individual actions/registries being acted upon/in
might aid readability.

Section 8.1

RFC 7908 is referenced only once, in a location that doesn't obviously
induce a normative requirement.  It does seem like a good thing to read
before implementing this document, though, so maybe the takeaway is to
add more references to it rather than demote it to informative.

NITS

Section 1

  Existing approaches to leak prevention rely on marking routes by
  operator configuration, with no check that the configuration
  corresponds to that of the eBGP neighbor, or enforcement that the two
  eBGP speakers agree on the relationship.  This document enhances the

I suggest adding an adjective to "relationship" (maybe "topology"?).

  BGP OPEN message to establish an agreement of the relationship on
  each eBGP session between autonomous systems in order to enforce

Similarly here, though maybe "nature of the relationship" in this
instance.

Section 2

  A BGP speaker may apply policy to reduce what is announced, and a
  recipient may apply policy to reduce the set of routes they accept.
  Violation of the above rules may result in route leaks.  Automatic
  enforcement of these rules should significantly reduce route leaks
  that may otherwise occur due to manual configuration mistakes.

If I understand correctly, "violation of the above rules" refers to the
enumerated rules a few paragraphs prior, and specifically not to the two
applications of policy mentioned in the preceding sentence.  Assuming
that's correct, then it seems useful to clarify the transition between
sentences, perhaps "use of such policies that violate the rules listed
above may result in route leaks" or "when these policies violate the
rules listed above, route leaks may occur".

Section 5

  An operator may want to achieve an equivalent outcome by configuring
  policies on a per-prefix basis to follow the definitions of peering
  relations as described in Section 2.  However, in this case, there
  are no built-in measures to check the correctness of the per-prefix
  peering configuration.

"built-in" is perhaps needlessly vague; we might say "in-band" or "no
measures in the protocol" instead.

Section 7

  Removing the OTC Attribute or changing its value can limit the
  opportunity of route leak detection.  Such activity can be done on

I think s/of/for/

[Ballot comment]
I’m happy to see this document proceeding forward. Thanks for all the work that went into it, and into the shepherding. I do have a few points I’d like to raise.

1. Section 4 talks about policy in several places. As you know, “policy” is a term with quite a bit of baggage in BGP, and without further qualification, it’s likely to be interpreted as “routing policy configured by the router’s operator”. I wondered at first if your choice of “policy” was deliberate, to imply that the specification is not expected to be hard coded into the implementation, but rather configured (or not) by the operator? But, the whole point of the spec is to move away from using policy configuration to protect against route leaks — requiring configuration to enact the import and export “policies” given in §4 would fly in the face of the document’s raison d’être. Furthermore, you close §4 with “the operator MUST NOT have the ability to modify the policies defined in this section” — and that does help, but not before considerable potential confusion is created by the unfortunate choice of terminology.



So, I think you mean that import rules (1)-(3) and export rules (1)-(2) MUST be hard coded into any compliant implementation. I strongly suggest you find a term other than “policy” to express what you mean. For example, “procedures” seems like a good replacement. You could say something like “the following procedures apply to the processing of the OTC Attribute during route reception” and “the following procedures apply to the processing of the OTC Attribute during route transmission”. (You could also try to put it in terms of RFC 4271, but it might be a bit painful.) I just grepped through §4 and a simple replacement of “policy” with “procedure” throughout seems like it would be almost sufficient.



I was ready to make this a DISCUSS until I came to the final sentence of §4. That sentence does clarify matters sufficiently to reach the minimum bar, but I think the document would be even more usable if further edits are made along the lines above.


2. Section 4 says



  The OTC Attribute may be set by the egress policy of the remote AS or

  by the ingress policy of the local AS.



First, my earlier comment about “policy” applies here as well — you could maybe say “on egress from the remote AS or on ingress to the local AS”. Beyond that, I suggest changing the “may” (which is admittedly lower-case”) to a “might”, which has even less risk of confusion with any kind of normative meaning. Presumably what you mean is actually that if the remote AS is noncompliant with this spec, the local AS will have to set the attribute, and this is a feature, not a bug.


3. In Section 4 you write,


  The same OTC Attribute which is set locally also provides
  a way to detect route leaks by an AS multiple hops away if a route is
  received from a Customer, Peer, or RS-Client.

I don’t understand this sentence, as written. I think maybe it needs to be several sentences. I don’t think it’s needed, or even desirable, to explain in detail in this document how you might make use of the OTC Attribute for troubleshooting, but if there’s a different document that does explain it, an informative reference might not hurt. I’m pretty sure I remember this being covered in one or more IDR and/or GROW presentations, but I don’t know if it got written down beyond slide sets.

4. In §1 you say “This document provides configuration automation using BGP Roles”. The document, per se, doesn’t provide any such thing of course — an implementation of the specification would provide such. “This document specifies” would be more correct I think.



A second point related to the same sentence is that it feels like a poor fit to refer to what you do in this spec as configuration automation, a term more usually associated with automatic, typically database-driven, generation and management of (router) configurations. In the second ¶ of §1, you identify configuration as the bad, error-prone, legacy way of preventing route leaks. So maybe something like, “This document specifies a means of replacing the configuration-based method of route leak prevention, described above, with a more automated method using BGP Roles,”

5. In your Terminology Section (§1.1) you define a number of terms that are defined again, immediately, in §2, namely Provider, Customer, RS, RS-Client, and Peer. I think the definitions provided in §2 are better than those in §1.1, and sufficient unto themselves, and that you could remove the first ¶ of §1.1. 


6. You refer to transit and non-transit providers in many places throughout the document. Although these seem to some of us like well-known terms of art that need no reference, I have the feeling that may not be true for our entire community, or worse still, different people might all “know” what it means but with different definitions, and so it might be desirable to provide a citation.

7. Have you given any thought to Autonomous System Migration Mechanisms (RFC 7705)? Mostly, I just have a free-floating unease here, because with the hacks described in RFC 7705, a given router may represent itself as any one of several different ASes, and your spec does ASN embedding and enforcement. Most likely there would be no problem, since the egress rules in §4 suggest the OTC attribute is to be attached as part of route transmission; therefore, a router might be expected to attach whatever value is appropriate based on the ASN it’s currently representing itself as. It might still be worth adding a note cautioning implementors about this, though, since implementations tend to do things for the sake of efficiency that spec authors aren’t expecting. One optimization pattern is to pre-build updates and copy them to many different transport connections; in such cases the OTC value might be prepopulated and the implementor might need to give extra attention to the exception case where a particular transport connection is representing a different ASN from the router's "real" ASN.

[Ballot comment]
I’m happy to see this document proceeding forward. Thanks for all the work that went into it, and into the shepherding. I do have a few points I’d like to raise.

1. Section 4 talks about policy in several places. As you know, “policy” is a term with quite a bit of baggage in BGP, and without further qualification, it’s likely to be interpreted as “routing policy configured by the router’s operator”. I wondered at first if your choice of “policy” was deliberate, to imply that the specification is not expected to be hard coded into the implementation, but rather configured (or not) by the operator? But, the whole point of the spec is to move away from using policy configuration to protect against route leaks — requiring configuration to enact the import and export “policies” given in §4 would fly in the face of the document’s raison d’être. Furthermore, you close §4 with “the operator MUST NOT have the ability to modify the policies defined in this section” — and that does help, but not before considerable potential confusion is created by the unfortunate choice of terminology.



So, I think you mean that import rules (1)-(3) and export rules (1)-(2) MUST be hard coded into any compliant implementation. I strongly suggest you find a term other than “policy” to express what you mean. For example, “procedures” seems like a good replacement. You could say something like “the following procedures apply to the processing of the OTC Attribute during route reception” and “the following procedures apply to the processing of the OTC Attribute during route transmission”. (You could also try to put it in terms of RFC 4271, but it might be a bit painful.) I just grepped through §4 and a simple replacement of “policy” with “procedure” throughout seems like it would be almost sufficient.



I was ready to make this a DISCUSS until I came to the final sentence of §4. That sentence does clarify matters sufficiently to reach the minimum bar, but I think the document would be even more usable if further edits are made along the lines above.


2. Section 4 says



  The OTC Attribute may be set by the egress policy of the remote AS or

  by the ingress policy of the local AS.



First, my earlier comment about “policy” applies here as well — you could maybe say “on egress from the remote AS or on ingress to the local AS”. Beyond that, I suggest changing the “may” (which is admittedly lower-case”) to a “might”, which has even less risk of confusion with any kind of normative meaning. Presumably what you mean is actually that if the remote AS is noncompliant with this spec, the local AS will have to set the attribute, and this is a feature, not a bug.


3. In Section 4 you write,


  The same OTC Attribute which is set locally also provides
  a way to detect route leaks by an AS multiple hops away if a route is
  received from a Customer, Peer, or RS-Client.

I don’t understand this sentence, as written. I think maybe it needs to be several sentences. I don’t think it’s needed, or even desirable, to explain in detail in this document how you might make use of the OTC Attribute for troubleshooting, but if there’s a different document that does explain it, an informative reference might not hurt. I’m pretty sure I remember this being covered in one or more IDR and/or GROW presentations, but I don’t know if it got written down beyond slide sets.

4. In §1 you say “This document provides configuration automation using BGP Roles”. The document, per se, doesn’t provide any such thing of course — an implementation of the specification would provide such. “This document specifies” would be more correct I think.



A second point related to the same sentence is that it feels like a poor fit to refer to what you do in this spec as configuration automation, a term more usually associated with automatic, typically database-driven, generation and management of (router) configurations. In the second ¶ of §1, you identify configuration as the bad, error-prone, legacy way of preventing route leaks. So maybe something like, “This document specifies a means of replacing the configuration-based method of route leak prevention, described above, with a more automated method using BGP Roles,”

5. In your Terminology Section (§1.1) you define a number of terms that are defined again, immediately, in §2, namely Provider, Customer, RS, RS-Client, and Peer. I think the definitions provided in §2 are better than those in §1.1, and sufficient unto themselves, and that you could remove the first ¶ of §1.1. 


6. You refer to transit and non-transit providers in many places throughout the document. Although these seem to some of us like well-known terms of art that need no reference, I have the feeling that may not be true for our entire community, or worse still, different people might all “know” what it means but with different definitions, and so it might be desirable to provide a citation.

7. Have you given any thought to Autonomous System Migration Mechanisms (RFC 7705)? Mostly, I just have a free-floating unease here, because with the hacks described in RFC 7705, a given router may represent itself as any one of several different ASes, and your spec does ASN embedding and enforcement. Most likely there would be no problem, since the egress rules in §4 suggest the OTC attribute is to be attached as part of route transmission; therefore, a router might be expected to attach whatever value is appropriate based on the ASN it’s currently representing itself as. It might still be worth adding a note cautioning implementors about this, though, since implementations tend to do things for the sake of efficiency that spec authors aren’t expecting. One optimization pattern is to pre-build updates and copy them to many different transport connections; in such cases the OTC value might be prepopulated and the implementor might need to give extra attention to the exception case where a particular transport connection is representing a different ASN.

[Ballot comment]
I’m happy to see this document proceeding forward. Thanks for all the work that went into it, and into the shepherding. I do have a few points I’d like to raise.

1. Section 4 talks about policy in several places. As you know, “policy” is a term with quite a bit of baggage in BGP, and without further qualification, it’s likely to be interpreted as “routing policy configured by the router’s operator”. I wondered at first if your choice of “policy” was deliberate, to imply that the specification is not expected to be hard coded into the implementation, but rather configured (or not) by the operator? But, the whole point of the spec is to move away from using policy configuration to protect against route leaks — requiring configuration to enact the import and export “policies” given in §4 would fly in the face of the document’s raison d’être. Furthermore, you close §4 with “the operator MUST NOT have the ability to modify the policies defined in this section” — and that does help, but not before considerable potential confusion is created by the unfortunate choice of terminology.



So, I think you mean that import rules (1)-(3) and export rules (1)-(2) MUST be hard coded into any compliant implementation. I strongly suggest you find a term other than “policy” to express what you mean. For example, “procedures” seems like a good replacement. You could say something like “the following procedures apply to the processing of the OTC Attribute during route reception” and “the following procedures apply to the processing of the OTC Attribute during route transmission”. (You could also try to put it in terms of RFC 4271, but it might be a bit painful.) I just grepped through §4 and a simple replacement of “policy” with “procedure” throughout seems like it would be almost sufficient.



I was ready to make this a DISCUSS until I came to the final sentence of §4. That sentence does clarify matters sufficiently to reach the minimum bar, but I think the document would be even more usable if further edits are made along the lines above.


2. Section 4 says



  The OTC Attribute may be set by the egress policy of the remote AS or

  by the ingress policy of the local AS.



First, my earlier comment about “policy” applies here as well — you could maybe say “on egress from the remote AS or on ingress to the local AS”. Beyond that, I suggest changing the “may” (which is admittedly lower-case”) to a “might”, which has even less risk of confusion with any kind of normative meaning. Presumably what you mean is actually that if the remote AS is noncompliant with this spec, the local AS will have to set the attribute, and this is a feature, not a bug.


3. In Section 4 you write,


  The same OTC Attribute which is set locally also provides
  a way to detect route leaks by an AS multiple hops away if a route is
  received from a Customer, Peer, or RS-Client.

I don’t understand this sentence, as written. I think maybe it needs to be several sentences. I don’t think it’s needed, or even desirable, to explain in detail in this document how you might make use of the OTC Attribute for troubleshooting, but if there’s a different document that does explain it, an informative reference might not hurt. I’m pretty sure I remember this being covered in one or more IDR and/or GROW presentations, but I don’t know if it got written down beyond slide sets.

4. In §1 you say “This document provides configuration automation using BGP Roles”. The document, per se, doesn’t provide any such thing of course — an implementation of the specification would provide such. “This document specifies” would be more correct I think.



A second point related to the same sentence is that it feels like a poor fit to refer to what you do in this spec as configuration automation, a term more usually associated with automatic, typically database-driven, generation and management of (router) configurations. In the second ¶ of §1, you identify configuration as the bad, error-prone, legacy way of preventing route leaks. So maybe something like, “This document specifies a means of replacing the configuration-based method of route leak prevention, described above, with a more automated method using BGP Roles,”

5. In your Terminology Section (§1.1) you define a number of terms that are defined again, immediately, in §2, namely Provider, Customer, RS, RS-Client, and Peer. I think the definitions provided in §2 are better than those in §1.1, and sufficient unto themselves, and that you could remove the first ¶ of §1.1. 


6. You refer to transit and non-transit providers in many places throughout the document. Although these seem to some of us like well-known terms of art that need no reference, I have the feeling that may not be true for our entire community, or worse still, different people might all “know” what it means but with different definitions, and so it might be desirable to provide a citation.

7. Have you given any thought to Autonomous System Migration Mechanisms (RFC 7705)? Mostly, I just have a free-floating concern here, because with the hacks described in RFC 7705, a given router may represent itself as any one of several different ASes, and your spec does ASN embedding and enforcement. Most likely there would be no problem, since the egress rules in §4 suggest the OTC attribute is to be attached as part of route transmission; therefore, a router might be expected to attach whatever value is appropriate based on the ASN it’s currently representing itself as. It might still be worth adding a note cautioning implementors about this, though, since implementations tend to do things for the sake of efficiency that spec authors aren’t expecting. One optimization pattern is to pre-build updates and copy them to many different transport connections; in such cases the OTC value might be prepopulated and the implementor might need to give extra attention to the exception case where a particular transport connection is representing a different ASN.

[Ballot comment]
I’m happy to see this document proceeding forward. Thanks for all the work that went into it, and into the shepherding. I do have a few points I’d like to raise.

1. Section 4 talks about policy in several places. As you know, “policy” is a term with quite a bit of baggage in BGP, and without further qualification, it’s likely to be interpreted as “routing policy configured by the router’s operator”. I wondered at first if your choice of “policy” was deliberate, to imply that the specification is not expected to be hard coded into the implementation, but rather configured (or not) by the operator? But, the whole point of the spec is to move away from using policy configuration to protect against route leaks — requiring configuration to enact the import and export “policies” given in §4 would fly in the face of the document’s raison d’être. Furthermore, you close §4 with “the operator MUST NOT have the ability to modify the policies defined in this section” — and that does help, but not before considerable potential confusion is created by the unfortunate choice of terminology.



So, I think you mean that import rules (1)-(3) and export rules (1)-(2) MUST be hard coded into any compliant implementation. I strongly suggest you find a term other than “policy” to express what you mean. For example, “procedures” seems like a good replacement. You could say something like “the following procedures apply to the processing of the OTC Attribute during route reception” and “the following procedures apply to the processing of the OTC Attribute during route transmission”. (You could also try to put it in terms of RFC 4271, but it might be a bit painful.) I just grepped through §4 and a simple replacement of “policy” with “procedure” throughout seems like it would be almost sufficient.



I was ready to make this a DISCUSS until I came to the final sentence of §4. That sentence does clarify matters sufficiently to reach the minimum bar, but I think the document would be even more usable if further edits are made along the lines above.


2. Section 4 says



  The OTC Attribute may be set by the egress policy of the remote AS or

  by the ingress policy of the local AS.



First, my earlier comment about “policy” applies here as well — you could maybe say “on egress from the remote AS or on ingress to the local AS”. Beyond that, I suggest changing the “may” (which is admittedly lower-case”) to a “might”, which has even less risk of confusion with any kind of normative meaning. Presumably what you mean is actually that if the remote AS is noncompliant with this spec, the local AS will have to set the attribute, and this is a feature, not a bug.


3. In Section 4 you write,


  The same OTC Attribute which is set locally also provides
  a way to detect route leaks by an AS multiple hops away if a route is
  received from a Customer, Peer, or RS-Client.

I don’t understand this sentence, as written. I think maybe it needs to be several sentences. I don’t think it’s needed, or even desirable, to explain in detail in this document how you might make use of the OTC Attribute for troubleshooting, but if there’s a different document that does explain it, an informative reference might not hurt. I’m pretty sure I remember this being covered in one or more IDR and/or GROW presentations, but I don’t know if it got written down beyond slide sets.

4. In §1 you say “This document provides configuration automation using BGP Roles”. The document, per se, doesn’t provide any such thing of course — an implementation of the specification would provide such. “This document specifies” would be more correct I think.



A second point related to the same sentence is that it feels like a poor fit to refer to what you do in this spec as configuration automation, a term more usually associated with automatic, typically database-driven, generation and management of (router) configurations. In the second ¶ of §1, you identify configuration as the bad, error-prone, legacy way of preventing route leaks. So maybe something like, “This document specifies a means of replacing the configuration-based method of route leak prevention, described above, with a more automated method using BGP Roles,”

5. In your Terminology Section (§1.1) you define a number of terms that are defined again, immediately, in §2, namely Provider, Customer, RS, RS-Client, and Peer. I think the definitions provided in §2 are better than those in §1.1, and sufficient unto themselves, and that you could remove the first ¶ of §1.1. 


6. You refer to transit and non-transit providers in many places throughout the document. Although these seem to some of us like well-known terms of art that need no reference, I have the feeling that may not be true for our entire community, or worse still, different people might all “know” what it means but with different definitions, and so it might be desirable to provide a citation.

7. Have you given any thought to Autonomous System Migration Mechanisms (RFC 7705)? Mostly, I just have a free-floating concern here, because with the hacks described in RFC 7705, a given router may represent itself as any one of several different ASes, and you do ASN embedding and enforcement. Most likely there would be no problem, since the egress rules in §4 suggest the OTC attribute is to be attached as part of route transmission; therefore, a router might be expected to attach whatever value is appropriate based on the ASN it’s currently representing itself as. It might still be worth adding a note cautioning implementors about this, though, since implementations tend to do things for the sake of efficiency that spec authors aren’t expecting. One optimization pattern is to pre-build updates and copy them to many different transport connections; in such cases the OTC value might be prepopulated and the implementor might need to give extra attention to the exception case where a particular transport connection is representing a different ASN.

[Ballot comment]
I’m happy to see this document proceeding forward. Thanks for all the work that went into it, and into the shepherding. I do have a few points I’d like to raise.

1. Section 4 talks about policy in several places. As you know, “policy” is a term with quite a bit of baggage in BGP, and without further qualification, it’s likely to be interpreted as “routing policy configured by the router’s operator”. I wondered at first if your choice of “policy” was deliberate, to imply that the specification is not expected to be hard coded into the implementation, but rather configured (or not) by the operator? But, the whole point of the spec is to move away from using policy configuration to protect against route leaks — requiring configuration to enact the import and export “policies” given in §4 would fly in the face of the document’s raison d’être. Furthermore, you close §4 with “the operator MUST NOT have the ability to modify the policies defined in this section” — and that does help, but not before considerable potential confusion is created by the unfortunate choice of terminology.



So, I think you mean that import rules (1)-(3) and export rules (1)-(2) MUST be hard coded into any compliant implementation. I strongly suggest you find a term other than “policy” to express what you mean. For example, “procedures” seems like a good replacement. You could say something like “the following procedures apply to the processing of the OTC Attribute during route reception” and “the following procedures apply to the processing of the OTC Attribute during route transmission”. (You could also try to put it in terms of RFC 4271, but it might be a bit painful.) I just grepped through §4 and a simple replacement of “policy” with “procedure” throughout seems like it would be almost sufficient.



I was ready to make this a DISCUSS until I came to the final sentence of §4. That sentence does clarify matters sufficiently to reach the minimum bar, but I think the document would be even more usable if further edits are made along the lines above.


2. Section 4 says



  The OTC Attribute may be set by the egress policy of the remote AS or

  by the ingress policy of the local AS.



First, my earlier comment about “policy” applies here as well — you could maybe say “on egress from the remote AS or on ingress to the local AS”. Beyond that, I suggest changing the “may” (which is admittedly lower-case”) to a “might”, which has even less risk of confusion with any kind of normative meaning. Presumably what you mean is actually that if the remote AS is noncompliant with this spec, the local AS will have to set the attribute, and this is a feature, not a bug.


3. In Section 4 you write,


  The same OTC Attribute which is set locally also provides
  a way to detect route leaks by an AS multiple hops away if a route is
  received from a Customer, Peer, or RS-Client.

I don’t understand this sentence, as written. I think maybe it needs to be several sentences. I don’t think it’s needed, or even desirable, to explain in detail in this document how you might make use of the OTC Attribute for troubleshooting, but if there’s a different document that does explain it, an informative reference might not hurt. I’m pretty sure I remember this being covered in one or more IDR and/or GROW presentations, but I don’t know if it got written down beyond slide sets.

4. In §1 you say “This document provides configuration automation using BGP Roles”. The document, per se, doesn’t provide any such thing of course — an implementation of the specification would provide such. “This document specifies” would be more correct I think.



A second point related to the same sentence is that it feels like a poor fit to refer to what you do in this spec as configuration automation, a term more usually associated with, well, automatic, typically database-driven, generation and management of (router) configurations. In the second ¶ of §1, you identify configuration as the bad, error-prone, legacy way of preventing route leaks. So maybe something like, “This document specifies a means of replacing the configuration-based method of route leak prevention, described above, with a more automated method using BGP Roles,”

5. In your Terminology Section (§1.1) you define a number of terms that are defined again, immediately, in §2, namely Provider, Customer, RS, RS-Client, and Peer. I think the definitions provided in §2 are better than those in §1.1, and sufficient unto themselves, and that you could remove the first ¶ of §1.1. 


6. You refer to transit and non-transit providers in many places throughout the document. Although these seem to some of us like well-known terms of art that need no reference, I have the feeling that may not be true for our entire community, or worse still, different people might all “know” what it means but with different definitions, and so it might be desirable to provide a citation.

7. Have you given any thought to Autonomous System Migration Mechanisms (RFC 7705)? Mostly, I just have a free-floating concern here, because with the hacks described in RFC 7705, a given router may represent itself as any one of several different ASes, and you do ASN embedding and enforcement. Most likely there would be no problem, since the egress rules in §4 suggest the OTC attribute is to be attached as part of route transmission; therefore, a router might be expected to attach whatever value is appropriate based on the ASN it’s currently representing itself as. It might still be worth adding a note cautioning implementors about this, though, since implementations tend to do things for the sake of efficiency that spec authors aren’t expecting. One optimization pattern is to pre-build updates and copy them to many different transport connections; in such cases the OTC value might be prepopulated and the implementor might need to give extra attention to the exception case where a particular transport connection is representing a different ASN.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-bgp-open-policy-18. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First in the Capability Codes registry located at:

https://www.iana.org/assignments/capability-codes/

the temporary registration for:

Value: 9
Description: BGP Role

will be made permanent and its reference changed to [ RFC-to-be ].

Second, a new registry is to be created called the BGP Role Value registry. The new registry will be located on the Capability Codes registry page located at:

https://www.iana.org/assignments/capability-codes/

The registry will be managed via IETF Review as defined by RFC8126. There are initial registrations in the new registry as follows:

+-------+--------------------------------+---------------+
| Value | Role name (for the local AS) | Reference |
+-------+--------------------------------+---------------+
| 0 | Provider | [ RFC-To-be ] |
| 1 | RS | [ RFC-To-be ] |
| 2 | RS-Client | [ RFC-To-be ] |
| 3 | Customer | [ RFC-To-be ] |
| 4 | Peer (i.e., Lateral Peer) | [ RFC-To-be ] |
| 5-255 | Unassigned | |
+-------+--------------------------------+---------------+

Third, in the OPEN Message Error subcodes registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the temporary registration for:

Value: 8
Name: Role Mismatch

will be made permanent and its reference changed to [ RFC-to-be ].

Fourth, in the BGP Path Attributes registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the temporary registration for:

Value: 35
Name: Only to Customer (OTC)

will be made permanent and its reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-12-17):

From: The IESG
To: IETF-Announce
CC: Susan Hares , aretana.ietf@gmail.com, draft-ietf-idr-bgp-open-policy@ietf.org, idr-chairs@ietf.org, idr@ietf.org, shares@ndzh.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Route Leak Prevention and Detection using Roles in UPDATE and OPEN Messages) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Route Leak Prevention and Detection using
Roles in UPDATE and OPEN
  Messages'
  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-12-17. 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


  Route leaks are the propagation of BGP prefixes that violate
  assumptions of BGP topology relationships, e.g., announcing a route
  learned from one transit provider to another transit provider or a
  lateral (i.e., non-transit) peer or announcing a route learned from
  one lateral peer to another lateral peer or a transit provider.
  These are usually the result of misconfigured or absent BGP route
  filtering or lack of coordination between autonomous systems (ASes).
  Existing approaches to leak prevention rely on marking routes by
  operator configuration, with no check that the configuration
  corresponds to that of the eBGP neighbor, or enforcement that the two
  eBGP speakers agree on the relationship.  This document enhances the
  BGP OPEN message to establish an agreement of the relationship on
  each eBGP session between autonomous systems in order to enforce
  appropriate configuration on both sides.  Propagated routes are then
  marked according to the agreed relationship, allowing both prevention
  and detection of route leaks.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7908: Problem Definition and Classification of BGP Route Leaks (Informational - Internet Engineering Task Force (IETF))
    rfc7938: Use of BGP for Routing in Large-Scale Data Centers (Informational - Internet Engineering Task Force (IETF))

(1) What type of RFC is being requested  (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Type: Proposed Standard
Why proper: Adds a capability to the BGP OPEN and a BGP attribute for Only to the customer
Listed in title page: Yes


(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:
  Route leaks are the propagation of BGP prefixes which violate
  assumptions of BGP topology relationships; e.g. passing a route
  learned from one lateral peer to another lateral peer or a transit
  provider, passing a route learned from one transit provider to
  another transit provider or a lateral peer.  Existing approaches to
  leak prevention rely on marking routes by operator configuration,
  with no check that the configuration corresponds to that of the eBGP
  neighbor, or enforcement that the two eBGP speakers agree on the
  relationship. 

 
  This document enhances BGP OPEN to establish agreement
  of the (peer, customer, provider, Route Server, Route Server client)
  relationship of two neighboring eBGP speakers to enforce appropriate
  configuration on both sides.  Propagated routes are then marked with
  an Only to Customer (OTC) attribute according to the agreed
  relationship, allowing both prevention and detection of route leaks.

Working Group Summary:
Route leaks are a problem that plague the operational Internet for over 20 years.
The WG group consensus for this draft goes across two WGs (GROW and IDR)
with both working group lending their support to define the problem
and design a series of fixes that can be deployed in operational networks.
While the discussions have been lengthy, there is solid support between
operators, researchers, and the membesrs of 2 WGs (GROW and IDR).
standardize the changs to the OPEN and the additions of an "only
to customer" (OTC) flag.

Document Quality:
The shepherd has been an active part of guiding this discussion in IDR and
grow for over 5 years.  The work from NIST (Doug Montgomery and  K. Sriram)
Brian Dickson, Randy Bush (IIJ, Arrcus), Keyur Patel (Arrcus), and
Alexander Azimov and Eugene Bogomazov has investigated
the technology from many angles.  The operators and the authors
have word smithed in the last editions to the shepherd's
satisfaction.

Existing implementations:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy

No MIB, Yang, or Media review: none needed.
Key review:  Cross-review with Grow WG that depends on this work
Reviews in Progress: RTG-IDR, OPS-DIR, and IANA early reviews called for
[requested as anticipated document will be in ADs for at least
  3 weeks.]

Personnel:
Document Shepherd:  Susan Hares
AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Review done of technology (5+ years)
Review of the write-ups and web-sites of the implementator
NITS:  a) MUST NOT, b) RFC8126 must replace RFC5226

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No see above write-up for reason.

Early OPS-DIR, RTG-DIR, SEC-DIR, IANA reviews done while in queue.

(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.

(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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.  See discussion above.

(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?
Authors:
Alexander Azimov
https://mailarchive.ietf.org/arch/msg/idr/8uUHqSwjk3AyunpqfkNdtqRL2Yg/

Eugene Bogomazon
https://mailarchive.ietf.org/arch/msg/idr/4261qgyVYEIWcXPFkPruT1w4Xbk/

Randy Bush
https://mailarchive.ietf.org/arch/msg/idr/iEeTEjuq7p4WTrSsfrfPMIilqoQ/

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/elvK3DVaNlxfEWBu66csafbjiIs/

Kotikalapudi Sriram
https://mailarchive.ietf.org/arch/msg/idr/tKgKf-MHP65-VhiVgYAmB3yGoNk/

Contributors:
Brian Dickson
https://mailarchive.ietf.org/arch/msg/idr/EOhETCY7qTEQ4zFdzukVI80Zob0/

Doug Mongomery
https://mailarchive.ietf.org/arch/msg/idr/Q2st99-q2TA22uMuc6iJjedtVQI/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
no

(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?

Strong consensus with broad support from operators, researches, and 2 WGs (IDR, GROW).

The consensus is strong and it links to the following operational documents from the Grow WG:
RFC7908
draft-ietf-grow-route-leak-detection-mitigation-04.txt

The problem and various idea has discussed for over 15 years.
The increasing problem makes the operators push for a resolution.

(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.

NITS:  (1/13/2021) --
a) MUST not --- moved to MUST NOT
b) RFC8126 -- must replace RFC5226

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
yes

(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?

No changes to existing RFCs.  Existing technolgooy.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Pre-allocation for this draft was already done:

1) capability code  (value 9)
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
9 BGP Role (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy] IETF

2) Error code
8 Role Mismatch (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy[

3) New Transitive Attribute - OTC
35 Only to Customer (OTC) (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy]

These allocation should be made permanent.

(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.

BGP Role Reigstry needs to be Expert Review. 
Potential Experts (Randy Bush, Grow chairs,  Warren Kumari, K. Sriram, Alexander Azimov)

(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.
Only NITs needed

(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?

none

(1) What type of RFC is being requested  (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Type: Proposed Standard
Why proper: Adds a capability to the BGP OPEN and a BGP attribute for Only to the customer
Listed in title page: Yes


(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:
  Route leaks are the propagation of BGP prefixes which violate
  assumptions of BGP topology relationships; e.g. passing a route
  learned from one lateral peer to another lateral peer or a transit
  provider, passing a route learned from one transit provider to
  another transit provider or a lateral peer.  Existing approaches to
  leak prevention rely on marking routes by operator configuration,
  with no check that the configuration corresponds to that of the eBGP
  neighbor, or enforcement that the two eBGP speakers agree on the
  relationship. 

 
  This document enhances BGP OPEN to establish agreement
  of the (peer, customer, provider, Route Server, Route Server client)
  relationship of two neighboring eBGP speakers to enforce appropriate
  configuration on both sides.  Propagated routes are then marked with
  an Only to Customer (OTC) attribute according to the agreed
  relationship, allowing both prevention and detection of route leaks.

Working Group Summary:
Route leaks are a problem that plague the operational Internet for over 20 years.
The WG group consensus for this draft goes across two WGs (GROW and IDR)
with both working group lending their support to define the problem
and design a series of fixes that can be deployed in operational networks.
While the discussions have been lengthy, there is solid support between
operators, researchers, and the membesrs of 2 WGs (GROW and IDR).
standardize the changs to the OPEN and the additions of an "only
to customer" (OTC) flag.

Document Quality:
The shepherd has been an active part of guiding this discussion in IDR and
grow for over 5 years.  The work from NIST (Doug Montgomery and  K. Sriram)
Brian Dickson, Randy Bush (IIJ, Arrcus), Keyur Patel (Arrcus), and
Alexander Azimov and Eugene Bogomazov has investigated
the technology from many angles.  The operators and the authors
have word smithed in the last editions to the shepherd's
satisfaction.

Existing implementations:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy

No MIB, Yang, or Media review: none needed.
Key review:  Cross-review with Grow WG that depends on this work
Reviews in Progress: RTG-IDR, OPS-DIR, and IANA early reviews called for
[requested as anticipated document will be in ADs for at least
  3 weeks.]

Personnel:
Document Shepherd:  Susan Hares
AD: Alvaro Retana

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Review done of technology (5+ years)
Review of the write-ups and web-sites of the implementator
NITS:  a) MUST NOT, b) RFC8126 must replace RFC5226

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No see above write-up for reason.

Early OPS-DIR, RTG-DIR, SEC-DIR, IANA reviews done while in queue.

(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.

(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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.  See discussion above.

(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?
Authors:
Alexander Azimov
https://mailarchive.ietf.org/arch/msg/idr/8uUHqSwjk3AyunpqfkNdtqRL2Yg/

Eugene Bogomazon
https://mailarchive.ietf.org/arch/msg/idr/4261qgyVYEIWcXPFkPruT1w4Xbk/

Randy Bush
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/elvK3DVaNlxfEWBu66csafbjiIs/

Kotikalapudi Sriram
https://mailarchive.ietf.org/arch/msg/idr/tKgKf-MHP65-VhiVgYAmB3yGoNk/

Contributors:
Brian Dickson
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Doug Mongomery
https://mailarchive.ietf.org/arch/msg/idr/Q2st99-q2TA22uMuc6iJjedtVQI/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
no

(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?

Strong consensus with broad support from operators, researches, and 2 WGs (IDR, GROW).

The consensus is strong and it links to the following operational documents from the Grow WG:
RFC7908
draft-ietf-grow-route-leak-detection-mitigation-04.txt

The problem and various idea has discussed for over 15 years.
The increasing problem makes the operators push for a resolution.

(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.

NITS:  (1/13/2021) --
a) MUST not --- moved to MUST NOT
b) RFC8126 -- must replace RFC5226

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
yes

(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?

No changes to existing RFCs.  Existing technolgooy.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Pre-allocation for this draft was already done:

1) capability code  (value 9)
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
9 BGP Role (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy] IETF

2) Error code
8 Role Mismatch (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy[

3) New Transitive Attribute - OTC
35 Only to Customer (OTC) (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy]

These allocation should be made permanent.

(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.

BGP Role Reigstry needs to be Expert Review. 
Potential Experts (Randy Bush, Grow chairs,  Warren Kumari, K. Sriram, Alexander Azimov)

(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.
Only NITs needed

(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?

none

(1) What type of RFC is being requested  (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Type: Proposed Standard
Why proper: Adds a capability to the BGP OPEN and a BGP attribute for Only to the customer
Listed in title page: Yes


(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:
  Route leaks are the propagation of BGP prefixes which violate
  assumptions of BGP topology relationships; e.g. passing a route
  learned from one lateral peer to another lateral peer or a transit
  provider, passing a route learned from one transit provider to
  another transit provider or a lateral peer.  Existing approaches to
  leak prevention rely on marking routes by operator configuration,
  with no check that the configuration corresponds to that of the eBGP
  neighbor, or enforcement that the two eBGP speakers agree on the
  relationship. 

 
  This document enhances BGP OPEN to establish agreement
  of the (peer, customer, provider, Route Server, Route Server client)
  relationship of two neighboring eBGP speakers to enforce appropriate
  configuration on both sides.  Propagated routes are then marked with
  an Only to Customer (OTC) attribute according to the agreed
  relationship, allowing both prevention and detection of route leaks.

Working Group Summary:
Route leaks are a problem that plague the operational Internet for over 20 years.
The WG group consensus for this draft goes across two WGs (GROW and IDR)
with both working group lending their support to define the problem
and design a series of fixes that can be deployed in operational networks.
While the discussions have been lengthy, there is solid support between
operators, researchers, and the membesrs of 2 WGs (GROW and IDR).
standardize the changs to the OPEN and the additions of an "only
to customer" (OTC) flag.

Document Quality:
The shepherd has been an active part of guiding this discussion in IDR and
grow for over 5 years.  The work from NIST (Doug Montgomery and  K. Sriram)
Brian Dickson, Randy Bush (IIJ, Arrcus), Keyur Patel (Arrcus), and
Alexander Azimov and Eugene Bogomazov has investigated
the technology from many angles.  The operators and the authors
have word smithed in the last editions to the shepherd's
satisfaction.

Existing implementations:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy

No MIB, Yang, or Media review: none needed.
Key review:  Cross-review with Grow WG that depends on this work
Reviews in Progress: RTG-IDR, OPS-DIR, and IANA early reviews called for
[requested as anticipated document will be in ADs for at least
  3 weeks.]

Personnel:
Document Shepherd:  Susan Hares
AD: Alvaro Retana
Co-chairs: Susan Hares and John Scudder.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Review done of technology (5+ years)
Review of the write-ups and web-sites of the implementator
NITS:  a) MUST NOT, b) RFC8126 must replace RFC5226

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No see above write-up for reason.

Early OPS-DIR, RTG-DIR, SEC-DIR, IANA reviews done while in queue.

(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.

(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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.  See discussion above.

(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?
Authors:
Alexander Azimov
https://mailarchive.ietf.org/arch/msg/idr/8uUHqSwjk3AyunpqfkNdtqRL2Yg/

Eugene Bogomazon
https://mailarchive.ietf.org/arch/msg/idr/4261qgyVYEIWcXPFkPruT1w4Xbk/

Randy Bush
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/elvK3DVaNlxfEWBu66csafbjiIs/

Kotikalapudi Sriram
https://mailarchive.ietf.org/arch/msg/idr/tKgKf-MHP65-VhiVgYAmB3yGoNk/

Contributors:
Brian Dickson
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Doug Mongomery
https://mailarchive.ietf.org/arch/msg/idr/Q2st99-q2TA22uMuc6iJjedtVQI/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
no

(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?

Strong consensus with broad support from operators, researches, and 2 WGs (IDR, GROW).

The consensus is strong and it links to the following operational documents from the Grow WG:
RFC7908
draft-ietf-grow-route-leak-detection-mitigation-04.txt

The problem and various idea has discussed for over 15 years.
The increasing problem makes the operators push for a resolution.

(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.

NITS:  (1/13/2021) --
a) MUST not --- moved to MUST NOT
b) RFC8126 -- must replace RFC5226

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
yes

(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?

No changes to existing RFCs.  Existing technolgooy.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Pre-allocation for this draft was already done:

1) capability code  (value 9)
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
9 BGP Role (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy] IETF

2) Error code
8 Role Mismatch (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy[

3) New Transitive Attribute - OTC
35 Only to Customer (OTC) (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy]

These allocation should be made permanent.

(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.

BGP Role Reigstry needs to be Expert Review. 
Potential Experts (Randy Bush, Grow chairs,  Warren Kumari, K. Sriram, Alexander Azimov)

(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.
Only NITs needed

(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?

none

(1) What type of RFC is being requested  (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Type: Proposed Standard
Why proper: Adds a capability to the BGP OPEN and a BGP attribute for Only to the customer
Listed in title page: Yes


(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:
  Route leaks are the propagation of BGP prefixes which violate
  assumptions of BGP topology relationships; e.g. passing a route
  learned from one lateral peer to another lateral peer or a transit
  provider, passing a route learned from one transit provider to
  another transit provider or a lateral peer.  Existing approaches to
  leak prevention rely on marking routes by operator configuration,
  with no check that the configuration corresponds to that of the eBGP
  neighbor, or enforcement that the two eBGP speakers agree on the
  relationship. 

 
  This document enhances BGP OPEN to establish agreement
  of the (peer, customer, provider, Route Server, Route Server client)
  relationship of two neighboring eBGP speakers to enforce appropriate
  configuration on both sides.  Propagated routes are then marked with
  an Only to Customer (OTC) attribute according to the agreed
  relationship, allowing both prevention and detection of route leaks.

Working Group Summary:
Route leaks are a problem that plague the operational Internet for over 20 years.
The WG group consensus for this draft goes across two WGs (GROW and IDR)
with both working group lending their support to define the problem
and design a series of fixes that can be deployed in operational networks.
While the discussions have been lengthy, there is solid support between
operators, researchers, and the membesrs of 2 WGs (GROW and IDR).
standardize the changs to the OPEN and the additions of an "only
to customer" (OTC) flag.

Document Quality:
The shepherd has been an active part of guiding this discussion in IDR and
grow for over 5 years.  The work from NIST (Doug Montgomery and  K. Sriram)
Brian Dickson, Randy Bush (IIJ, Arrcus), Keyur Patel (Arrcus), and
Alexander Azimov and Eugene Bogomazov has investigated
the technology from many angles.  The operators and the authors
have word smithed in the last editions to the shepherd's
satisfaction.

Existing implementations:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy

No MIB, Yang, or Media review: none needed.
Key review:  Cross-review with Grow WG that depends on this work
Reviews in Progress: RTG-IDR, OPS-DIR, and IANA early reviews called for
[requested as anticipated document will be in ADs for at least
  3 weeks.]

Personnel:
Document Shepherd:  Susan Hares
AD: Alvaro Retana
Co-chairs: Susan Hares and John Scudder.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Review done of technology (5+ years)
Review of the write-ups and web-sites of the implementator
NITS:  a) MUST NOT, b) RFC8126 must replace RFC5226

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No see above write-up for reason.

Early OPS-DIR, RTG-DIR, SEC-DIR, IANA reviews done while in queue.

(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.

(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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.  See discussion above.

(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?
Authors:
Alexander Azimov
https://mailarchive.ietf.org/arch/msg/idr/8uUHqSwjk3AyunpqfkNdtqRL2Yg/

Eugene Bogomazon
https://mailarchive.ietf.org/arch/msg/idr/4261qgyVYEIWcXPFkPruT1w4Xbk/

Randy Bush
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/elvK3DVaNlxfEWBu66csafbjiIs/

Kotikalapudi Sriram
https://mailarchive.ietf.org/arch/msg/idr/tKgKf-MHP65-VhiVgYAmB3yGoNk/

Contributors:
Brian Dickson
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Doug Mongomery
https://mailarchive.ietf.org/arch/msg/idr/Q2st99-q2TA22uMuc6iJjedtVQI/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
no

(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?

Strong consensus with broad support from operators, researches, and 2 WGs (IDR, GROW).

The consensus is strong and it links to the following operational documents from the Grow WG:
RFC7908,  RFC8212 (updates RFC4271),
draft-ietf-grow-route-leak-detection-mitigation-04.txt

The problem and various idea has discussed for over 15 years.
The increasing problem makes the operators push for a resolution.

(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.

NITS:  (1/13/2021) --
a) MUST not --- moved to MUST NOT
b) RFC8126 -- must replace RFC5226

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
yes

(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?

No changes to existing RFCs.  Existing technolgooy.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Pre-allocation for this draft was already done:

1) capability code  (value 9)
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
9 BGP Role (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy] IETF

2) Error code
8 Role Mismatch (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy[

3) New Transitive Attribute - OTC
35 Only to Customer (OTC) (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy]

These allocation should be made permanent.

(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.

BGP Role Reigstry needs to be Expert Review. 
Potential Experts (Randy Bush, Grow chairs,  Warren Kumari, K. Sriram, Alexander Azimov)

(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.
Only NITs needed

(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?

none

Shepherd waits on: -15 with NITs fixed

NITS:  (1/13/2021) --
a) MUST not --- moved to MUST NOT
b)RFC8126 -- must replace RFC5226

Date of write-up form: 11/1/2019


(1) What type of RFC is being requested  (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Type: Proposed Standard
Why proper: Adds a capability to the BGP OPEN and a BGP attribute for Only to the customer
Listed in title page: Yes


(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:
  Route leaks are the propagation of BGP prefixes which violate
  assumptions of BGP topology relationships; e.g. passing a route
  learned from one lateral peer to another lateral peer or a transit
  provider, passing a route learned from one transit provider to
  another transit provider or a lateral peer.  Existing approaches to
  leak prevention rely on marking routes by operator configuration,
  with no check that the configuration corresponds to that of the eBGP
  neighbor, or enforcement that the two eBGP speakers agree on the
  relationship. 

 
  This document enhances BGP OPEN to establish agreement
  of the (peer, customer, provider, Route Server, Route Server client)
  relationship of two neighboring eBGP speakers to enforce appropriate
  configuration on both sides.  Propagated routes are then marked with
  an Only to Customer (OTC) attribute according to the agreed
  relationship, allowing both prevention and detection of route leaks.

Working Group Summary:
Route leaks are a problem that plague the operational Internet for over 20 years.
The WG group consensus for this draft goes across two WGs (GROW and IDR)
with both working group lending their support to define the problem
and design a series of fixes that can be deployed in operational networks.
While the discussions have been lengthy, there is solid support between
operators, researchers, and the membesrs of 2 WGs (GROW and IDR).
standardize the changs to the OPEN and the additions of an "only
to customer" (OTC) flag.

Document Quality:
The shepherd has been an active part of guiding this discussion in IDR and
grow for over 5 years.  The work from NIST (Doug Montgomery and  K. Sriram)
Brian Dickson, Randy Bush (IIJ, Arrcus), Keyur Patel (Arrcus), and
Alexander Azimov and Eugene Bogomazov has investigated
the technology from many angles.  The operators and the authors
have word smithed in the last editions to the shepherd's
satisfaction.

Existing implementations:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy

No MIB, Yang, or Media review: none needed.
Key review:  Cross-review with Grow WG that depends on this work
Reviews in Progress: RTG-IDR, OPS-DIR, and IANA early reviews called for
[requested as anticipated document will be in ADs for at least
  3 weeks.]

Personnel:
Document Shepherd:  Susan Hares
AD: Alvaro Retana
Co-chairs: Susan Hares and John Scudder.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Review done of technology (5+ years)
Review of the write-ups and web-sites of the implementator
NITS:  a) MUST NOT, b) RFC8126 must replace RFC5226

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No see above write-up for reason.

Early OPS-DIR, RTG-DIR, SEC-DIR, IANA reviews done while in queue.

(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.

(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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.  See discussion above.

(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?
Authors:
Alexander Azimov
https://mailarchive.ietf.org/arch/msg/idr/8uUHqSwjk3AyunpqfkNdtqRL2Yg/

Eugene Bogomazon
https://mailarchive.ietf.org/arch/msg/idr/4261qgyVYEIWcXPFkPruT1w4Xbk/

Randy Bush
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/elvK3DVaNlxfEWBu66csafbjiIs/

Kotikalapudi Sriram
https://mailarchive.ietf.org/arch/msg/idr/tKgKf-MHP65-VhiVgYAmB3yGoNk/

Contributors:
Brian Dickson
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Doug Mongomery
https://mailarchive.ietf.org/arch/msg/idr/Q2st99-q2TA22uMuc6iJjedtVQI/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
no

(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?

Strong consensus with broad support from operators, researches, and 2 WGs (IDR, GROW).

The consensus is strong and it links to the following operational documents from the Grow WG:
RFC7908,  RFC8212 (updates RFC4271),
draft-ietf-grow-route-leak-detection-mitigation-04.txt

The problem and various idea has discussed for over 15 years.
The increasing problem makes the operators push for a resolution.

(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.

NITS:  (1/13/2021) --
a) MUST not --- moved to MUST NOT
b) RFC8126 -- must replace RFC5226

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
yes

(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?

No changes to existing RFCs.  Existing technolgooy.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Pre-allocation for this draft was already done:

1) capability code  (value 9)
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
9 BGP Role (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy] IETF

2) Error code
8 Role Mismatch (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy[

3) New Transitive Attribute - OTC
35 Only to Customer (OTC) (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy]

These allocation should be made permanent.

(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.

BGP Role Reigstry needs to be Expert Review. 
Potential Experts (Randy Bush, Grow chairs,  Warren Kumari, K. Sriram, Alexander Azimov)

(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.
Only NITs needed

(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?

none

Shepherd waits on: -15 with NITs fixed

NITS:  (1/13/2021) --
a) MUST not --- moved to MUST NOT
b)RFC8126 -- must replace RFC5226

Date of write-up form: 11/1/2019


(1) What type of RFC is being requested  (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Type: Proposed Standard
Why proper: Adds a capability to the BGP OPEN and a BGP attribute for Only to the customer
Listed in title page: Yes


(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:
  Route leaks are the propagation of BGP prefixes which violate
  assumptions of BGP topology relationships; e.g. passing a route
  learned from one lateral peer to another lateral peer or a transit
  provider, passing a route learned from one transit provider to
  another transit provider or a lateral peer.  Existing approaches to
  leak prevention rely on marking routes by operator configuration,
  with no check that the configuration corresponds to that of the eBGP
  neighbor, or enforcement that the two eBGP speakers agree on the
  relationship. 

 
  This document enhances BGP OPEN to establish agreement
  of the (peer, customer, provider, Route Server, Route Server client)
  relationship of two neighboring eBGP speakers to enforce appropriate
  configuration on both sides.  Propagated routes are then marked with
  an Only to Customer (OTC) attribute according to the agreed
  relationship, allowing both prevention and detection of route leaks.

Working Group Summary:
Route leaks are a problem that plague the operational Internet for over 20 years.
The WG group consensus for this draft goes across two WGs (GROW and IDR)
with both working group lending their support to define the problem
and design a series of fixes that can be deployed in operational networks.
While the discussions have been lengthy, there is solid support between
operators, researchers, and the membesrs of 2 WGs (GROW and IDR).
standardize the changs to the OPEN and the additions of an "only
to customer" (OTC) flag.

Document Quality:
The shepherd has been an active part of guiding this discussion in IDR and
grow for over 5 years.  The work from NIST (Doug Montgomery and  K. Sriram)
Brian Dickson, Randy Bush (IIJ, Arrcus), Keyur Patel (Arrcus), and
Alexander Azimov and Eugene Bogomazov has investigated
the technology from many angles.  The operators and the authors
have word smithed in the last editions to the shepherd's
satisfaction.

Existing implementations:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy

No MIB, Yang, or Media review: none needed.
Key review:  Cross-review with Grow WG that depends on this work
Reviews in Progress: RTG-IDR, OPS-DIR, and IANA early reviews called for
[requested as anticipated document will be in ADs for at least
  3 weeks.]

Personnel:
Document Shepherd:  Susan Hares
AD: Alvaro Retana
Co-chairs: Susan Hares and John Scudder.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.

Review done of technology (5+ years)
Review of the write-ups and web-sites of the implementator
NITS:  a) MUST NOT, b) RFC8126 must replace RFC5226

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No see above write-up for reason.

Early OPS-DIR, RTG-DIR, SEC-DIR, IANA reviews done while in queue.

(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.

(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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.  See discussion above.

(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?
Authors:
Alexander Azimov
https://mailarchive.ietf.org/arch/msg/idr/8uUHqSwjk3AyunpqfkNdtqRL2Yg/

Eugene Bogomazon
https://mailarchive.ietf.org/arch/msg/idr/4261qgyVYEIWcXPFkPruT1w4Xbk/

Randy Bush
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Keyur Patel
https://mailarchive.ietf.org/arch/msg/idr/elvK3DVaNlxfEWBu66csafbjiIs/

Kotikalapudi Sriram
https://mailarchive.ietf.org/arch/msg/idr/tKgKf-MHP65-VhiVgYAmB3yGoNk/

Contributors:
Brian Dickson
https://mailarchive.ietf.org/arch/browse/idr/?q=open-policy

Doug Mongomery
https://mailarchive.ietf.org/arch/msg/idr/Q2st99-q2TA22uMuc6iJjedtVQI/

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
no

(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?

Strong consensus with broad support from operators, researches, and 2 WGs (IDR, GROW).

The consensus is strong and it links to the following operational documents from the Grow WG:
RFC7908,  RFC8212 (updates RFC4271),
draft-ietf-grow-route-leak-detection-mitigation-04.txt

The problem and various idea has discussed for over 15 years.
The increasing problem makes the operators push for a resolution.

(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.

NITS:  (1/13/2021) --
a) MUST not --- moved to MUST NOT
b) RFC8126 -- must replace RFC5226

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
None needed

(13) Have all references within this document been identified as either normative or informative?
yes

(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?

No changes to existing RFCs.  Existing technolgooy.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.

Pre-allocation for this draft was already done:

1) capability code  (value 9)
https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
9 BGP Role (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy] IETF

2) Error code
8 Role Mismatch (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy[

3) New Transitive Attribute - OTC
35 Only to Customer (OTC) (TEMPORARY - registered 2018-03-29, extension registered 2020-03-20, expires 2021-03-29) [draft-ietf-idr-bgp-open-policy]

These allocation should be made permanent.

(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.

BGP Role Reigstry needs to be Expert Review. 
Potential Experts (Randy Bush, Grow chairs,  Warren Kumari, K. Sriram, Alexander Azimov)

(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.
Only NITs needed

(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?

none

Date of write-up form: 11/1/2019

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

(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:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

(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.

(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? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

(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?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(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?

(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.)

(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.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(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?

(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.

(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.

(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).

(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.

(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.

(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?