Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

["Susan Hares" <[e-mail]>]

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:[e-mail]] 
Sent: Thursday, June 04, 2015 2:24 AM
To: Susan Hares
Cc: [e-mail]; [e-mail]; 'Joel M. Halpern'; [e-mail];
'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: [phone]         Campus Ring 1 | 28759 Bremen | Germany

Fax:   [phone]         < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>