I thought about something like this with extended communities before I wrote my
draft.
There is no order to communities. They can come in any order
and routers can change the order. Routers will remove duplicate communities.
So, you can only use any noun or verb once and, because there
is no order
On Wed, Sep 21, 2016 at 1:24 PM, Gert Doering wrote:
> Having this hard-coded in RFCs and code in routers is both far too
> complex to implement, and far too limited at the same time (what if
> I only want "North Chile" but that isn't in the implementation?) -
> which is why I'm opting for the mo
Hi,
On Wed, Sep 21, 2016 at 12:51:30PM -0400, Matthew Ringel wrote:
> Collect enough nouns and verbs, and it follows that you can have a
> language, where the specific communities might be in a common database
> (e.g. PeeringDB*), and networks can say that they support a (yet to be
> specified) st
Presuming that the existing BGP community space is all we have to work
with right now, and that we're operating networks right now, so we
need something that works right now, it might be better to look at
what we can do as a level of abstraction right now.
Thinking about the data to be communicate
+grow
On Wed, Sep 21, 2016 at 12:02 PM, Robert Raszuk wrote:
> But it already there ... it is even WG document ..
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-registered-
> wide-bgp-communities/
>
>
>
i'm unclear how this is helping this dicussion.
>
> On Wed, Sep 21, 2016 at 2:05 PM, N
Because if we say adopt large as 4:4:4:4 amount of this mapping is reduced.
Or we can adopt as-is then enlarge ...
Thx,
r.
On Wed, Sep 21, 2016 at 2:04 PM, Nick Hilliard wrote:
> Robert Raszuk wrote:
> > The problem with 16:16 and now with endorsing 32:32:32 is that it still
> > requires an e
Robert Raszuk wrote:
> The problem with 16:16 and now with endorsing 32:32:32 is that it still
> requires an external oracle to manually translate encoded magic number
> into set of actions.
I'm struggling to understand how and why this is relevant to adopting
large as-is.
Operators are free to
+grow, they got lost somewhere on the way...
(grow folk interested might want to just go look at the archive:
https://www.ietf.org/mail-archive/web/idr/current/msg16066.html
...which is this thread...
sadly this discussion is spread over at least:
https://www.ietf.org/mail-archive/web/idr/curr
On Wed, 21 Sep 2016, Robert Raszuk wrote:
Are you suggesting to embed the action (here prepend) into MYAS:PEERAS
fields ? Last part would be a parameter ... cool.
So if I need to also send different MED I would need yet one more magic
pair MYAS:PEERAS correct ?
Communities have always be
Hi,
On Wed, Sep 21, 2016 at 02:40:43PM +0200, Robert Raszuk wrote:
> > An implementation could easily do this in their route-policy language
> >
> > if ( community in ( MYAS:PEERAS:([1-9]) ) ) then
> > set as-path prepend MYAS times $1
> > endif
> >
> > with "MYAS" and "PEERAS" properly
Hi Gert,
> An implementation could easily do this in their route-policy language
>
> if ( community in ( MYAS:PEERAS:([1-9]) ) ) then
> set as-path prepend MYAS times $1
> endif
>
> with "MYAS" and "PEERAS" properly pre-defined in route-policy context.
Are you suggesting to embed the ac
On Wed, 21 Sep 2016, Robert Raszuk wrote:
There is no free lunch ... why operators would highly benefit - vendors
need to add code to current policy language to handle new fields. And
this is where the crux of the issue is why -flex or -wide was not yet
been implemented.
So while your propos
Hi,
> The problem with 16:16 and now with endorsing 32:32:32 is that it still
> requires an external oracle to manually translate encoded magic number into
> set of actions.
It provides flexible behaviour that can be agreed upon between consenting
network operators. This is a feature, not a
Hi,
On Wed, Sep 21, 2016 at 11:14:06AM +0200, Robert Raszuk wrote:
> Let me provide an example:
>
> ???I have 400 PEs and I want to do 10 different length of prepends depending
> on the peering AS.
>
> So today when I advertise the prefix I need 10 different communites for it
> and 10 different
/* Adding GROW as most of this discussion is applicable to GROW WG */
Nick,
There is complexity, yes, but I don't quite see why you claim that "no
> one except a handful of backbone operators" understands how to use the
> current communities system, because that is glaringly not the case.
>
The
15 matches
Mail list logo
