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