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
