Juergen:
Mahesh Jethanandari indicated that he wanted to make sure the comment after
2c below has been responded to the following comment:
>"I am concerned about adding protocol mechanisms that are specific to a
certain data model.
> It is unclear what a "node" unit it, terms like 'highly reliable
notifications' and 'high bandwidth,
> asynchronous interface, with real-time guarantees' are somewhat unclear -
how do we
> determine we have met any of these requirements?"
I want to thank you and Mahesh for making sure this question gets asked.
You are correct that I2RS is data-model focused, and the unit of
notification is data dependent. Below my best estimate of the units with
times, notifications, normal groups of the units with times. See
Definitions for the info, I2RS Model info, Notifications and read/write
groupings.
Would it be helpful to have this information on a wiki-page for now? I will
query each model author to provide their input to the wiki page, and start a
discussion on the mail list.
I think it is useful to put these requirements in their drafts. What do you
think?
Sue Hares
===================================
Definitions
A few repetitions of the definitions may help from the architecture document
and interims may help:
Highly reliable notifications: are notifications which provide notifications
which align with the current status. In the I2RS interim notes, we noted
notifications are not logging which is covered by the traceability draft.
Notifications are status changes and each model provides the status changes.
If the changes come too quickly (E.g. route changes), then the change will
give the latest status. Highly reliable notifications are guaranteed to
arrive normally, but buffer overrun or system issue may cause a few to be
lost. Perfectly reliable notifications are possible in high-available
systems which duplicate streams of data. The I2RS WG is not asking for
perfectly reliable data streams.
High-bandwidth: It is assumed that the pull of a full RIB, full topology
model (all topologies), and a full FB-FIB is possible. However, the normal
mode is a query of a portion of these models. As discussed in the 5/27/2015
interim, a full pull may find that portions of the RIB change during the
pull. Joel Halpern suggest NETCONF may be a better mechanism for the full
dump. However, the portions of the models - must be reported quickly so
that programmatic changes can be made.
Asynchronous: means that multiple streams of data from different transport
sessions can query/write different portions of any of the I2RS models in
parallel - AND these read/write portions of the model can operates in
parallel along with pub/sub, traceability. Writes operate in parallel
operating on portions of the model. Exact definition of locking of the
portion of a model for a write has been discussed, but this should be
discussed per module.
Real-time guarantees: Real time guarantees means that the processing and
response must be listed under a certain time per module. The module can
give general ranges, but the specific definition is left to the
implementation. I will start a mail thread on these guarantees per module.
My understanding is that we are looking for seconds or sub-second in routes,
portions of topology, and in the filter rule.
I2RS Module information
===============================
This node will provide you the unit of focus for the protocol independent
modules (I2RS RIB, I2RS topology, and I2RS Filter-Based RIB Model). The
I2RS RIB and I2RS Topology have yang modules, and the I2RS Filter-Based RIB
Model has an Information al model so we can provide the unit of focus.
(Hopefully, the I2RS Filter-based RIB Model will have the yang model read by
6/24)
Protocol independent models (info/yang) were developed for BGP, OSPF, ISIS,
MPLS and SFC. These yang modules are being revised and could be reviewed at
the 6/24/2015 interim. These drafts are in flux so I need to query the mail
list on the use cases, and the authors on their changes. I can get more
detail by the end of next week so we can talk about it at the 6/24/2015
interim. Some of the flux is the also base yang modules (as an example BGP)
that impacts derivatives (EVPN, L2VPN, L3VPN).
I have reference the explanation sections in the I2RS drafts. As a yang
doctor, I hope it is evident which yang language parallel to these sections.
(if not, please post suggestions for corrections so the authors can fix
these drafts).
Model Unit type reference
Frequency of reference
======= ======== ============ =========
===============================
I2RS RIB Route main key unit section 2.3 high
R/W
Next-hop dependent subunit section 2.4 high to
medium R/W
RIB grouping of routes section 2.2
Initial start-up (mostly R/ some W)
RIB list grouping of RIBS section
2.1 Initial start-up (mostly R/ some W)
The topology nodes are out for the non-TE version. TE version will not
arrive until IETF time-frame.
I2RS Topology Unit Type Reference
Frequency of Reference
============== ======== ======= ===========
===========================
Generic Topology Node main unit section 3.1 R/W or W
from agent data
Link main unit section
3.2 R/W or W from agent data
Network main unit section 3.1/3.2
R/W or W from Agent
Full pull query
Termination sub-unit section 3.1
- point
L2 Topology same as generic section 2 - see note on
TE additions
L3 Topology same as generic section 3.2 for IGP - see
note on TE Additions
Section 3.3 for OSPF
L1 Topology same as generic See note: draft being
overhauled to align
to TEAS link & TE models
Service Topology same as generic See note: draft being
overhauled to link to
L3SM style of service topologies
Module: Unit Type Section
Frequency
======== ====== ====== ====================
==========
FB-RIB policy-rule main unit section 4.2 info
module R/W main unit
FB-RIB_ Ordered list of see section
4.1-4.3 R/W policy rule inserted
ordered-list filters
into ordered list
interface-list ordered list see section 4.2-4.3
Initial start-up /config
of interface
+ interface status
references
FB-RIB RIB group see section 4.1 to 4.2
Groups policy-rule +
Interfaces
Note on Topology modules
. All topology will be augment by TE modules with structure in
draft-ietf-teas-yang-te-topo-00 as updated by
https://github.com/ietf-mpls-yang/te.
. L1 topology draft - will be overhauled based on decision on
ephemeral state (just completed), and the TE drafts which have topology. It
may take portions of other TEAS drafts (
<https://datatracker.ietf.org/doc/draft-saad-teas-yang-te/>
draft-saad-teas-yang-te-01)
. Service module needs to provide link to work from service. Only
one service model is being designed:
o L3SM - protocol independent service module for L3 services
(https://datatracker.ietf.org/doc/draft-l3vpn-service-yang/
o L2SM - is not yet started.
o Service forwarding topologies - initial draft done
Notifications Status
Timing
-----------------
--------------------------------------------- --------
I2RS RIB nexthop-resolution-status-change
second or less
Route-change
second or less
L3 Topology igp-node-event
second or less
igp-link-event
igp-prefix-event
igp-termination-point-event
L2 Topology TBD - but likely the same)
second or less
(l2-node-event,
l2-link-event, l2-prefix-event,
L2-termination-point-event)
L1 Topology TBD- but likely the same
second or less
Service Topology Unknown - too much in flux
FB-RIB FB-RIB interface loss
second or less
Policy-Rule interface loss
second or less
Policy-Rule
second+
Query/Write
Groupings Normal High
Normal Time High BW time
--------------------- ---------- ----------------------
----------------- -------------------
I2RS RIB: Routes 1-10Ks 100K to 1Million < 1 second
1-5 second
I2RS RIB: RIBs 1-20 RIBs 100-300 RIB TBD
TBD
(10K-100K RT) (10K-100k)
Topology 1-5K node not really sure
TBD TBD
300-10K links
1K - 50K topology
FB RIB 1-10K rules not really sure
<1 second TBD
*tp = termination point
-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email protected]]
Sent: Thursday, June 04, 2015 2:24 AM
To: Susan Hares
Cc: [email protected]; [email protected]; 'Joel M. Halpern'; [email protected];
'Alia Atlas'
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)
On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote:
> The minutes for the I2RS meeting are at:
>
>
>
>
<http://www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-int
er> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter
> im-201
> 5-i2rs-8
>
>
>
> These minute provide a lengthy of issues in the requirements. From
> these minutes, there are the following 6 conclusions on the protocol
> requirements that Jeff stated:
>
>
>
> 1) There will be no consideration of an overlay model unless a fully
> formed proposal is presented.
>
> Jeff and I appreciate Ken Watsen's comments on the list, but we have
> had lots of suggestions regarding an overlay proposal - but no full
> proposal. At this time, the WG will only consider full proposals and
> not suggestions toward a proposal.
For the record: I am highly concerned about solutions that require (i)
separate data models for ephemeral state and (ii) data model specific merge
logic. While this may work for I2RS, this approach does not scale or has a
very high cost of scaling to other ephemeral state editing needs.
> 2) Jeff's document provides details on ephemeral state requirements
> that have not changed. These requirements include:
>
> a. Highly reliable notifications (but not perfectly reliable
> notifications)
>
> b. High bandwidth, asynchronous interface, with real-time guarantees
on
> getting data,
>
> c. Node identification of clients that write by client identity,
> secondary identity, and priority. Data models will determine what is
> the "node" unit. For example, the I2RS RIB node unit is the route.
I am concerned about adding protocol mechanisms that are specific to a
certain data model. It is unclear what a "node" unit it, terms like 'highly
reliable notifications' and 'high bandwidth, asynchronous interface, with
real-time guarantees' are somewhat unclear - how do we determine we have met
any of these requirements?
> d. There is one priority per client.
>
> e. Priority is kept in the NACM at the client level [rather than path
> level (5/27 meeting) or group level (list discussion).
Why does this mapping of username to priority have to be maintained in NACM?
> 3) Joel suggests that large data write may be best done in netconf
with
> guarantees
>
> a. I2RS will be focused on highly asynchronous interfaces with less
> than full routing tables.
>
> b. A client whose large data is interrupted by a notification has a
> difficult time determine when the notification happened in the stream
> - so the I2RS client must ask the agent again.
>
> c. Logging for traceability is different than event notification.
Except c), I do not understand this. What are these 'guarantees' 3) is
about?
> 5) Secondary identity data is read-only meta-data that is stored in
the
> agent associated with a data model node that is being created or
> updated
> (write-access) in the data store.
Ehem, what is read-only data that is created or written? Did you want to say
that the identity meta-data is immutable once a data node has been created?
And if so, has priority the same property: Is priority of a data node is
determined at creation time and then immutable?
> 6) I2RS Client and Agent Identities are mutually authenticated by
> Authentication server (AAA),
>
> The values of identities are originally set by operators.
>
I am not sure how agent identity authentication via AAA works. Can someone
point me to the right direction if I assume a secure transport such as SSH
or TLS?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
