Re: [OPSAWG] AD review for draft-ietf-opsawg-model-automation-framework-04

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Med,

Thanks for the final updates.  I've requested IETF LC on -06.

Regards,
Rob


> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: 21 September 2020 09:12
> To: Rob Wilton (rwilton) <[e-mail]>; opsawg <[e-mail]>
> Cc: [e-mail]
> Subject: RE: AD review for draft-ietf-opsawg-model-automation-framework-04
> 
> Hi Bob,
> 
> Thank you for double checking.
> 
> I confirm that your initial AD review message I received was truncated
> (see attached).
> 
> Will update the draft to take into account the missing part.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Rob Wilton (rwilton) [mailto:[e-mail]]
> > Envoyé : vendredi 18 septembre 2020 19:21
> > À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; opsawg
> > <[e-mail]>
> > Cc : [e-mail]
> > Objet : RE: AD review for draft-ietf-opsawg-model-automation-
> > framework-04
> >
> > Hi Med,
> >
> > The changes that you have made look good.  But I had some comments
> > at the end of my review email that it doesn't look like you have
> > responded to, or actioned.  Hence, I'm wondering if my review email
> > might have been truncated, or the end of it missed (from "Also, I
> > ...") onwards (copied below).
> >
> >
> > A.3.1.1.  Schema Mount
> >
> >    That capability does not cover design time.
> >
> > This sentence is unclear on its own.  Perhaps either expand it or
> > remove it.
> >
> > Also, I wouldn't regard schema mount as necessarily being specific
> > to device models, and could be used for network and service YANG
> > models as well.  Although there may not be a good place to put it.
> >
> > 14.
> > A.3.2.  Device Models: Samples
> >
> > As above, having a section for interfaces/interface management would
> > be useful.  I also think think it would be good to have a section
> > for device management (e.g. system, nacm)
> >
> > I would potentially reorder the list of modules:
> >    - Move Core Routing up, near the top of the list (above BGP)
> >    - L2VPN (next to) but before EVPN
> >    - Perhaps move BGP down, and having routing policy next to it
> > might be helpful
> >    - NAT and Stateless Address Sharing could perhaps move down.
> >
> >
> > Editorial nits to check:
> >
> > 1. Network Operator -> network operator?
> > 2. Perhaps "it can accommodate modules" -> "it can also accommodate
> > modules"?
> > 3. "follow top-down approach" -> "follow a top-down approach"
> > 4. "validated during the implementation time" -> "validated during
> > implementation"
> > 5. For Diagram A2, possibly could have just used the full names and
> > not requried the legend.
> > 6. "[RFC8345] with TE topologies specifics." -> "[RFC8345] with TE
> > topology related content."
> > 7. "Network Topology Models" -> Network Topologies Model"?
> > 8. "TE Topology Models" => "TE Topology Model"?
> > 9. "Layer 3 Topology Models:" -> "Layer 3 Topology Model:"
> > 10. "Layer 3 topologies specifics" -> "Layer 3 topology specifics"
> > 11. "Layer 2 Topology Models:" -> "Layer 2 Topology Model:"
> > 12. "Layer 2 topologies specifics" -> "Layer 2 topology specifics"
> > 13. Figure 4: "Config Validate" -> "Config Validation", and realign
> > "Monitoring"
> >
> > Please can you check?
> >
> > Regards,
> > Rob
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] <[e-mail]>
> > > Sent: 08 September 2020 13:28
> > > To: Rob Wilton (rwilton) <[e-mail]>; opsawg
> > <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: RE: AD review for
> > > draft-ietf-opsawg-model-automation-framework-04
> > >
> > > Rob,
> > >
> > > FWIW, an updated version with changes to address your review is
> > > available
> > > online:
> > >
> > > URL:            https://www.ietf.org/id/draft-ietf-opsawg-model-
> > > automation-framework-05.txt
> > > Status:         https://datatracker.ietf.org/doc/draft-ietf-
> > opsawg-model-
> > > automation-framework/
> > > Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-
> > opsawg-
> > > model-automation-framework
> > > Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-
> > model-
> > > automation-framework-05
> > > Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-
> > opsawg-model-
> > > automation-framework-05
> > >
> > > Please let us know if any of your comments is still pending. Thank
> > you.
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : [e-mail]
> > > > [mailto:[e-mail]]
> > > > Envoyé : lundi 7 septembre 2020 16:35 À : Rob Wilton (rwilton)
> > > > <[e-mail]>; opsawg <[e-mail]> Cc :
> > > > [e-mail]
> > > > Objet : RE: AD review for draft-ietf-opsawg-model-automation-
> > > > framework-04
> > > >
> > > > Hi Rob,
> > > >
> > > > Thank you for the detailed review.
> > > >
> > > > Please see inline.
> > > >
> > > > I let my co-authors further comment.
> > > >
> > > > Cheers,
> > > > Med
> > > >
> > > > > -----Message d'origine-----
> > > > > De : Rob Wilton (rwilton) [mailto:[e-mail]] Envoyé :
> > > > vendredi
> > > > > 4 septembre 2020 19:22 À : opsawg <[e-mail]>;
> > > > > draft-ietf-opsawg-model-automation-
> > > > > [e-mail]
> > > > > Objet : AD review for
> > > > > draft-ietf-opsawg-model-automation-framework-
> > > > 04
> > > > >
> > > > > Apologies for the lengthy delay in performing the AD review.
> > > > >
> > > > > I found that this document to be well written so I would like
> > to
> > > > thank
> > > > > the authors, WG, and doc shepherd for that.  My more
> > significant
> > > > > comments relate to questions on the scope of this
> > architecture.
> > > > >
> > > > >
> > > > > More significant comments:
> > > > >
> > > > > 1. By "Data Model" does this document mean "YANG data model"?
> > And
> > > > if
> > > > > so, does it take this meaning all through this document, or
> > only
> > > > some
> > > > > of the time?
> > > > >
> > > >
> > > > [Med] "Data Model" is used as a generic term as per
> > rfc3444#section-4.
> > > > We are using "YANG data models" or "YANG module" when we wanted
> > to
> > > > be more specific about the DM flavour.
> > > >
> > > > I double checked the text to make sure this is consistently used
> > > > along the document. Updated some occurrences in the text where
> > the
> > > > use of "YANG data model" is more accurate.
> > > >
> > > > > 2. Generically, service data models are not necessarily
> > written in
> > > > > YANG (e.g., I think that MEF are defining them using OpenAPI).
> > > > > So, related to (1), is this architecture intended to be tied
> > to
> > > > > only service models defined in YANG, or be more broadly
> > applicable?
> > > >
> > > > [Med] We don't require the service models to be YANG-modelled
> > (see
> > > > for instance the example depicted in Figure 2). That's said, the
> > use
> > > > of YANG in all levels would ease mapping operations.
> > > >
> > > > >
> > > > > 3. This architecture seems to quite strictly represent 3
> > layers
> > > > > (service, network, device).  Does it envisage that these
> > layers
> > > > > may themselves be deconstructed?  E.g. a customer service can
> > be
> > > > > constructed from underlying services
> > > >
> > > > [Med] Yes, that's not excluded. The architecture can be
> > "recursive"
> > > > (Such as rfc8597#section-3.1.3).
> > > >
> > > >  (e.g., as discussed in section
> > > > > 3.1, but more as an East-West relationship).  Similarly,
> > device
> > > > models
> > > > > could also be deconstructed, e.g., if the dataplane is
> > decoupled
> > > > from
> > > > > the control plane, or if a device itself acts as a controller
> > > > managing
> > > > > other devices.
> > > >
> > > > [Med] The document does not make assumptions on the organic
> > > > structure or where the functions are provided. Having a
> > controller
> > > > co-located with other YANG-controlled functions is not excluded.
> > > >
> > > > >
> > > > > 4. My minimal understanding of the MEF LSO architecture was
> > that
> > > > they
> > > > > put quite a lot of emphasis on East-West models, probably at
> > the
> > > > > service layer. Is this effectively the same as what is
> > described
> > > > > in Figure 1 in section 3.1?
> > > >
> > > > [Med] Inter-domain interactions between two services or two
> > adjacent
> > > > networks are not shown in Figure 1. This figure focuses mainly
> > on
> > > > the interface between a service and an underlying network.
> > > >
> > > >   Does the potential existence of these East-
> > > > > West APIs need to be described in any more detail?
> > > > >
> > > >
> > > > [Med] A network can act as a "customer" and request services
> > from
> > > > other networks. The peer network will then follow the levels
> > > > depicted in the architecture. This is for example hinted in this
> > > > text for
> > > > example:
> > > >
> > > >    o  allow customers (or Network Operators) to dynamically
> > adjust the
> > > >       network resources based on service requirements as
> > described in
> > > >       Service Models (e.g., Figure 2) and the current network
> > > >       performance information described in the telemetry
> > modules.
> > > >
> > > > We can add some more text if needed.
> > > >
> > > > Section 4.3 discusses how multi-domain mapping can be handled at
> > the
> > > > server level. This assumes that the interaction is not between
> > the
> > > > domains themselves but driven by the service layer.
> > > >
> > > > >
> > > > > Minor comments/clarifications:
> > > > >
> > > > > Section 3.1: Data Models: Layering and Representation
> > > > >
> > > > > 5. Network Models are mainly network resource-facing modules;
> > they
> > > > >    describe various aspects of a network infrastructure,
> > including
> > > > >    devices and their subsystems, and relevant protocols
> > operating
> > > > > at the
> > > > >    link and network layers across multiple devices (e.g.,
> > network
> > > > >    topology and traffic-engineering tunnel modules).
> > > > >
> > > > > Would it be fair to say that Network Models might be protocol
> > > > > specific, or might be generalized?  If so, is that worth
> > mentioning?
> > > > >
> > > >
> > > > [Med] Network models may include some protocol-specific
> > parameters.
> > > > I'm neutral whether this needs to be mentioned in the text.
> > > >
> > > > >
> > > > > 6. Re: DOTS & RFC 8783, I'm not sure how well the YANG model
> > > > > defined in that drafts fits into the category of Service YANG
> > model.
> > > > >
> > > >
> > > > [Med] RFC8783 defines the filtering service requested by a
> > > > client/customers; how this request triggers the selection of the
> > > > devices that need to be configured, the exact set of ACLs, and
> > the
> > > > enforcing of the ACLs in these devices is managed by other
> > layers
> > > > (RFC8519). From that perspective, we do think that the module in
> > RFC
> > > > 8783 satisfies the following from RFC8309:
> > > >
> > > >    "Details
> > > >    included in the service model include a description of the
> > > > service as
> > > >    experienced by the customer, but not features of how that
> > service
> > > > is
> > > >    delivered or realized by the service provider. "
> > > >
> > > > > 7. Pipe vs hose vs funnel.  Are these terms, or do they need
> > to
> > > > > be, defined somewhere?  In particular it is not obvious to me
> > what
> > > > > the distinction is between pipe vs hose.
> > > >
> > > > [Med] "pipe" means that only point-to-point communications are
> > > > allowed while "hose" means that communications from one to N is
> > allowed.
> > > >
> > > > We can text to explain this.
> > > >
> > > > >
> > > > >
> > > > > In Appendix A:
> > > > > 8. Would it be useful to discuss or reference YANG Catalog (as
> > a
> > > > > source of querying YANG models), the public YANG github
> > > > > repository,
> > > > or
> > > > > YANG module tags as a method of organizing YANG models?
> > > > >
> > > >
> > > > [Med] Good point. Will consider adding some text.
> > > >
> > > > > 9.
> > > > >    o  Tunnel identities to ease manipulating extensions to
> > specific
> > > > >       tunnels [RFC8675].
> > > > >
> > > > > I found this sentence slightly unclear.  Perhaps it could be
> > > > reworded?
> > > > >
> > > >
> > > > [Med] Fair point. Updated to :
> > > >
> > > > " o  Tunnel identities: [RFC8675] defines a collection of YANG
> > > > identities used
> > > >      as interface types for tunnel interfaces."
> > > >
> > > > > 10.
> > > > >    o  Generic Policy Model:
> > > > >
> > > > >    The Simplified Use of Policy Abstractions (SUPA) policy-
> > based ...
> > > > >
> > > > > It does not like this draft is going anywhere, and I'm not
> > > > > convinced that it is really helpful to reference it here.  Or,
> > if
> > > > > it must be referenced, it should be caveated accordingly.
> > > > >
> > > >
> > > > [Med] Fair enough. I tend to agree with you.
> > > >
> > > > > 11.
> > > > > A.3.  Device Models: Samples
> > > > >
> > > > > I think that it would be helpful if this diagram, and the list
> > in
> > > > > section A3.2, had references to the interface YANG module.
> > > > >
> > > >
> > > > [Med] Point taken.
> > > >
> > > > > 12.
> > > > > A.3.1.  Model Composition
> > > > >
> > > > >    o  Device Model
> > > > >
> > > > >    [I-D.ietf-rtgwg-device-model] presents ...
> > > > >
> > > > > Again, I'm not sure that this is a helpful reference, given
> > that
> > > > > the approach defined in this draft did not gain traction, and
> > > > > instead, a more loosely coupled structure was preferred.
> > E.g., I
> > > > > see that tags (and arguably schema mount) solve this
> > > > > organizational problem in a more flexible way.
> > > > >
> > > >
> > > > [Med] Fair point.
> > > >
> > > > > 13.
> > > > > A.3.1.1.  Schema Mount
> > > > >
> > > > >    That capability does not cover design time.
> > > > >
> > > > > This sentence is unclear on its own.  Perhaps either expand it
> > or
> > > > > remove it
> > > >
> > > > [Med] OK.
> > >
> > >
> 
> __________________________________________________________________________
> _______________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.