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

[Adam Chappell <[e-mail]>]

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.