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

Christoph Loibl <c@tix.at> Thu, 13 February 2020 13:24 UTC

Return-Path: <c@tix.at>
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 A63B61200F7; Thu, 13 Feb 2020 05:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 umv8dwlJYJ2b; Thu, 13 Feb 2020 05:24:04 -0800 (PST)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D69F1200F8; Thu, 13 Feb 2020 05:24:04 -0800 (PST)
Received: from 80-110-104-164.cgn.dynamic.surfer.at ([80.110.104.164] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1j2ETJ-0004bc-2V; Thu, 13 Feb 2020 14:24:01 +0100
From: Christoph Loibl <c@tix.at>
Message-Id: <36B17AE5-3405-4284-ADF6-D599B4F9C6F4@tix.at>
Content-Type: multipart/alternative; boundary="Apple-Mail=_93E98559-6877-4544-AE95-ABEAA2E1982A"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Thu, 13 Feb 2020 14:24:00 +0100
In-Reply-To: <20200212234136.GC32507@pfrc.org>
Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr@ietf.org
To: Jeffrey Haas <jhaas@pfrc.org>
References: <20200212234136.GC32507@pfrc.org>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xiq4N_1OOZ9zHgrtlQ-_cLhVMTo>
Subject: Re: [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: Thu, 13 Feb 2020 13:24:08 -0000

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
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 13.02.2020, at 00:41, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> 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
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr