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

[Susan Hares <[e-mail]>]

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:[e-mail]] 
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,

 

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

 

 

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,