Re: [i2rs] OPS-DIR review of draft-ietf-i2rs-yang-l3-topology-10

[Hariharan Ananthakrishnan <[e-mail]>]

Hi Ignas,

Thanks for the review. We have updated the draft addressing your review comments. The multi-topology references have been removed and example OSPF topology has been moved to appendix. We also removed the ISIS example. The intended use of this model is to provide a L3 Unicast topology model. The topology related use cases are defined in section 6 of draft-i2rs-usecase-reqs-summary.

Thanks,
Hari, Alex, Jan, Xufeng, Nitin, Robert

- Hari

On 26/07/2017, 08:13, "Ignas Bagdonas" <[e-mail]> wrote:

    Hi there,
    
    I have been selected as OPS-DIR reviewer for this document.
    
    Document: draft-ietf-i2rs-yang-l3-topology-10
    
    Reviewer: Ignas Bagdonas
    
    Review result: Has issues.
    
    
    Major question that I get after reading this document is on how the 
    proposed model would be used and provide practically useful topology 
    abstraction interface, especially in the context of multitopology 
    routing. The document covers multitopology as augmentation to L3 unicast 
    topology model, and this exposes per-protocol MT specifics, which seems 
    to fall exactly opposite to the intention of the document to provide 
    abstracted topology view. MT topology view is a subset of protocol 
    specific topology plus it can contain routes coming from other sources 
    too, and the model approach specified in this document does not seem to 
    allow for expressing such constructs. One practical use case is 
    multicast RPF lookup control, typically that is an IGP MT view plus 
    local override routes, typically statically injected. For this use case 
    the model described would require the topology to be strictly coming 
    from a single IGP source, either IS-IS or OSPF, with no ability to 
    intermix both, and with no ability to represent routes external to IS-IS 
    or OSPF topology sources. Having separate models for IS-IS and OPSF for 
    augmenting the base L3 topology model does not allow for hiding the 
    differences in representation of IS-IS and OSPF derived topology 
    aspects, in particular the MT identifiers. For the user this would 
    require to know which one of the IGPs is used instead of getting just 
    the specific topology view regardless of what are the underlying 
    topology sources. What is the intended use of this model then - is it on 
    providing interface to protocol specific topology (which then raises a 
    question on how it correlates to protocol specific models' operational 
    part, and section 1 second paragraph mentions precisely that), or is it 
    on providing routing information source independent interface to 
    topology? As a summary, the document would benefit from operational 
    considerations section that would explain the intended use of this model 
    and how it correlates and interworks with IGP specific models. Without a 
    clear answer where the model is positioned it is difficult to provide 
    more detailed review on the model structure itself.
    
    Metrics being a single uint32 value - that may not be flexible enough to 
    represent realistic scenarios where a topology instance may have 
    different routing information sources with incompatible or incomparable 
    metrics. At least two independent metric components would be needed for 
    that.
    
    
    Nits:
    
    Title page has 6 authors listed.
    
    Are Xufeng's contact details correct?
    
    s/Netconf/NETCONF
    
    s/Parantheses/Parentheses
    
    NET-id, NET Id should all be NET
    
    ISIS model has a reference to OSPF MT RFC.
    
    ISIS model for multi-topology-id has max-elements "128" limit. MT TLV 
    can be repeated and thus a larger number of topology ids can be signalled.
    
    s/paper/document
    
    
    Overall the document would benefit from grammar check. Abstract, 
    Introduction, and Overview sections contain quite much of repetitive text.
    
    
    Thank you.
    
    Ignas