[bess] draft-rosen-bess-pta-flags

Eric C Rosen <erosen@juniper.net> Wed, 11 February 2015 20:27 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7AA1A1AA8 for <bess@ietfa.amsl.com>; Wed, 11 Feb 2015 12:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 ZzXat2SlmJPq for <bess@ietfa.amsl.com>; Wed, 11 Feb 2015 12:27:47 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFB21A079D for <bess@ietf.org>; Wed, 11 Feb 2015 12:27:47 -0800 (PST)
Received: from [172.29.34.156] (66.129.241.11) by BY1PR0501MB1094.namprd05.prod.outlook.com (25.160.103.140) with Microsoft SMTP Server (TLS) id 15.1.81.19; Wed, 11 Feb 2015 20:27:17 +0000
Message-ID: <54DBBB1E.5010401@juniper.net>
Date: Wed, 11 Feb 2015 15:27:10 -0500
From: Eric C Rosen <erosen@juniper.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "bess@ietf.org" <bess@ietf.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.11]
X-ClientProxiedBy: BY2PR04CA058.namprd04.prod.outlook.com (10.141.249.176) To BY1PR0501MB1094.namprd05.prod.outlook.com (25.160.103.140)
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1094;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BY1PR0501MB1094;
X-Forefront-PRVS: 0484063412
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(230783001)(23676002)(229853001)(2351001)(2501002)(33656002)(36756003)(50466002)(87976001)(59896002)(54356999)(87266999)(77096005)(50986999)(65816999)(42186005)(450100001)(86362001)(40100003)(122386002)(65806001)(65956001)(66066001)(47776003)(83506001)(92566002)(62966003)(77156002)(110136001)(46102003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1094; H:[172.29.34.156]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1094;
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2015 20:27:17.7231 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1094
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/70HQD-G6XXEwS5jNioZW1FhtKVo>
Cc: erosen@juniper.net
Subject: [bess] draft-rosen-bess-pta-flags
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Feb 2015 20:27:49 -0000

The PMSI Tunnel attribute defined in RFC6514 contains a "flags" octet. 
RFC 6514 only defines a single one-bit flag, "Leaf Information 
Required".  However, the next revision of 
draft-dolganow-l3vpn-mvpn-expl-track is probably going to specify the 
use of a second bit from the flags octet.  And 
draft-rabadan-bess-evpn-optimized-ir specifies the use of 4 bits from 
the flags octet.  Since this particular octet only contains eight bits, 
it is probably a good idea to have an IANA registry for it, to minimize 
the chance that two different drafts will try to allocate the same bit 
for different purposes.

Thus the trivial draft draft-rosen-bess-pta-flags, which, if progressed 
to RFC, would establish this registry.

Given the small number of possible allocations, the proposed 
registration procedure is "Standards Action", which automatically 
includes the possibility of "early allocation".

It might also be worth thinking about whether the interpretation of the 
flags octet should be dependent on the type of route to which the PMSI 
Tunnel attribute is attached.  However, that complication is not 
currently suggested in the draft.

Comments?