Re: [OPSAWG] Implementation report: ietf-l3vpn-ntw.yang Service Model

[tom petch <[e-mail]>]

From: OPSAWG <[e-mail]> on behalf of Roque Gagliano (rogaglia) <rogaglia=[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/opsawg