Received-SPF: neutral (mail21-am1: 204.154.129.150 is neither permitted nor
 denied by domain of tellabs.com) client-ip=204.154.129.150;
 envelope-from=Jonathan.Sadler@tellabs.com;
 helo=usnvwwmspedge02.tellabs-west.tellabsinc.net ; llabsinc.net ; 
From: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
To: Shane Amante <shane@castlepoint.net>, Joel M.Halpern <jmh@joelhalpern.com>
Date: Wed, 3 Oct 2012 07:49:21 -0500
Thread-Topic: [irs-discuss] Comments on Topology API use case document
Thread-Index: Ac2hI4bmdhAAIg9XShKxS1diNRROpQAPWIdg
Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B01417B01B449@EX-NAP.tellabs-west.tellabsinc.net>
References: <506BA52E.2060008@joelhalpern.com>
 <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net>
In-Reply-To: <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "irs-discuss@ietf.org" <irs-discuss@ietf.org>
Subject: Re: [irs-discuss] Comments on Topology API use case document
Precedence: list

Shane, Joel, et al -

You may be interested in modeling work that was done at ITU-T discussing mu=
lti-layer topology relationships.  The specific document to look at is G.80=
0 (2012): Unified Functional Architecture of Transport Networks. (http://ww=
w.itu.int/rec/T-REC-G.800)

The specific component in this approach to describing networks that describ=
es multi-layer topology relationships is the Transitional Link.  See Sectio=
n 6.2.1.

There was a liaison sent from ITU-T SG 15 to CCAMP that described how this =
topological component can be used in multi-layer ODU networks.  Please see =
SG15 LS221 - Examples of the use of Transitional Links (ITU-T G.709) (https=
://datatracker.ietf.org/liaison/953/).

>From this, work has been started on how a transitional link can be represen=
ted in link-state routing protocols thereby providing detail of the hierarc=
hical relationships to path computation entities.

I see strong value in including this in IRS style applications as it enable=
s the entity interested in topology to be able to understand all of the det=
ails where the service provider wishes it to be known (i.e. subject to poli=
cy controls).

Jonathan Sadler

-----Original Message-----
From: irs-discuss-bounces@ietf.org [mailto:irs-discuss-bounces@ietf.org] On=
 Behalf Of Shane Amante
Sent: Tuesday, October 02, 2012 11:57 PM
To: Joel M.Halpern
Cc: irs-discuss@ietf.org
Subject: Re: [irs-discuss] Comments on Topology API use case document

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.
>
> 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 int=
eresting and powerful function.  it is a policy function.  But it is no mor=
e the entire policy manager than a security policy manager is the entire po=
licy 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 edge=
s 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.

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 qu=
alifying it.  The reason we chose "Policy Manager" is that it seemed the cl=
osest 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 t=
his stage, we're depicting this as a single "Policy Manager" function; howe=
ver, if this work evolves it's likely this will get broken down into sub-co=
mponents (security, routing, etc.) to more precisely define their domain-sp=
ecific attributes.


> I have to disagree with the definition of Multi-Layer Topology.  I agree =
that topologies are layered.  However, the OSI topology abstraction is abso=
lutely 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 in=
frastructure, which is in term supported by Ethernet, some which may actual=
ly be emulated Ethernet on MPLS on ...

Hrm.  Ultimately, what I think you're describe is a perfect example of buil=
ding a specific hierarchical network.  The problem is, today, we *DO NOT* h=
ave any (standards-based) way to represent the reality of those hierarchica=
l 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 en=
umerated some attributes of *individual* protocols or network components, (=
cf: SNMP MIB's), but they are entirely /standalone/.  Instead, we need to t=
ake 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 *vocabular=
y*.  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 s=
hortest-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 depe=
nds upon physical realities not visible to any automated system.  (The numb=
er 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 o=
f 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 di=
fferent paradigm than the other IRS drafts.  Is this deliberate, indicating=
 that these use cases need a different mechanism than is elsewhere describe=
d?  (I wold have simply indicated that the Topology manager will need to ap=
ply 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
_______________________________________________
irs-discuss mailing list
irs-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/irs-discuss


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D