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
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
