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

["Joel M. Halpern" <[e-mail]>]

Thanks for the prompt and helpful response Shane.

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.

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.

Yours,
Joel

On 10/3/2012 12:56 AM, Shane Amante wrote:
> Hi Joel,
>
> Thanks for your review.  Please see below.
>
> On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <[e-mail]> 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 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.
>
> 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
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>