Subject: [Idr] the first field

From: Randy Bush <[email-masked]>
Date: Mon, 19 Sep 2016 09:20:44 -0700

clue bat please.  i am making the assumption that, as we consider using
communities to cause remote (further than next AS) semantics, the intent
is to use the first field (e.g. the first 32 of 32:32:32) to denote the
originating AS, so we know who to blame.  am i off here?

randy

---

From: heasley <[email-masked]>
Date: Mon, 19 Sep 2016 16:34:41 +0000

> originating AS, so we know who to blame.  am i off here?

IMO, yes.  the first 4B is a "namespace ID".  that NID controls the spec
for the following 8B.  So, the question is whose namespace are you using;
AS2914's?  AS701's? usw.  what it signals is determined by the AS who
receives AND chooses to interpret it.

---

From: Jared Mauch <[email-masked]>
Date: Mon, 19 Sep 2016 12:44:16 -0400

> originating AS, so we know who to blame.  am i off here?

	I think this depends on the directionality of the signaling.

	customer -> provider may send eg: 2914:1234 to say do fixed action
based on 1234.

	provider -> customer 2914:1234 may be a signal about route origin,
relationship type.

	in each case, 2914:.* would presumably control/document what
each integer value means.

	Hope this answers your question.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Gert Doering <[email-masked]>
Date: Mon, 19 Sep 2016 19:40:56 +0200

Hi,

> originating AS, so we know who to blame.  am i off here?

It's not how I understand things, and I would it complicated to generate
filters based on <anything>:5539:<something>

I understood the approach to mean I can send stuff to, like, 2914, to affect
their dealing with a remote AS, say 3320.

So, 2914:3320:0 might mean "hey 2914, please do NOT announce to 3320",
while "2914:3320:3" could mean "hey 2914, please do 3x prepend towards 3320".

Generalized

 <the AS that should do something>:<the AS peering that is affected>:<what>

where the 2nd 32bit-value could also be something generic, like "all peers"
or "all customers / all upstreams", however 2914 chose to express that
(2914:2914:50 -> "set local-pref 50"?)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Randy Bush <[email-masked]>
Date: Mon, 19 Sep 2016 12:59:36 -0700

> (2914:2914:50 -> "set local-pref 50"?)

i am not arguing for or against.  but, as i was discussing with someone,
if we do not have a common view of the semantics, this may explain the
lack of convergence on the syntax.

randy

---

From: Joe Provo <[email-masked]>
Date: Mon, 19 Sep 2016 16:02:14 -0400

> > communities to cause remote (further than next AS) semantics, the intent

One should never assume that actions requested further than the flow 
of ones payments will be honoured. That doesn't bar the request nor 
anyone supporting said request for free, but this is my first reading 
of action at a distance. I'll go re-read the threads.
nip]
>  <the AS that should do something>:<the AS peering that is affected>:<what>

That's close to my previous "<actor>:<target>:<action>". For action at
a distnace, the onus is on the actor as to from whom they'll honour 
requests for <action> toward <target>.  Given we're positing a world
involving action at a distance, <target> should not be assumed to be
a direct adjacency. 

It would not be unimaginable for a transit provider to offer BGP 
customers the ability to signal actions for prefixes facing arbitrary
ASNs, where the customer gets the luxury of not having to monitor the
provider's adjecencies ("oh no - I have been leaking prefixes because 
they now use a third-party to reach FOO!") and the provider could simply
act locally or also tag the request for appropriate remote action.

Cheers!

Joe

-- 
        RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG