[Idr] 5575bis nit - ASes in extended communities

Jeffrey Haas <jhaas@pfrc.org> Wed, 12 February 2020 23:36 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B312001A; Wed, 12 Feb 2020 15:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJnznKc9vV7C; Wed, 12 Feb 2020 15:36:05 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1D63E120045; Wed, 12 Feb 2020 15:36:05 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 046961E2F6; Wed, 12 Feb 2020 18:41:36 -0500 (EST)
Date: Wed, 12 Feb 2020 18:41:36 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: draft-ietf-idr-rfc5575bis@ietf.org, idr@ietf.org
Message-ID: <20200212234136.GC32507@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YI-MRCmkeivT5OYC0qVN9um8CI8>
Subject: [Idr] 5575bis nit - ASes in extended communities
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2020 23:36:07 -0000

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