Re: [RTG-DIR] Routing directorate QA review of draft-ietf-i2rs-yang-l3-topology

[Tony Przygienda <[e-mail]>]

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