Return-Path: 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 ) id 1j2ETJ-0004bc-2V; Thu, 13 Feb 2020 14:24:01 +0100 From: Christoph Loibl 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 References: <20200212234136.GC32507@pfrc.org> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 13:24:08 -0000 --Apple-Mail=_93E98559-6877-4544-AE95-ABEAA2E1982A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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/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=E2=80=99t checked what other implementations actually put there. Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 13.02.2020, at 00:41, Jeffrey Haas wrote: >=20 > In RFC 5575 and 5575-bis, we have several extended communities = defined. >=20 > : = +-----------+----------------------+--------------------------------+ > : | 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 = | > : = +-----------+----------------------+--------------------------------+ > :=20 > : Table 2: Traffic Action Extended Communities >=20 > Nits: We use byte in some spots for AS, octet in others. "addres" is = a > typo. >=20 > 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? >=20 > 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. >=20 > While the AS number is largely an advisory number for the features in > question, it does potentially have impact on policy. >=20 > 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." >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_93E98559-6877-4544-AE95-ABEAA2E1982A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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/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=E2=80=99t = 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 =             &n= bsp; | encoding =             &n= bsp;         |
: =    +-----------+----------------------+--------------------= ------------+
:    | 0x8006 =    | traffic-rate-bytes   | 2-byte ASN, 4-byte = float       |
: =    | TBD       | = traffic-rate-packets | 2-byte ASN, 4-byte float =       |
: =    | 0x8007    | traffic-action =       | bitmask =             &n= bsp;          |
:    | 0x8008    | rt-redirect = AS-2byte | 2-octet AS, 4-octet value      |
:    | 0x8108    | rt-redirect = IPv4     | 4-octet IPv4 addres, 2-octet =   |
:    | =           | =             &n= bsp;        | value =             &n= bsp;           &nbs= p;|
:    | 0x8208    | = rt-redirect AS-4byte | 4-octet AS, 2-octet value =      |
:    | = 0x8009    | traffic-marking =      | DSCP value =             &n= bsp;       |
: =    +-----------+----------------------+--------------------= ------------+
:
: =             &n= bsp;  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

= --Apple-Mail=_93E98559-6877-4544-AE95-ABEAA2E1982A--