[OPSAWG] I-D Action: draft-ietf-opsawg-yang-vpn-service-pm-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : A YANG Model for Network and VPN Service Performance Monitoring Authors : Bo Wu Qin Wu Mohamed Boucadair Oscar Gonzalez de Dios Bin Wen Filename: draft-ietf-opsawg-yang-vpn-service-pm-07.txt Pages : 39 Date: 2022-04-25 Abstract: The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both networks and VPN services that can be used to monitor and manage network performance on the topology at higher layer or the service topology between VPN sites. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-vpn-service-pm/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-vpn-service-pm-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] IPR POLL: draft-ietf-opsawg-sap
Hi OPSAWG, No, I'm not aware of any IPR that applies to this draft. Samier Barguil De: OPSAWG en nombre de Joe Clarke (jclarke) Enviado: viernes, 22 de abril de 2022 21:01 Para: opsawg@ietf.org Asunto: [OPSAWG] IPR POLL: draft-ietf-opsawg-sap Authors and contributors, please respond on-list as to whether or not you are aware of any IPR that pertains to this work. Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If you are aware of IPR, indicate whether or not this has been disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179). Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06
Hi Adrian, Many thanks for your detailed review. We have released Rev-07 to address these issues, see if they are fully addressed. https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-07 Please also find some replies inline. Thanks, Bo -Original Message- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Saturday, April 23, 2022 12:35 AM To: draft-ietf-opsawg-yang-vpn-service...@ietf.org Cc: 'opsawg' Subject: Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06 Hi, I'm the document shepherd for this document as it moves beyond the WG for requested publication as an RFC. I reviewed the draft at -03 during WG last call, so my comments here are basically editorial with only a few small questions. If the authors could produce a new revision, I will start work on the shepherd write-up. One other point: can someone say whether this draft has been shared with the IPPM working group? Thanks, Adrian === Introduction. First sentence could use a reference to RFC 6020. [Bo Wu] Fixed. --- Introduction OLD It defines that the performance measurement telemetry model to be tied with the service, such as Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall network performance or Service Level Agreement (SLA). NEW It defines that the performance measurement telemetry model should be tied to the services (such as a Layer 3 VPN or Layer 2 VPN) or to the network models to monitor the overall network performance and the Service Level Agreements (SLAs). END [Bo Wu] Fixed. --- 2.1 OLD SLA Service Level Agreements NEW SLA Service Level Agreement END [Bo Wu] Fixed. --- 3. For example, the controller can use information from [RFC8345], [I-D.ietf-opsawg-sap] or VPN instances. I think this is where there should be a reference to RFC 9182 and draft-ietf-opsawg-l2nm. [Bo Wu] Fixed. --- 3.1 s/dynamic-changing/dynamic/ [Bo Wu] Fixed. --- 4. OLD This document defines the YANG module, "ietf-network-vpn-pm", which is an augmentation to the "ietf-network" and "ietf-network-topology". NEW This document defines the YANG module, "ietf-network-vpn-pm", which is an augmentation to the "ietf-network" and "ietf-network-topology" modules. END [Bo Wu] Fixed. --- 4. Would it be more consistent if the box on the right of Figure 2 showed "ietf-network-vpn-pm"? [Bo Wu] Fixed. --- I think that Figure 3 could use a little tidying. - Some gaps in lines - A couple of lines slightly out of place - S2A and S2B are confusinly places - The cross-over of VN3-N2 and VN1-N1 is unclear - Wording of the Legend a little unclear How about... VPN 1 VPN 2 ++ ++ // // / S1C_[VN3]::: / // / \ : / / S2A_[VN1][VN3]_S2B / / \ ::: / / : : / Overlay / \ : : / / S1B_[VN2][VN1]_S1A / / : :/ +-:---:--+ +---:-:--:---+ :: : : : : ::: Site-1A : +---:-:--:---:-+ Site-1C [CE1]___:_/___[N1]___[N2]___:/__[CE3] :/ / / \ _// :/ [CE5]_:___/ /\ _/ /::/ Site-2A/:/ \ / / :: / / :[N5] / :: / Underlay Network / : / __/ \__ / :: / / : /___/ \__ /::/ Site-1B / : / ___/ \ /: / Site-2B [CE2]__/[N4]__[N3]/[CE4] / / +--+ Legend: N:Node VN:VPN-Node S:Site CE:Customer Edge __ Link within a network layer : Mapping between network layers [Bo Wu] Fixed. Thanks for helping to correct the figure. --- 4.1 s/topologies are both built/topologies are built/ [Bo Wu] Fixed. --- The legend for Figure 4 should include "TP" (if TPs are actually relevant to the figure and aren't something you should remove - the text doesn't mention them, and they don't really seem to be important in Section 4.1). Probably, TP should be added to the list in Section 2.1 with a reference to where TP is properly explained. 4.4 would then be able to lean on that definition. [Bo Wu] Fixed. Thanks for catching this. The reference of TP has been added in Section 2.1. --- 4.1 s/VPN PM can provides/VPN PM can provide/ [Bo Wu] Fixed. --- 4.2 s/[RFC9181])./[RFC9181]./ [Bo Wu] Fixed. --- 4.2 etc. Not sure why 'mac-num'
Re: [OPSAWG] Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06
Hi Adrian, About the issue on Normative Reference, RFC4026 as specific, the authors think this will cause downref since RFC4026 is an Informational draft. We still suggest RFC4026 as an informative reference because the model just references it as informational. Thanks, Bo -Original Message- From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Wubo (lana) Sent: Monday, April 25, 2022 4:44 PM To: adr...@olddog.co.uk; draft-ietf-opsawg-yang-vpn-service...@ietf.org Cc: 'opsawg' Subject: Re: [OPSAWG] Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06 Hi Adrian, Many thanks for your detailed review. We have released Rev-07 to address these issues, see if they are fully addressed. https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-07 Please also find some replies inline. Thanks, Bo -Original Message- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Saturday, April 23, 2022 12:35 AM To: draft-ietf-opsawg-yang-vpn-service...@ietf.org Cc: 'opsawg' Subject: Document shepherd review of draft-ietf-opsawg-yang-vpn-service-pm-06 Hi, I'm the document shepherd for this document as it moves beyond the WG for requested publication as an RFC. I reviewed the draft at -03 during WG last call, so my comments here are basically editorial with only a few small questions. If the authors could produce a new revision, I will start work on the shepherd write-up. One other point: can someone say whether this draft has been shared with the IPPM working group? Thanks, Adrian === Introduction. First sentence could use a reference to RFC 6020. [Bo Wu] Fixed. --- Introduction OLD It defines that the performance measurement telemetry model to be tied with the service, such as Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall network performance or Service Level Agreement (SLA). NEW It defines that the performance measurement telemetry model should be tied to the services (such as a Layer 3 VPN or Layer 2 VPN) or to the network models to monitor the overall network performance and the Service Level Agreements (SLAs). END [Bo Wu] Fixed. --- 2.1 OLD SLA Service Level Agreements NEW SLA Service Level Agreement END [Bo Wu] Fixed. --- 3. For example, the controller can use information from [RFC8345], [I-D.ietf-opsawg-sap] or VPN instances. I think this is where there should be a reference to RFC 9182 and draft-ietf-opsawg-l2nm. [Bo Wu] Fixed. --- 3.1 s/dynamic-changing/dynamic/ [Bo Wu] Fixed. --- 4. OLD This document defines the YANG module, "ietf-network-vpn-pm", which is an augmentation to the "ietf-network" and "ietf-network-topology". NEW This document defines the YANG module, "ietf-network-vpn-pm", which is an augmentation to the "ietf-network" and "ietf-network-topology" modules. END [Bo Wu] Fixed. --- 4. Would it be more consistent if the box on the right of Figure 2 showed "ietf-network-vpn-pm"? [Bo Wu] Fixed. --- I think that Figure 3 could use a little tidying. - Some gaps in lines - A couple of lines slightly out of place - S2A and S2B are confusinly places - The cross-over of VN3-N2 and VN1-N1 is unclear - Wording of the Legend a little unclear How about... VPN 1 VPN 2 ++ ++ // // / S1C_[VN3]::: / // / \ : / / S2A_[VN1][VN3]_S2B / / \ ::: / / : : / Overlay / \ : : / / S1B_[VN2][VN1]_S1A / / : :/ +-:---:--+ +---:-:--:---+ :: : : : : ::: Site-1A : +---:-:--:---:-+ Site-1C [CE1]___:_/___[N1]___[N2]___:/__[CE3] :/ / / \ _// :/ [CE5]_:___/ /\ _/ /::/ Site-2A/:/ \ / / :: / / :[N5] / :: / Underlay Network / : / __/ \__ / :: / / : /___/ \__ /::/ Site-1B / : / ___/ \ /: / Site-2B [CE2]__/[N4]__[N3]/[CE4] / / +--+ Legend: N:Node VN:VPN-Node S:Site CE:Customer Edge __ Link within a network layer : Mapping between network layers [Bo Wu] Fixed. Thanks for helping to correct the figure. --- 4.1 s/topologies are both built/topologies are built/ [Bo Wu] Fixed. --- The legend for Figure 4 should include "TP"
[OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-yang-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : YANG Modules for Service Assurance Authors : Benoit Claise Jean Quilbeuf Paolo Lucente Paolo Fasano Thangam Arumugam Filename: draft-ietf-opsawg-service-assurance-yang-04.txt Pages : 45 Date: 2022-04-25 Abstract: This document specifies YANG modules representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices. A companion RFC, Service Assurance for Intent-based Networking Architecture, presents an architecture for implementing the assurance of such services. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assurance-yang-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-04 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-yang-04.txt
Dear All, This new version of the draft addresses the comments from Tom Petch and Mohamed Boucadair. Thanks again for their reviews. Best, Jean > -Original Message- > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of internet- > dra...@ietf.org > Sent: Monday 25 April 2022 18:32 > To: i-d-annou...@ietf.org > Cc: opsawg@ietf.org > Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-service-assurance-yang- > 04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operations and Management Area Working > Group WG of the IETF. > > Title : YANG Modules for Service Assurance > Authors : Benoit Claise > Jean Quilbeuf > Paolo Lucente > Paolo Fasano > Thangam Arumugam > Filename: draft-ietf-opsawg-service-assurance-yang-04.txt > Pages : 45 > Date: 2022-04-25 > > Abstract: >This document specifies YANG modules representing assurance graphs. >These graphs represent the assurance of a given service by >decomposing it into atomic assurance elements called subservices. A >companion RFC, Service Assurance for Intent-based Networking >Architecture, presents an architecture for implementing the assurance >of such services. > >The YANG data models in this document conforms to the Network >Management Datastore Architecture (NMDA) defined in RFC 8342. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-service-assurance-yang-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-04 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > 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
