Subject: [Idr] 5575bis nit - ASes in extended communities

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Feb 2020 18:41:36 -0500

In RFC 5575 and 5575-bis, we have several extended communities defined.

:    +-----------+----------------------+--------------------------------+
:    | community | action               | encoding                       |
:    +-----------+----------------------+--------------------------------+
:    | 0x8006    | traffic-rate-bytes   | 2-byte ASN, 4-byte float       |
:    | TBD       | traffic-rate-packets | 2-byte ASN, 4-byte float       |
:    | 0x8007    | traffic-action       | bitmask                        |
:    | 0x8008    | rt-redirect AS-2byte | 2-octet AS, 4-octet value      |
:    | 0x8108    | rt-redirect IPv4     | 4-octet IPv4 addres, 2-octet   |
:    |           |                      | value                          |
:    | 0x8208    | rt-redirect AS-4byte | 4-octet AS, 2-octet value      |
:    | 0x8009    | traffic-marking      | DSCP value                     |
:    +-----------+----------------------+--------------------------------+
: 
:                Table 2: Traffic Action Extended Communities

Nits: We use byte in some spots for AS, octet in others.  "addres" is a
typo.

A question came up from a customer, else I would have let this question
lay idle:  When you're running flowspec within a BGP Confederation (RFC 5065),
whose AS do you stick in there?  The Member-AS, or the AS Confederation
Identifier?

I could make a few weak arguments that the Member-AS makes sense. (And, is
in fact, what Juniper's code currently does.)  However, I think the general
intent is such that consistent action within the Confederation is what is
desired, similar to what it'd be like if the behavior is iBGP.

While the AS number is largely an advisory number for the features in
question, it does potentially have impact on policy.

My recommendation would be we add some text roughly like the following:
Add "In the circumstance that this specification is utilized in a BGP
Confederation [RFC 5065], AS Numbers used by these Traffic Action Extended
Communities SHOULD be the BGP speaker's Confederation Identifier AS."

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Feb 2020 06:54:51 -0500

> In RFC 5575 and 5575-bis, we have several extended communities defined.
[...]
> Communities SHOULD be the BGP speaker's Confederation Identifier AS."

Thinking slightly further, the text should be:
"In the circumstance that this specification is utilized in a BGP
Confederation [RFC 5065], AS Numbers used by the Traffic Rate Extended
Communities SHOULD be the BGP speaker's Confederation Identifier AS."

The AS numbers for redirect are provisioned from VRF import policy and
wouldn't be touched.

-- Jeff

---

From: Christoph Loibl <[email-masked]>
Date: Thu, 13 Feb 2020 14:24:00 +0100

Hi Jeff,

I opened 2 issues for tracking that (also including your thoughts from the second mail) on github:

https://github.com/stoffi92/rfc5575bis/issues/160 <https://github.com/stoffi92/rfc5575bis/issues/160>

https://github.com/stoffi92/rfc5575bis/issues/161 <https://github.com/stoffi92/rfc5575bis/issues/161>

I came across the second issue a while back when I was writing import policies and saw what juniper does (thanks for sharing the details), but I haven’t checked what other implementations actually put there.

Cheers

Christoph

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 13.02.2020, at 00:41, Jeffrey Haas <[email-masked]> wrote:
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr