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

[Alexander Azimov <[e-mail]>]

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

> 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 <[e-mail]> wrote:
>
>> 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,
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>


-- 
Best regards,
Alexander Azimov