Subject: Re: [i2rs] FW: New Version Notification for draft-nitinb-i2rs-rib-info-model-01.txt

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 01 Aug 2013 21:59:59 -0400

On 7/15/13 3:31 PM, Nitin Bahadur wrote:
> 
> A new version of the RIB info model draft has been posted.
>  
> Notable changes include:
> - Addition of multicast support
> - Text clarifications as per received comments

Thanks for the presentation today, Nitin.  I have some comments on the
draft in addition to what was already said (though there may be some
duplicates).  See JMC below:

Section 4:

Route programming in the RIB SHOULD result in a return code that
   contains the following attributes:

JMC: Why would one not want to return a result code?  I think this needs
to be a MUST and there is evidence in a later section supporting this.

Section 4:

JMC: How is this result code encapsulated?  I realize this is an
information model, but I thought there would be some description of this
in your RBNF in Section 6.

Section 5:

Asynchronous notifications are sent by the network device's RIB
manager to an external entity when some event occurs on the network
   device.  A RIB data-model MUST support sending asynchronous
   notifications.  A brief list of suggested notifications is as below:
   o  Route change notification, with return code as specified in
      Section 4
   o  Nexthop resolution status (resolved/unresolved) notification

JMC: While a RIB data-model must support notifications, there are no
notifications that must be supported?  Are you suggesting that the two
examples listed here would be mandatory?

Section 6:

<ipv4-route> ::= <IPV4_ADDRESS> <IPV4_PREFIX_LENGTH>
                    [<multicast-source-ipv4-address>]
<ipv6-route> ::= <IPV6_ADDRESS> <IPV6_PREFIX_LENGTH>

JMC: I agree with Carlos (and I think you missed his point) IPV4_ADDRESS
and IPV6_ADDRESS should be IPV4_PREFIX and IPV6_PREFIX as these are not
addresses but route prefixes (the next-hop is an address)

Section 8.1:

JMC: Bulking (as you call it) then must also be supported by a RIB
client to request data in bulk.

Section 8.2:

Bulking (grouping of multiple write operations in a single message)
   MUST be supported when an external entity wants to write to the RIB.
   The response from the network device MUST include a return-code for
   each write operation in the bulk message.

JMC: Here, you say the return code per operation is a MUST, which
implies that in Section 4, this should be a MUST as well.

Section 8.3:

There can be cases where a single network event results in multiple
   events and/or notifications from the network device to an external
   entity.  On the other hand, due to timing of multiple things
   happening at the same time, a network device might have to send
   multiple events and/or notifications to an external entity.  The
   network device originated event/notification message MUST support
   bulking of multiple events and notifications in a single message.

JMC: Here is where I think we need to request something akin to pub-sub
where the Client can do filtering based on specific events types and
parameters within those events.  While a bulk blob of events might be
nice for the RIB, I would think a client would want to be tactical about
the events (and, in fact, within Cisco we offer this kind of granular
filtering).

Section 9:

All interactions between a RIB manager and an external entity MUST be
   authenticated.

JMC: Should you also add authorized in addition to authenticated?  This
would imply that interactions between Clients and the RIB must have
specific permission to red, write in general and in specific parts of
the RIB and specific RIBs and routing tables.

Joe

> 
> Thanks
> 
> Nitin
> 
> On 7/15/13 12:29 PM, "[email-masked]" <[email-masked]>
> wrote:
> 
>>
>> A new version of I-D, draft-nitinb-i2rs-rib-info-model-01.txt
>> has been successfully submitted by Nitin Bahadur and posted to the
>> IETF repository.
>>
>> Filename:	 draft-nitinb-i2rs-rib-info-model
>> Revision:	 01
>> Title:		 Routing Information Base Info Model
>> Creation date:	 2013-07-15
>> Group:		 Individual Submission
>> Number of pages: 24
>> URL:             
>> http://www.ietf.org/internet-drafts/draft-nitinb-i2rs-rib-info-model-01.tx
>> t
>> Status:          
>> http://datatracker.ietf.org/doc/draft-nitinb-i2rs-rib-info-model
>> Htmlized:        
>> http://tools.ietf.org/html/draft-nitinb-i2rs-rib-info-model-01
>> Diff:            
>> http://www.ietf.org/rfcdiff?url2=draft-nitinb-i2rs-rib-info-model-01
>>
>> Abstract:
>>   Routing and routing functions in enterprise and carrier networks are
>>   typically performed by network devices (routers and switches) using a
>>   routing information base (RIB).  Protocols and configuration push
>>   data into the RIB and the RIB manager install state into the
>>   hardware; for packet forwarding.  This draft specifies an information
>>   model for the RIB to enable defining a standardized data model.  Such
>>   a data model can be used to define an interface to the RIB from an
>>   entity that may even be external to the network device.  This
>>   interface can be used to support new use-cases being defined by the
>>   IETF I2RS WG.
>>
>>                  
>>        
>>
>>
>> The IETF Secretariat
>>
>>
>>
> 
> 
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
> 

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 14 Aug 2013 02:19:43 +0000

Hi Joe,

   Please see inline below for responses.

>to be a MUST and there is evidence in a later section supporting this.

Agreed. Fixed.

>in your RBNF in Section 6.

See comment below.

>examples listed here would be mandatory?

Notifications section is the least developed so far. Yes, we need to
specify what the contents of notifications should be and what
notifications must/should be supported.

>addresses but route prefixes (the next-hop is an address)

Fair point. Updated draft along the lines of:

<ipv4-route> ::= <ipv4-prefix> [<multicast-source-ipv4-address>]
<ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_ADDRESS_LENGTH>

>client to request data in bulk.

Yes. Added text towards that.

>implies that in Section 4, this should be a MUST as well.

Yes updated.

>the events (and, in fact, within Cisco we offer this kind of granular

Yes you could define a decent pub-sub model to limit the amount of data
transmitted and for efficiency reasons.

>JMC: Should you also add authorized in addition to authenticated?

Added.

Thanks
Nitin

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 14 Aug 2013 18:47:12 -0400

>    Please see inline below for responses.

Blanket thanks for the attention and adoption of comments, Nitin.

Joe