Subject: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

From: "Susan Hares" <[email-masked]>
Date: Thu, 4 Jun 2020 17:19:30 -0400

This begins a 2 week WG LC for draft-ietf-idr-bgp-open-policy-10.txt

>From 6/4 to 6/18/2020.  

There are 3 implementations:   BIRD (1.76, 2.05) , FRR, and Mikrotik. 

The BIRD and FRR implementations interoperate. 

I do not have details on Mikrotik.  

Details on the  interoperability are on the following IDR wiki page: 

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

Only one  error handling issues exists on the ability of BIRD 

to send Role Mismatch (Open Error (2), subcode 8).  

Another protocol was assigned to subcode 8.  

Please comment on the following questions: 

1) Is this specification ready for publication? 

2) Are there deployments where this BGP protocol extension is valuable? 

3) Do you believe the error code handling is ready for publication? 

The shepherd for this draft is Susan Hares.  

During the WG LC, the shepherd's report will be sent. 

Cheers,

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 5 Jun 2020 06:47:45 -0700

Sue,

I support publication of this draft.

Cheers,
Jeff

> On Jun 4, 2020, at 14:20, Susan Hares <[email-masked]> wrote:
> 
> 
> During the WG LC, the shepherd’s report will be sent.
>  
> Cheers,
>  
>  
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Brian Dickson <[email-masked]>
Date: Fri, 5 Jun 2020 10:20:35 -0700

> 1) Is this specification ready for publication?

I have read the latest version of this draft.
I believe it is ready for publication and support advancement to
publication.

> 2) Are there deployments where this BGP protocol extension is valuable?

This BGP protocol extension is valuable in every conceivable
Internet-connected BGP-speaking router, i.e. for address families IPv4 and
IPv6 at a minimum.

> 3) Do you believe the error code handling is ready for publication?

Yes.

Brian

---

From: Sebastian Becker <[email-masked]>
Date: Sat, 6 Jun 2020 16:50:52 +0200

Hi Susan,

in line with Brian (thanks for the wording, hope you don’t mind that I copy it for my reply):

1) Is this specification ready for publication?
	I have read the latest version of this draft.
	I believe it is ready for publication and support advancement to publication.
 
2) Are there deployments where this BGP protocol extension is valuable?
	This BGP protocol extension is valuable in every conceivable Internet-connected BGP-speaking router, i.e. for address families IPv4 and IPv6 at a minimum.

-- 
Sebastian Becker
[email-masked]

On Thu, Jun 4, 2020 at 2:20 PM Susan Hares <[email-masked] <mailto:[email-masked]>> wrote:
This begins a 2 week WG LC for draft-ietf-idr-bgp-open-policy-10.txt

From 6/4 to 6/18/2020. 

https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy <https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy>

Cheers,

Idr mailing list

[email-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 10 Jun 2020 20:14:17 +0000

Sue,
I support the publication of this draft,

Thanks,
Oliver

-----------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Office) +1.301.975.4856
(GVoice) +1.240.668.4117

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Thursday, June 4, 2020 at 5:21 PM
To: "'idr@ietf. org'" <[email-masked]>
Subject: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

Details on the  interoperability are on the following IDR wiki page:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-open-policy<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-open-policy&data=02%7C01%7Coliver.borchert%40nist.gov%7C602b89ee1a5e435452ea08d808cd2d56%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637269024604715725&sdata=KFcm6goZMSv0gYrLo1PJhOchzPbCTI0x1nxFIzPieJE%3D&reserved=0>

Cheers,

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 10 Jun 2020 19:01:58 -0400

I support this draft and believe the specification is ready for publication.

I think the role capability for auto route leaking mitigation is very
valuable for both service providers as well as very large enterprises.

This WGLC draft along with below route leak detection of well known large
BGP communities can help tremendously in automating route leak mitigation.

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02

BGP Large Community
https://tools.ietf.org/html/rfc8092

Speaking from the looking glass  of a tier 1 provider Verizon we could
definitely benefit from the role priority feature from the leak types
described in RFC 7908.

https://tools.ietf.org/html/rfc7908

Kind regards

Gyan

On Wed, Jun 10, 2020 at 4:15 PM Borchert, Oliver (Fed) <oliver.borchert=
[email-masked]> wrote:

> *From: *Idr <[email-masked]> on behalf of Susan Hares <
> [email-masked]>
> *Date: *Thursday, June 4, 2020 at 5:21 PM
> *To: *"'idr@ietf. org'" <[email-masked]>
> *Subject: *[Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to
> 6/18)(.
>
>
>
> <https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-bgp-open-policy&data=02%7C01%7Coliver.borchert%40nist.gov%7C602b89ee1a5e435452ea08d808cd2d56%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637269024604715725&sdata=KFcm6goZMSv0gYrLo1PJhOchzPbCTI0x1nxFIzPieJE%3D&reserved=0>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Pavel Lunin <[email-masked]>
Date: Thu, 11 Jun 2020 01:02:07 +0000

Hi Susan,

1) I support the advancement of this draft to publication.

A little comment though. The so called "Gao-Rexford model" and more generally role-based relationships logic is mostly applicable to eBGP sessions. iBGP sessions are usually 'complex' in terms used in this document, so assigning roles to iBGP speakers seems practically unnecessary. From the implementation point of view it doesn't change a lot: ability to assign roles to iBGP speakers doesn't seem to make any harm, and having the option of not assigning the roles lets the network operators make the decision whether they want to change the today's behavior of iBGP default policies.

However from the operational point of view it's somewhat unclear if authors propose to configure roles on iBGP sessions. The general term "BGP" is used everywhere throughout the document (with an exception of only one occurrence), so it might seem that the document recommends to set the roles on all iBGP sessions as well as eBGP. Here it might look evident that the general context is inter-domain routing, so the document covers eBGP. However the potential audience of this document is very broad, including people not very experienced in BGP operational practices (this is were route leaks often come from) so I would suggest to make this point more explicit. Probably some occurrences of the word 'BGP' should be replaced by 'eBGP' or just a little sentence/paragraph is needed to make this point clearer.

> By default, strict mode SHOULD be set to false for backward compatibility with BGP speakers that do not yet support this mechanism.
Same here. "Backward compatibility" suggests that in future all or almost all BGP sessions should be configured with roles while it's not totally correct: iBGP speakers won't probably ever need roles and role-based policies.

This being said, this nuance only affects operational practice recommendations. Protocol behavior specification, as defined by the document, looks good: both eBGP and iBGP can be configured with roles if needed.

2) Deployments of this extension will be valuable for almost all use cases where eBGP is used to exchange public Internet routes.

Kind regards,
Pavel

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 11 Jun 2020 15:56:28 +0800

Can the authors give more explanation on the following description in
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-open-policy-10#sect
ion-8:

There are peering relationships that are 'complex', i.e., both

   parties are intentionally sending prefixes received from each other

   to their non-transit peers and/or transit providers.  If multiple BGP

   peerings can segregate the 'complex' parts of the relationship, the

   complex peering roles can be segregated into different normal BGP

   sessions, and BGP Roles MUST be used on each of the resulting normal

   (non-complex) BGP sessions.

Some figures or more detailed explanations will be helpful to get the
description of “complex”.  Is there any situation that the multiple BGP
peering can’t be segregated?

Best Regards

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2020年6月5日 5:20
收件人: 'idr@ietf. org' <[email-masked]>
主题: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

Cheers,

---

From: Dmitry Afanasiev <[email-masked]>
Date: Thu, 11 Jun 2020 11:31:15 +0300

Hi Susan,

--
Dmitry Afanasiev

---

From: Randy Bush <[email-masked]>
Date: Thu, 11 Jun 2020 07:31:39 -0700

> peering can’t be segregated?

we call such relationships complex because they have been quite varied.
so i am not sure how far down this rabbit hole alexander wants to go.

but let me give you an example.  i can use this one because the
relationship was publicly discovered and then disclosed.

back in the day, i think it was PSInet and AboveNet were in a peering
war.  it was causing actual damage to a significant population.  so
verio, which peered with both, configured to transit them to eachother
through verio in the middle note that this was an intermediate party
giving partial (only some routes) transit to two other parties.

now this is but one example, trying to get folk to think about how large
and complex the space of complex relationships is.  so i am not too
supportive of trying to describe the space in any formal sense.  while
gao rexford has been well demonstrated not to always hold, it is a
wonderfully simplifying assumption which lets us think about things and
then say that the rest is complex. :)

randy

---

From: Pavel Lunin <[email-masked]>
Date: Thu, 11 Jun 2020 15:41:49 +0000

Am I wrong in my understanding that virtually any iBGP session is 'complex' in terms of this document?

E. g. an MP-BGP session between an MPLS PE and route reflectors, is it 'complex'?

As I see no other special clause in the document to treat iBGP, as of my understanding, all iBGP is 'complex' so no roles needed.

Another kind of 'complex' peering might be some sort of 'non-Internet eBGP': leaf-spine eBGP fabrics for example. Or any VPN eBGP: inter-provider option C, eBGP over IPSec in the enterprise between hub site and branches etc etc.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

---

From: Pavel Lunin <[email-masked]>
Date: Thu, 11 Jun 2020 15:41:49 +0000

---

From: Alexander Azimov <[email-masked]>
Date: Thu, 11 Jun 2020 23:06:57 +0300

Dear colleagues,

Thank you for your comments. I'll try to clarify questions regarded to
complex relations and applicability of roles to iBGP sessions.

In the majority of cases in the document and especially for the 'BGP Role
is a new configuration option that SHOULD be configured on each BGP
session.' was meant eBGP session between ISPs. The wrong wording grows from
the old version of the drafts where we had an additional 'Internal' role.
It was removed because it had no use for the route leak prevention and
detection while adding additional complexity. This confusing wording will
be fixed.

The 'complex' cover cases where peering relation between parties is a
combination of c2p/p2p/p2c relations. Here are a few examples:

   - Two ISPs provide transit service to each other - it may be paid
   transit or free, it just exists. In some works, this relation is called
   siblings;
   - Two ISPs have customer-to-provider relation in one region peer for
   free in another region.

The point of the draft that was quoted by Aijun suggests that different
peering relations can be separated in different BGP sessions thus giving a
way to keep full beauty of automation that is provided by BGP roles. For
the second example - it works out of the box.

чт, 11 июн. 2020 г. в 18:42, Pavel Lunin <[email-masked]>:

> As I see no other special clause in the document to treat iBGP, as of my
> understanding, all iBGP is 'complex' so no roles needed.
>
> Another kind of 'complex' peering might be some sort of 'non-Internet
> eBGP': leaf-spine eBGP fabrics for example. Or any VPN eBGP: inter-provider
> option C, eBGP over IPSec in the enterprise between hub site and branches
> etc etc.
>
>

-- 
Best regards,
Alexander Azimov

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 12 Jun 2020 09:15:21 -0400

Pavel:

Thank you for this feedback. I expect a new revision of the draft-ietf-idr-bgp-open-policy within a few days.  We will continue the discussion on this point until we reach a full resolution. 

As shepherd, I am waiting for -11.txt to see if this addresses your issues.      

Sue 

From: Pavel Lunin [mailto:[email-masked]] 
Sent: Wednesday, June 10, 2020 9:02 PM
To: Susan Hares
Cc: 'idr@ietf. org'
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

Hi Susan,

 

Kind regards,

Pavel

Cheers,

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 12 Jun 2020 13:46:36 -0400

Hi Susan

I agree with Pavel’s important point in the draft in that this feature
would be for “inter domain” which from internet perspective would be ASBRs
ties interconnection between providers thus “eBGP” only and could be over
AFI/SAFI 1/1 2/1 1/128 2/128.

I mention the SAFI 128 as the internet has mix of carriers having internet
table carried in 3 scenarios — global table IP backbone, global table over
mpls, IP VPN.  In the IP VPN case their are providers that segregate global
table to be clean of customer routes with only connected interfaces IGP for
P,PE,RR reachability and Internet table carried in a dedicated internet
VRF.  In those cases inter-as carriers may do mpls inter-as option or if IP
only an IP based bgp policy.  Their maybe some cases but less often where
MPLS is used over internet and public internet and private is carried over
the same MPLS transport.

Those permutations of the operators network inter-as types maybe important
to mention as may impact the use of role feature.

The main use case is for internet providers but could be used for large
enterprises as well.

Once vendors implement the feature any operator can use for any use case so
which is why it’s critical to keep disabled by Default.

That being said we would not want the role priority feature to be Default
enabled since you cannot distinguish eBGP or iBGP from a MP reach
capability standpoint it really has to be disabled by Default.  This would
allow in a controlled fashion by operators to enable on their “inter-as”
ASBR-ASBR boundary ties only.

Kind Regards

Gyan

On Wed, Jun 10, 2020 at 9:02 PM Pavel Lunin <[email-masked]> wrote:

> A little comment though. The so called "Gao-Rexford model" and more
> generally role-based relationships logic is mostly applicable to eBGP
> sessions. iBGP sessions are usually 'complex' in terms used in this
> document, so assigning roles to iBGP speakers seems practically
> unnecessary. From the implementation point of view it doesn't change a lot:
> ability to assign roles to iBGP speakers doesn't seem to make any harm, and
> having the option of not assigning the roles lets the network operators
> make the decision whether they want to change the today's behavior of iBGP
> default policies.
>
> However from the operational point of view it's somewhat unclear if
> authors propose to configure roles on iBGP sessions. The general term "BGP"
> is used everywhere throughout the document (with an exception of only one
> occurrence), so it might seem that the document recommends to set the roles
> on all iBGP sessions as well as eBGP. Here it might look evident that the
> general context is inter-domain routing, so the document covers eBGP.
> However the potential audience of this document is very broad, including
> people not very experienced in BGP operational practices (this is were
> route leaks often come from) so I would suggest to make this point more
> explicit. Probably some occurrences of the word 'BGP' should be replaced by
> 'eBGP' or just a little sentence/paragraph is needed to make this point
> clearer.
>
> > By default, strict mode SHOULD be set to false for backward
> compatibility with BGP speakers that do not yet support this mechanism.
> Same here. "Backward compatibility" suggests that in future all or almost
> all BGP sessions should be configured with roles while it's not totally
> correct: iBGP speakers won't probably ever need roles and role-based
> policies.
>
> This being said, this nuance only affects operational practice
> recommendations. Protocol behavior specification, as defined by the
> document, looks good: both eBGP and iBGP can be configured with roles if
> needed.
>
> 2) Deployments of this extension will be valuable for almost all use cases
> where eBGP is used to exchange public Internet routes.
>
>
> Kind regards,
> Pavel
>
>
-- 

*Gyan Mishra*

---

From: Alexander Azimov <[email-masked]>
Date: Tue, 16 Jun 2020 22:59:48 +0300

Dear colleagues,

In the last days, I have accumulated comments that were received both
on-list and off-list. I'd like to thank all who contributed to the improved
quality of the document. Accompanied by minor changes there are two
important edits that I'd like to highlight:

   - We clearly specified the scope of the Roles configuration: 'BGP Roles
   SHOULD be configured on each eBGP session between ISPs that carry IPv4
   and(or) IPv6 unicast prefixes'. In section 8 there is also an explicit
   statement that the applicability of Roles for other address families is out
   of scope of this document.
   - The registry for Roles now has three parts: Expert Review
   (0-127), First Come First Served (128-251), and Experimental Use (252-255).
   The statement is added that guarantees that newly defined roles will not
   pair with Roles defined in the draft.

Since these changes don't affect the OTC/Role mechanics no changes and
needed in the implementations.
The new version of the draft is available:
https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-11

пт, 12 июн. 2020 г. в 20:47, Gyan Mishra <[email-masked]>:

> Once vendors implement the feature any operator can use for any use case
> so which is why it’s critical to keep disabled by Default.
>
>> 2) Deployments of this extension will be valuable for almost all use
>> cases where eBGP is used to exchange public Internet routes.
>>
>>
>> Kind regards,
>> Pavel
>>
>>

-- 
Best regards,
Alexander Azimov

---

From: Pavel Lunin <[email-masked]>
Date: Tue, 16 Jun 2020 23:18:10 +0000

Hi Susan and all,

I have read the new version (-11) and discussed it with Alexander off list. The document is now more explicit about non eBGP and non Internet-routing use cases both in terms of how the roles and OTC should be implemented and how they should be configured.

So all types of BGP sessions can potentially be configured with roles but the document explicitly states that it makes no assumption regarding any use cases other than plain vanilla inet/inet6 unicast eBGP between network operators.

It looks clear to me.

I also asked Alexander about the following case:

- Operator A announces to operator B an eBGP route with the OTC attribute set (operator B is a customer of operator A)
- The route is than propagated through the operator's B network via iBGP
- At some distinct point, operator B, in it's turn, announces the route to its customer C via eBGP.

Alexander explained that this is covered by the following phrase:

>Once the OTC attribute has been set, it MUST be preserved unchanged

So no matter how the route is propagated within the operator's B network (vanilla iBGP, inet-vpn, evpn type5 or whatever else) the original OTC value must be preserved just like it happens for AS-PATH. It also sound legitimate for me.

So I fully support publication of this document.

--
Pavel

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, June 16, 2020 9:59 PM, Alexander Azimov <[email-masked]> wrote:

> Dear colleagues,
>
> In the last days, I have accumulated comments that were received both on-list and off-list. I'd like to thank all who contributed to the improved quality of the document. Accompanied by minor changes there are two important edits that I'd like to highlight:
>
> - We clearly specified the scope of the Roles configuration: 'BGP Roles SHOULD be configured on each eBGP session between ISPs that carry IPv4 and(or) IPv6 unicast prefixes'. In section 8 there is also an explicit statement that the applicability of Roles for other address families is out of scope of this document.
> - The registry for Roles now has three parts: Expert Review (0-127), First Come First Served (128-251), and Experimental Use (252-255). The statement is added that guarantees that newly defined roles will not pair with Roles defined in the draft.
>
> Since these changes don't affect the OTC/Role mechanics no changes and needed in the implementations.
> The new version of the draft is available: https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-11
>
>> I agree with Pavel’s important point in the draft in that this feature would be for “inter domain” which from internet perspective would be ASBRs ties interconnection between providers thus “eBGP” only and could be over AFI/SAFI 1/1 2/1 1/128 2/128.
>>
>> I mention the SAFI 128 as the internet has mix of carriers having internet table carried in 3 scenarios — global table IP backbone, global table over mpls, IP VPN. In the IP VPN case their are providers that segregate global table to be clean of customer routes with only connected interfaces IGP for P,PE,RR reachability and Internet table carried in a dedicated internet VRF. In those cases inter-as carriers may do mpls inter-as option or if IP only an IP based bgp policy. Their maybe some cases but less often where MPLS is used over internet and public internet and private is carried over the same MPLS transport.
>>
>> Those permutations of the operators network inter-as types maybe important to mention as may impact the use of role feature.
>>
>> The main use case is for internet providers but could be used for large enterprises as well.
>>
>> Once vendors implement the feature any operator can use for any use case so which is why it’s critical to keep disabled by Default.
>>
>> That being said we would not want the role priority feature to be Default enabled since you cannot distinguish eBGP or iBGP from a MP reach capability standpoint it really has to be disabled by Default. This would allow in a controlled fashion by operators to enable on their “inter-as” ASBR-ASBR boundary ties only.
>>
>> Kind Regards
>>
>> Gyan
>>
>> http://www.verizon.com/
>> Gyan Mishra
>> Network Solutions Architect
>>
>> M 301 502-1347
>> 13101 Columbia Pike Silver Spring, MD
>>

---

From: Andrei Robachevsky <[email-masked]>
Date: Wed, 17 Jun 2020 14:44:51 +0200

I read the latest version (draft-ietf-idr-bgp-open-policy-11) and agree
that is it ready for publication.

The only suggestion I may make it to be even more explicit about how
roles and OTC are supposed to be set or not when announcing routes
internally (e.g. iBGP). I am referring to the issue that Pavel Lunin
brought up. I think a sentence in the Introduction explaining the scope
would help.

Andrei

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Jun 2020 17:23:20 -0400

Few comments on the latest draft.

In Section 6 at the very top can we change the verbiage describing OTC from
“transitive” to “optional transitive” as the BGP path attribute is not a
required transitive attribute.

Also since the this new OTC path attribute is set on the eBGP peering
session it is then propagated within the operators transit AS iBGP mesh.
For clarity it maybe good to mention the OTC attribute being set on the
eBGP peering and then being propagated within a providers network via iBGP
to other external peering.

Section 5 mentions role correction mismatch, however what if one side of
peering session supports and other side does not the session would not come
up similar to role mismatch.  I think text should be added for that
scenario.

It maybe a good idea in the appendix to specificity the logical functional
configuration that is auto generated from each of the role mode settings.
In some of the role modes it seems similar to no-export or no-advertise
community being set for all prefixes from a peer based on role mode.

Can the OTC optional transitive path attribute be used in BGP best path
selection process, and if so then RFC 4271 should be updated to reflect.

Once the OTC path attribute is set on a prefix similar to the concept of
BGP community setting, where you can append communities with “additive”
push function, or you can pop and reset or remove the pre existing
communities.  Can the OTC path attribute set on a set of prefixes be
removed once it’s set and can it be done inbound or outbound and on any
eBGP or iBGP session.

Kind Regards

Gyan

-- 

*Gyan Mishra*

---

From: Luuk Hendriks <[email-masked]>
Date: Thu, 18 Jun 2020 09:28:30 +0200

Hi Susan, list,

> 1) Is this specification ready for publication? 

Yes, I think this document is ready for publication.

> 2) Are there deployments where this BGP protocol extension is valuable? 

I believe a vast majority of deployments will benefit from this simple
(i.e. elegant) but powerful extension, and therefore I fully support it.

> 3) Do you believe the error code handling is ready for publication? 

No opinion, I do not feel knowledgable/experienced enough to give a hard
yes/no here.

Small nit, Sec 6:
"The purpose of this attribute is to guarantee that once _a_ route"

 luuk

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 30 Jun 2020 10:10:31 -0400

Pavel:

Thank you for this email regarding the resolution of your concern with version 11.   

Sue 

From: Pavel Lunin [mailto:[email-masked]] 
Sent: Tuesday, June 16, 2020 7:18 PM
To: Alexander Azimov
Cc: Gyan Mishra; idr@ietf. org; Susan Hares
Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-open-policy-10.txt (6/4 to 6/18)(.

Hi Susan and all,

It looks clear to me.

--

Pavel

Dear colleagues,

*	We clearly specified the scope of the Roles configuration: 'BGP Roles SHOULD be configured on each eBGP session between ISPs that carry IPv4 and(or) IPv6 unicast prefixes'. In section 8 there is also an explicit statement that the applicability of Roles for other address families is out of scope of this document.
*	The registry for Roles now has three parts: Expert Review (0-127), First Come First Served (128-251), and Experimental Use (252-255). The statement is added that guarantees that newly defined roles will not pair with Roles defined in the draft.

 

Hi Susan

Kind Regards 

Gyan

Hi Susan,

 

Kind regards,

Pavel

Cheers,

Idr mailing list

[email-masked]

-- 

 <http://www.verizon.com/> Image removed by sender.

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

Idr mailing list

[email-masked]

 

-- 

Best regards,

Alexander Azimov