[OPSAWG] TR: New Version Notification for draft-ietf-opsawg-model-automation-framework-03.txt
Hi all, We updated the draft with many edits to enhance the readability of the document. We also made two major changes: * Update the security section * Make it clear what modules are still missing for operating VPN services (see Figure 6) and companion text in particular. With these fixes, we think that the draft is ready for the WGLC. Cheer, Med -Message d'origine- De : internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Envoyé : jeudi 28 mai 2020 09:02 À : Liang Geng; BOUCADAIR Mohamed TGI/OLN; Diego Lopez; Qin Wu; Diego R. Lopez; Qin WU; Chongfeng Xie Objet : New Version Notification for draft-ietf-opsawg-model-automation-framework-03.txt A new version of I-D, draft-ietf-opsawg-model-automation-framework-03.txt has been successfully submitted by Mohamed Boucadair and posted to the IETF repository. Name: draft-ietf-opsawg-model-automation-framework Revision: 03 Title: A Framework for Automating Service and Network Management with YANG Document date: 2020-05-28 Group: opsawg Pages: 38 URL: https://www.ietf.org/internet-drafts/draft-ietf-opsawg-model-automation-framework-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-03 Abstract: Data models for service and network management provides a programmatic approach for representing services or networks and deriving (1) configuration information that will be communicated to network and service components that are used to build and deliver the service and (2) state information that will be monitored and tracked. Indeed, data models can be used during various phases of the service and network management life cycle, such as service instantiation, provisioning, optimization, monitoring, diagnostic, and assurance. Also, data models are instrumental in the automation of network management. They also provide closed-loop control for the sake of adaptive and deterministic service creation, delivery, and maintenance. This document describes an architecture for service and network management automation that takes advantage of YANG modeling technologies. This architecture is drawn from a network provider perspective irrespective of the origin of a data module; it can thus accommodate modules that are developed outside the IETF. The document aims in particular to exemplify an approach that specifies the journey from technology-agnostic services to technology-specific actions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
Tom, The difficulties with layer0-types were due to the complexity of the technology we were trying to model. Having a common layer0-types has actually helped a lot since only one module (the layer0-types) had to go through "several revolutions" instead of the six modules which depends on it. There were also some technical issues in one draft which were discovered by people working on other draft only after the code was moved to the layer0-types. This helped at least to discover the issues earlier in the process. Italo > -Original Message- > From: tom petch [mailto:ie...@btconnect.com] > Sent: venerdì 29 maggio 2020 12:48 > To: Italo Busi ; adr...@olddog.co.uk; 'Joe Clarke > (jclarke)' ; 'Oscar González de Dios' > > Cc: 'opsawg' > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > From: Italo Busi > Sent: 29 May 2020 08:56 > > I support developing a separate module for the common types/groupings/... > > This approach has worked quite well within TEAS and CCAMP WG. > > I agree that there are some risks with this work: my suggestion is just be > aware > of the risks and be careful to avoid them. > > Working in parallel on L3NM, L2NM and the common modules would really > help identifying what is really common and what it is not. > > The suggestion we have got in CCAMP WG was not to send to IESG the > common module alone but to send it with at least one of the modules > importing it. > > I would suggest to follow the same approach in OPSWG if a separate module > for the common types/groupings/... is developed. > > > I asked what the four documents were since AFAICT two are published RFC, > and that has been confirmed. So what is going to happen to those RFC? > > And as you will know from CCAMP, layer0 types has undergone several > revolutions before getting to its current state. These common identity etc > are > hard to get right in the IETF. > > Tom Petch > > Italo > > > -Original Message- > > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > > Sent: giovedì 28 maggio 2020 19:15 > > To: 'tom petch' ; 'Joe Clarke (jclarke)' > > ; 'Oscar González de Dios' > > > > Cc: 'opsawg' > > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > > > OK, thanks, that's clear. > > > > I *think* (I was on the call where this was discussed) that it was > > exactly the worry about importing a whole module that led to the > > suggestion of having a separate module just for common types. As I > > understand it, there was a desire to have a common type used in > > several modules, but some implementers felt that this would lead them > > to have to import the whole module (not just the type). > > > > The idea of a separate module certainly has some risks associated: not > > capturing the right things; including too much "stuff"; forcing > > commonality where none exists. > > > > There is, as you suggest, an alternative that each module goes its own > > way and there is no sharing. I *think* we received a strong steer that > > sharing is a good idea. > > > > Best, > > Adrian > > > > -Original Message- > > From: tom petch > > Sent: 28 May 2020 17:26 > > To: 'Joe Clarke (jclarke)' ; > > 'Oscar González de Dios' ; > > adr...@olddog.co.uk > > Cc: 'opsawg' > > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > > > From: Adrian Farrel > > Sent: 28 May 2020 14:29 > > > > Hey Tom, > > > > Is there a typo in your email? You said... > > > > > So carving out the current types (etc) will likely lead to a bad > > > outcome; it is a question of looking carefully across the range of > > > documents to see what is, or is likely to be common. > > > > I wondered whether you intended a "not" in there somewhere. > > > > > > Adrian, > > no, no 'not' was intended. The danger is taking e.g. the 50 or so > > pages of identity, typedef, grouping in L2NM and assuming that they > > form a good starting point or, worse still, making a logical OR of the > > four documents under consideration and to create a monster document > > and assuming that that is a good basis. > > > > Critical assessment is what is needed IMHO. Sometimes it is better to > > create your own version of vpn-id or ODUC than import a hundred pages > > of someone else's in order to get them. > > > > Tom Petch > > > > If you wrote what you intended, could you explain a little further > > what the danger is? > > > > Best, > > Adrian > > > > -Original Message- > > From: OPSAWG On Behalf Of tom petch > > Sent: 26 May 2020 17:05 > > To: Joe Clarke (jclarke) ; Oscar > > González de Dios > > Cc: opsawg > > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > > > From: OPSAWG on behalf of Joe Clarke > > (jclarke) > > Sent: 21 May 2020 15:43 > > > > > > > > 2. L3NM > > Revision of the three main issues: > > Implementation Report by Cisco. It has two main issues > > (https://github.com/IETF-OPSAWG-WG/l3nm/issues/110) > > - Common module to have all the L3NM specific
Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
> I asked what the four documents were since AFAICT two are published > RFC, and that has been confirmed. So what is going to happen to those > RFC? My proposal (but who am I to say what will actually happen) was: - step one: nothing The new module is shaped as it would have been had it been created before those RFCs were made - step two: putatively never happening If those RFCs are respun at any time, they could make use of the new module Best, Adrian ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
From: Italo Busi Sent: 29 May 2020 08:56 I support developing a separate module for the common types/groupings/... This approach has worked quite well within TEAS and CCAMP WG. I agree that there are some risks with this work: my suggestion is just be aware of the risks and be careful to avoid them. Working in parallel on L3NM, L2NM and the common modules would really help identifying what is really common and what it is not. The suggestion we have got in CCAMP WG was not to send to IESG the common module alone but to send it with at least one of the modules importing it. I would suggest to follow the same approach in OPSWG if a separate module for the common types/groupings/... is developed. I asked what the four documents were since AFAICT two are published RFC, and that has been confirmed. So what is going to happen to those RFC? And as you will know from CCAMP, layer0 types has undergone several revolutions before getting to its current state. These common identity etc are hard to get right in the IETF. Tom Petch Italo > -Original Message- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: giovedì 28 maggio 2020 19:15 > To: 'tom petch' ; 'Joe Clarke (jclarke)' > ; 'Oscar González de Dios' > > Cc: 'opsawg' > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > OK, thanks, that's clear. > > I *think* (I was on the call where this was discussed) that it was exactly the > worry about importing a whole module that led to the suggestion of having a > separate module just for common types. As I understand it, there was a desire > to have a common type used in several modules, but some implementers felt > that this would lead them to have to import the whole module (not just the > type). > > The idea of a separate module certainly has some risks associated: not > capturing the right things; including too much "stuff"; forcing commonality > where none exists. > > There is, as you suggest, an alternative that each module goes its own way and > there is no sharing. I *think* we received a strong steer that sharing is a > good > idea. > > Best, > Adrian > > -Original Message- > From: tom petch > Sent: 28 May 2020 17:26 > To: 'Joe Clarke (jclarke)' ; 'Oscar > González de Dios' ; > adr...@olddog.co.uk > Cc: 'opsawg' > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > From: Adrian Farrel > Sent: 28 May 2020 14:29 > > Hey Tom, > > Is there a typo in your email? You said... > > > So carving out the current types (etc) will likely lead to a bad > > outcome; it is a question of looking carefully across the range of > > documents to see what is, or is likely to be common. > > I wondered whether you intended a "not" in there somewhere. > > > Adrian, > no, no 'not' was intended. The danger is taking e.g. the 50 or so pages of > identity, typedef, grouping in L2NM and assuming that they form a good > starting point or, worse still, making a logical OR of the four documents > under > consideration and to create a monster document and assuming that that is a > good basis. > > Critical assessment is what is needed IMHO. Sometimes it is better to create > your own version of vpn-id or ODUC than import a hundred pages of someone > else's in order to get them. > > Tom Petch > > If you wrote what you intended, could you explain a little further what the > danger is? > > Best, > Adrian > > -Original Message- > From: OPSAWG On Behalf Of tom petch > Sent: 26 May 2020 17:05 > To: Joe Clarke (jclarke) ; Oscar González > de Dios > Cc: opsawg > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > From: OPSAWG on behalf of Joe Clarke (jclarke) > > Sent: 21 May 2020 15:43 > > > > 2. L3NM > Revision of the three main issues: > Implementation Report by Cisco. It has two main issues > (https://github.com/IETF-OPSAWG-WG/l3nm/issues/110) > - Common module to have all the L3NM specific requirements. Type-like > module. > [Anton]: It makes implementation simpler. Does not generate unnecessary > dependencies > [Adrian]: It depends on if we need module for specific types, to avoid > unnecessary imports. Also don't you only need to import types, not the entire > module? > [Qin]: With L3SM we did not take an augmentation approach. If there are > common types defined in both models, then we may need to find the common > components. We should decouple of L3SM. > [Sriram]: Prefer to have a separate type-file for the specific parameters. > [Oscar]: Define a common type-file for the service models. > [Qin]: Is it possible to manage it as an independent draft? > > [Oscar in github issues]: After the discussions, it seems reasonable to have a > separate Yang module to contain the types. The suggestion is to write the > module to cover the four service models (client service models, l3sm, l2sm and > Network service models, l2nm, l3nm). It seems reasonable to include this > module in l3nm draft instead of creating a new one to avoid dependencies.
Re: [OPSAWG] Shepherd review of draft-ietf-opsawg-tacacs-yang
Hi Joe, Many thanks for the review. I will correct the errors in the -06 revision. Thanks, Bo -邮件原件- 发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Joe Clarke (jclarke) 发送时间: 2020年5月28日 22:52 收件人: opsawg 主题: [OPSAWG] Shepherd review of draft-ietf-opsawg-tacacs-yang I have completed my first draft of the shepherd write-up of this document. In the abstract I noticed it says that this document defines “YANG modules” when it only defines “a YANG module” now. Can text referring to the plural modules be updated? Also, any other review of the write-up would be appreciated. https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/shepherdwriteup/ Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
Hi all, I support developing a separate module for the common types/groupings/... This approach has worked quite well within TEAS and CCAMP WG. I agree that there are some risks with this work: my suggestion is just be aware of the risks and be careful to avoid them. Working in parallel on L3NM, L2NM and the common modules would really help identifying what is really common and what it is not. The suggestion we have got in CCAMP WG was not to send to IESG the common module alone but to send it with at least one of the modules importing it. I would suggest to follow the same approach in OPSWG if a separate module for the common types/groupings/... is developed. Italo > -Original Message- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: giovedì 28 maggio 2020 19:15 > To: 'tom petch' ; 'Joe Clarke (jclarke)' > ; 'Oscar González de Dios' > > Cc: 'opsawg' > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > OK, thanks, that's clear. > > I *think* (I was on the call where this was discussed) that it was exactly the > worry about importing a whole module that led to the suggestion of having a > separate module just for common types. As I understand it, there was a desire > to have a common type used in several modules, but some implementers felt > that this would lead them to have to import the whole module (not just the > type). > > The idea of a separate module certainly has some risks associated: not > capturing the right things; including too much "stuff"; forcing commonality > where none exists. > > There is, as you suggest, an alternative that each module goes its own way and > there is no sharing. I *think* we received a strong steer that sharing is a > good > idea. > > Best, > Adrian > > -Original Message- > From: tom petch > Sent: 28 May 2020 17:26 > To: 'Joe Clarke (jclarke)' ; 'Oscar > González de Dios' ; > adr...@olddog.co.uk > Cc: 'opsawg' > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > From: Adrian Farrel > Sent: 28 May 2020 14:29 > > Hey Tom, > > Is there a typo in your email? You said... > > > So carving out the current types (etc) will likely lead to a bad > > outcome; it is a question of looking carefully across the range of > > documents to see what is, or is likely to be common. > > I wondered whether you intended a "not" in there somewhere. > > > Adrian, > no, no 'not' was intended. The danger is taking e.g. the 50 or so pages of > identity, typedef, grouping in L2NM and assuming that they form a good > starting point or, worse still, making a logical OR of the four documents > under > consideration and to create a monster document and assuming that that is a > good basis. > > Critical assessment is what is needed IMHO. Sometimes it is better to create > your own version of vpn-id or ODUC than import a hundred pages of someone > else's in order to get them. > > Tom Petch > > If you wrote what you intended, could you explain a little further what the > danger is? > > Best, > Adrian > > -Original Message- > From: OPSAWG On Behalf Of tom petch > Sent: 26 May 2020 17:05 > To: Joe Clarke (jclarke) ; Oscar González > de Dios > Cc: opsawg > Subject: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions > > From: OPSAWG on behalf of Joe Clarke (jclarke) > > Sent: 21 May 2020 15:43 > > > > 2. L3NM > Revision of the three main issues: > Implementation Report by Cisco. It has two main issues > (https://github.com/IETF-OPSAWG-WG/l3nm/issues/110) > - Common module to have all the L3NM specific requirements. Type-like > module. > [Anton]: It makes implementation simpler. Does not generate unnecessary > dependencies > [Adrian]: It depends on if we need module for specific types, to avoid > unnecessary imports. Also don't you only need to import types, not the entire > module? > [Qin]: With L3SM we did not take an augmentation approach. If there are > common types defined in both models, then we may need to find the common > components. We should decouple of L3SM. > [Sriram]: Prefer to have a separate type-file for the specific parameters. > [Oscar]: Define a common type-file for the service models. > [Qin]: Is it possible to manage it as an independent draft? > > [Oscar in github issues]: After the discussions, it seems reasonable to have a > separate Yang module to contain the types. The suggestion is to write the > module to cover the four service models (client service models, l3sm, l2sm and > Network service models, l2nm, l3nm). It seems reasonable to include this > module in l3nm draft instead of creating a new one to avoid dependencies. > Samier, Dan and Anton to collaborate for a first version of the split > > As chair, I want to call this out since it sounds like the authors made a > decision > here, and I want to make sure the whole WG has a chance to weigh in. In > reading these minutes and issue #110, I can see the value of a types module to > avoid what may be confusing
