From: OPSAWG <[email protected]> on behalf of Roque Gagliano (rogaglia)
<[email protected]>
Sent: 09 May 2020 16:08
Hello,
I implemented the “draft-ietf-opsawg-l3sm-l3nm-03” (Revision 2020-04-03) on
Cisco NSO and Cisco Crosswork Network Controller. I am happy to fill any forms
(sorry but new to the WG).
The good news is that I did not find any syntax problem and was able to compile
and implement the full model.
I do have two on this new version for the WG:
1) Major: Why importing the "ietf-l3vpn-svc" module?
I think this is a major problem as it violates the architecture in Section 4
and the note in section 5 that states: "Note that the use of L3NM within a
Service Provider does assume nor preclude exposing the VPN service via L3SM.".
If there is no dependencies with L3SM, we should not force the network
controller to support it, neither its libraries. I noted that the SVC data
model is mainly important to have a common library of types, identities and
features. However, the correct implementation would be a separate YANG module
for these libraries that both L3SM and L3NM import from.
<tp>
Well there are dependencies as you state, that a raft of feature and identity
are referenced from the imported module; earlier versions of l3sm-l3nm did not
do this. It is typical of the way the IETF works, of the nature of Working
Groups, that a better arrangement of the work is not considered until too
late. It is absurd, really, that a L3SM finds itself defining a list of
topologies, a list of routing protocols and so on. RFC8299 did not AFAIK come
out of a Working Group; I knew of the I-D, draft-wu-... waited for a WG to
adopt it and then the RFC just appeared; too late to change it. To me it is
dead obvious that it should not be a single monolithic module, it should have
been divided up. But even within a WG it is a struggle to get defined a set of
building blocks which other work can build on, as has happened in a number of
WG. The definition of YANG types in CCAMP and TEAS comes to mind.
So, is it worth creating such building blocks in this case? Trouble is, they
cut across WG, there is no obvious home for them, nowhere to come to agreement
on what they should be
Tom Petch
All in all, importing the SVC module breaks the separation between the two
layers. If we would like to re-use types, identities, features definitions, a
separate module for them should be defined.
2) Minor: RD Semantic:
The document proposes:
leaf rd {
type union {
type rt-types:route-distinguisher;
type empty;
}
}
Leafs have an implicit empty state (unless you use the default
statement) but the authors are trying to give a specific meaning to the empty
state by using a union statement. I believe a much natural representation would
be:
leaf rd {
type rt-types:route-distinguisher;
}
leaf auto-assign-rd {
when "not(../rd)";
type boolean;
}
Regards,
Roque
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
