From nobody Tue Aug 10 09:23:24 2021 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4DD3A131E; Tue, 10 Aug 2021 09:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tI4BymrZGzV; Tue, 10 Aug 2021 09:23:10 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1283A1318; Tue, 10 Aug 2021 09:23:09 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id a8so33871150pjk.4; Tue, 10 Aug 2021 09:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ey9tGPfn1Y/GccIigNvWudGQFeHFHwMw9mxhxWPWMmE=; b=fFRXajhUDGCIdoYHwHAY9aRzhUz/6b3+q1Otms+rhivo3XDVV387uE6BaB5Vz8nLaX ea37pOmGmTmDVf+HHUweigYuLvh1xfzBRM05al1IkQrlPqVKkTbYgrV/hPOtlSUVMRwb pjgTHigYIUbCul+3qz0qnZeopjl8LoE+zOQvYUzEW1GgvCGv1viASqUeGXtPGKNheZlB ksw/7CbKiluy41BAjHSrqDltPzJLVFwXitQOAV/+KMCd7qWpPZqec5wikPggbbTfwDG4 aFvyPVE3P8oQzVYYENMuW128SDo/YT8hUMChRfsR5Qw/CWSB1So/orfD27N0gqCCy+Ym QDlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ey9tGPfn1Y/GccIigNvWudGQFeHFHwMw9mxhxWPWMmE=; b=kEQcGxNHEObHhqTKEd3wqUPtNx34kCV/1nJGmvyTN3acL4CyJ22KqNawLbn9oYOI79 hNqFM7BRfGBzJxV6H3SbCEOfS4Q0MZOL+tWcdKYhSEnOs4GaQ//r2z02gu12TACdp3gy b5VPhoRGg9y7/SC2GYDz3tbMkrKqmY28cRRwVz4NFCt8MywypKZC16pY7PD6w/QqdlOi PWfM5gVolveDBUFgSqUFAmzXLO05kQmyXA3P82xMGPPwGyFezyrBgmHZS/RLg3hJn5sR rdb4twTX8bgPtdG8ln7uuHVPXuDUMvowvA2219vpRHp+XsT/r8tCE/ZCmWd555jM/GDL DRiA== X-Gm-Message-State: AOAM530ZKFXclgeKrmsfMcRfVu7Ym1WWL/I4kJFjiy/3iadcl6IR3QYk LNghl4sCvwornEBAoGhX/sfH+aZRW171d9miBEU= X-Google-Smtp-Source: ABdhPJwt1ALLAU/yql/5EtWSHSdDjHBEmKCT9PTFxSpa3NZTDuyYfTRYVRPxZShuRXILHHT3E6WTzGoR9PaY3RC9pfE= X-Received: by 2002:a17:902:ac87:b029:12d:3e59:cb7d with SMTP id h7-20020a170902ac87b029012d3e59cb7dmr6679292plr.22.1628612588039; Tue, 10 Aug 2021 09:23:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Azimov Date: Tue, 10 Aug 2021 19:22:52 +0300 Message-ID: To: Alvaro Retana Cc: Susan Hares , draft-ietf-idr-bgp-open-policy@ietf.org, "idr-chairs@ietf.org" , "grow@ietf.org grow@ietf.org" , IDR List Content-Type: multipart/alternative; boundary="000000000000c96ff805c936eac8" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-open-policy-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 16:23:19 -0000 --000000000000c96ff805c936eac8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Alvaro, Thank you once again for your very careful review and detailed comments. We tried our best to carefully consider all your comments, incorporated changes accordingly in version -16, and uploaded it. https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-16 Our (authors=E2=80=99) responses to your specific comments are inline below= and marked with [AA/KS]. Before jumping to the long list of inline comments I'd like to highlight that while policy specification is better worded now, their principles remain unchanged. So, the existing implementations remain practically unaffected except for the minor consideration of the presence of multiple OTCs per UPDATE. The inline comments took 21 pages in Word. The last line should read: [End of Review -15] If that does not show, then it means the text got cut off somewhere. Let us know. Alexander / Sriram ------------------------------------------ [Idr] AD Review of draft-ietf-idr-bgp-open-policy-15 Alvaro Retana Wed, 09 June 2021 19:40 UTC Dear authors: Thank you for your work on addressing the route leaks problem! I think the document still needs a lot of work. In general, the precision in the language is not what I would expect from a Standards Track document. Also, I believe the specification is not complete. Please see details inline. Instead of returning the document to the WG, and because it is short, I am including a long list of suggestions below. Given all the proposed changes, we will eventually need to run a new WGLC explicitly including the grow WG -- I have cc'd them in this message as well. Thanks! Alvaro. [Line numbers from idnits.] ... 14 Route Leak Prevention using Roles in Update and Open messages 15 draft-ietf-idr-bgp-open-policy-15 [minor] s/Update and Open/UPDATE and OPEN BGP [AA/KS] Fixed. [major] Throughout the document the concept of "sending prefixes" (or sometimes announcing them) is used -- I understand that these are common phrases. However, that is not the terminology used in rfc4271. Please use "route advertisement" (and variations) instead. Note that "propagated" is also ok. [AA/KS] Fixed. 17 Abstract 19 Route leaks are the propagation of BGP prefixes which violate 20 assumptions of BGP topology relationships; e.g. passing a route 21 learned from one lateral peer to another lateral peer or a transit 22 provider, passing a route learned from one transit provider to 23 another transit provider or a lateral peer. Existing approaches to 24 leak prevention rely on marking routes by operator configuration, 25 with no check that the configuration corresponds to that of the eBGP 26 neighbor, or enforcement that the two eBGP speakers agree on the 27 relationship. This document enhances BGP OPEN to establish agreement 28 of the (peer, customer, provider, Route Server, Route Server client) 29 relationship of two neighboring eBGP speakers to enforce appropriate 30 configuration on both sides. Propagated routes are then marked with 31 an Only to Customer (OTC) attribute according to the agreed 32 relationship, allowing both prevention and detection of route leaks. [minor] OLD> 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. Suggestion> This document enhances the BGP OPEN message to establish an agreement of the relationship between two eBGP speakers in order to enforce appropriate configuration on both sides. Propagated routes are then marked accordin= g to the agreed relationship, allowing both prevention and detection of route leaks. [AA/KS] Done. ... 94 1. Introduction 96 A BGP route leak occurs when a route is learned from a transit 97 provider or lateral peer and then announced to another provider or 98 lateral peer. See [RFC7908]. These are usually the result of 99 misconfigured or absent BGP route filtering or lack of coordination 100 between two eBGP speakers. [nit] s/peer. See [RFC7908]./peer [RFC7908]. [AA/KS] Fixed. [nit] s/between two eBGP speakers./between autonomous systems. [AA/KS] Fixed. 102 The mechanism proposed in 103 [I-D.ietf-grow-route-leak-detection-mitigation] uses large= - 104 communities to perform detection and mitigation of route leaks. 105 While signaling using communities is easy to implement and deploy 106 quickly, it normally relies on operator-maintained policy 107 configuration, which is vulnerable to misconfiguration [Streibelt]. 108 The community signal can also be stripped at the ISP boundaries. [major] This paragraph says that another proposal uses a different mechanism to solve the same problem...but that it has issues. I am not a fan of comparing solutions, much less ones that are still in progress (even if the authors overlap). Please remove this paragraph. Having said that, I-D.ietf-grow-route-leak-detection-mitigation points back at this document as a way to help automate the process described there. Are there any specific dependencies on that draft from this one? I don't think so, but if there are, that would be the reason to reference it. I am assuming that any interaction will be included in I-D.ietf-grow-route-leak-detection-mitigation -- and that it won't change this document. That other ID is still under discussion. [AA/KS] The paragraphs with comparison with the other draft has been removed. 110 This document provides configuration automation using 'BGP roles', 111 which are negotiated using a new BGP Capability Code in OPEN message 112 (see Section 4 in [RFC5492]). Either or both BGP speakers MAY be 113 configured to require that this capability be agreed for the BGP OPEN 114 to succeed. [nit] s/in OPEN message/in the OPEN message [AA/KS] Fixed. [minor] s/see Section 4 in [RFC5492]/[RFC5492] [AA/KS] Fixed. [major] "MAY be configured to require" This phrase sounds like a contradiction: it is optional to require something. Let's leave the normative language to the normative parts of this document. s/MAY/may [AA/KS] Fixed. 116 A new optional, transitive BGP Path Attribute Only to Customer (OTC) 117 is specified that SHOULD be automatically configured using BGP roles. 118 This attribute prevents networks from creating leaks, and detects 119 leaks created by third parties. [major] Again, let's keep normative language for later. Suggestion> A new optional, transitive BGP Path Attribute, called Only to Customer (OTC), is specified in Section 6. It prevents networks from creating leaks, and detects leaks created by third parties. [AA/KS] Fixed. New text as follows: This document provides configuration automation using BGP Roles, which are negotiated using a BGP Role Capability in the OPEN message [RFC5492]. ... 124 2. Peering Relationships 126 Despite the use of terms such as "customer", "peer", etc. in this 127 document, these are not necessarily business relationships based on 128 payment agreements. These terms are used to represent restrictions 129 on BGP route propagation, sometimes known as the Gao-Rexford model 130 [Gao]. The following is a list of various roles in eBGP peering and 131 the corresponding rules for route propagation: [major] Given the normative language used below, it should be made clear that the names of the roles are defined for and apply only to the discussion in this document. I don't want there to be confusion related to general terms like "peer". It would be ideal if the roles were identified by their capitalization, to differentiate between "Peer" (the role) and "peer" (as in the BGP speaker at the other side of the session). Please review the document and make the necessary changes. [AA/KS] s/peer/Peer/g + all other roles are also capitalized; see revised Sections 2 and 3. Added a Terminology Section 1.1 where these roles (Peer, Provider, etc.), local/remote AS, and =E2=80=9Croute is ineligible=E2=80=9D= are clearly defined. Suggestion> The terms defined and used in this document (see below) don't necessaril= y represent business relationships based on payment agreements. These terms are used to represent restrictions on BGP route propagation, sometimes known as the Gao-Rexford model [Gao]. The following is a list of the roles for eBGP peering and their corresponding rules for route propagation: [AA/KS] Done. 133 Provider: MAY send to a customer all available prefixes. [major] The option is not to send all or nothing, but the fact that a Provider can send anything (from a default, to a subset, to all) to a Customer, right? Suggestion> Provider: MAY propagate any available route to a Customer. [AA/KS] Applied, also s/propagate/advertise/. See revised Sec. 2. 135 Customer: MAY send to a provider prefixes which the sende= r 136 originates and prefixes learned from any of their customers. A 137 customer MUST NOT send to a provider prefixes learned from its 138 peers, from other providers, or from Route Servers. [major] "MAY send to a provider...prefixes learned from any of their customers." This got me thinking of the fact that the role (Customer) is for a specific eBGP session, but an AS may have multiple eBGP sessions with multiple roles, which is where the part about "learned from any of their customers" comes from. Please add some text at the start of this section (maybe in a separate paragraph after the first couple of sentences above) to explain. [AA/KS] Done. Please see revised Section 2. Also, we have added =E2=80=9C= =E2=80=A6on each eBGP session between autonomous systems (ASes)=E2=80=9D in relevant places = -- in the Intro section, Sections 3 and 5. [major] "MUST NOT send...prefixes learned from..." Again, given that the roles are session-based, how do you expect this requirement to be satisfied? IOW, how would an eBGP session in routerA know that a specific prefix was learned from a Peer (or not) at routerB on the other side of the network? [AA/KS] There are some details that need to be understood. If a route was advertised by a Peer, Provider, or RS and it is not marked with OTC, then the ingress router adds an OTC Attribute with the AS number of the sender (remote AS). See revised Section 4. The mere presence of an OTC indicates to the egress router that the route was learned from a Peer, Provider, or RS and it can be advertised only to customers. The absence of an OTC Attribute indicates to the egress router that the route was either advertised by a Customer or originated by the local AS. If a route received from a Customer at an ingress router has an OTC Attribute, then the route is rejected by ingress policy. So, a customer route or a locally originated route never has OTC attached when received at the egress router. Now, this is explained well in the revised Section 4 in the updated draft. [AA/KS] We have added new wording in Section 4 to explain the above for the reader=E2=80=99s benefit. This new wording appears immediately after the eg= ress policy description. I believe that current practice of using communities to identify where the routes came from is a straight-forward solution to this issue. Please add something to that effect, as an example of how the requirement can be met -- but also declare the specific mechanism out of scope. [AA/KS] That internal (i.e., intra-AS) mechanism is subsumed in the OTC mechanism. Please see the explanation provided above. This issue is not specific to Customers, so add the extra text after the roles are defined. [AA/KS] We think here you are taking about the mention of =E2=80=9Cmultiple= eBGP sessions with multiple roles=E2=80=9D. As stated above, we took care of this generally by= adding =E2=80=9C=E2=80=A6on each eBGP session between autonomous systems (ASes)=E2= =80=9D a few times in the Intro section and in Sections 3 and 5. [minor] The only role not listed is RS-Client. I'm assuming that prefixes learned from a RS-Client also MUST NOT be advertised, right? [AA/KS] Yes, RS-Client is not listed (in what a Customer MAY propagate). The assumption is that an RS does not have a Provider (transit provider) by definition. An RS treats all ASes connected to it as RS-Clients. So, a local AS with a Customer Role is not an RS and thus does not have RS-Clients. Suggestion> Customer: MAY advertise any route learned from a Customer, or locally originated, to a Provider. All other routes MUST NOT be propagated. [AA/KS] Fixed. 140 Route Server (RS): MAY send to an Route Server client (RS-client) 141 all available prefixes. [] Suggestion> Route Server (RS): MAY propagate any available route to a Route Server Client (RS-Client). [AA/KS] Fixed. 143 RS-client: MAY send to an RS prefixes which the sender originates 144 and prefixes learned from its customers. An RS-client MUST NOT 145 send to an RS prefixes learned from its peers or providers, or 146 from another RS. [] Suggestion> RS-Client: MAY advertise any route learned from a Customer or locally originated to a Route Server. All other routes MUST NOT be propagated. [AA/KS] Fixed 148 Peer: MAY send to a peer prefixes which the sender originates and 149 prefixes learned from its customers. A peer MUST NOT send to a 150 peer prefixes learned from other peers, from its providers, or 151 from RS(s). [] Suggestion> Peer: MAY advertise any route learned from a Customer or locally originated to a Peer. All other routes MUST NOT be propagated. [AA/KS] Fixed 153 Of course, any BGP speaker may apply policy to reduce what is 154 announced, and a recipient may apply policy to reduce the set of 155 routes they accept. Violation of the above rules may result in route 156 leaks and MUST NOT be allowed. Automatic enforcement of these rules 157 should significantly reduce route leaks that may otherwise occur due 158 to manual configuration mistakes. While enforcing the above rules 159 will address most BGP peering scenarios, their configuration is not 160 part of BGP itself; therefore, configuration of ingress and egress 161 prefix filters is still strongly advised. [nit] s/Of course, any BGP/A BGP [AA/KS] Fixed. [major] "MUST NOT be allowed" I don't know how this requirement is enforced: the sender should advertise what is specified. Adding a normative requirement to the options and requirements listed doesn't contribute... Suggestion: remove the whole sentence; there is some redundancy with the next one. [AA/KS] s/Violation of the above rules may result in route leaks and MUST NOT be allowed./Violation of the above rules may result in route leaks./ [?] "their configuration is not part of BGP itself" I don't understand what this phrase is intended to mean. [AA/KS] Yes, confusing. Removed the phrase. Replaced the paragraph with this shorter and clearer one: 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. 163 3. BGP Role [] This section should be placed *before* =C2=A72 (Peering Relationships), so that the roles are described before the advertisement rules. Some of the text in the first paragraph of =C2=A72 (about business relationships) should be moved here. [AA/KS] We were following the sequence of introduction -> motivation & definitions -> solution specification. And the idea behind =C2=A72 was to describe motivation and then go to the solution with BGP Roles. The way the wording has been revised in these sections should make this flow even better. Please see revised Sections 2 and 3. 165 BGP Role is a new configuration option that is configured on a per- 166 session basis. BGP Roles reflect the agreement between two BGP 167 speakers about their relationship. One of the Roles described below 168 SHOULD be configured on each eBGP session between ISPs that carry 169 IPv4 and(or) IPv6 unicast prefixes. [minor] "BGP Role is a new configuration option that is configured on a per-session basis." I don't think that this document should deal with specifics of what could be configured in an implementation -- but with the function of the roles. Suggestion> The BGP Role characterizes the relationship between the eBGP speakers forming a session. [AA/KS] The updated paragraph (at the top of Section 3) reads as follows: The BGP Role characterizes the relationship between the eBGP speakers forming a session. BGP Role is configured on a per-session basis. An eBGP speaker SHOULD configure the BGP Role locally based on the local AS's knowledge of its Role. The only exception is when the eBGP connection is complex (see Section 5). BGP Roles are mutually confirmed using the BGP Role Capability (described in Section 3.1) on each eBGP session between autonomous systems (ASes). One of the Roles described below SHOULD be configured at the local AS for each eBGP session with a neighbor (remote AS) (see definitions in Section 1.1). [major] "One of the Roles described below SHOULD be configured on each eBGP session between ISPs that carry IPv4 and(or) IPv6 unicast prefixes." I have several questions: - When is it ok to not use a role? Why is the configuration recommended and not required? [AA/KS] The exception is the =E2=80=98complex=E2=80=99 relations case that = is described in the additional considerations section. See the updated paragraph at the top of Section 3 (copied above). - Only between ISPs? What about Customers? Are Route Servers considered ISPs? At minimum, you should describe the term some more. This should also scope the applicability. [AA/KS] The ISP term was used very loosely. Correction: s/ISP/AS/. Please see the updated paragraph (copied above). - Only unicast routes? Why? This probably goes to the definition of a route leak and where it happens. rfc7908 focuses on what has been seen on the Internet -- but I'm sure that as long as the same types of relationships/topologies, the same type of issues can occur. I'm not asking that you explore that, but maybe a quick mention (in the Introduction) that the main focus/applicability is the Internet, then it won't be necessary to mention AFs. [AA/KS] Per your suggestion, we have inserted this sentence in the Intro section: =E2=80=9CThe main focus/applicability is the Internet (IPv4 and I= Pv6 route announcements).=E2=80=9D We make only one other mention of IPv4 and I= Pv6 at the end of Section 4 as follows: The described ingress and egress policies are applicable only for unicast IPv4 and IPv6 address families and MUST not affect other address families by default. ... 184 Since BGP Role reflects the relationship between two BGP speakers, it 185 could also be used for other purposes besides route leak mitigation. [] Like what? I'm not disagreeing, but it seems like this sentence is unnecessary. [AA/KS] For example, one can imagine configuring local preference based on BGP Roles configuration. But since it is out of the scope of this document, we have removed the whole sentence. 187 4. BGP Role Capability 189 The TLV (type, length, value) of the BGP Role capability are: 191 o Type - ; [major] Capabilities are not exactly defined as TLVs. Suggestion> The BGP Role Capability is defined as follows: o Code: 9 ... [AA/KS] Fixed ... 197 +-------+---------------------+ 198 | Value | Role name | 199 +-------+---------------------+ 200 | 0 | Sender is Provider | 201 | 1 | Sender is RS | 202 | 2 | Sender is RS-client | 203 | 3 | Sender is Customer | 204 | 4 | Sender is Peer | 205 +-------+---------------------+ [minor] The description of the Value says that the Role corresponds to the speaker/sender. There's no need to use "Sender is" for every entry. Also, the "Role name" is simply Provider, RS, etc. [AA/KS] We now use the terms local AS /remote AS per your suggestion instead of sender/receiver. Hence, in the table, s/Role name/Role name (for the local AS)/ Also, we got rid of =E2=80=9CSender is=E2=80=9D. Please see the new Table 1= in the updated draft. 207 Table 1: Predefined BGP Role Values [major] It is not a given that a single capability has to be included -- rfc5492 includes the case where a multiple of the same can be present. Suggestion> A BGP Speaker MUST NOT advertise multiple versions of the BGP Role Capability. If a BGP Speaker receives multiple copies of the BGP Role Capability.... ??? [AA/KS] We have added the suggested text at the end of Section 3.1 as follows: If BGP Role is locally configured, the eBGP speaker MUST advertise BGP Role Capability in the BGP OPEN message. An eBGP speaker MUST NOT advertise multiple versions of the BGP Role Capability. [AA/KS] For the second part of your suggestion, we have also added the following in Section 3.2: If an eBGP speaker receives multiple but identical BGP Role Capabilities with the same value in each, then the speaker MUST consider it to be a single BGP Role Capability and proceed [RFC5492]. If multiple BGP Role Capabilities are received and not all of them have the same value, then the BGP speaker MUST reject the connection using the Role Mismatch Notification (code 2, subcode 8). 209 5. Role correctness [minor] This section talks about the validation of the capability. Please make it a sub-section of =C2=A74. [AA/KS] We have restructured the sections as follows: 3. BGP Role . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. BGP Role Capability . . . . . . . . . . . . . . . . . . . 5 3.2. Role Correctness . . . . . . . . . . . . . . . . . . . . 5 211 Section 3 described how BGP Role encodes the relationship between two 212 eBGP speakers. But the mere presence of BGP Role doesn't 213 automatically guarantee role agreement between two BGP peers. [minor] The encoding is defined in =C2=A74. [AA/KS] Fixed. Please see the top 2 paragraphs of Sec. 3.2. 215 To enforce correctness, the BGP Role check is applied with a set of 216 constraints on how speakers' BGP Roles MUST correspond. Of course, 217 each speaker MUST announce and accept the BGP Role capability in the 218 BGP OPEN message exchange. [major] "MUST announce and accept" This requirement contradicts the default setting of "strict mode": if false, then the speaker cannot be expected to both send and receive the capability. [AA/KS] We got rid of the cited phrase. We also got rid of the contradiction. At the bottom of Sec 3.1, it now says: If BGP Role is locally configured, the eBGP speaker MUST advertise BGP Role Capability in the BGP OPEN message. An eBGP speaker MUST NOT advertise multiple versions of the BGP Role Capability. I think that we could eliminate =C2=A75.1 by bringing the intent of the text up to this section. Suggestion> A BGP Speaker that supports the BGP Role Capability SHOULD include it in the OPEN Message. If the BGP Role Capability is sent, but one is not received, then the connection SHOULD be rejected using the Role Mismatch Notification (code 2, subcode 8); this mode of operation is called "strict mode". For backwards compatibility, if the BGP speaker does not receive the capability from its peer, it MAY proceed with session establishment without consideration for the roles defined here; this SHOULD be the default mode of operation. [AA/KS] Great suggestion. We have followed it. Previous Section 5 is now Section 3.2. Previous Section 5.1 has been subsumed in Section 3.2 per your suggestion. Section 3.2 is now well-organized including dealing with error condition with multiple versions of the BGP Role Capability. Note that in this suggestion I used the "Role Mismatch Notification", but not receiving the capability is not really a role mismatch -- its a "missing capability" error. This type of error is not currently defined. It is up to you whether you want to define it here or not. [AA/KS] Using the Role Mismatch Notification here seems the prudent choice. No need to define another error type. 220 If a speaker receives a BGP Role capability, it MUST check the value 221 of the received capability (i.e., the sender's role) with its own BGP 222 Role. The allowed pairings are as follows: [major] "MUST check" The required action is not to check, but to make sure that the advertised values match one of the pairs below. Suggestion (using also text from the last paragraph in this section)> If the BGP Role Capability is sent and one is also received from the peer, the roles must correspond to the relationships in Table 2. If the roles do not correspond, the BGP Speaker MUST reject the connection using the Role Mismatch Notification (code 2, subcode 8). [AA/KS] Applied. See 2nd para in Sec. 3.2. 224 +---------------+-----------------+ 225 | Sender's Role | Receiver's Role | 226 +---------------+-----------------+ 227 | Provider | Customer | 228 | Customer | Provider | 229 | RS | RS-client | 230 | RS-client | RS | 231 | Peer | Peer | 232 +---------------+-----------------+ [major] I find the language of the local router checking the "received capability (i.e., the sender's role)" confusing since I would have expected the local router to be the sender. To avoid confusion, it might be clearer to call the roles "local" and "remote". I realize that in the end the point of view doesn't matter much as long as a router picks one -- but this is a standards track specification and it should be as precise as possible. [AA/KS] Fixed. We now use =E2=80=98local AS=E2=80=99/ =E2=80=98remote AS=E2= =80=99 terminology per your advice. We describe it upfront in Section 1.1 (Terminology). In the table (cited above), we did the following: s/Sender=E2=80=99s Role/Local AS Role/= and s/Receiver's Role/Remote AS Role/. See Table 2 in Section 3.2. ... 236 If the role of the receiving speaker for the eBGP session in 237 consideration is included in Table 1 and the observed Role pair is 238 not in the above table, then the receiving speaker MUST reject the 239 eBGP connection, send a Role Mismatch Notification (code 2, subcode 240 ), and also send a Connection Rejected Notification [RFC4486] 241 (Notification with error code 6, subcode 5). [] I moved this text to the suggested paragraph before Table 2. Also, note that only one Notification can be sent at a time. [AA/KS] Fixed. Suggestions followed. Please see the revised paragraph before Table 2. xxx ... 255 6. BGP Only to Customer (OTC) Attribute 257 Newly defined here, the Only to Customer (OTC) is an optional, 4 258 bytes long, transitive BGP Path attribute with the Type Code . 259 The purpose of this attribute is to guarantee that once a route is 260 sent to customer, peer, or RS-client, it will subsequently go only to 261 customers. The value of OTC is an AS number determined by policy as 262 described below. The semantics and usage of the OTC attribute are 263 made clear by the ingress and egress policies described below. [] Suggestion> The Only to Customer (OTC) Attribute is an optional transitive path attribute with Attribute Type Code 35 and a length of 4 octets. The attribute value is an AS number (ASN) determined by the policy described below. [AA/KS] We applied your wording, but kept the phrase related to the purpose of the attribute. Please see the first paragraph of Section 4. [major] What should a receiver do if the length is not set to 4? [AA/KS] Added the following wording in the renumbered Section 4: If an eBGP speaker receives an UPDATE with an OTC Attribute with a length different from 4 octets, then the UPDATE SHALL be considered malformed. If malformed, the UPDATE message SHALL be handled using the approach of "treat-as-withdraw" [RFC7606]. [AA/KS] In the above, we are following the approach suggested in RFC 7606 for malformed BGP attributes. 265 The following ingress policy applies to the OTC attribute: 267 1. If a route with OTC attribute is received from a Customer or RS- 268 client, then it is a route leak and MUST be rejected. [nit] s/with OTC attribute/with the OTC attribute/g [AA/KS] Fixed as follows: 1. 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 (see Section 1.1). [major] "MUST be rejected" What *exactly* does this mean in terms of BGP? There is no "rejection" action -- so I'm guessing that "rejected" means that the route has to be ignored, not used, and not propagated. In line with rfc4271/=C2=A79.1.1, would "the route MUST be considered ineligible" be appropriate? [AA/KS] Changed to =E2=80=98considered ineligible=E2=80=99. We also define = the term in the new Section 1.1 (Terminology). 270 2. If a route with OTC attribute is received from a Peer and its 271 value is not equal to the sending neighbor's Autonomous System 272 (AS) number, then it is a route leak and MUST be rejected. [major] Can multiple OTC attributes be sent? What should the receiver do in that case? I'm also thinking about cases where attributes may be added by multiple ASes. [AA/KS] We have added this wording towards the end in Section 4 (updated draft): Correct implementation of the procedures specified in this document is not expected to result in the presence of multiple OTC Attributes in an UPDATE. However, if an eBGP speaker receives multiple OTC Attributes with a route, then the only difference in the processing is in Step 2 of the ingress policy. [AA/KS] Also, Step 2 of the ingress policy now reads: 2. If a route with the OTC Attribute is received from a Peer and at least one of the OTC Attributes has a value that is not equal to the remote (i.e., Peer's) AS number, then it is a route leak and MUST be considered ineligible. ... 278 The egress policy MUST be: [major] "MUST be" Given that the clauses (below) also contain normative language, this "MUST" is unnecessary. s/.../The following egress policy applies to the OTC attribute: [AA/KS] Fixed as follows: The following egress policy applies to the processing of the OTC Attribute: 280 1. A route with the OTC attribute set MUST NOT be sent to Providers, 281 Peers, or RS(s). [major] This rule seems to contradict the last one on ingress, which expects the OTC attribute from Peers. ?? [AA/KS] There is no contradiction. We have worded it better as follows (we have interchanged steps 1 and 2 in the revised draft): 2. If a route already contains the OTC Attribute, it MUST NOT be propagated to Providers, Peers, or RS(s). [AA/KS] Explanation: An ingress router at the local AS expects to receive routes with the OTC attribute set when the remote AS is a Provide, Peer, or RS. When the remote is a Peer, the ASN in the OTC MUST match the ASN of the remote AS for the route to be eligible (for route selection). If the remote is a Provider or RS, then ASN value in the OTC need not match the ASN of the remote AS for eligibility. When a route is received at ingress from a Provider, RS, or Peer, and the OTC is absent, then an OTC is added at the ingress with ASN value equal to that of the remote AS. So, whoever sets the OTC (remote AS or local AS) when route is propagated from Provider->Customer, Peer->Peer, or RS->RS-client, the OTC will have the same value. The egress router does not forward a route with OTC already set (at a prior AS or at ingress) to a Provider, Peer, or RC; such a route is sent only to the customers. So, the ingress policy is responsible for detecting leaks, egress policy for preventing leaks, and both of them perform OTC marking. The detection may take place multiple hops away. A shorter version of the explanation above is now included in Section 4 immediately after the egress policy. [minor] s/A route with the OTC attribute set MUST NOT be/The OTC Attribute MUST NOT be included in routes [AA/KS:] No! That is not correct. When sending a locally-originated or Customer route to a Peer, an OTC with value equal to the local ASN is added. Note: A Customer or RS-Client are not adding the OTC attribute when advertising a route to its Provider or RS, respectively. 283 2. If route is sent to a Customer or Peer, or an RS-client (when the 284 sender is an RS) and the OTC attribute is not present, then it 285 MUST be added with value equal to AS number of the sender. [] Suggestion> If a route to be sent to a Customer, Peer, or an RS-client (when the sender is an RS), and the OTC attribute is not present, it MUST be added with a value equal to the AS number of the sender. [AA/KS] Yes, done. Worded it as follows (note: we have interchanged steps 1 and 2 in the revised draft): 1. If a route is to be advertised to a Customer, Peer, or RS-Client (when the sender is an RS), and the OTC Attribute is not present, then an OTC Attribute MUST be added with a value equal to the AS number of the local AS. [major] There is no corresponding ingress policy that checks the ASN to match routes received from Providers or RS. (#2 only talks about Peers) [AA/KS:] There is no need. The presence of the OTC attribute on a route received from a Provider or RS does not require any action to be taken on ingress concerning the OTC. The OTC attribute may have been set by the neighbor (remote AS) or an earlier AS in the path. There is no need to check the OTC value. The mere presence of an OTC Attribute is a signal for the egress router that the route can be sent only to Customers (i.e., MUST NOT be sent to a Provider or Peer). However, the absence of an OTC Attribute on a route received from a Provider, Peer, or RS requires that the OTC Attribute be added on ingress with an ASN value equal to that of the sending neighbor (remote AS). This is to cover for a Provider, Peer, or RS that is not upgraded to do OTC. ... 289 7. Enforcement 291 Having the relationship unequivocally agreed between the two peers in 292 BGP OPEN is critical; BGP implementations MUST enforce the 293 relationship/role establishment rules (see Section 5) in order to 294 ameliorate operator policy configuration errors (if any). [] The suggested text in =C2=A75 eliminates the need for this paragraph. [AA/KS] Yes. In fact, the whole =E2=80=98Enforcement=E2=80=99 section is go= ne/partly subsumed in other sections. 296 Similarly, the application of that relationship on prefix propagation 297 using OTC MUST be enforced by the BGP implementations, and not 298 exposed to user misconfiguration. [] This is a very important point: there are no exceptions to the policies in =C2=A76. Please add some text to that effect in =C2=A76. Suggestion> The operator MUST NOT have the ability to modify the policies defined in this section. [AA/KS] Applied. This sentence is moved to the renumbered Section 4 at the end . 300 As opposed to communities, BGP attributes may not be generally 301 modified or stripped by the operator; BGP router implementations 302 enforce such treatment. This is the desired property for the OTC 303 marking. Hence, this document specifies OTC as an attribute. [] This text goes back to comparing solutions...not needed. [AA/KS] Yes. The text is removed. 305 8. Additional Considerations ... 315 No Roles SHOULD be configured on a 'complex' BGP session (assuming it 316 is not segregated) and in that case, OTC MUST be set by configuration 317 on a per-prefix basis. However, there are no built-in measures to 318 check correctness of OTC use if BGP Role is not configured= . [major] "OTC MUST be set by configuration" I think this phrase contradicts the statement in =C2=A77 about "OTC...not exposed to user misconfiguration": both behaviors (allowing configuration, and not) cannot be required at the same time. Perhaps all the MUSTs involved can be changed to SHOULDs. ?? [AA/KS] The sentence about "OTC...not exposed to user misconfiguration" was not needed and has been removed. We have also reworded the above cited paragraph. The revised paragraph reads as follows (=E2=80=9CAdditional Considerations=E2=80=9D is now Sec. 5): No Roles SHOULD be configured on a 'complex' eBGP session (assuming it is not segregated) and in that case, the OTC Attribute processing MUST be done relying on configuration on a per-prefix basis. Also, in this case, the per-prefix peering configuration MUST follow the same definitions of peering relations as described in Section 2. However, in this case, there are no built-in measures to check correctness of the per-prefix peering configuration. [major] "...there are no built-in measures to check correctness of OTC use if BGP Role is not configured." - If the role is not configured, but the receiving router supports OTC, what should it do? It sounds that =C2=A76 only applies then the BGP Role Capability is successfully negotiated -- is that true? [AA/KS] First, the sentence has been revised. Please see the revised paragraph copied above starting with =E2=80=98No Roles =E2=80=A6=E2=80=99. [AA/KS] Regarding when =C2=A76 (now =C2=A74) applies, given the updated dra= ft, there is no issue or confusion anymore. The following revised wording (#1 and #2) fixes it (this takes care of Mach=E2=80=99s comments also): 1. Paragraph at the top of Section 3: The BGP Role characterizes the relationship between the eBGP speakers forming a session. BGP Role is configured on a per-session basis. An eBGP speaker SHOULD configure the BGP Role locally based on the local AS's knowledge of its Role. The only exception is when the eBGP connection is complex (see Section 5). BGP Roles are mutually confirmed using the BGP Role Capability (described in Section 3.1) on each eBGP session between autonomous systems (ASes). One of the Roles described below SHOULD be configured at the local AS for each eBGP session with a neighbor (remote AS) (see definitions in Section 1.1). 2. Paragraph in Section 3.2: If the BGP Role Capability is sent, but one is not received, then the connection MAY be rejected using the Role Mismatch Notification (code 2, subcode 8); this mode of operation is called the "strict mode". For backward compatibility, if the BGP speaker does not receive the capability from its peer, it SHOULD ignore the absence of BGP Role Capability and proceed with session establishment; this SHOULD be the default non-strict mode of operation. In this case, the locally configured BGP Role is used for the procedures described in Section 4. [AA/KS] Summary: Whether in strict or default mode, BGP Role is configured, except it may not be mutually confirmed in the default mode. [AA/KS] The policies in =C2=A74 (was =C2=A76) apply even in the case of com= plex relationships based on local configuration of the per-prefix eBGP peering configuration (see 2nd paragraph in Section 5). - OTOH, if the role is configured and "strict mode" is *not* used, it sounds as if =C2=A76 only applies if "strict mode" is used? Is that true, or should the receiver, who configured the role, but didn't receive the Capability, and now received the attribute use the policy in =C2=A76? [AA/KS] This issue goes away in light of the significant wording changes noted above. Whichever the case, it should be clearly called out somewhere. [This point is closely related to Mach's rtg-dir review.] [AA/KS] Yes. As stated above, this issue goes away in light of the wording changes/clarifications (that were also agreed to with Mach). 320 The incorrect setting of BGP Roles and/or OTC attributes may affect 321 prefix propagation. Further, this document doesn't specify any 322 special handling of incorrect/private ASNs in OTC attribute; such 323 errors should not happen with proper configuration. [minor] "special handling of incorrect/private ASNs in OTC" =C2=A76 says that the ASN has to match the neighbor's. That should take care of the number not being the right one. [AA/KS] There is no assumption that OTC value always equals to neighbor=E2= =80=99s ASN. It could be set multiple hops away and propagated Provider-to-Customer (downward) on each of the hops. The revised paragraph at the end in =C2=A74= (was =C2=A76) reads: The incorrect setting of BGP Roles and/or OTC Attributes may affect prefix propagation. Further, this document does not specify any special handling of incorrect AS numbers in the OTC Attribute. Such errors should not happen with proper configuration. What about confederations? I understand the intent here is to prevent leaks in the Internet, so a private ASN shouldn't show up there. =C2=A75 hints at the BGP Role Capability being applicable only to eBGP, but it doesn't normatively constrain it to "normal" eBGP sessions. Should it? I think it should. If you do too, what should a receiver do if the Capability is received over iBGP or an eBGP session that is not "normal" -- ignore sounds like a good thing. [AA/KS] Yes, =E2=80=9Cignore=E2=80=9D -- meaning do not act on it and let t= he OTC Attribute propagate -- seems correct. IMO, the OTC processing at the ingress/egress of the confederation will happen correctly as per this draft (RFC). So, nothing specific to confederations needs to be said. Please advise. 325 As the BGP Role reflects the peering relationship between neighbors, 326 it might have other uses beyond the route leak solution discussed so 327 far. For example, BGP Role might affect route priority, or be used 328 to distinguish borders of a network if a network consists of multiple 329 ASs. Though such uses may be worthwhile, they are not the goal of 330 this document. Note that such uses would require local policy 331 control. [major] Please don't speculate about other uses! If there are other uses, then they should be specified. [AA/KS] Yes, agree. We have removed the paragraph. 333 The use of BGP Roles are specified for unicast IPv4 and IPv6 address 334 families. While BGP roles can be configured on other address 335 families its applicability for these cases is out of scope of this 336 document. [major] Ok. So this means that the receiver should look at the Multiprotocol capability (if present) and make sure that the proper AFI/SAFI are included. This needs to be specified in =C2=A74. What should the receiver do if the Capability is received for a different, or additional, AFI/SAFI? Or does all this mean that the policy in =C2=A76 simply doesn't apply to other AFI/SAFIs? What should a receiver do if the OTC attribute is received on a different AFI/SAFI? [AA/KS] BGP Role capability isn=E2=80=99t negotiated on the AFI/SAFI granul= arity. Per your earlier suggestion, we added the following sentence upfront in the Section 1: =E2=80=9CThe main focus/applicability is the Internet (IPv4 and = IPv6 unicast route advertisements).=E2=80=9D So, we have now deleted the above q= uoted sentence. We also added the following in Section 4 (last paragraph): The described ingress and egress policies are applicable only for unicast IPv4 and IPv6 address families and MUST not affect other address families by default. [AA/KS] Let us know if you feel that the above resolves the issue about AFI/SAFI. 338 As BGP role configuration results in automatic creation of inbound/ 339 outbound filters, existence of roles should be treated as existence 340 of Import and Export policy [RFC8212]. [minor] "BGP role configuration results in..." The configuration doesn't result in anything -- the successful negotiation of the capability does. Same comment for "existence of roles". [AA/KS] See below. [major] "should be treated as existence of Import and Export policy [RFC8212]" Should this text use normative language? SHOULD/MUST? Is this a recommendation or a requirement? If recommended, when would it be ok to not consider the negotiation to satisfy rfc8212? [] Was this interaction with rfc8212 considered by the grow WG? [AA/KS] We have removed the paragraph. RFC 8212 only says that there must exist Explicit Import/Export Policies. It doesn=E2=80=99t list any specific= ones. It allows the vendor to choose what they consider qualify for such policies. 342 9. IANA Considerations 344 This document defines a new Capability Codes option [to be removed 345 upon publication: https://www.iana.org/assignments/capability-codes/ 346 capability-codes.xhtml ] [RFC5492], named "BGP Role" with an assigned 347 value . The length of this capability is 1. [minor] s/Capability Codes option/BGP Capability [AA/KS] Fixed. We have revised the IANA Considerations (Section 6) to read substantially better. [minor] s/, named "BGP Role" with an assigned value ./named "BGP Role". IANA has assigned value 9. [AA/KS] Fixed [minor] The length is already specified in =C2=A74; no need to repeat that = here. [AA/KS] Fixed 349 The BGP Role capability includes a Value field, for which IANA is 350 requested to create and maintain a new sub-registry called "BGP Role 351 Value". Assignments consist of Value and corresponding Role name. 352 Initially this registry is to be populated with the data contained in 353 Table 1 found in Section 4. Future assignments may be made by a 354 Standard Action procedure [RFC8126]. The allocation policy for new 355 entries up to and including value 127 is "Expert Review" [RFC8126]. 356 The allocation policy for values 128 through 251 is "First Come First 357 Served". The values from 252 through 255 are for "Experimental Use". [major] Where should this sub-registry be located? I'm assuming that it would be placed in the Capability Codes registry -- you need to be explicit about that. [AA/KS] Fixed. Please see the new wording. [major] The paragraph indicates two different allocation procedures: Standard Action, and then others for different parts of the range. Which is it? [AA/KS] It is best to assign the values only through IETF Review. The IANA section is updated accordingly. [major] If there will be an "Expert Review" range, you will need to provide specific guidance to the experts. Keep in mind that Expert Review doesn't require WG approval (or even discussion), unless the guidance is specific about that. Take a look at draft-ietf-idr-bgp-ls-registry for an example of guidance that includes the WG -- if that's what you want. [AA/KS] Please see comment above. This is all fixed. [minor] Please add a table here to show the values. Pointing at Table 1 is not enough because it doesn't include the unassigned range. [AA/KS] Done. New Table 3 is added. [minor] Also, please include a table showing the ranges and the allocation policy, if more than one. [AA/KS] Done. Table 3 is newly added. 359 This document defines a new subcode, "Role Mismatch" with an assigned 360 value in the OPEN Message Error subcodes registry [to be 361 removed upon publication: http://www.iana.org/assignments/bgp- 362 parameters/bgp-parameters.xhtml#bgp-parameters-6] [RFC4271]. [major] s/a new subcode, "Role Mismatch" with an assigned value in the OPEN Message Error subcodes registry [...] [RFC4271]./the "Role Mismatch" Message Error subcode. IANA has assigned value 8 [...]. [AA/KS] Fixed. 364 This document defines a new optional, transitive BGP Path Attributes 365 option, named "Only to Customer (OTC)" with an assigned value 366 [To be removed upon publication: http://www.iana.org/assignments/bgp- 367 parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271]. The 368 length of this attribute is four bytes. [major] s/a new optional, transitive BGP Path Attributes option, named "Only to Customer (OTC)" with an assigned value [...] [RFC4271]./the "Only to Customer (OTC)" BGP Path Attribute [...]. IANA has assigned code value 35. [AA/KS] Fixed [minor] The length is already specified in =C2=A76; no need to repeat that = here. [AA/KS] Fixed 370 10. Security Considerations 372 This document proposes a mechanism for prevention of route leaks that 373 are the result of BGP policy misconfiguration. 375 A misconfiguration in OTC setup may affect prefix propagation. But 376 the automation that is provided by BGP roles should make such 377 misconfiguration unlikely. [minor] Please add references to rfc4271 and rfc4272. [AA/KS] Done [major] There are multiple security issues that a rogue router (whether it is due to misconfiguration or on purpose) can take advantage of. Prefix propagation, both in the "route will go further" point of view, as well as when the "route will not go as far". Please elaborate a little on the differences. Also, there are cases, with strict mode on for example, where the session may not even be established. Please include these risks in this section. [AA/KS] We have carefully revised the whole Security Considerations section to incorporate the above comments. ... 405 11.2. Informative References ... 419 [RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., 420 and B. Dickson, "Problem Definition and Classification of 421 BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 422 2016, = . [major] The definition of a route leak is the base for this work, so this reference should be Normative. [AA/KS] Fixed 424 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 425 Writing an IANA Considerations Section in RFCs", BCP 26, 426 RFC 8126, DOI 10.17487/RFC8126, June 2017, 427 . [major] This reference should be Normative. [AA/KS] Fixed [End of Review -15] =D0=B2=D1=82, 15 =D0=B8=D1=8E=D0=BD. 2021 =D0=B3. =D0=B2 00:47, Alvaro Reta= na : > On June 12, 2021 at 5:12:37 PM, Alexander Azimov wrote: > > > Hi! > > ... > > May I ask you to give more details on this part of your comment? > > > Also, I believe the specification is not complete. > > Can you amplify what parts of mechanics are missing? > > There are some comments in =C2=A74, 6, 7...about the use of multiple > capabilities, error handling, multiple OTC attributes, incomplete > policies, use of the OTC attribute if the capabilities were not > successfully negotiated, etc. > > THT -- thanks! > > Alvaro. > --=20 Best regards, Alexander Azimov --000000000000c96ff805c936eac8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Alvaro,

=C2=A0

Thank you once again for your very careful review and detailed comments.

We tried our best to carefully consider a= ll your comments,=C2=A0incorporated changes accordingly in version -16, and uploaded it.

htt= ps://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-16=

Our (authors=E2=80=99) responses to your specific comments are inline below and marked with [AA/KS].

=C2=A0

Before jumping to the long list of inline= comments I'd like to highlight that while policy=C2=A0specification is= better worded now, their principles remain unchanged.

So, the existing implementations remain practically unaffected except for the minor=C2=A0consideration of the presence of multiple OTCs per UPDATE.

=C2=A0

The inline comments took 21 pages in Word. The last line should read: [End = of Review -15]

If that does not s= how, then it means the text got cut off somewhere. Let us know.=C2=A0


Alexander / Sriram


------------------------------------------

=C2=A0

[Idr] AD Review of draft-ietf-idr-bgp-open-policy-15

Alvaro Retana <aretana.ietf@gmail.com>= ; Wed, 09 June 2021 19:40 UTC

=C2=A0

Dear authors:

=C2=A0

Thank you for your work on addressing the route leaks problem!

=C2=A0

I think the document still needs a lot of work.=C2=A0 In general, the

precision in the language is not what I would expect from a Standards

Track document. =C2=A0Also, I believe the specification is not complete.

Please see details inline.

=C2=A0

Instead of returning the document to the WG, and because it is short,

I am including a long list of suggestions below.=C2=A0 Given all the

proposed changes, we will eventually need to run a new WGLC explicitly

including the grow WG -- I have cc'd them in this message as well.

=C2=A0

Thanks!

=C2=A0

Alvaro.

=C2=A0

[Line numbers from idnits.]

=C2=A0

...

14=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 Route Leak Prevention using Roles in Update and Open messages

15=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-idr-bgp-open-policy-15=

=C2=A0

[minor] s/Update and Open/UPDATE and OPEN BGP

=C2=A0

[AA/KS] = Fixed.

=C2=A0

[major] Throughout the document the concept of "sending prefixes" (or

sometimes announcing them) is used -- I understand that these are

common phrases. =C2=A0However, that is not the terminology used in rfc4271.

Please use "route advertisement" (and variations) instead.=C2=A0 Note that

"propagated" is also ok.

=C2=A0

[AA/KS] <= /span>Fixed.

=C2=A0

17=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Abstract

=C2=A0

19=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Route leaks are the propagation of BGP prefixes which violate

20=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 assumptions of BGP topology relationships; e.g. passing a route

21=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 learned from one lateral peer to another lateral peer or a transit

22=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 provider, passing a route learned from one transit provider to

23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 another transit provider or a lateral peer.=C2=A0 Existing approaches to

24=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 leak prevention rely on marking routes by operator configuration,

25=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 with no check that the configuration corresponds to that of the eBGP

26=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 neighbor, or enforcement that the two eBGP speakers agree on the

27=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 relationship.=C2=A0 This document enhances BGP OPEN to establish agreement

28=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 of the (peer, customer, provider, Route Server, Route Server client)

29=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 relationship of two neighboring eBGP speakers to enforce appropriate

30=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 configuration on both sides.=C2=A0 Propagated routes are then marked with

31=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 an Only to Customer (OTC) attribute according to the agreed

32=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 relationship, allowing both prevention and detection of route leaks.

=C2=A0

[minor]

=C2=A0

OLD>

=C2=A0 =C2=A0This document enhances BGP OPEN to establish agreement of the (peer,

=C2=A0 =C2=A0customer, provider, Route Server, Route Server client) =C2=A0relationship of

=C2=A0 =C2=A0two neighboring eBGP speakers to enforce appropriate configuration on both

=C2=A0 =C2=A0sides. Propagated routes are then marked with an Only to Customer (OTC)

=C2=A0 =C2=A0attribute according to the agreed relationship, allowing both prevention

=C2=A0 =C2=A0and detection of route leaks.

=C2=A0

Suggestion>

=C2=A0 =C2=A0This document enhances the BGP OPEN message to establish an agreement of<= /p>

=C2=A0 =C2=A0the relationship between two eBGP speakers in order to enforce appropriate

=C2=A0 =C2=A0configuration on both sides.=C2=A0 Propagated routes are then marked according

=C2=A0 =C2=A0to the agreed relationship, allowing both prevention and detection of route=

=C2=A0 =C2=A0leaks.

=C2=A0

[AA/KS] = Done.

=C2=A0

...

94=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.=C2=A0 Introduction

=C2=A0

96=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 A BGP route leak occurs when a route is learned from a transit

97=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 provider or lateral peer and then announced to another provider or

98=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 lateral peer.=C2=A0 See [RFC7908].=C2=A0 These are usually the result of

99=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 misconfigured or absent BGP route filtering or lack of coordination

100=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 between two eBGP speakers.

=C2=A0

[nit] s/peer.=C2=A0 See [RFC7908]./peer [RFC7908].=C2=A0=C2= =A0=C2=A0=C2=A0

=C2=A0

[AA/KS] Fixed.

=C2=A0

[nit] s/between two eBGP speakers./between autonomous systems.

=C2=A0

[AA/KS] Fixed.

=C2=A0

102=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The mechanism proposed in

103=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 [I-D.ietf-grow-route-leak-detection-mitigation] uses large-

104=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 communities to perform detection and mitigation of route leaks.

105=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 While signaling using communities is easy to implement and deploy

106=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 quickly, it normally relies on operator-maintained policy

107=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 configuration, which is vulnerable to misconfiguration [Streibelt].

108=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The community signal can also be stripped at the ISP boundaries.

=C2=A0

[major] This paragraph says that another proposal uses a different

mechanism to solve the same problem...but that it has issues.=C2=A0 I am

not a fan of comparing solutions, much less ones that are still in

progress (even if the authors overlap).=C2=A0 Please remove this paragraph.

=C2=A0

Having said that, I-D.ietf-grow-route-leak-detection-mitigation points

back at this document as a way to help automate the process described

there.=C2=A0 Are there any specific dependencies on that draft from this

one?=C2=A0 I don't think so, but if there are, that would be the reason to

reference it.

=C2=A0

I am assuming that any interaction will be included in

I-D.ietf-grow-route-leak-detection-mitigation -- and that it won't

change this document. =C2=A0That other ID is still under discussion.=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] The paragraphs with comparison with the other draft has been removed.

=C2=A0

110=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 This document provides configuration automation using 'BGP roles',

111=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 which are negotiated using a new BGP Capability Code in OPEN message

112=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 (see Section 4 in [RFC5492]).=C2=A0 Either or both BGP speakers MAY be

113=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 configured to require that this capability be agreed for the BGP OPEN

114=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 to succeed.

=C2=A0

[nit] s/in OPEN message/in the OPEN message=C2=A0=C2= =A0=C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed.

=C2=A0

[minor] s/see Section 4 in [RFC5492]/[RFC5492]

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed.

=C2=A0

[major] "MAY be configured to require" =C2=A0 This phrase sounds like a

contradiction: it is optional to require something.=C2=A0 Let's leave the

normative language to the normative parts of this document. =C2=A0s/MAY/may<= /p>

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] = Fixed.

=C2=A0= =C2=A0=C2=A0=C2=A0

116=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 A new optional, transitive BGP Path Attribute Only to Customer (OTC)

117=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 is specified that SHOULD be automatically configured using BGP roles.

118=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 This attribute prevents networks from creating leaks, and detects

119=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 leaks created by third parties.

=C2=A0

[major] Again, let's keep normative language for later.

=C2=A0

Suggestion>

=C2=A0 =C2=A0A new optional, transitive BGP Path Attribute, called Only to Customer

=C2=A0 =C2=A0(OTC), is specified in Section 6.=C2=A0 It prevents networks from creating

=C2=A0 =C2=A0leaks, and detects leaks created by third parties.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed. New text as follows:

=C2=A0=C2=A0 This document provides configurati= on automation using BGP Roles,

=C2=A0=C2=A0 which are negotiated using a BGP R= ole Capability in the OPEN message

=C2=A0=C2=A0 [RFC5492].=C2=A0

=C2=A0

...

124=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 2.=C2=A0 Peering Relationships

=C2=A0

126=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Despite the use of terms such as "customer", "peer", etc. in this

127=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 document, these are not necessarily business relationships based on

128=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 payment agreements. =C2=A0These terms are used to represent restrictions

129=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 on BGP route propagation, sometimes known as the Gao-Rexford model

130=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 [Gao].=C2=A0 The following is a list of various roles in eBGP peering and

131=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 the corresponding rules for route propagation:

=C2=A0= =C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0

[major] Given the normative language used below, it should be made

clear that the names of the roles are defined for and apply only to

the discussion in this document.=C2=A0 I don't want there to be confusion

related to general terms like "peer".

=C2=A0

It would be ideal if the roles were identified by their

capitalization, to differentiate between "Peer" (the role) and "peer"

(as in the BGP speaker at the other side of the session).=C2=A0 Please

review the document and make the necessary changes.

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS]=C2=A0 s/peer/Peer/g + all other roles are also capitalized; see revised Sections 2 and 3. Added a Terminology Section 1.1 where these roles (Peer, Provider, etc.), local/remote AS, and =E2=80=9Croute is ineligible=E2=80=9D are clearly d= efined.=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0

<= /span>

=C2=A0

Suggestion>

=C2=A0 =C2=A0The terms defined and used in this document (see below) don't necessarily<= /p>

=C2=A0 =C2=A0represent business relationships based on payment agreements.=C2=A0 These terms

=C2=A0 =C2=A0are used to represent restrictions on BGP route propagation, sometimes

=C2=A0 =C2=A0known as the Gao-Rexford model [Gao].=C2=A0 The following is a list of the roles

=C2=A0 =C2=A0for eBGP peering and their corresponding rules for route propagation:

=C2=A0

[AA/KS] Done.

=C2=A0

133=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Provider: =C2=A0MAY send to a customer all available prefixes.

=C2=A0

[major] The option is not to send all or nothing, but the fact that a

Provider can send anything (from a default, to a subset, to all) to a

Customer, right?

=C2=A0

Suggestion>

=C2=A0 =C2=A0Provider: =C2=A0MAY propagate any available route to a Customer.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS]=C2=A0 Applied, also s/propagate/advertise/. See revised Sec. 2.

=C2=A0

135=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Customer: =C2=A0MAY send to a provider prefixes which the sender

136=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0originates and prefixes learned from any of their customers. =C2=A0A

137=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0customer MUST NOT send to a provider prefixes learned from its

138=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0peers, from other providers, or from Route Servers.

=C2=A0

[major] "MAY send to a provider...prefixes learned from any of their customers."<= /p>

=C2=A0

This got me thinking of the fact that the role (Customer) is for a

specific eBGP session, but an AS may have multiple eBGP sessions with

multiple roles, which is where the part about "learned from any of

their customers" comes from.=C2=A0 Please add some text at the start of

this section (maybe in a separate paragraph after the first couple of

sentences above) to explain.

=C2=A0

[AA/KS] Done. Please see revised Section 2. Also, we have added =E2=80=9C=E2=80=A6on each eBGP sessi= on between autonomous systems (ASes)=E2=80=9D in relevant places -- in the Intro secti= on, Sections 3 and 5.

=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0

[major] "MUST NOT send...prefixes learned from..." =C2=A0Again, given that

the roles are session-based, how do you expect this requirement to be

satisfied?=C2=A0 IOW, how would an eBGP session in routerA know that a

specific prefix was learned from a Peer (or not) at routerB on the

other side of the network?

=C2=A0

[AA/KS] There are some details that need to be understood. If a route was advertised by a Peer, Provider, = or RS and it is not marked with OTC, then the ingress router adds an OTC Attri= bute with the AS number of the sender (remote AS). See revised Section 4. The me= re presence of an OTC indicates to the egress router that the route was learne= d from a Peer, Provider, or RS and it can be advertised only to customers. The abs= ence of an OTC Attribute indicates to the egress router that the route was eithe= r advertised by a Customer or originated by the local AS. If a route received from a Customer at an ingress router has an OTC Attribute, then the route i= s rejected by ingress policy. So, a customer route or a locally originated route never= has OTC attached when received at the egress router. Now, this is explained wel= l in the revised Section 4 in the updated draft.

=C2=A0

[AA/KS] We have added new wording in Section 4 to explain the above for the reader=E2=80=99s benefit. This ne= w wording appears immediately after the egress policy description.=C2=A0 =C2=A0=C2=A0= =C2=A0

=C2=A0

I believe that current practice of using communities to identify where

the routes came from is a straight-forward solution to this issue.

Please add something to that effect, as an example of how the

requirement can be met -- but also declare the specific mechanism out

of scope.

=C2=A0

[AA/KS] That internal (i.e., intra-AS) mechanism is subsumed in the OTC mechanism. Please see the explanation provided above.

=C2=A0

This issue is not specific to Customers, so add the extra text after

the roles are defined.

=C2=A0

[AA/KS] We think here you are taking about the mention of =E2=80=9Cmultiple eBGP sessi= ons with

multiple roles=E2=80=9D. As stated above, we took care of this generally by adding =E2=80=9C=E2=80=A6on= each eBGP session between autonomous systems (ASes)=E2=80=9D a few times in the Intro section= and in Sections 3 and 5.

=C2=A0

[minor] The only role not listed is RS-Client.=C2=A0 I'm assuming that

prefixes learned from a RS-Client also MUST NOT be advertised, right?

=C2=A0

[AA/KS] Yes, RS-Client is not listed (in what a Customer MAY propagate). The assumption = is that an RS does not have a Provider (transit provider) by definition. An RS treats all ASes connected to it as RS-Clients. So, a local AS with a Custom= er Role is not an RS and thus does not have RS-Clients.=C2=A0 =C2=A0

=C2=A0

Suggestion>

=C2=A0 =C2=A0Customer: MAY advertise any route learned from a Customer, or locally

=C2=A0 =C2=A0originated, to a Provider.=C2=A0 All other routes MUST NOT be propagated.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed.

=C2=A0

140=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Route Server (RS): =C2=A0MAY send to an Route Server client (RS-client)

141=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0all available prefixes.

=C2=A0

[] Suggestion>

=C2=A0 =C2=A0Route Server (RS): =C2=A0MAY propagate any available route to a Route Server

=C2=A0 =C2=A0Client (RS-Client).

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed.

=C2=A0

143=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 RS-client: =C2=A0MAY send to an RS prefixes which the sender originates

144=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0and prefixes learned from its customers.=C2=A0 An RS-client MUST NOT

145=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0send to an RS prefixes learned from its peers or providers, or

146=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0from another RS.

=C2=A0

[] Suggestion>

=C2=A0 =C2=A0RS-Client: MAY advertise any route learned from a Customer or locally

=C2=A0 =C2=A0originated to a Route Server.=C2=A0 All other routes MUST NOT be propagated.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed

=C2=A0

=C2=A0

148=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Peer: =C2=A0MAY send to a peer prefixes which the sender originates and

149=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0prefixes learned from its customers.=C2=A0 A peer MUST NOT send to a

150=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0peer prefixes learned from other peers, from its providers, or

151=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0from RS(s).

=C2=A0

[] Suggestion>

=C2=A0 =C2=A0Peer: MAY advertise any route learned from a Customer or locally

=C2=A0 =C2=A0originated to a Peer.=C2=A0 All other routes MUST NOT be propagated.

=C2=A0

[AA/KS] Fixed

153=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Of course, any BGP speaker may apply policy to reduce what is

154=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 announced, and a recipient may apply policy to reduce the set of

155=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 routes they accept. =C2=A0Violation of the above rules may result in route

156=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 leaks and MUST NOT be allowed.=C2=A0 Automatic enforcement of these rules

157=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 should significantly reduce route leaks that may otherwise occur due

158=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 to manual configuration mistakes.=C2=A0 While enforcing the above rules

159=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 will address most BGP peering scenarios, their configuration is not

160=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 part of BGP itself; therefore, configuration of ingress and egress

161=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 prefix filters is still strongly advised.

=C2=A0

[nit] s/Of course, any BGP/A BGP

[AA/KS] Fixed.

=C2=A0

=C2=A0

[major] "MUST NOT be allowed" =C2=A0I don't know how this requirement is

enforced: the sender should advertise what is specified.=C2=A0 Adding a

normative requirement to the options and requirements listed doesn't

contribute...

=C2=A0

Suggestion: remove the whole sentence; there is some redundancy with

the next one.=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] s/Violation of the above rules may result in ro= ute leaks and MUST NOT be allowed./Violation of the above rules may result in route leaks./

=C2=A0= =C2=A0=C2=A0=C2=A0

=C2=A0

[?] "their configuration is not part of BGP itself" =C2=A0I don't

understand what this phrase is intended to mean.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS]=C2=A0 Yes, confusing. Removed the phrase. Repla= ced the paragraph with this shorter and clearer one:

=C2=A0=C2=A0 A BGP speaker may apply policy to reduce what is announced, and a

=C2=A0=C2=A0 recipient may apply policy to reduce the s= et of routes they accept.=

=C2=A0=C2=A0 Violation of the above rules may result in route leaks.=C2=A0 Automatic

=C2=A0=C2=A0 enforcement of these rules should significantly reduce route leaks

=C2=A0=C2=A0 that may otherwise occur due to manual configuration mistakes.

=C2=A0

163=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 3.=C2=A0 BGP Role

=C2=A0

[] This section should be placed *before* =C2=A72 (Peering Relationships),

so that the roles are described before the advertisement rules.=C2=A0 Some

of the text in the first paragraph of =C2=A72 (about business

relationships) should be moved here.=C2=A0=C2=A0=C2=A0=C2=A0 <= /span>

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] We were fol= lowing the sequence of introduction -> motivation & definitions -> solution specification. And the id= ea behind =C2=A72 was to describe motivation and then go to the solution with = BGP Roles. The way the wording has been revised in these sections should make t= his flow even=C2=A0 better. Please see revised Sections 2 and 3.

=C2=A0

=C2=A0

165=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 BGP Role is a new configuration option that is configured on a per-

166=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 session basis.=C2=A0 BGP Roles reflect the agreement between two BGP

167=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 speakers about their relationship.=C2=A0 One of the Roles described below

168=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 SHOULD be configured on each eBGP session between ISPs that carry

169=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 IPv4 and(or) IPv6 unicast prefixes.

=C2=A0

[minor] "BGP Role is a new configuration option that is configured on

a per-session basis."

=C2=A0

I don't think that this document should deal with specifics of what

could be configured in an implementation -- but with the function of

the roles.

=C2=A0

Suggestion>

=C2=A0 =C2=A0The BGP Role characterizes the relationship between the eBGP speakers

=C2=A0 =C2=A0forming a session.=C2=A0=C2=A0=C2=A0=C2=A0

[AA/KS] The updated paragraph (at the top of Section 3) reads as follows:

=C2=A0=C2=A0 The BGP Role characterizes the rel= ationship between the eBGP speakers

=C2=A0=C2=A0 forming a session.=C2=A0 BGP Role = is configured on a per-session basis.

=C2=A0=C2=A0 An eBGP speaker SHOULD configure t= he BGP Role locally based on the

=C2=A0=C2=A0 local AS's knowledge of its Ro= le.=C2=A0 The only exception is when the

=C2=A0=C2=A0 eBGP connection is complex (see Se= ction 5).=C2=A0 BGP Roles are mutually

=C2=A0=C2=A0 confirmed using the BGP Role Capab= ility (described in Section 3.1) on

=C2=A0=C2=A0 each eBGP session between autonomo= us systems (ASes).=C2=A0 One of the

=C2=A0=C2=A0 Roles described below SHOULD be co= nfigured at the local AS for each

=C2=A0=C2=A0 eBGP session with a neighbor (remo= te AS) (see definitions in

=C2=A0=C2=A0 Section 1.1).

=C2=A0

[major] "One of the Roles described below SHOULD be configured on each

eBGP session between ISPs that carry IPv4 and(or) IPv6 unicast

prefixes."

=C2=A0

I have several questions:

=C2=A0

- =C2=A0When is it ok to not use a role?=C2=A0 Why is the configuration

recommended and not required?=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

[AA/KS] = The exception is the =E2= =80=98complex=E2=80=99 relations case that is described in the additional considerations section.= See the updated paragraph at the top of Section 3 (copied above). =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

- Only between ISPs? =C2=A0What about Customers?=C2=A0 Are Route Servers

considered ISPs? =C2=A0At minimum, you should describe the term some more.

This should also scope the applicability.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] The ISP term was used very loosely.=C2=A0 Correction: s/ISP/AS/. Please see the updated paragraph (copied above).

=C2=A0

- Only unicast routes?=C2=A0 Why? =C2=A0 This probably goes to the definition of

a route leak and where it happens. =C2=A0rfc7908 focuses on what has been

seen on the Internet -- but I'm sure that as long as the same types of

relationships/topologies, the same type of issues can occur.=C2=A0 I'm not

asking that you explore that, but maybe a quick mention (in the

Introduction) that the main focus/applicability is the Internet, then

it won't be necessary to mention AFs.

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] Per your suggestion, we have inserted this sentence in the Intro section:=C2=A0 =E2=80=9CThe ma= in focus/applicability is the Internet (IPv4 and IPv6=C2=A0 route announcements).=E2=80=9D We make only one other mention of IPv4 and IPv6 a= t the end of Section 4 as follows:=

=C2=A0=C2=A0 The described ingress and egress policies are applicable only for

=C2=A0 =C2=A0unicast IPv4 and IPv6 address families an= d MUST not affect other=

=C2=A0=C2=A0 address families by default.

=C2=A0

...

184=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Since BGP Role reflects the relationship between two BGP speakers, it

185=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 could also be used for other purposes besides route leak mitigation.

=C2=A0

[] Like what?=C2=A0 I'm not disagreeing, but it seems like this sentence is

unnecessary.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] For example, one can imagine configuring local preference based on BGP Roles configuration. But since it is out of the scope of this document, we have removed the whole sentence.

=C2=A0

187=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 4.=C2=A0 BGP Role Capability

=C2=A0

189=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The TLV (type, length, value) of the BGP Role capability are:

=C2=A0

191=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 o =C2=A0Type - <TBD1>;

=C2=A0

[major] Capabilities are not exactly defined as TLVs.

=C2=A0

Suggestion>

=C2=A0 =C2=A0The BGP Role Capability is defined as follows:

=C2=A0

=C2=A0 =C2=A0o =C2=A0Code: 9

=C2=A0 =C2=A0...

[AA/KS]=C2=A0 Fixed

=C2=A0

...

197=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------+---------------------+

198=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Value | Role name =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |

199=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------+---------------------+

200=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 0 =C2=A0 | Sender is Prov= ider =C2=A0|

201=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 1 =C2=A0 | Sender is RS =C2=A0 =C2=A0 =C2=A0 =C2=A0|

202=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 2 =C2=A0 | Sender is RS-client |

203=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 3 =C2=A0 | Sender is Cust= omer =C2=A0|

204=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 4 =C2=A0 | Sender is Peer =C2=A0 =C2=A0 =C2=A0|

205=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------+---------------------+

=C2=A0

[minor] The description of the Value says that the Role corresponds to

the speaker/sender. =C2=A0There's no need to use "Sender is" for every

entry.=C2=A0 Also, the "Role name" is simply Provider, RS, etc.=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

[AA/KS] We now use the terms local AS /remote AS per your suggestion instead of sender/receiver. Hence, in the table, s/Role name/Role name (for the local AS)/=C2=A0

Also, we got rid of =E2=80=9CSender is=E2=80=9D. Please see the new Table 1 in the updated draft.

=C2=A0=C2= =A0=C2=A0=C2=A0

=C2=A0

207=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Table 1: Predefined BGP Role Values

=C2=A0

[major] It is not a given that a single capability has to be included

-- rfc5492 includes the case where a multiple of the same can be

present.

=C2=A0

Suggestion>

=C2=A0 =C2=A0A BGP Speaker MUST NOT advertise multiple versions of the BGP Role

=C2=A0 =C2=A0Capability. =C2=A0If a BGP Speaker receives multiple copies of the BGP Role

=C2=A0 =C2=A0Capability.... ???=C2=A0=C2=A0= =C2=A0=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS]=C2=A0 We have added the suggested text at the end= of Section 3.1 as follows:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If BGP Rol= e is locally configured, the eBGP speaker MUST advertise

=C2=A0=C2=A0 BGP Role Capability in the BGP OPE= N message.=C2=A0 An eBGP speaker MUST

=C2=A0=C2=A0 NOT advertise multiple versions of= the BGP Role Capability.

=C2=A0

[AA/KS] For the second part of your suggestion, we have also added the following in Section 3.2:=

=C2=A0=C2=A0 If an eBGP speaker receives multiple but identical BGP Role

=C2=A0=C2=A0 Capabilities with the same value in each, then the speaker MUST<= /span>

=C2=A0=C2=A0 consider it to be a single BGP Role Capability and proceed [RFC5492].

=C2=A0=C2=A0 If multiple BGP Role Capabilities are received and not all of them

=C2=A0=C2=A0 have the same value, then the BGP speaker MUST reject the connection

=C2=A0=C2=A0 using the Role Mismatch Notification (code 2, subcode 8).

=C2=A0

=C2=A0

209=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 5.=C2=A0 Role correctness

=C2=A0

[minor] This section talks about the validation of the capability.

Please make it a sub-section of =C2=A74.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS]=C2=A0 We have restructured the sections as follow= s:

=C2=A0

=C2=A0=C2=A0 3.=C2=A0 BGP Role=C2=A0 . . . . . . . . . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 4

=C2=A0=C2=A0=C2=A0=C2=A0 3.1.=C2=A0 BGP Role Capability . . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 5

=C2=A0=C2=A0=C2=A0=C2=A0 3.2.=C2=A0 Role Correctness=C2=A0 . . . . . . . . . . . . . . . . . . . .=C2=A0=C2=A0 5

=C2=A0

=C2=A0

211=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Section 3 described how BGP Role encodes the relationship between two

212=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 eBGP speakers.=C2=A0 But the mere presence of BGP Role doesn't

213=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 automatically guarantee role agreement between two BGP peers.

=C2=A0

[minor] The encoding is defined in =C2=A74.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS]=C2=A0 Fixed. Please see the top 2 paragraphs of Sec. 3.2.

=C2=A0

=C2=A0

215=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 To enforce correctness, the BGP Role check is applied with a set of

216=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 constraints on how speakers' BGP Roles MUST correspond.=C2=A0 Of course,

217=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 each speaker MUST announce and accept the BGP Role capability in the

218=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 BGP OPEN message exchange.

=C2=A0

[major] "MUST announce and accept"

=C2=A0

This requirement contradicts the default setting of "strict mode": if

false, then the speaker cannot be expected to both send and receive

the capability.

=C2=A0

[AA/KS] We got rid of the cited phrase. We also got rid of the contradiction. At the bottom of Se= c 3.1, it now says:

=C2=A0=C2=A0 If BGP Role is locally configured,= the eBGP speaker MUST advertise

=C2=A0=C2=A0 BGP Role Capability in the BGP OPE= N message.=C2=A0 An eBGP speaker MUST

=C2=A0=C2=A0 NOT advertise multiple versions of= the BGP Role Capability.

=C2=A0

I think that we could eliminate =C2=A75.1 by bringing the intent of the

text up to this section. =C2=A0Suggestion>

=C2=A0

=C2=A0 =C2=A0A BGP Speaker that supports the BGP Role Capability SHOULD include it in

=C2=A0 =C2=A0the OPEN Message.=C2=A0 If the BGP Role Capability is sent, but one is not

=C2=A0 =C2=A0received, then the connection SHOULD be rejected using the Role Mismatch

=C2=A0 =C2=A0Notification (code 2, subcode 8); this mode of operation is called "strict

=C2=A0 =C2=A0mode". For backwards compatibility, if the BGP speaker does not receive

=C2=A0 =C2=A0the capability from its peer, it MAY proceed with session establishment<= /p>

=C2=A0 =C2=A0without consideration for the roles defined here; this SHOULD be the

=C2=A0 =C2=A0default mode of operation.

=C2=A0

[AA/KS] Great suggestion. We have followed it. Previous Section 5 is now Section 3.2. Previous Section 5.1 has been subsumed in Section 3.2 per your suggestion. Section 3.2 is now well-organized including dealing with error condition wi= th multiple versions of the BGP Role Capability.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0

Note that in this suggestion I used the "Role Mismatch Notification",

but not receiving the capability is not really a role mismatch -- its

a "missing capability" error.=C2=A0 This type of error is not currently

defined.=C2=A0 It is up to you whether you want to define it here or not.

=C2=A0

[AA/KS] Using the Role Mismatch Notification here seems the prudent choice. No need to define anot= her error type.=C2=A0

=C2=A0

=C2=A0

220=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 If a speaker receives a BGP Role capability, it MUST check the value

221=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 of the received capability (i.e., the sender's role) with its own BGP

222=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Role.=C2=A0 The allowed pairings are as follows:

=C2=A0

[major] "MUST check" =C2=A0 The required action is not to check, but to

make sure that the advertised values match one of the pairs below.

=C2=A0

Suggestion (using also text from the last paragraph in this section)>

=C2=A0

=C2=A0 =C2=A0If the BGP Role Capability is sent and one is also received from the peer,

=C2=A0 =C2=A0the roles must correspond to the relationships in Table 2.=C2=A0 If the roles<= /p>

=C2=A0 =C2=A0do not correspond, the BGP Speaker MUST reject the connection using the Role

=C2=A0 =C2=A0Mismatch Notification (code 2, subcode 8).

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Applied.=C2=A0 See 2nd para in Sec. 3.2. <= /p>

=C2=A0

=C2=A0

224=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+-----------------+

225=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Sender's Role | Receiver's Role= |

226=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+-----------------+

227=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Provider =C2=A0 =C2=A0 =C2=A0| Customer =C2=A0 =C2=A0 =C2=A0 =C2=A0|

228=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Customer =C2=A0 =C2=A0 =C2=A0| Provider =C2=A0 =C2=A0 =C2=A0 =C2=A0|

229=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| RS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| RS-client =C2=A0 =C2=A0 =C2=A0 |

230=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| RS-client =C2=A0 =C2=A0 | RS =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

231=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Peer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | Peer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

232=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------+-----------------+

=C2=A0

[major] I find the language of the local router checking the "received

capability (i.e., the sender's role)" confusing since I would have

expected the local router to be the sender.=C2=A0 To avoid confusion, it

might be clearer to call the roles "local" and "remote".=C2=A0 I realize<= /p>

that in the end the point of view doesn't matter much as long as a

router picks one -- but this is a standards track specification and it

should be as precise as possible.

=C2=A0

[AA/KS] Fixed. We now use =E2=80=98local AS=E2=80=99/ =E2=80=98r= emote AS=E2=80=99 terminology per your advice. We describe it upfront in Section 1.1 (Terminology). In the table (cited above), we did the following: s/Sender=E2=80=99s Role/Local AS Role= / and s/Receiver's Role/Remote AS Role/. See Table 2 in Section 3.2. =

=C2=A0

...

236=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 If the role of the receiving speaker for the eBGP session in

237=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 consideration is included in Table 1 and the observed Role pair is

238=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 not in the above table, then the receiving speaker MUST reject the

239=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 eBGP connection, send a Role Mismatch Notification (code 2, subcode

240=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 <TBD2>), and also send a Connection Rejected Notification [RFC4486]

241=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 (Notification with error code 6, subcode 5).

=C2=A0

[] I moved this text to the suggested paragraph before Table 2.=C2=A0 Also,

note that only one Notification can be sent at a time.

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] Fixed. Suggestions followed. Please see the revised paragraph before Table 2. xxx

...

255=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 6.=C2=A0 BGP Only to Customer (OTC) Attribute

=C2=A0

257=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Newly defined here, the Only to Customer (OTC) is an optional, 4

258=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 bytes long, transitive BGP Path attribute with the Type Code <TBD3>.

259=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The purpose of this attribute is to guarantee that once a route is

260=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 sent to customer, peer, or RS-client, it will subsequently go only to

261=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 customers.=C2=A0 The value of OTC is an AS number determined by policy as

262=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 described below.=C2=A0 The semantics and usage of the OTC attribute are

263=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 made clear by the ingress and egress policies described below.

=C2=A0

[] Suggestion>

=C2=A0

=C2=A0 =C2=A0The Only to Customer (OTC) Attribute is an optional transitive path

=C2=A0 =C2=A0attribute with Attribute Type Code 35 and a length of 4 octets.=C2=A0 The

=C2=A0 =C2=A0attribute value is an AS number (ASN) determined by the policy described

=C2=A0 =C2=A0below.

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] We applied your wording, but kept the phrase related to the purpose of the attribute.=C2=A0= Please see the first paragraph of Section 4.

=C2=A0

[major] What should a receiver do if the length is not set to 4?

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Added the following wording in the renumbered Section 4:

=C2=A0=C2=A0 If an eBGP speaker receives an UPD= ATE with an OTC Attribute with a

=C2=A0=C2=A0 length different from 4 octets, th= en the UPDATE SHALL be considered

=C2=A0=C2=A0 malformed.=C2=A0 If malformed, the UPDATE message SHALL be handled using

=C2=A0=C2=A0 the approach of "treat-as-withdraw" [RFC7606].

=C2=A0

[AA/KS] In the above, we are following the approach suggested in RFC 7606 for malformed BGP attribut= es.

=C2=A0

265=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The following ingress policy applies to the OTC attribute:

=C2=A0

267=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 1.=C2=A0 If a route with OTC attribute is received from a Customer or RS-

268=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 client, then it is a route leak and MUST be rejected.

=C2=A0

[nit] s/with OTC attribute/with the OTC attribute/g

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] =C2=A0Fixed as follows:

=C2=A0=C2=A0 1.=C2=A0 If a route with the OTC Attribute is received from a Customer or

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RS-Client= , then it is a route leak and MUST be considered

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ineligibl= e (see Section 1.1).

=C2=A0

=C2=A0

[major] "MUST be rejected" =C2=A0What *exactly* does this mean in terms of

BGP?=C2=A0 There is no "rejection" action -- so I'm guessing that

"rejected" means that the route has to be ignored, not used, and not

propagated.=C2=A0 In line with rfc4271/=C2=A79.1.1, would "the route MUST be

considered ineligible" be appropriate?

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Changed to =E2=80=98<= /span>considered ineligible=E2=80=99. We also define the term in the new Section 1.1 (Terminology).

=C2=A0

=C2=A0

270=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 2.=C2=A0 If a route with OTC attribute is received from a Peer and its

271=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 value is not equal to the sending neighbor's Autonomous System

272=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 (AS) number, then it is a route leak and MUST be rejected.

=C2=A0

[major] Can multiple OTC attributes be sent?=C2=A0 What should the receiver

do in that case? =C2=A0I'm also thinking about cases where attributes may

be added by multiple ASes.

=C2=A0

[AA/KS] We have added this wording towards the end in Section 4 (updated draft):

=C2=A0=C2=A0 Correct implementation of the procedures specified in this document

=C2=A0=C2=A0 is not expected to result in the presence of multiple OTC Attributes

=C2=A0=C2=A0 in an UPDATE.=C2=A0 However, if an eBGP speaker receives = multiple OTC

=C2=A0=C2=A0 Attributes with a route, then the only difference in the processing

=C2=A0=C2=A0 is in Step 2 of the ingress policy.

=C2=A0

[AA/KS] Also, Step 2 of the ingress policy now reads:

=C2=A0=C2=A0 2.=C2=A0 If a route with the OTC Attribute is received from a Peer and at

=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0least one of the OTC Attributes h= as a value that is not equal to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the remote (i.e.,=C2=A0 Peer'= s) AS number, then it is a route leak and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST be considered ineligible.=C2=A0

=C2=A0

...

278=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The egress policy MUST be:

=C2=A0

[major] "MUST be" =C2=A0 Given that the clauses (below) also contain

normative language, this "MUST" is unnecessary.

=C2=A0

s/.../The following egress policy applies to the OTC attribute:

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS]=C2=A0 Fixed as follows:

=C2=A0=C2=A0 The following egress policy applies to the processing of the OTC<= /span>

=C2=A0=C2=A0 Attribute:

=C2=A0

280=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 1.=C2=A0 A route with the OTC attribute set MUST NOT be sent to Providers,

281=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Peers, or RS(s).

=C2=A0

[major] This rule seems to contradict the last one on ingress, which

expects the OTC attribute from Peers. =C2=A0??

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] There is no contradiction. We have worded it better as follows (we have interchanged steps 1 and 2 in the revised draf= t):

=C2=A0=C2=A0 2.=C2=A0 If a route already contains the OTC Attribute, it MUST NOT be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propagat= ed to Providers, Peers, or RS(s).

=C2=A0

[AA/KS] Explanation: An ingress router at the local AS expects to receive routes with the OTC attribute set when the remote AS is a Provide, Peer, or RS. When the remo= te is a Peer, the ASN in the OTC MUST match the ASN of the remote AS for the route to be eligible (for route selection). If the remote is a Provider o= r RS, then ASN value in the OTC need not match the ASN of the remote AS for eligibility. When a route is received at ingress from a Provider, RS, or Peer, and the OTC is absent, then an OTC is added at the ingress with ASN value equal to that of the remote AS. So, whoever sets the OTC (remote AS= or local AS) when route is propagated from Provider->Customer, Peer->P= eer, or RS->RS-client, the OTC will have the same value. The egress router = does not forward a route with OTC already set (at a prior AS or at ingress) to= a Provider, Peer, or RC; such a route is sent only to the customers. So, th= e ingress policy is responsible for detecting leaks, egress policy for preventing leaks, and both of them perform OTC marking. The detection may take place multiple hops away.

=C2=A0= =C2=A0=C2=A0=C2=A0

A shorter version of the explanation above is now included in Section 4 immediately after the egress policy.

=C2=A0

[minor] s/A route with the OTC attribute set MUST NOT be/The OTC

Attribute MUST NOT be included in routes

=C2=A0

[AA/KS:] No! That is not correct. When sending a locally-originated or Customer route to a Peer, an = OTC with value equal to the local ASN is added. Note: A Customer or RS-Client a= re not adding the OTC attribute when advertising a route to its Provider or RS, respectively.

=C2=A0

283=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 2.=C2=A0 If route is sent to a Customer or Peer, or an RS-client (when the

284=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 sender is an RS) and the OTC attribute is not present, then it

285=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST be added with value equal to AS number of the sender.

=C2=A0

[] Suggestion>

=C2=A0 =C2=A0If a route to be sent to a Customer, Peer, or an RS-client (when the

=C2=A0 =C2=A0sender is an RS), and the OTC attribute is not present, it MUST be added

=C2=A0 =C2=A0with a value equal to the AS number of the sender.

=C2=A0

[AA/KS] Yes, done. Worded it as follows (note: we have interchanged steps 1 and 2 in the revis= ed draft):

=C2=A0=C2=A0 1.=C2=A0 If a route is to be advertised to a Customer, Peer, or RS-Client

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (when the sender i= s an RS), and the OTC Attribute is not present,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then an OTC Attrib= ute MUST be added with a value equal to the AS

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 number of the loca= l AS.

=C2=A0

[major] There is no corresponding ingress policy that checks the ASN

to match routes received from Providers or RS. =C2=A0(#2 only talks about

Peers)

=C2=A0

[AA/KS:] There is no need. The presence of the OTC attribute on a route received from a Provider= or RS does not require any action to be taken on ingress concerning the OTC. T= he OTC attribute may have been set by the neighbor (remote AS) or an earlier A= S in the path. There is no need to check the OTC value. The mere presence of an = OTC Attribute is a signal for the egress router that the route can be sent only to Custom= ers (i.e., MUST NOT be sent to a Provider or Peer). However, the absence of an = OTC Attribute on a route received from a Provider, Peer, or RS requires that the OTC Attr= ibute be added on ingress with an ASN value equal to that of the sending neighbor (remote AS). This is to cover for a Provider, Peer, or RS that is not upgra= ded to do OTC.

=C2=A0

...

289=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 7.=C2=A0 Enforcement

=C2=A0

291=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Having the relationship unequivocally agreed between the two peers in

292=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 BGP OPEN is critical; BGP implementations MUST enforce the

293=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 relationship/role establishment rules (see Section 5) in order to

294=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 ameliorate operator policy configuration errors (if any).

=C2=A0

[] The suggested text in =C2=A75 eliminates the need for this paragraph.

=C2=A0

[AA/KS] Yes. In fact, the whole =E2=80=98Enforcement=E2=80=99 section is gone/partly subsumed in = other sections.

=C2=A0

296=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Similarly, the application of that relationship on prefix propagation

297=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 using OTC MUST be enforced by the BGP implementations, and not

298=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 exposed to user misconfiguration.

=C2=A0

[] This is a very important point: there are no exceptions to the

policies in =C2=A76. =C2=A0Please add some text to that effect in =C2=A76.

=C2=A0

Suggestion>

=C2=A0 =C2=A0The operator MUST NOT have the ability to modify the policies defined in=

=C2=A0 =C2=A0this section.=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Applied. This sentence is moved to the renumbered Section 4 at the end .

=C2=A0

300=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 As opposed to communities, BGP attributes may not be generally

301=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 modified or stripped by the operator; BGP router implementations

302=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 enforce such treatment. =C2=A0This is the desired property for the OTC

303=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 marking.=C2=A0 Hence, this document specifies OTC as an attribute.

=C2=A0

[] This text goes back to comparing solutions...not needed.

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] =C2=A0Yes. The text is removed.

=C2=A0

305=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 8.=C2=A0 Additional Considerations

...

315=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 No Roles SHOULD be configured on a 'complex' BGP session (assuming it

316=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 is not segregated) and in that case, OTC MUST be set by configuration

317=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 on a per-prefix basis. =C2=A0However, there are no built-in measures to

318=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 check correctness of OTC use if BGP Role is not configured.

=C2=A0

[major] "OTC MUST be set by configuration" =C2=A0I think this phrase

contradicts the statement in =C2=A77 about "OTC...not exposed to user

misconfiguration": both behaviors (allowing configuration, and not)

cannot be required at the same time.=C2=A0 Perhaps all the MUSTs involved

can be changed to SHOULDs. =C2=A0??=C2=A0=C2=A0=C2=A0=C2= =A0

=C2=A0

[AA/KS] The sentence about "OTC...not exposed to user misconfiguration" was not needed= and has been removed. We have also reworded the above cited paragraph. The revi= sed paragraph reads as follows (=E2=80=9CAdditional Considerations=E2=80=9D is = now Sec. 5):

=C2=A0=C2=A0 No Roles SHOULD be configured on a= 'complex' eBGP session (assuming

=C2=A0=C2=A0 it is not segregated) and in that = case, the OTC Attribute processing

=C2=A0=C2=A0 MUST be done relying on configurat= ion on a per-prefix basis.=C2=A0 Also,

=C2=A0=C2=A0 in this case, the per-prefix peeri= ng configuration MUST follow the

=C2=A0=C2=A0 same definitions of peering relati= ons as described in Section 2.

=C2=A0=C2=A0 However, in this case, there are n= o built-in measures to check

=C2=A0=C2=A0 correctness of the per-prefix peer= ing configuration.

=C2=A0

[major] "...there are no built-in measures to check correctness of OTC

use if BGP Role is not configured."

=C2=A0

- If the role is not configured, but the receiving router supports

OTC, what should it do? =C2=A0It sounds that =C2=A76 only applies then the BGP

Role Capability is successfully negotiated -- is that true?

=C2=A0

[AA/KS] First, the sentence has been revised. Please see the revised paragraph copied above starting with =E2=80=98No Roles =E2=80=A6=E2=80=99.

=C2=A0

[AA/KS] Regarding when =C2=A76 (now =C2=A74) applies, given the updated draft, there is no issue o= r confusion anymore. The following revised wording (#1 and #2) fixes it (this takes care of Mach= =E2=80=99s comments also):

=C2=A0=C2=A0 1. Paragraph at the top of Section= 3:

=C2=A0

=C2=A0=C2=A0 The BGP Role characterizes the rel= ationship between the eBGP speakers

=C2=A0=C2=A0 forming a session.=C2=A0 BGP Role = is configured on a per-session basis.

=C2=A0=C2=A0 An eBGP speaker SHOULD configure t= he BGP Role locally based on the

=C2=A0=C2=A0 local AS's knowledge of its Ro= le.=C2=A0 The only exception is when the

=C2=A0=C2=A0 eBGP connection is complex (see Se= ction 5).=C2=A0 BGP Roles are mutually

=C2=A0=C2=A0 confirmed using the BGP Role Capab= ility (described in Section 3.1) on

=C2=A0=C2=A0 each eBGP session between autonomo= us systems (ASes).=C2=A0 One of the

=C2=A0=C2=A0 Roles described below SHOULD be co= nfigured at the local AS for each

=C2=A0=C2=A0 eBGP session with a neighbor (remo= te AS) (see definitions in

=C2=A0=C2=A0 Section 1.1).

=C2=A0

=C2=A0=C2=A0 2. Paragraph in Section 3.2:

=C2=A0=C2=A0

=C2=A0=C2=A0 If the BGP Role Capability is sent= , but one is not received, then the

=C2=A0=C2=A0 connection MAY be rejected using t= he Role Mismatch Notification (code

=C2=A0=C2=A0 2, subcode 8); this mode of operat= ion is called the "strict mode".

=C2=A0=C2=A0 For backward compatibility, if the= BGP speaker does not receive the

=C2=A0=C2=A0 capability from its peer, it SHOUL= D ignore the absence of BGP Role

=C2=A0=C2=A0 Capability and proceed with sessio= n establishment; this SHOULD be the

=C2=A0=C2=A0 default non-strict mode of operati= on.=C2=A0 In this case, the locally

=C2=A0=C2=A0 configured BGP Role is used for th= e procedures described in

=C2=A0=C2=A0 Section 4.

=C2=A0=C2=A0

[AA/KS] =C2=A0Summary: Whether in strict or def= ault mode, BGP Role is configured, except it may not be mutually confirmed in the defa= ult mode.

=C2=A0

[AA/KS] The policies in =C2=A74 (was =C2=A76) apply even in the case of complex relationships based on loca= l configuration of the per-prefix eBGP peering configuration (see 2nd paragra= ph in Section 5).

=C2=A0

- OTOH, if the role is configured and "strict mode" is *not* used, it

sounds as if =C2=A76 only applies if "strict mode" is used?=C2=A0 Is that true,

or should the receiver, who configured the role, but didn't receive

the Capability, and now received the attribute use the policy in =C2=A76?

=C2=A0

[AA/KS] This issue goes away in light of the significant wording changes noted above.

=C2=A0

Whichever the case, it should be clearly called out somewhere. =C2=A0[This

point is closely related to Mach's rtg-dir review.]

=C2=A0

[AA/KS] Yes. As stated above, this issue goes away in light of the wording changes/clarifications (that were also agreed to with Mach).

=C2=A0

320=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The incorrect setting of BGP Roles and/or OTC attributes may affect

321=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 prefix propagation. =C2=A0Further, this document doesn't specify any

322=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 special handling of incorrect/private ASNs in OTC attribute; such

323=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 errors should not happen with proper configuration.

=C2=A0

[minor] "special handling of incorrect/private ASNs in OTC" =C2=A0 =C2=A76 says<= /p>

that the ASN has to match the neighbor's.=C2=A0 That should take care of

the number not being the right one.

=C2=A0

[AA/KS] There is no assumption that OTC value always equals to neighbor=E2=80=99s ASN. It could= be set multiple hops away and propagated Provider-to-Customer (downward) on each o= f the hops. The revised paragraph at the end in =C2=A74 (was =C2=A76) reads:

=C2=A0

=C2=A0=C2=A0 The incorrect setting of BGP Roles and/or OTC Attributes may affect

=C2=A0=C2=A0 prefix propagation.=C2=A0 Further, this do= cument does not specify any

=C2=A0=C2=A0 special handling of incorrect AS numbers i= n the OTC Attribute.=C2=A0 Such

=C2=A0=C2=A0 errors should not happen with proper configuration.<= /p>

=C2=A0

What about confederations?=C2=A0 I understand the intent here is to prevent

leaks in the Internet, so a private ASN shouldn't show up there. =C2=A0=C2=A75

hints at the BGP Role Capability being applicable only to eBGP, but it

doesn't normatively constrain it to "normal" eBGP sessions.=C2=A0 Should

it?=C2=A0 I think it should.=C2=A0 If you do too, what should a receiver do if

the Capability is received over iBGP or an eBGP session that is not

"normal" -- ignore sounds like a good thing.

=C2=A0

[AA/KS] Yes, =E2=80=9Cignore=E2= =80=9D -- meaning do not act on it and let the OTC Attribute propagate -- seems correct. IMO, the OTC processing at the ingress/egress of the confederation will happen correctly as per this draft (RFC). So, nothing specific to confederations needs to be said. Please advi= se.

=C2=A0

325=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 As the BGP Role reflects the peering relationship between neighbors,

326=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 it might have other uses beyond the route leak solution discussed so

327=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 far.=C2=A0 For example, BGP Role might affect route priority, or be used

328=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 to distinguish borders of a network if a network consists of multiple

329=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 ASs.=C2=A0 Though such uses may be worthwhile, they are not the goal of

330=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 this document.=C2=A0 Note that such uses would require local policy

331=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 control.

=C2=A0

[major] Please don't speculate about other uses!=C2=A0 If there are other

uses, then they should be specified.

=C2=A0

[AA/KS] Yes, agree. We have removed the paragraph.

=C2=A0

=C2=A0

333=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The use of BGP Roles are specified for unicast IPv4 and IPv6 address

334=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 families.=C2=A0 While BGP roles can be configured on other address

335=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 families its applicability for these cases is out of scope of this

336=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 document.

=C2=A0

[major] Ok.=C2=A0 So this means that the receiver should look at the

Multiprotocol capability (if present) and make sure that the proper

AFI/SAFI are included. =C2=A0This needs to be specified in =C2=A74.=C2=A0 What should

the receiver do if the Capability is received for a different, or

additional, AFI/SAFI? =C2=A0Or does all this mean that the policy in =C2=A76

simply doesn't apply to other AFI/SAFIs?=C2=A0 What should a receiver do if

the OTC attribute is received on a different AFI/SAFI?=C2= =A0=C2=A0=C2=A0=C2=A0

=C2=A0

[AA/KS] BGP Role capability isn=E2=80=99t negotiated on the AFI/SAFI granularity. Per your earlier su= ggestion, we added the following sentence upfront in the Section 1: =E2=80=9CThe main = focus/applicability is the Internet (IPv4 and IPv6 unicast route advertisements).=E2=80=9D So= , we have now deleted the above quoted sentence. We also added the following in Sec= tion 4 (last paragraph):<= /span>

=C2=A0=C2=A0 The described ingress and egress policie= s are applicable only for

=C2=A0=C2=A0 unicast IPv4 and IPv6 address families a= nd MUST not affect other

=C2=A0=C2=A0 address families by default.=C2=A0

=C2=A0

[AA/KS] Let us know if you feel that the above resolves the issue about AFI/SAFI.

=C2=A0

338=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 As BGP role configuration results in automatic creation of inbound/

339=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 outbound filters, existence of roles should be treated as existence

340=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 of Import and Export policy [RFC8212].

=C2=A0

[minor] "BGP role configuration results in..." =C2=A0 The configuration

doesn't result in anything -- the successful negotiation of the

capability does. =C2=A0Same comment for "existence of roles".=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS]=C2=A0 See below.

=C2=A0

[major] "should be treated as existence of Import and Export policy

[RFC8212]" =C2=A0Should this text use normative language?=C2=A0 SHOULD/MUST?=C2=A0 Is

this a recommendation or a requirement?=C2=A0 If recommended, when would it

be ok to not consider the negotiation to satisfy rfc8212?

=C2=A0

[] Was this interaction with rfc8212 considered by the grow WG?

=C2=A0

[AA/KS]=C2=A0 We have removed the paragraph. RFC 8212 onl= y says that there must exist Explicit Import/Export Policies. It doesn=E2=80=99t list any specific= ones. It allows the vendor to choose what they consider qualify for such policies. <= /span>

=C2=A0=C2=A0=C2=A0

342=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 9.=C2=A0 IANA Considerations

=C2=A0

344=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 This document defines a new Capability Codes option [to be removed

345=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 upon publication: https://www.iana.org/assignments/cap= ability-codes/

346=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 capability-codes.xhtml ] [RFC5492], named "BGP Role" with an assigned

347=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 value <TBD1>. =C2=A0The length of this capability is 1.

=C2=A0

[minor] s/Capability Codes option/BGP Capability=C2=A0=C2= =A0=C2=A0=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] Fixed. We have revised the IANA Considerations (Section 6) to read substantially better.

=C2=A0

[minor] s/, named "BGP Role" with an assigned value <TBD1>./named "BGP

Role".=C2=A0 IANA has assigned value 9.= =C2=A0=C2=A0=C2= =A0=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] Fixed

=C2=A0

[minor] The length is already specified in =C2=A74; no need to repeat that here.=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed

=C2=A0

349=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The BGP Role capability includes a Value field, for which IANA is

350=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 requested to create and maintain a new sub-registry called "BGP Role

351=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Value". =C2=A0Assignments consist of Value and corresponding Role name.

352=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Initially this registry is to be populated with the data contained in

353=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Table 1 found in Section 4. =C2=A0Future assignments may be made by a

354=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Standard Action procedure [RFC8126].=C2=A0 The allocation policy for new

355=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 entries up to and including value 127 is "Expert Review" [RFC8126].

356=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 The allocation policy for values 128 through 251 is "First Come First

357=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 Served".=C2=A0 The values from 252 through 255 are for "Experimental Use".

=C2=A0

[major] Where should this sub-registry be located?=C2=A0 I'm assuming that

it would be placed in the Capability Codes registry -- you need to be

explicit about that.=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

[AA/KS] Fixed. Please see the new wording.

=C2=A0

[major] The paragraph indicates two different allocation procedures:

Standard Action, and then others for different parts of the range.

Which is it?=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0

[AA/KS] It is best to assign the values only through IETF Review. The IANA section is updated accordingly.<= /p>

=C2=A0

=20

[major] If there will be an "Expert Review" range, you will need to

provide specific guidance to the experts.=C2=A0 Keep in mind that Expert

Review doesn't require WG approval (or even discussion), unless the

guidance is specific about that.=C2=A0 Take a look at

draft-ietf-idr-bgp-ls-registry for an example of guidance that

includes the WG -- if that's what you want.=C2=A0=C2=A0= =C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Please see comment above. This is all fixed.

=C2=A0

[minor] Please add a table here to show the values.=C2=A0 Pointing at Table 1

is not enough because it doesn't include the unassigned range.

=C2=A0

[AA/KS] Done. New Table 3 is added.

=C2=A0

[minor] Also, please include a table showing the ranges and the

allocation policy, if more than one.

=C2=A0

[AA/KS] Done. Table 3 is newly added.

=C2=A0

359=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 This document defines a new subcode, "Role Mismatch" with an assigned

360=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 value <TBD2> in the OPEN Message Error subcodes registry [to be

361=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 removed upon publication: http://www.iana.org/assignments/bgp-

362=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 parameters/bgp-parameters.xhtml#bgp-parameters-6] [RFC4271].

=C2=A0

[major] s/a new subcode, "Role Mismatch" with an assigned value <TBD2>

in the OPEN Message Error subcodes registry [...] [RFC4271]./the "Role

Mismatch" Message Error subcode.=C2=A0 IANA has assigned value 8 [...].=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed.

=C2=A0

364=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 This document defines a new optional, transitive BGP Path Attributes

365=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 option, named "Only to Customer (OTC)" with an assigned value <TBD3>

366=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 [To be removed upon publication: http://www.i= ana.org/assignments/bgp-

367=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 parameters/bgp-parameters.xhtml#bgp-parameters-2] [RFC4271].=C2=A0 The

368=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 length of this attribute is four bytes.

=C2=A0

[major] s/a new optional, transitive BGP Path Attributes option, named

"Only to Customer (OTC)" with an assigned value <TBD3> [...]

[RFC4271]./the "Only to Customer (OTC)" BGP Path Attribute [...].

IANA has assigned code value 35.=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] Fixed

=C2=A0

[minor] The length is already specified in =C2=A76; no need to repeat that here.=

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed

=C2=A0

=C2=A0

370=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 10.=C2=A0 Security Considerations

=C2=A0

372=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 This document proposes a mechanism for prevention of route leaks that

373=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 are the result of BGP policy misconfiguration.

=C2=A0

375=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 A misconfiguration in OTC setup may affect prefix propagation.=C2=A0 But

376=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 the automation that is provided by BGP roles should make such

377=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 misconfiguration unlikely.

=C2=A0

[minor] Please add references to rfc4271 and rfc4272.

=C2=A0

[AA/KS] Done

=C2=A0

[major] There are multiple security issues that a rogue router

(whether it is due to misconfiguration or on purpose) can take

advantage of. =C2=A0Prefix propagation, both in the "route will go further"

point of view, as well as when the "route will not go as far".=C2=A0 Please

elaborate a little on the differences.

=C2=A0

Also, there are cases, with strict mode on for example, where the

session may not even be established.=C2=A0 Please include these risks in

this section.

=C2=A0

[AA/KS] We have carefull= y revised the whole Security Considerations section to incorporate the above comments.

=C2=A0= =C2=A0=C2=A0=C2=A0

...

405=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 11.2.=C2=A0 Informative References

...

419=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 [RFC7908] =C2=A0Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,

420=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and B. Dickson, "Problem Definition and Classification of=

421=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June

422=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02016, <= https://www.rfc-editor.org/info/rfc7908>.

=C2=A0

[major] The definition of a route leak is the base for this work, so

this reference should be Normative.

=C2=A0=C2= =A0=C2=A0=C2=A0

[AA/KS] Fixed

=C2=A0

424=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 [RFC8126] =C2=A0Cotton, M., Leiba, B., and T. Narten, "Guidelines for

425=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Writing an IANA Considerations Section in RFCs", BCP 26,<= /span>

426=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 8126, DOI 10.17487/RFC8126, June 2017,

427=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https:= //www.rfc-editor.org/info/rfc8126>.

=C2=A0

[major] This reference should be Normative.<= span id=3D"gmail-1009652722">

=C2=A0= =C2=A0=C2=A0=C2=A0

[AA/KS] Fixed

=C2=A0

[End of Review -15]

=C2=A0


=D0=B2=D1=82, 15 =D0=B8=D1=8E= =D0=BD. 2021 =D0=B3. =D0=B2 00:47, Alvaro Retana <aretana.ietf@gmail.com>:
On June 12, 2021 at 5:12:37 PM, Alexand= er Azimov wrote:


Hi!

...
> May I ask you to give more details on this part of your comment?
> > Also, I believe the specification is not complete.
> Can you amplify what parts of mechanics are missing?

There are some comments in =C2=A74, 6, 7...about the use of multiple
capabilities, error handling, multiple OTC attributes, incomplete
policies, use of the OTC attribute if the capabilities were not
successfully negotiated, etc.

THT -- thanks!

Alvaro.


--
Best regards,
Alexander Azi= mov
--000000000000c96ff805c936eac8--