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 < [email protected]> 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 <[email protected]> > 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 <[email protected]> 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. >> > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
