Re: [GROW] WGLC - draft-ietf-grow-large-communities-usage - ENDS 04/06/2017 (Apr 6th)

2017-03-23 Thread Christopher Morrow
I presume that the authors will come to closure on the additional/changed wording in 4.3.2, I'll start the publication request at this time noting consensus was reached. thanks! On Thu, Mar 23, 2017 at 11:57 AM, Adam Chappell wrote: > Yes, agreed - 4.3.2 using the UN

Re: [GROW] [Sidrops] [Idr] operator inputs -- route leak solution

2017-03-23 Thread Randy Bush
> If ISPs do not turn this *on* on their customer connections, it will not > do anything - and given that those ISPs that *need* to turn this on are > the ones that are not caring today, I'm still not seeing why they would > turn this on tomorrow. not quite. if ntt and l3 told fiber@home "on or

Re: [GROW] WGLC - draft-ietf-grow-large-communities-usage - ENDS 04/06/2017 (Apr 6th)

2017-03-23 Thread Job Snijders
On Thu, Mar 23, 2017 at 03:41:03PM +0100, Adam Chappell wrote: > I think the focus on RFC1998 Sec. 4 and the desire to be a practical > example, rather than an exhaustive list of possibilities is important. > With that in mind, I wonder if section 4.3 should really encourage > *location-based*

Re: [GROW] [Idr] operator inputs -- route leak solution

2017-03-23 Thread Andrei Robachevsky
Gert Doering wrote on 23/03/2017 08:45: > Please explain to me how this is going to work if "lazy upstream ISP" > keeps being lazy, and does nothing. I agree. However the motivation for the proposed solution comes from the desire to fix the problem in the future when RPKI and BGPSEC are

Re: [GROW] WGLC - draft-ietf-grow-large-communities-usage - ENDS 04/06/2017 (Apr 6th)

2017-03-23 Thread Adam Chappell
I think the focus on RFC1998 Sec. 4 and the desire to be a practical example, rather than an exhaustive list of possibilities is important. With that in mind, I wonder if section 4.3 should really encourage *location-based* manipulation of LOCAL_PREF? (I must humbly acknowledge that the original

Re: [GROW] [Sidrops] operator inputs -- route leak solution

2017-03-23 Thread Susan Hares
Brian, Sriram and Randy: Let me suggest we take the rest of this discussion on these IDR two drafts offline from IDR. The IDR Chairs noted when the draft-ietf-idr-route-leak-detection mitigation was adopted that there was overlap between you two documents. We also noted interests in

Re: [GROW] [Idr] operator inputs -- route leak solution

2017-03-23 Thread Gert Doering
Hi, On Thu, Mar 23, 2017 at 12:08:39AM +0200, Nick Hilliard wrote: > Gert Doering wrote: > > If ISPs do not turn this *on* on their customer connections, it will not > > do anything - and given that those ISPs that *need* to turn this on are > > the ones that are not caring today, I'm still not