[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?
- [bess] draft-rosen-bess-pta-flags Eric C Rosen
- Re: [bess] draft-rosen-bess-pta-flags Rabadan, Jorge (Jorge)
- Re: [bess] draft-rosen-bess-pta-flags Jeff Tantsura