On 8/Jan/20 16:52, James Jun wrote:
> I see. LOCAL_PREF and RFC 1998 style of community attributes however are
> not the right tool for signalling exit locations -- it does not scale.
> Sure, it's a useful hammer to hard enforce a baseline mode of preference
> on given route (e.g. route of la
> From: Saku Ytti
> Sent: Wednesday, January 8, 2020 1:09 PM
>
> On Wed, 8 Jan 2020 at 14:46, wrote:
>
> > Other might be: “These experimental work is of great value to the
> community and there’s a process now to announce and manage these
> experiments, what about net neutrality, and besides
On Wed, Jan 08, 2020 at 04:36:29PM +0200, Mark Tinka wrote:
>
> We provide customers with a ton of LOCAL_PREF options they can activate
> in our network via communities:
>
> http://as37100.net/?bgp
>
> As I mentioned to Saku re: the ORIGIN attribute, I don't mind customers
> using this on us si
On 8/Jan/20 16:26, James Jun wrote:
>
> I get that you'd want to reset MED on peering sessions, but any particular
> rationale on why you'd rewrite MED to 0 on customer sessions?
>
> I would argue that providing the ability for customers to transfer backhaul
> costs onto their transit provider
On 8/Jan/20 15:49, Saku Ytti wrote:
>
> If you reset MED in effort to stop me from transferring my
> infrastructure costs to your network, I can still set origin and force
> cold potato in your network.
Okay, I see how this could be abused in a scenario where you have
multiple peering location
On Wed, Jan 08, 2020 at 03:06:45PM +0200, Mark Tinka wrote:
>
> From our side, on peering links, re-write all MED to 0 and scrubs all
> communities, and replace them with our own.
>
> On customer links, we re-write MED to 0.
[ snip ]
I get that you'd want to reset MED on peering sessions, but
On Wed, 8 Jan 2020 at 15:24, Mark Tinka wrote:
> Hmmh, now I'm curious... please explain why rewriting MED but not ORIGIN
> doesn't help.
If you reset MED in effort to stop me from transferring my
infrastructure costs to your network, I can still set origin and force
cold potato in your network.
On 8/Jan/20 15:12, Saku Ytti wrote:
>
> If you rewrite MED but not origin, then you're not really
> accomplishing anything.
Hmmh, now I'm curious... please explain why rewriting MED but not ORIGIN
doesn't help.
Mark.
On Wed, 8 Jan 2020 at 15:09, Mark Tinka wrote:
> From our side, on peering links, re-write all MED to 0 and scrubs all
> communities, and replace them with our own.
If you rewrite MED, you SHOULD rewrite origin (which RFC prohibits,
incorrectly). I can understand rationale for rewriting MED, yo
On Wed, 8 Jan 2020 at 14:46, wrote:
> Other might be: “These experimental work is of great value to the community
> and there’s a process now to announce and manage these experiments, what
> about net neutrality, and besides modern BGP implementations should handle
> well formatted attributes
On 8/Jan/20 14:44, adamv0...@netconsultings.com wrote:
> Would like to gather current views of a wider community on BGP Path
> Attribute Filtering (discarding selected attributes in particular, not
> treat as withdraw) as an addition to the long list of standard
> conditioning tools like max as-
Would like to gather current views of a wider community on BGP Path
Attribute Filtering (discarding selected attributes in particular, not treat
as withdraw) as an addition to the long list of standard conditioning tools
like max as-path length limit, limiting number of communities all the way to
r
12 matches
Mail list logo
