Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <506BA52E.2060008@joelhalpern.com>
Date: Tue, 2 Oct 2012 22:56:44 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net>
References: <506BA52E.2060008@joelhalpern.com>
To: Joel M. Halpern <jmh@joelhalpern.com>
Cc: "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] Comments on Topology API use case document
Precedence: list

Hi Joel,

Thanks for your review.  Please see below.

On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> Overall, this looks very helpful.
>=20
> 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.)

We'll look at making the text in terminology section better align with =
the broader definition of a Policy Manager in Section 3.3.=20

Indeed, a "Policy Management" function is indeed critical.  Arguably, =
it's in the top two most critical elements of this work, IMO.  And, =
you're right that we need to align on definitions for what it is for =
fear or forever qualifying it.  The reason we chose "Policy Manager" is =
that it seemed the closest match to what are (likely) considered routine =
functions in networking today, namely, "routing policies" (cf: BGP), =
"security policies" (cf: ACL preventing/allowing packets through), etc.  =
Is that part clear?  Note, at this stage, we're depicting this as a =
single "Policy Manager" function; however, if this work evolves it's =
likely this will get broken down into sub-components (security, routing, =
etc.) to more precisely define their domain-specific attributes.


> 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 ...

Hrm.  Ultimately, what I think you're describe is a perfect example of =
building a specific hierarchical network.  The problem is, today, we *DO =
NOT* have any (standards-based) way to represent the reality of those =
hierarchical relationships /outside of/ the data-plane and =
control-plane[1].  Over the years, we've clearly engineered such =
hierarchy directly into the routing (and, forwarding) planes of network =
equipment.  In addition, we've barely enumerated some attributes of =
*individual* protocols or network components, (cf: SNMP MIB's), but they =
are entirely /standalone/.  Instead, we need to take the next step.  =
Specifically, we need to fully enumerate attributes and, more =
importantly, metadata of individual control & data-plane protocols (and, =
related network components) using a common, standards-based =
*vocabulary*.  Only once we do that will it be possible to:
a) Define hierarchical relationships between network components =
(protocols, services, etc.), using the aforementioned =
attributes/metadata as filtering/selection criteria, as appropriate; =
and,
b) Summarize all of this vocabulary into schemas/data-models that can =
then be exchanged between systems that *DO NOT* (cannot *and* will not) =
directly participate in routing & forwarding.
Ultimately, this is the core essence of SDN/IRS.

[1] BGP recursing to an IGP for next-hop; LDP relying on IGP to =
determine shortest-path, etc.


> 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.)

Really!?!?  ;-)

More seriously, I thought this was made clear in the first two =
paragraphs of Section 4.1.1, "Capacity Planning and Traffic =
Engineering":
---snip---
   [...] Due to this inefficiency, the
   underlying physical network inventory information, (containing SRLG
   and corresponding critical network asset information), used by the
   IP/MPLS Capacity Planning and TE applications is not updated
   frequently, thus exposing the network to, at minimum, inefficient
   utilization and, at worst, critical impairments.
---snip---


> 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.

I'm not sure I understand the above comment.  Can you elaborate?

-shane=