Early Review of draft-ietf-i2rs-yang-l3-topology-01

Request Review of draft-ietf-i2rs-yang-l3-topology
Requested rev. no specific revision (document currently at 16)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-05-09
Requested 2016-04-25
Other Reviews Opsdir Telechat review of -08 by Ron Bonica (diff)
Secdir Telechat review of -08 by Hilarie Orman (diff)
Genart Last Call review of -08 by Paul Kyzivat (diff)
Yangdoctors Early review of -02 by Carl Moberg (diff)
Rtgdir Early review of -10 by Christian Hopps (diff)
Yangdoctors Early review of -10 by Ladislav Lhotka (diff)
Rtgdir Early review of -10 by Michael Richardson (diff)
Secdir Last Call review of -13 by Hilarie Orman (diff)
Genart Last Call review of -13 by Paul Kyzivat (diff)
Review State Completed
Reviewer Tony Przygienda
Review review-ietf-i2rs-yang-l3-topology-01-rtgdir-early-przygienda-2016-05-09
Posted at https://www.ietf.org/mail-archive/web/rtg-dir/current/msg02912.html
Reviewed rev. 01 (document currently at 16)
Review result Has Issues
Draft last updated 2016-05-09
Review completed: 2016-05-09


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 


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. 




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.



-- tony