Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <506C3F71.2020106@joelhalpern.com>
Date: Wed, 3 Oct 2012 21:46:16 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DE36DA3-AA9A-4071-A34F-CA46F73708FC@castlepoint.net>
References: <506BA52E.2060008@joelhalpern.com>
 <1522D7C2-0CE1-478C-8FD9-A0ABFBFB1CDA@castlepoint.net>
 <506C3F71.2020106@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,

On Oct 3, 2012, at 7:36 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> Thanks for the prompt and helpful response Shane.
>=20
> With regard to the hierarchical topology model, I strongly agree that =
we need a model that supports hierarchy / layering / service dependence.
> My concern is that the text currently says that the ISO layers are a =
good starting point for this.  As far as I can tell, the ISO model is a =
very bad pace o start developing such a model.

OK; however, we need some way to address it.  I'd welcome your and =
others opinions on a better alternative.


> With regard to the configuration protocol, the text talks about =
injecting information into the routing protocol instance, or using the =
existing configuration tools.  Other drafts have talked about the IRS =
agent as a new channel, which provides a similar but distinguished set =
of configuration.  There have also been discussions of how information =
gets intoIGPs (directly telling the GP to emit a route vs configuring a =
class of static route and having it imported.)  It seems to methat this =
is an important area, with much work to be done.  Thus, it seems simpler =
if this draft simply said it would use IRS related confiuration =
mechanisms to make its changes, and did not try to categorize or =
approximate those.

Actually, before submitting the draft we (co-authors) had been having a =
debate on this very subject.  I think this will be an area of "lively" =
discussion, both on the mailing list and in-person.

Ultimately, there's likely several dimensions we need to evaluate to =
determine what the possibly-to-be-formed IRS WG will work on, what other =
(existing) IETF WG's will work on, what _already_exists_ by other IETF =
WG's that can get re-used, etc.  With respect to the latter, we tried to =
recognize that "IRS" does not have to solve for every single use case.  =
Rather, there are likely classes of use cases where existing (IETF) =
protocols are more than adequate to fulfill that need -- some immediate =
examples that comes to mind are: NETCONF & YANG.  These protocols seem =
adequate for use cases where there is no requirement for =
(near-)real-time communication/transactions, there is not a substantial =
concern about on-the-wire-overhead, etc.  Example use cases in this =
draft that may fit this criteria are: Cap Planning and Traffic =
Engineering, assuming their intervals are defined in terms of hours or =
longer.  That said, there still is a critical need to recognize that =
these use cases could use NETCONF/YANG, *but* we need to "encourage" the =
work to define an appropriate data-model within, probably, NETMOD to =
carry/exchange the required set of information to/from NE's.  Likewise, =
there's also a need to have a data-model that can work from the Topology =
Manager to/from the Applications/Client that consume this information.  =
With respect to the latter, is that something that the maybe =
to-be-formed IRS WG will get tasked with?  Or, is there another WG =
already set-up to do this?  If not, can we possibly consider =
re-chartering an existing WG to do this ... even if the WG doesn't exist =
in the Routing Area?

OTOH, where there is a critical requirement for (near-)real-time =
communication, that's where things get more interesting.  As has been =
pointed out in the past, there was /a lot/ of discussion on the need for =
a "streaming interface" -- however, the conversation got muddy & stalled =
out, seemingly because there was an assertion on the need for such a =
thing, but not the use cases and articulation of what is required in a =
"streaming interface".  IMO, I think that this draft, and others, are =
hopefully bringing more light to specific use cases to help move the =
conversation forward.  In particular, I think some use cases that are =
definitely in this category of requiring (near-)real-time communication =
is: detecting & mitigating DDoS attacks, reactionary Traffic Engineering =
(i.e.: due to unplanned events), etc. through IRS.  I'm sure others can =
add more to that list.

Anyway, I hope this helps shed light on why we've chosen, for now, to =
try to articulate that there may be existing mechanisms/protocols that =
*could* be used to solve *some* of these use cases, but that more work =
still needs to be done (i.e.: defining data-models) and we should =
discuss whether to do that work and, of course, where.  Obviously, for =
those use cases that require (near-)real-time communication, and =
possibly other requirements that can't be accommodated by today's =
protocols, that will likely lead to a more focused set of requirements, =
etc. that will drive a set of short-term deliverables for =
maybe-to-be-formed IRS WG ...

Thanks,

-shane


>=20
> Yours,
> Joel
>=20
> On 10/3/2012 12:56 AM, Shane Amante 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
>> 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.
>>=20
>>=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?
>>=20
>> -shane
>> _______________________________________________
>> irs-discuss mailing list
>> irs-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>=20
>=20