Re: [i2rs] Opsdir early review of draft-ietf-i2rs-rib-info-model-12

[Nitin Bahadur <[e-mail]>]

Hi Mahesh,

 Please see NB> below for comments to how I’m looking to address your concerns.

Section 2.
    
    Figure 2 shows the RIB model. By putting it where it is, I would have expected
    that all the elements of the diagram would be explained in that section. One
    has to read section 2.1 and 2.2 to figure the details.

NB> RIB model is very complex and putting everything under the overall Section 2 would be more confusing. Everything related to the RIB model is in Section 2 and it’s sub-sections. I am not sure how you would like that re-organized. The figure is put first so that when people read the sub-sections they can mentally place where those pieces fit together in the puzzle.
    
    Even then it is difficult to comprehend by reading all sections what the
    diagram is trying to convey. First of all, it appears that there can be
    multiple routing instances

but the diagram refers to one routing instance. If
    the idea is to refer to one routing instance in the RIB model, then as the name
    suggests, it is not the RIB model, but one routing instance of the RIB model.
    Either change the name or show the diagram with multiple instances.

NB> Yes, there can be many routing instances. Text will be clarified to reflect that and the figure will be updated.
    
    Also if each RIB consists of 0..N routes, that is not clear from the diagram.
    It appears that each routing-instance has 1..N RIBs and 0..N routes with no
    relationship to each other.

NB> Fixed. Each RIB can contain 0..N routes

    Section 2.3
    
    Similarly for Figure 3, the diagram is in section 2.3, but if one has to
    understand the diagram, one has to read section 2.4 to understand the diagram.

NB> I’ve added a reference to Section 2.4 in Section 2.3. Section 2.3 will balloon to a huge size if I merge 2.3 and 2.4 together. Readability and referencing from later sections will be terrible.
    
    Figure 3 shows the route model. It specifies 6 match conditions, but shows only
    5 in the diagram. What happened to IP multicast match?
    
NB> Awesome catch! Fixing it. There should be only 5 match conditions. IP mcast is a special case that can be accomplished using other match conditions (as specified later in the grammar).

    Section 2.4
    
    Figure 4 is titled Nexthop model. There is no explanation of the figure in
    Section 2.4 and what the different pieces of the diagram mean. Instead, it
    talks about how nexthop points to a BGP peer, a reference which is not clear by
    looking at the diagram.

NB> Last part of Section 2.4 was indeed crummy and incoherent. Fixing it.
    
    I would have expected at least an explanation of the rest of the diagram. The
    next section gets into Nexthop types, with no apparent ties to the diagram.

NB> Section being updated.

    
    Section 3 and 4.
    
    There is a lot of common text between the two sections. I do not know if there
    is a way to combine it.

NB> First paragraph of both sections is common. Rest is dis-similar. I looked at it twice, but could not come up with a clean way of avoiding duplication ☹
    
    There is no word like modify-able or even modifiable. s/are modify-able
    objects/can be modified/
    
NB> Fixed

    Section 6. RIB grammar
    
    The section says the grammar is intended to help the reader better understand
    the english text description. But it then goes on to say that if there is lack
    of clarify in the grammar the english text will take precedence. So what gives
    - english text or grammar?
    
    Also where is the english text?
 
NB> Those wordings are being fixed.

Thanks
Nitin