Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Thomas Nadeau <tnadeau@lucidvision.com>
In-Reply-To: <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net>
Date: Wed, 3 Oct 2012 08:10:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF5969F7-11DB-414B-80BF-9D790724A4C0@lucidvision.com>
References: <506BA52E.2060008@joelhalpern.com>
 <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net>
To: Shane Amante <shane@castlepoint.net>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>,
 "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] Comments on Topology API use case document
Precedence: list

On Oct 3, 2012:12:56 AM, at 12:56 AM, Shane Amante =
<shane@castlepoint.net> wrote:

> Hi Joel,
>=20
> Thanks for your review.  Please see below.
>=20
> 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.)
>=20
> 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
>=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.
>=20
>=20
>> 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 ...
>=20
> 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.
>=20
> [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to =
determine shortest-path, etc.

	Just to add to this. Joel, while I agree with you RE: the "OSI =
topology", we are not trying to enumerate EVERYTHING in the network nor =
are we out to incarnate those theoretical layers. Ultimately what we =
want is to represent different abstractions of topology that are used =
for routing/switching. This is really a matter of grouping =
links/ports/nodes, their facets, and then connecting or relating them =
together. This then can represent active and inactive topological =
elements in arbitrary ways, but more importantly, how they really exist =
within one's network versus a theoretical model (i.e.: OSI).=20

>> 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.)
>=20
> Really!?!?  ;-)
>=20
> 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---
>=20
>=20
>> 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.
>=20
> I'm not sure I understand the above comment.  Can you elaborate?

	I agree; I am confused. The draft does not (intentionally) =
describe any specific mechanisms; the aim was to describe how normalized =
topology could be used.  We have a forth coming requirements draft that =
further elaborates on what components need to exist in order for these =
use cases to work.

	--Tom


>=20
> -shane
> _______________________________________________
> irs-discuss mailing list
> irs-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/irs-discuss
>=20