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

From: Alexander Azimov <[email-masked]>
Date: Thu, 2 Jul 2020 02:00:38 +0300

Dear WG,

Once again I'd like to thank those who spent their time reading the
document and sending back new and new edits.
I'm going to check the list and summarize it in the v12 tomorrow.

вт, 30 июн. 2020 г. в 17:28, Susan Hares <[email-masked]>:

> Greeting Sriram and Alex:
>
>
>
> I have reviewed all the comments from the IDR WG on this document.  It is
> delightful to have so many operational considerations included in the
> discussion.
>
>
>
> My understanding from reading all the comments is that all parties believe
> we have reached consensus.  However, I would like to see  I would like to
> see revision -12.txt published.  At which point, I will do 2 things in
>
> parallel:
>
>
>
> a) call for a validation that -12.txt resolves all issues in IDR and Grow
>
> - I will do a 1 week call for IDR and Grow final input
>
>
>
> b) do the shepherd's report at the same time.
>
>
>
> Thank you, Susan Hares
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
Best regards,
Alexander Azimov

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 3 Jul 2020 16:52:51 +0300

Dear colleagues,

I've just published v12
<https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy-12>, which
covers comments that were raised during the wglc.
The most important change in wording is at the beginning of section 3:

>    BGP Role is a new configuration option that can be configured on any
>    BGP session.  BGP Roles reflect the agreement between two BGP
>    speakers about their relationship.  One of the Roles described below
>    SHOULD be configured on each eBGP session between ISPs that carry
>    IPv4 and(or) IPv6 unicast prefixes.

The idea here is to remove limitations for Role usage for possible
extensions while keeping precise descriptions for using Customer, Provider,
Peer, RS, RS-Client roles.

чт, 2 июл. 2020 г. в 02:00, Alexander Azimov <[email-masked]>:

>> My understanding from reading all the comments is that all parties
>> believe we have reached consensus.  However, I would like to see  I would
>> like to see revision -12.txt published.  At which point, I will do 2 things
>> in
>>
>> parallel:
>>
>>
>>

-- 
Best regards,
Alexander Azimov

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 3 Jul 2020 14:35:46 -0400

Alexander

Minor nit.

In the first sentence should it say eBGP and not any peer.

Thanks

Gyan

On Fri, Jul 3, 2020 at 9:53 AM Alexander Azimov <[email-masked]>
wrote:

>>> I have reviewed all the comments from the IDR WG on this document.  It
>>> is delightful to have so many operational considerations included in the
>>> discussion.
>>>
>>>
>>>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 3 Jul 2020 21:57:13 +0300

Gyan,

There can be BGP Roles that are not bound to eBGP. For example, some time
ago we had an idea about 'Internal' role that was applicable for both eBGP
and iBGP neighbors. I've already heard about other scenarios.

The above wording leaves an open door for all kinds of extensions. At the
same time, it gives a clear description of where Customer, Provider, Peer,
RS, RS-Client should be configured - 'eBGP session between ISPs that carry
IPv4 and(or) IPv6 unicast prefixes'.

-- 
Best regards,
Alexander Azimov

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 4 Jul 2020 00:32:41 -0400

Alexander

In the context of keeping the door open for future internal roles as the
reader would be confused when reading “any” meaning iBGP, however internal
roles don’t exist today.  My recommendation would be to update the draft to
say “any” when the internal roles are explicitly defined.  That could be
done anytime when you have fully vetted the internal role concept and the
draft is updated accordingly.

Kind Regards

Gyan

On Fri, Jul 3, 2020 at 2:57 PM Alexander Azimov <[email-masked]>
wrote:

>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>>
>
> --
> Best regards,
> Alexander Azimov
>
-- 

*Gyan Mishra*