[CCAMP] on consistent representation of upstream/downstream information in ROs

Lou Berger <lberger@labn.net> Tue, 30 July 2013 17:31 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 226E811E81E8 for <ccamp@ietfa.amsl.com>; Tue, 30 Jul 2013 10:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.904
X-Spam-Status: No, score=-100.904 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BEdUrj5wjNr4 for <ccamp@ietfa.amsl.com>; Tue, 30 Jul 2013 10:31:45 -0700 (PDT)
Received: from oproxy5.bluehost.com (oproxy5-pub.bluehost.com []) by ietfa.amsl.com (Postfix) with SMTP id E66C111E81D4 for <ccamp@ietf.org>; Tue, 30 Jul 2013 10:31:43 -0700 (PDT)
Received: (qmail 5499 invoked by uid 0); 30 Jul 2013 17:31:17 -0000
Received: from unknown (HELO box313.bluehost.com) ( by oproxy5.bluehost.com with SMTP; 30 Jul 2013 17:31:17 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=r8+QWvkCtwX4aLrWOG3o3QO/qafdVrB1Zx4M8x4YXjY=; b=pHjgOO612OJvPB9tZhB2E6RLF6vM4DP3OiE3s5Dg/vGs7xQi9/Mrk+ETWuD0r4kaTG/MS5DN5exx/N+dbfQXffWtdrVwU2eoDYcOiAmRO+zuH/GSj8OFebs5CEVaCrkT;
Received: from box313.bluehost.com ([]:41410 helo=[]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1V4DlU-0001hq-Ne; Tue, 30 Jul 2013 11:31:16 -0600
Message-ID: <51F7F863.2080702@labn.net>
Date: Tue, 30 Jul 2013 19:31:15 +0200
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: CCAMP <ccamp@ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth authed with lberger@labn.net}
Cc: draft-ietf-ccamp-te-metric-recording@tools.ietf.org, draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org
Subject: [CCAMP] on consistent representation of upstream/downstream information in ROs
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2013 17:31:56 -0000

	I notice that the above drafts don't quite follow how
upstream/downstream label ROs are identified in RFC3473, i.e. separate
objects with direction identified using the U-bit.

Is there any objection to using this same identification approach in
both drafts?
(Certainly there's a tradeoff of consistency vs optimal
bidirection/unidirectional representation, but I think consistency wins
with so little difference in this case.)