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

[Christopher Morrow <[e-mail]>]

Oh Hai!

err... I prematurely sent this along to the IESG :( Joel held it up until
4/6 when we can see if the decision is 'needs more work' or 'go to iesg!'.

thanks joel!

On Thu, Mar 23, 2017 at 9:26 PM, Christopher Morrow <
[e-mail]> wrote:

> 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 <[e-mail]>
> wrote:
>
>> Yes, agreed - 4.3.2 using the UN M.49 region codes might well be a better
>> idea.  At least allows us to demonstrate the technique in the document and
>> it not necessarily be unfeasible in production networks if someone decides
>> to use the example verbatim. And the change isn't huge either - will send
>> diff to you direct, Job.
>>
>> -- Adam.
>>
>>
>>
>>
>> On 23 March 2017 at 16:16, Job Snijders <[e-mail]> wrote:
>>
>>> 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* manipulation of LOCAL_PREF?
>>> >
>>> > (I must humbly acknowledge that the original text of the idea here was
>>> part
>>> > of a contribution I made).
>>> >
>>> > Location-based AS_PATH prepend, and general manipulation of LOCAL_PREF
>>> all
>>> > fine and good, but would large-scale operators today really advise
>>> their
>>> > customers to make use of features to signal degree of preference
>>> > on sub-AS scale? The warning about preference -> selection ->
>>> advertisement
>>> > seems definitely appropriate.
>>> >
>>> > There's a suggestion, for example, that I can put 2914:12:528 on my NTT
>>> > port in Amsterdam to ensure that I only receive traffic from outside
>>> the
>>> > Netherlands. I think we know that's not going to fly.
>>> >
>>> > The idea is probably interesting to a customer, but the harsh reality
>>> is
>>> > that today's implementations don't cut it: the customer's BGP route is
>>> > tightly coupled to the part of the SP's network to which he connects,
>>> and
>>> > the route announcement is thus subject to the whims of the SP's BGP
>>> > topology - which he likely reserves the right to change - from that
>>> point
>>> > on.
>>> >
>>> > Realistically what I generally see are advertisement suppression knobs
>>> to
>>> > influence inter-region (rather than country) propagation of a route.
>>> >
>>> > So, with those practical considerations in mind, does this specific
>>> > technique really belong in a document that we'd like to be a best
>>> practice
>>> > or good example guide to be read by those setting their policies for
>>> what
>>> > Large Community attributes they will receive, process and act on?
>>>
>>> You are right, the technique somewhat relies on specific network
>>> designs.
>>>
>>> What do you propose? Remove 4.3 in its entirety? If we only remove
>>> section 4.3.2, the remainder of the section is essentially RFC 1998 in a
>>> nutshell, so perhaps from a RFC stream continuity perspective, it is
>>> redundant.
>>>
>>> Alternatively, the text can be rewritten to refer to regions rather then
>>> countries.
>>>
>>> Kind regards,
>>>
>>> Job
>>>
>>
>>
>>
>> --
>>
>> -- Adam.
>>
>
>