I just uploaded the IRS BOF minutes to the IETF server. They are also attached
to this email in text form. Thanks to Sue Hares and Dave Ward for providing the
rough input that I summarized into these minutes.
Thanks, Ross
Minutes from IRS BOF
2012.11.05, Altanta
Agenda:
Agenda-bashing and administrivia (chairs)
Scope and purpose of BoF (Adrian Farrel)
Overview of Problem Statement and Framework (Joel Halpern)
Overview of Use Cases and Requirements (Shane Amante)
Potential Charter (Ross Callon)
Obvious Questions (Dave Ward)
Discussion (all)
Summary and Closure (chairs and AD)
0. Administrivia - Ross Callon
Note Well was discussed.
This is a WG forming BOF, so Ross will go over draft charter later in BOF. Dave
will go through some questions that have been asked.
No questions
I. Purpose of bof - Adrian Farrel
Thank you for coming. Key elements that we need to address: consensus that
there is work to be done, clear focus on topics; determine if work is within
the scope of the IETF (eg in either routing or operations); a critical mass of
people commit to doing the work (not 1 or 2 people).
No questions
II. Overview of Problem Statement and Framework - Joel Halpern
This is related to but not the same as use cases. We are talking about a
problem, not a protocol.
What is needed:
- data modeling for routing and signaling state
- SNMP is not a good date model for anything,
- there is a challenge in modeling policy
- (for models see slides)
- We need a framework to integrate the external data into Routing
- indirection, policy, loop-detection
- we need to provide the triage that is needed for the red
alert stream (ie, aid when one outage causes flood of alerts)
- we are not starting on defining a protocol we have lots
of protocols. We are starting on data models.
Main concerns:
- Standard Models
- clear self-describing semantics
- sufficient coverage for use cases needing fact
- Applications are not routers
- Security, authorization, and identity
- we must put it in from the beginning.
- It must scale to large sizes.
(see diagram on slides)
PAL - slides (see slides)
IRS Interface Key Aspects
- Multiple simultaneous asynch
- some long, some short, parallel operations
- Configuration
- We need to interact with the changes of configuration
- (Many implementations can handle interactions to configuration)
- Must know about capabilities, The applications have to know what
you can do.
What IRS is not
- not config, not router/signaling, not the only way,
- not to replace bgp or ospf pll out
- Not to a specific devices or not a specific case
Start with a Focused Scope
- small set of data-models (RIB layer) for control,
- Set of events to support related use-cases,
- Data-model for topology,
- investigate protocol options for the interface
- define a set of motivating use-case to drive this scope
- We will fail if we try to do all if it!!!!
- We have to make extensible,
IRS Policy Framework
- discussion of diagram
- It has to be many-to-many,
- Unfortunately - we can make the simplification of 1 to many,
Policy Framework Topics
- Identity
- Role
- Scope - what I can read
- Influence - what I write
- Resources
- that persist and may consume things
- Policy
- implicit policy - exists within protocols, some routers choose between
- explicit policy - read and write in the configuration
- Both must be represented in the protocol
- Policy Actions
- We came up with a start-up
- We would like review
Questions / Discussion
- Kireeti Kompella - Are all applications network related?
Joel: Long term both (network related and not). Short term focus on
applications that are network aware.
- Kireeti - we should go back to Minneapolis for boiling lakes instead of
oceans. Policy
is this routing policy? Please make this clear.
Joel: Two types: Policies of IRS
IRS affects routing policy
- Kireeti: Third, IRS is not a direct replacement for routing protocols. Does
this mean indirect?
JH: In a static (e.g. static routing - maybe) but, the assumption is that
dynamic routing and signaling is in operation
- Vijay Kervani: In Paris, we had a BOF I2AX which is related to this but
focused on a protocol. Don't remember this discussion there. I co-chaired.
JH: We should look at the IA2EXT. Please send info on this to the list
- Bombi K: Please do not use the term IRS.
- Bombi: Is it a network API or a router API?
Joel: This is a control entity or a control commissioner. It is talking
between a control entity and the routers. A control entity
(client/commissioner) talks to one or more network nodes (e.g. routers).
- Bombi: If you are familiar with other related work in other SDOs, you should
review it.
- Tom Nadeau: (Channeling Keyur Patel via jabber): IRS is supposed to augment
not replace routing protocols.
- Peter Lothberg: You are assuming multiple control planes talking to this.
How do you arbitrate and deal with coherency?
Joel: This is discussed in the Policy document.
- Edward Crabbe: The 'application' terminology we're using is a bit confusing;
ultimately all the things we're talking about are control systems and should be
treated as such. Also you can replace routing protocols with this protocol,
whether you intended or not.
Joel: Intent is always limiting.
III. Use Cases and Requirements - Shane Amante
See list of documents for use cases + + a new draft will be published by Geoff
Matson, after I-D window reopens.
Caveat: Shane will quickly summarize contents of drafts. We are not suggesting
that all use cases need to be addressed initially.
Please look at and read the use cases drafts.
In my opinion, across several use case drafts, what you really will find is
the synthesis of information that are outside the routing control plane, e.g.:
Netflow, to ultimately help direct routing protocols to make more globally
optimal forwarding decisions. I think Joel did a great job of highlighting this
in his talk.
Draft 1: draft-amante-irs-topology-use-cases-00
- There are existing inventory & statistics warehouse systems that something
like this is going to reach out and get information from.
- IRS needs to think about how to extract information from those systems.
- Commonality: TE, VPN, Rapid IP & ASN renumber, etc.
- Unique: Capacity planning, path computation element (PCE)
- ALTO servers
Draft 2: draft-keyupdate-irs-bgp-usecases-01
- BGP configuration largest in the box, RSVP-TE LSP's are second.
- Having the ability to synchronize consistent BGP policies across an entire
AS is extremely important,
- BGP Traffic Engineering is important, as shown by Russ White in his draft.
- Common
- Flow spec (react to DDOS attacks) similar to white-irs-use
- Optimized exit control
Draft 3 Draft-white-irs-use-case-00
- Optimized exit control - BGP does not allow fine grain control
- Need to react quickly to DDOS attack
- Dynamically optimize flows in hub & spoke network
- Inside DataCenter
- Between Data Center routing - Bandwidth on Demand
- Overall use cases are about: fine grain tuning of traffic flows in a network
Draft 4: Geoffrey Mattson's Draft
- If optical transponders are offboard, it is useful to be able to monitor bit
error-rate degrading over time and tell, through IRS, IP/MPLS routers to
react to that, i.e.: shift traffic away from a bad link, in order to repair it.
Draft 5: Draft-medved-irs-topology-requirements-00
- Concentrated look at use case & requirements for the north-bound API
- This goes from the commissioner to the application(s) above it
- Clear need for a data model that can provide a common vocabulary
to describe the elements IRS handles
- This use case has protocol requirements
Draft 6: draft-rfernado-irs-framework-requirement-00
- publish-subscribe for asynchronous notification of events that occur
- p2p transport connection between client and a server,
- In order, reliable data delivery in both directions,
- Security requirement: server needs to validate identity of client, before
allowing client to read or perform read-write actions
- Important: from an application that sits above it - the application
shouldn't have to worry about the mechanisms to provide services. There should
be templates that can be abstracted from the network.
Requirement Summary
- Need standard/common vocabulary to describe the functional network
components in the IP Routing System within Standards-based data models
- Need "application friendly" mechanisms to retrieve information from
network elements and push configuration/policies/etc. back into groups of
network elements.
Overall
- Critical need to make globally optimized routing/forwarding and
configuration changes to entire network
- When trying to improve efficiency or handle DDOS attacks, need fine-
grained influence over routing/forwarding mechanisms
Questions / Discussion:
- Russ White: Although it sounds like we are trying to boil the ocean, we are
trying to list an ocean of requirements and then take a cup of ocean to solve.
This isn't about replacing the routing protocols but, opening up the control
plane of routers that we tweak everyday in a coordinated way.
- David Lampeter: Two example use cases (changing IGP metric and ASN changes).
NETMOD is modeling the routing system. When do you use NETMOD vs IRS?
Shane: Need to have routing information available in a policy form, then IRS
can retrieve that in NETMOD templates so that IRS can act on it.
- Someone Hussein from Infinera: Feels like you are proposing a solution first
and then a use case, need use cases first
Shane: It's important to recognize that there are existing systems out there
now (e.g. stats collections and inventory systems) that haven't been first
class citizens, but need to be from PoV of IRS. This is just a straw man
proposal.
- SH (not sure who this was): Briefly mentioned optical enhancements, will you
be looking at optical topology?
Shane: Eventually, that would be nice. To get started, that's most likely too
much to bite off, so am willing to focus just on IP/MPLS networks for now.
- Ed Crabbe: Sounds like you are confusing what's available from SNMP
Shane: There are existing protocols to talk with transponders and if we can
reuse them, great but, what's missing is the coordination mechanism. Can do
something very simple today via the CLI but, I hope we get beyond that.
- Ed: Seems dangerous to talk about replacing all known protocols
Shane: Not saying that. Saying that I want a data model, not TL1 or CLI.
- Rudiger Volk: Im confused. JH's slides showed interfaces that exercise more
control. What Im hearing from you Shane is that I want to do all control of
the system and download policies. Is the goal to build multiple interacting
commissioners or do we have somewhat more modest goals here.
Shane: This is an entire taxonomy of use cases. Should discuss that when we
discuss what is charter of WG.
IV. Charter Overview - Ross Callon
WGs do best with limited defined charters, OK to postpone some work to later.
Issue that came up in discussion of draft charter that had been mailed to the
irs-discuss list: Fast path vs Slow path. Fast versus slow is relative. We do
not want to confuse implementation versus standards.
Which protocol - an existing protocol or define a new one protocol?
- The WG needs to figure this out
Initial charter focuses on use cases, not protocol. I doubt we will define a
new protocol, more likely we will use an existing protocol.
Issue with regard to Use Cases
- Tightly scoped key use cases for operational use of IRS.
- Text in draft charter states these use cases will include at least (see
more detail in draft charter sent to IRS-discuss list). Question has been
asked: Does this preclude other use cases?
- No-- but we need to focus to make progress
(Q&A postponed until after Dave Wards talk)
V. Obvious Questions - Dave Ward
How big is the community working on IRS?
- 408 members of mailing list
- 11 drafts, lots of authors
- 25% operators, 35% vendors, 25% academics or other
What about my use Case?
- The number of use cases being written up is greater than one
- Evaluation of use case is to be considered example not canonical design
- They are to make sure we have reasonable targets not the only targets for
the technology,
My encoding is the prettiest
- No it isn't
- None are perfect today,
- First we start with the data model, and encoding
Recap: IRS and Programming
- IRS is a mechanism to learn state from the network
- (see slides)
IRS Concerns
- (long list, see slides)
Candidates for session and data modeling
Pros: (see slide) yang, modular,
Gaps: operational state, state persistence, state ownership, HA semantics,
pluggable on-the-wire,
Topology tools
- Current team investigating Netconf/yang applicability to IRS
- Rex ferando ([email protected])
- Martin Bjorklund ([email protected])
- Bruno Rijsman ([email protected])
VI. Open Discussion
Lou Berger: Definition of topology too broad: OTN, WDM, L2, MPLS, VPN,
everything. What's in scope or out of scope I can't tell. Either expand on
definition or "pick this use case" Should be part of the charter for proper
scoping.
Margaret Wasserman: We tried a lot of time how you are going to manage
devices. All have had similar problem
if you can only manage only a subset of
functionality on a piece of equipment and therefore run another "thing" to
control the rest of the equipment. Why is this situation different? Why is a
common subset useful now?
Margaret W: Very afraid that it was stated so many times "not boil the ocean"
that this causes concern.
Rudiger Volk: <minute taker did not catch>
Jamal: We are not talking about protocols, why are we talking about NC/Y? Can I
write a draft on my favorite protocol?
Ross: Yes
David Lampeter: Classic config protocols are slow path, what is the fast
path?
?: Is this SDN?
A: It is related.
Chris L: What are Northbound APIs on top of the commissioner and that might
define what we need southbound. What can we use/abuse in the IETF
Shane Amante: She may be concerned with rate of adoption
this work is using
existing forwarding and control plane protocols we have today. The most time
consuming effort is deploying new control and forwarding plane protocols. The
reuse of existing protocols and augmenting them is critical.
Dmitri: concern of the modeling work. It should be not limited to information
model first. A definition of an agent that was used by Joel may limit the work.
Function and memory and need state
Brian Dixon: The slow path vs fast path. Vendors should not implement this by
making a gateway to the cli and the commissioner could be a CLI. The best way
to view this is as not as a protocol integration but, a horizontal integration
across elements across an entire network. Not all of the functions but, all the
classes of behavior.
Wes Hartiker: I don't think you are trying to boil an ocean but rather, a body
of water on a distant planet. The body of work is bigger than behave. To avoid
the design by committee is to think about: do we have to do all of this at
once? Managing the multiple RIBs is hard enough.
Rudiger Volk: What is the absolute key issue is the data modeling. To answer
(didnt get rest)
Margaret: the work for getting a more unified solution to get to
managing a device has taken decades and the data modeling for all the usual
features
to do everything (model) and request new ways for changing
everything. Use cases defining data models. Working too slow or too fast
that
should be potential optimizations
Peter Lothberg: Very happy to see that modeling optical devices is in there.
Today they have to do 2k transactions a second.
Shows of hands:
People interested in helping with this work:
~40 interested in this work
Should we form a WG:
~60 for WG formation
~6 for not a WG to be formed
Compared to current draft charter, how many deliverables should we have:
current set: 12
fewer docs: 30
wholly different: 0
Comment: Please add security
ADs / Chairs: Next step is to continue to discuss charter, what docs to drop,
etc. Thanks.
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
