[irs-discuss] Comments on Topology API use case document

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 03 October 2012 02:38 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: irs-discuss@ietfa.amsl.com
Delivered-To: irs-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0673C21F846C for <irs-discuss@ietfa.amsl.com>; Tue, 2 Oct 2012 19:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.092
X-Spam-Level:
X-Spam-Status: No, score=-102.092 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFljlVEsRl5b for <irs-discuss@ietfa.amsl.com>; Tue, 2 Oct 2012 19:38:50 -0700 (PDT)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 891CB21F845D for <irs-discuss@ietf.org>; Tue, 2 Oct 2012 19:38:50 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 422C7A6B60 for <irs-discuss@ietf.org>; Tue, 2 Oct 2012 19:38:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9386A1814C3 for <irs-discuss@ietf.org>; Tue, 2 Oct 2012 19:38:42 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [10.10.10.104] (pool-71-161-51-10.clppva.btas.verizon.net [71.161.51.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 20FAF1814C2 for <irs-discuss@ietf.org>; Tue, 2 Oct 2012 19:38:42 -0700 (PDT)
Message-ID: <506BA52E.2060008@joelhalpern.com>
Date: Tue, 02 Oct 2012 22:38:38 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [irs-discuss] Comments on Topology API use case document
X-BeenThere: irs-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:irs-discuss@ietf.org>
List-Help: <mailto:irs-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:irs-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Oct 2012 02:38:51 -0000

Overall, this looks very helpful.

In the terminology section, two things struck me:
First, we probably need to consistently qualify the term "Policy 
Manager".  What is described in this document as the "Policy Manager" is 
a very interesting and powerful function.  it is a policy function.  But 
it is no more the entire policy manager than a security policy manager 
is the entire policy manager.  It seems to me that this is a discipline 
we need to acquire early, or we will forever find ourselves arguing 
about the meaning of terms when we actually agree.  (The later 
description of the Policy Manager edges into the broader perspective, 
but isn't really the same.)

I have to disagree with the definition of Multi-Layer Topology.  I agree 
that topologies are layered.  However, the OSI topology abstraction is 
absolutely wrong.  As was pointed out to me many years ago, and has 
become more prevalent ever sine, w run L2 VPN services on MPLS 
infrastructure on IP infrastructure, which is in term supported by 
Ethernet, some which may actually be emulated Ethernet on MPLS on ...

While I appreciate the importance of the Inventory function in 
evaluating SRLGs, I think the document should probably point out that 
this often depends upon physical realities not visible to any automated 
system.  (The number of stories of operators failing to meet diversity 
guarantees are legion.)

I find it strange that this draft describes change application using a 
different paradigm than the other IRS drafts.  Is this deliberate, 
indicating that these use cases need a different mechanism than is 
elsewhere described?  (I wold have simply indicated that the Topology 
manager will need to apply changes, and left it there as far as this 
document is concerned.

Yours,
Jo9el M. Halpern