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

From: Ignas Bagdonas <[email-masked]>
Date: Wed, 26 Jul 2017 16:13:39 +0100

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Jul 2017 13:01:13 -0400

Ignas:

Thank you for your review of the L3 Topology model.  I appreciate that you
are reviewing while many people are on vacation!  Alex Clemm should be in
touch with you shortly. 

Sue Hares 

-----Original Message-----
From: OPS-DIR [mailto:[email-masked]] On Behalf Of Ignas Bagdonas
Sent: Wednesday, July 26, 2017 11:14 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [OPS-DIR] OPS-DIR review of draft-ietf-i2rs-yang-l3-topology-10

Hi there,

Reviewer: Ignas Bagdonas

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:

s/Netconf/NETCONF

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

Thank you.

Ignas

_______________________________________________
OPS-DIR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ops-dir