Early Review of draft-ietf-i2rs-yang-l3-topology-01
review-ietf-i2rs-yang-l3-topology-01-rtgdir-early-przygienda-2016-05-09-00

I was requested as part of the routing directorate to provide a QA review for 
draft-ietf-i2rs-yang-l3-topology-01. I give my input assuming the wider angle
of the complete yang-topology work in i2rs

first

since this specific draft is just an extension of it. I follow this up by
examples of detailed technical concerns/work items I found.

To start off with a wider angle:



Overall, the draft seems a bit hard to follow as far as the use-case
correlation goes in several aspects (I admit there are valid use-cases for this
draft but between the i2rs-usecase and l3-topology drafts they are not easy to
detect/understand). In more detail:

i)      draft-ietf-i2rs-usecase-reqs-summary-02 provides no clear, hard
rationale for having an l3-topology draft in i2rs in this form IMO. There are
some requirements about “IGP node failure for faster detection” but l3-topology
draft does not cover any clear use-cases in section 6 as claimed, neither in
e.g. Section 6.1 (VC) nor 6.3 (where e.g. Topo-REQ-01 seems to have been
miswritten?). Further, the model does not include IGP low level elements like
LSAs, statistics or any of the things required for the PCE/SFC use cases (such
as protection types, prefixes, admin groups) or ultimately things desired in
section 4 of draft-ietf-i2rs-usecase-reqs-summary-02. The draft  omits so much
information that it can be used to maybe ‘high-level share’ topology info but
not for computations relating to detailed IGP IGP forwarding computation
decisions (e.g. overload bits or capabilities are omitted). A clear, detailed
use example introduced in the draft could go a long way to improve things.  In
comparison, when looking @ the i2rs drafts related to it, I cannot clearly
delineate WHICH type of information is supposed to be contained in the topology
draft and which in auto drafts. To give a specific example the draft
teas-te-topology seems to be in an excellent shape and have a clear purpose in
life, draft-i2rs-yang-l3 and draft-i2rs-yang-l2 leave the impression of being
unclear in scope and intended use-cases.

ii)     it would be beneficial to mention that BGP-LS is providing the superset
of the information contained in this draft (albeit not as a “model”) in a
standardized fashion already. RFC 7752 has been published on standards track
and is being deployed @ a quick rate. IMO the l3-topology draft could do a
better job delineating the use-cases it will serve from the ones covered by
BGP-LS already or describes the expected overlap.

iii)

For the suggested models to work well a strong support for Yang push is needed.
The network topology draft is mentioning Yang push and obviously restconf
exists but both were not seeing the necessary amount of contributions in IETF
or implementations IMO.

Smaller angle (examples of detailed technical concerns):

I see tons of information missing in the draft which IGPs carry and need to be
conveyed to understand WHAT IGPs actually do and I don’t see a clear
indications whether it’s intentional or will be remedied and to which extent
(again, without a clear use case correlation it’s hard to decide WHAT needs to
be in). To give couple random examples:

i)       Prefix metrics: where is I/E which is very important, otherwise the
metrics are not comparable?  I know that “flags” can be claimed to cover
everything in the future but the flags need to be described for the
implementations to interoperate.

ii)      I do not find things like overload bits, capabilities & so on that
determine how the information is being used and whether e.g. the node/link even
participates in control and/or data plane.

iii)      A node can be ABR (in multiple areas) and ASBR @ same time while it
can be only one of 1 or 2 or 1-2 in ISIS (historically expressed like this
while it could be considered as a logical combination of both as well). The
model does not capture that as far I saw. Both things look the same while ISIS
node type should be an enum probably.

iv)       Multi-topology ID in ISIS is 12 bits.

v)       Overload/colors/admin tags/ TE metrics and many other things are
missing while e.g. topology ID is included. Again, the delineation between TE
draft and topology drafts does not seem clear to me.



Overall, I do think that a l3 topology draft is necessary but its purpose is
not explained clearly enough. With that it is non-obvious which
topology/node/link information it needs to ultimately carry. I would encourage
the WG/authors to correlate the draft clearly with use cases and even better,
usage examples and explain why/when BGP-LS will not meet those use-cases. It
will be then necessary to subject the draft to the scrutiny of OSPF/ISIS
experts which will make sure that it contains a set of information that allows
the client of such a model the derivation of conclusions to meet the  intended
use cases. If these models are to progress successfully and enjoy wide
acceptance I recommend a stronger focus at area director level given to the
yang push model work.



thanks

-- tony