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

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 02 Oct 2012 22:38:38 -0400

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.)

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 ...

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.)

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.

Yours,
Jo9el M. Halpern

---

From: Shane Amante <[email-masked]>
Date: Tue, 2 Oct 2012 22:56:44 -0600

Hi Joel,

Thanks for your review.  Please see below.

On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <[email-masked]> wrote:
> 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

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 3 Oct 2012 08:10:16 -0400

> [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). 

> 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

> 
> -shane
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Wed, 3 Oct 2012 07:49:21 -0500

Shane, Joel, et al -

You may be interested in modeling work that was done at ITU-T discussing multi-layer topology relationships.  The specific document to look at is G.800 (2012): Unified Functional Architecture of Transport Networks. (http://www.itu.int/rec/T-REC-G.800)

The specific component in this approach to describing networks that describes multi-layer topology relationships is the Transitional Link.  See Section 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 represented in link-state routing protocols thereby providing detail of the hierarchical relationships to path computation entities.

I see strong value in including this in IRS style applications as it enables the entity interested in topology to be able to understand all of the details where the service provider wishes it to be known (i.e. subject to policy controls).

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Tuesday, October 02, 2012 11:57 PM
To: Joel M.Halpern
Cc: [email-masked]
Subject: Re: [irs-discuss] Comments on Topology API use case document

Hi Joel,

Really!?!?  ;-)

---snip---

-shane

============================================================
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
============================================================

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Oct 2012 09:36:49 -0400

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

---

From: Shane Amante <[email-masked]>
Date: Wed, 3 Oct 2012 21:46:16 -0600

Hi Joel,

On Oct 3, 2012, at 7:36 AM, Joel M. Halpern <[email-masked]> wrote:
> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 04 Oct 2012 00:24:38 -0400

I agreethat we need to look at using existing protocols / mechaisms.
My concern is merely that the wording in the raft, in trying to raise 
that, describes using existing configuration protocols and direct 
manipulation of the routing protocol internals.  There are significantly 
more alternatives, both i the extant category and in the new category.

Hence, I am merely asking that the use case not get cluttered with text 
on the specifics.  (All solving this takes is removing one or two 
sentences.)

Yours,
Joel

On 10/3/2012 11:46 PM, Shane Amante wrote:
> 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 cou
 ld 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?