Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
Hi Uri, Thanks for the comments. I'd like to clarify there's no black and white separation between conventional OAM and telemetry. Conventional OAM is also indispensable in many cases and some tools is also evolving to bear more characteristics of a typical telemetry system. I'll make the modification and clarification accordingly. Haoyu -Original Message- From: Blumenthal, Uri - 0553 - MITLL [mailto:u...@ll.mit.edu] Sent: Wednesday, October 17, 2018 5:55 AM To: adr...@olddog.co.uk Cc: Tianran Zhou ; opsawg@ietf.org; draft-song-opsawg-...@ietf.org Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf SNMP is a management protocol, not a data transfer one. SNMP Trap is like a UDP message - send and forget. SNMP Notify can require confirmation, so you can make sure it reaches it's destination (or know that it could not). I rather disagree with the characterization "low data rate and high overhead" - compared to what, and by what criteria? P.S. IMHO, SNMP Traps are perfect for telemetry. Regards, Uri Sent from my iPhone > On Oct 17, 2018, at 04:27, Adrian Farrel wrote: > > Hi Tianran, > > Yes, I mean the "Trap" which is now called "Notification." > > You're right in your assessment of the drawbacks, and you should add to that > list the drawback of the low data rat and high overhead that come with the > protocol. > > I didn't mention the Notification to propose it as a mechanism for telemetry, > but just so that your introductory text has a complete description of the > pre-existing environment. > > Best, > Adrian > >> -Original Message- >> From: Tianran Zhou [mailto:zhoutian...@huawei.com] >> Sent: 17 October 2018 04:09 >> To: adr...@olddog.co.uk; opsawg@ietf.org >> Cc: draft-song-opsawg-...@ietf.org >> Subject: RE: Thoughts on draft-song-opsawg-ntf >> >> Hi Adrian, >> >> Thank you very much for your careful review and comments. >> >> On this discussion: >> "In 1.4 you have >> Since SNMP is poll-based, it incurs >> low data rate and high processing overhead. >> I don't think this is quite fair on SNMP. The protocol also includes > Notifications >> allowing information to be output by a device. Your main point about low data >> rates and high overhead, still stand, but with a different slant." >> >> Do you mean the SNMP trap, which is used for alarm and event? >> I agree, it's push based notification with binary encoding. However, >> 1. no easy CRUD operations >> 2. no customizable periodical and on-change export. So have to use poll >> operation. >> 3. need special definition and support, not apply for any mib data. >> >> Do you think the above are the SNMP defeat for telemetry use? >> >> Or what your thoughts? >> >> Thanks, >> Tianran >> >>> -Original Message- >>> From: Adrian Farrel [mailto:adr...@olddog.co.uk] >>> Sent: Wednesday, October 17, 2018 3:40 AM >>> To: opsawg@ietf.org >>> Cc: draft-song-opsawg-...@ietf.org >>> Subject: Thoughts on draft-song-opsawg-ntf >>> >>> Hi authors and working group. >>> >>> I just had cause to read this document and thought I would share my comments >>> on the list. >>> >>> The draft appears as -00, but it is a little more mature than that implies >>> because it replaces draft-song-ntf-02. >>> >>> I think a foundation document on telemetry would be useful for the IETF, and >>> the OPSAWG may be a good place to discuss and progress that work. >>> This document seems like a reasonable starting point for that work although >>> there will inevitably need to be some additions and modifications. Actually, >>> I found this document pretty complete. >>> >>> My comments are a combination of substantive issues and nits. >>> >>> Hope this helps. >>> >>> Regards, >>> Adrian >>> >>> == Discussion points == >>> >>> In 1.4 you have >>> Since SNMP is poll-based, it incurs >>> low data rate and high processing overhead. >>> I don't think this is quite fair on SNMP. The protocol also includes >>> Notifications allowing information to be output by a device. Your main point >>> about low data rates and high overhead, still stand, but with a different >>> slant. >>> >>> --- >>> >>> Although you talk about IPFIX quite a bit later in the document, I think > that, >>> as part of the scene setting, you might include a paragraph about it early >>> in 1.4. >>> >>> --- >>> >>> The text after Figure 1 did not completely convince me of the need for >>> interaction between the three "telemetry planes". Perhaps you could expand >>> the examples and discussion to highlight/clarify this? >>> >>> --- >>> >>> Clearly you are going to have to write some Security Considerations. >>> There is quite a lot to say about what is a layered security model with > plenty >>> of attack vectors, and substantial risks as the telemetry data can result >>> in operational changes that could harm data delivery and even bring the >>> network down. Furthermore, examination of telemetry data can reveal >>> weaknesses in the network. >>> >>>
Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
Hi - On 10/17/2018 6:37 PM, Tianran Zhou wrote: I do not mean to say the SNMP design is problematic. But I think it's not designed for periodically getting operational data, which is one important case for streaming telemetry. That's one of the possible use cases for RFC 2981 or RFC 3877, and was considered in their design. If you think those MIB modules are inadequate, it would be helpful for you to spell out exactly why they fail to meet the need. Compared with current YANG-Push (https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push) activity, user can get any data described in existing YANG data store (not only the notifications), and can appoint the period when the data originator pushes the event. I really do recommend you look at RFC 2981. It provides exactly that capability. Again, if you think RFC 2981 does not meet that need, I ask you to spell out exactly how the design is deficient. Randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
Hi Adrian, Thank you very much for the comments. I'll try to address all your comments in the new revisions. Given the time and bandwidth, I may leave some parts (e.g., security concern) to future revisions. Yes, gRPC is a recursive acronym and "g" doesn't mean google although we all know where it comes from ;) Haoyu -Original Message- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Tuesday, October 16, 2018 12:40 PM To: opsawg@ietf.org Cc: draft-song-opsawg-...@ietf.org Subject: Thoughts on draft-song-opsawg-ntf Hi authors and working group. I just had cause to read this document and thought I would share my comments on the list. The draft appears as -00, but it is a little more mature than that implies because it replaces draft-song-ntf-02. I think a foundation document on telemetry would be useful for the IETF, and the OPSAWG may be a good place to discuss and progress that work. This document seems like a reasonable starting point for that work although there will inevitably need to be some additions and modifications. Actually, I found this document pretty complete. My comments are a combination of substantive issues and nits. Hope this helps. Regards, Adrian == Discussion points == In 1.4 you have Since SNMP is poll-based, it incurs low data rate and high processing overhead. I don't think this is quite fair on SNMP. The protocol also includes Notifications allowing information to be output by a device. Your main point about low data rates and high overhead, still stand, but with a different slant. --- Although you talk about IPFIX quite a bit later in the document, I think that, as part of the scene setting, you might include a paragraph about it early in 1.4. --- The text after Figure 1 did not completely convince me of the need for interaction between the three "telemetry planes". Perhaps you could expand the examples and discussion to highlight/clarify this? --- Clearly you are going to have to write some Security Considerations. There is quite a lot to say about what is a layered security model with plenty of attack vectors, and substantial risks as the telemetry data can result in operational changes that could harm data delivery and even bring the network down. Furthermore, examination of telemetry data can reveal weaknesses in the network. == Nits == The authors will need to reduce the number of front page names to 5. Move the others to a Contributors section. Might as well do this sooner rather than later. --- Abstract This document suggests the necessity of an architectural framework for network telemetry in order to meet the current and future network operation requirements. Suggest you change this a little because you actually provide the framework. How about... This document provides an architectural framework for network telemetry in order to meet the current and future network operation requirements. --- You need to write an Introduction section and present it as Section 1. You don't need a lot of text: start with the Abstract and expand it a little. --- The Requirements Language text should move to a new Section 1.1 --- You should expand the abbreviations on first use. I see: AI ARCA ML OAM SDN --- A couple of the terms in 1.3 are confusing. > gNMI: gPRC Network Management Interface Should that be gRPC? > gRPC: gRPC Remote Procedure Call This seems circular. --- Not sure that RFC 1157 is the best reference for SNMP in section 1.4. How about 3416? --- Figure 3 Does gPRC mean gRPC? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] EARLY CALL: Agenda topics for IETF 103
Hi Joe, I'd like to apply a presentation slot for the draft song-opsawg-ntf-01. In the talk, I'll presents the updates of the draft and address the issues raised during the email discussion. Thanks! Best, Haoyu -Original Message- From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Joe Clarke Sent: Tuesday, September 11, 2018 10:06 AM To: opsawg@ietf.org Subject: [OPSAWG] EARLY CALL: Agenda topics for IETF 103 Hello, opsawg. We have requested a meeting slot for IETF 103 in Bangkok. Like previous meetings, we have requested a 2.5 hour meeting combining opsawg and Ops Area. We'd like to get people to start thinking about presentation topics and to start working on their slides. If you are thinking about proposing a presentation, keep in mind that your presentation should _NOT_ simply present your document section-by-section. In fact, it shouldn't present your document section-by-section at all. A good presentation will discuss the problem briefly, describe the solution, and then ask questions of the WG as to what is needed to proceed with the document. That is, what areas do you need specific input? Where might you need help to fully form a viable solution? What additional considerations should WG be aware of? In addition to proposing your presentation, email the list ahead of the meeting requesting a review of your document and seeding your questions so the WG can prepare good answers for you. Remember, we want a discussion both in the room and on the list. Finally, keep your time in mind. Many slots are 10 minutes, which should likely have a max of four slides to allow for some discussion. Presentations that simply go section-by-section through documents will not be accepted. Please send requests for presentation slots to opsawg-cha...@ietf.org. The final cut off for presentations will be October 31, 2018 to ensure the list has time to review documents. Thanks. Joe on behalf of the co-chairs ___ 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] Thoughts on draft-song-opsawg-ntf
Hi Randy, Thank you for your pointer. I do not mean to say the SNMP design is problematic. But I think it's not designed for periodically getting operational data, which is one important case for streaming telemetry. Compared with current YANG-Push (https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push) activity, user can get any data described in existing YANG data store (not only the notifications), and can appoint the period when the data originator pushes the event. Thanks, Tianran > -Original Message- > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Randy Presuhn > Sent: Thursday, October 18, 2018 8:38 AM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf > > Hi - > > On 10/16/2018 8:08 PM, Tianran Zhou wrote: > > > 2. no customizable periodical and on-change export. So have to use poll > operation. > > Have you tried RFC 2981 or RFC 3877? > If so, what aspects of their design did you find problematic? > > > 3. need special definition and support, not apply for any mib data. > > I don't understand what this is intended to mean. > > Randy > > ___ > 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] Thoughts on draft-song-opsawg-ntf
Hi Tianran, Yes, I mean the "Trap" which is now called "Notification." You're right in your assessment of the drawbacks, and you should add to that list the drawback of the low data rat and high overhead that come with the protocol. I didn't mention the Notification to propose it as a mechanism for telemetry, but just so that your introductory text has a complete description of the pre-existing environment. Best, Adrian > -Original Message- > From: Tianran Zhou [mailto:zhoutian...@huawei.com] > Sent: 17 October 2018 04:09 > To: adr...@olddog.co.uk; opsawg@ietf.org > Cc: draft-song-opsawg-...@ietf.org > Subject: RE: Thoughts on draft-song-opsawg-ntf > > Hi Adrian, > > Thank you very much for your careful review and comments. > > On this discussion: > "In 1.4 you have >Since SNMP is poll-based, it incurs >low data rate and high processing overhead. > I don't think this is quite fair on SNMP. The protocol also includes Notifications > allowing information to be output by a device. Your main point about low data > rates and high overhead, still stand, but with a different slant." > > Do you mean the SNMP trap, which is used for alarm and event? > I agree, it's push based notification with binary encoding. However, > 1. no easy CRUD operations > 2. no customizable periodical and on-change export. So have to use poll > operation. > 3. need special definition and support, not apply for any mib data. > > Do you think the above are the SNMP defeat for telemetry use? > > Or what your thoughts? > > Thanks, > Tianran > > > -Original Message- > > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > > Sent: Wednesday, October 17, 2018 3:40 AM > > To: opsawg@ietf.org > > Cc: draft-song-opsawg-...@ietf.org > > Subject: Thoughts on draft-song-opsawg-ntf > > > > Hi authors and working group. > > > > I just had cause to read this document and thought I would share my comments > > on the list. > > > > The draft appears as -00, but it is a little more mature than that implies > > because it replaces draft-song-ntf-02. > > > > I think a foundation document on telemetry would be useful for the IETF, and > > the OPSAWG may be a good place to discuss and progress that work. > > This document seems like a reasonable starting point for that work although > > there will inevitably need to be some additions and modifications. Actually, > > I found this document pretty complete. > > > > My comments are a combination of substantive issues and nits. > > > > Hope this helps. > > > > Regards, > > Adrian > > > > == Discussion points == > > > > In 1.4 you have > >Since SNMP is poll-based, it incurs > >low data rate and high processing overhead. > > I don't think this is quite fair on SNMP. The protocol also includes > > Notifications allowing information to be output by a device. Your main point > > about low data rates and high overhead, still stand, but with a different > > slant. > > > > --- > > > > Although you talk about IPFIX quite a bit later in the document, I think that, > > as part of the scene setting, you might include a paragraph about it early > > in 1.4. > > > > --- > > > > The text after Figure 1 did not completely convince me of the need for > > interaction between the three "telemetry planes". Perhaps you could expand > > the examples and discussion to highlight/clarify this? > > > > --- > > > > Clearly you are going to have to write some Security Considerations. > > There is quite a lot to say about what is a layered security model with plenty > > of attack vectors, and substantial risks as the telemetry data can result > > in operational changes that could harm data delivery and even bring the > > network down. Furthermore, examination of telemetry data can reveal > > weaknesses in the network. > > > > == Nits == > > > > The authors will need to reduce the number of front page names to 5. > > Move the others to a Contributors section. Might as well do this sooner rather > > than later. > > > > --- > > > > Abstract > > > >This document suggests the necessity of an architectural framework > >for network telemetry in order to meet the current and future network > >operation requirements. > > > > Suggest you change this a little because you actually provide the framework. > > How about... > > > >This document provides an architectural framework for network > >telemetry in order to meet the current and future network operation > >requirements. > > > > --- > > > > You need to write an Introduction section and present it as Section 1. > > You don't need a lot of text: start with the Abstract and expand it a little. > > > > --- > > > > The Requirements Language text should move to a new Section 1.1 > > > > --- > > > > You should expand the abbreviations on first use. I see: > > AI > > ARCA > > ML > > OAM > > SDN > > > > --- > > > > A couple of the terms in 1.3 are confusing. > > > > > gNMI: gPRC Network Management Interface > > Should that be gRPC? > > > > >
Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
Hi Adrian, I see. Thank you very much for your suggestions. We will update the document to clarify this. Thanks, Tianran > -Original Message- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: Wednesday, October 17, 2018 5:27 PM > To: Tianran Zhou ; opsawg@ietf.org > Cc: draft-song-opsawg-...@ietf.org > Subject: RE: Thoughts on draft-song-opsawg-ntf > > Hi Tianran, > > Yes, I mean the "Trap" which is now called "Notification." > > You're right in your assessment of the drawbacks, and you should add to that > list the drawback of the low data rat and high overhead that come with the > protocol. > > I didn't mention the Notification to propose it as a mechanism for telemetry, > but just so that your introductory text has a complete description of the > pre-existing environment. > > Best, > Adrian > > > -Original Message- > > From: Tianran Zhou [mailto:zhoutian...@huawei.com] > > Sent: 17 October 2018 04:09 > > To: adr...@olddog.co.uk; opsawg@ietf.org > > Cc: draft-song-opsawg-...@ietf.org > > Subject: RE: Thoughts on draft-song-opsawg-ntf > > > > Hi Adrian, > > > > Thank you very much for your careful review and comments. > > > > On this discussion: > > "In 1.4 you have > >Since SNMP is poll-based, it incurs > >low data rate and high processing overhead. > > I don't think this is quite fair on SNMP. The protocol also includes > Notifications > > allowing information to be output by a device. Your main point about > > low data rates and high overhead, still stand, but with a different slant." > > > > Do you mean the SNMP trap, which is used for alarm and event? > > I agree, it's push based notification with binary encoding. However, > > 1. no easy CRUD operations 2. no customizable periodical and on-change > > export. So have to use poll operation. > > 3. need special definition and support, not apply for any mib data. > > > > Do you think the above are the SNMP defeat for telemetry use? > > > > Or what your thoughts? > > > > Thanks, > > Tianran > > > > > -Original Message- > > > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > > > Sent: Wednesday, October 17, 2018 3:40 AM > > > To: opsawg@ietf.org > > > Cc: draft-song-opsawg-...@ietf.org > > > Subject: Thoughts on draft-song-opsawg-ntf > > > > > > Hi authors and working group. > > > > > > I just had cause to read this document and thought I would share my > > > comments on the list. > > > > > > The draft appears as -00, but it is a little more mature than that > > > implies because it replaces draft-song-ntf-02. > > > > > > I think a foundation document on telemetry would be useful for the > > > IETF, and the OPSAWG may be a good place to discuss and progress that > work. > > > This document seems like a reasonable starting point for that work > > > although there will inevitably need to be some additions and > > > modifications. Actually, I found this document pretty complete. > > > > > > My comments are a combination of substantive issues and nits. > > > > > > Hope this helps. > > > > > > Regards, > > > Adrian > > > > > > == Discussion points == > > > > > > In 1.4 you have > > >Since SNMP is poll-based, it incurs > > >low data rate and high processing overhead. > > > I don't think this is quite fair on SNMP. The protocol also includes > > > Notifications allowing information to be output by a device. Your > > > main point about low data rates and high overhead, still stand, but > > > with a different slant. > > > > > > --- > > > > > > Although you talk about IPFIX quite a bit later in the document, I > > > think > that, > > > as part of the scene setting, you might include a paragraph about it > > > early in 1.4. > > > > > > --- > > > > > > The text after Figure 1 did not completely convince me of the need > > > for interaction between the three "telemetry planes". Perhaps you > > > could expand the examples and discussion to highlight/clarify this? > > > > > > --- > > > > > > Clearly you are going to have to write some Security Considerations. > > > There is quite a lot to say about what is a layered security model > > > with > plenty > > > of attack vectors, and substantial risks as the telemetry data can > > > result in operational changes that could harm data delivery and even > > > bring the network down. Furthermore, examination of telemetry data > > > can reveal weaknesses in the network. > > > > > > == Nits == > > > > > > The authors will need to reduce the number of front page names to 5. > > > Move the others to a Contributors section. Might as well do this > > > sooner > rather > > > than later. > > > > > > --- > > > > > > Abstract > > > > > >This document suggests the necessity of an architectural framework > > >for network telemetry in order to meet the current and future network > > >operation requirements. > > > > > > Suggest you change this a little because you actually provide the > framework. > > > How about... > > > > > >This document provides an architectural
Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
SNMP is a management protocol, not a data transfer one. SNMP Trap is like a UDP message - send and forget. SNMP Notify can require confirmation, so you can make sure it reaches it's destination (or know that it could not). I rather disagree with the characterization "low data rate and high overhead" - compared to what, and by what criteria? P.S. IMHO, SNMP Traps are perfect for telemetry. Regards, Uri Sent from my iPhone > On Oct 17, 2018, at 04:27, Adrian Farrel wrote: > > Hi Tianran, > > Yes, I mean the "Trap" which is now called "Notification." > > You're right in your assessment of the drawbacks, and you should add to that > list the drawback of the low data rat and high overhead that come with the > protocol. > > I didn't mention the Notification to propose it as a mechanism for telemetry, > but just so that your introductory text has a complete description of the > pre-existing environment. > > Best, > Adrian > >> -Original Message- >> From: Tianran Zhou [mailto:zhoutian...@huawei.com] >> Sent: 17 October 2018 04:09 >> To: adr...@olddog.co.uk; opsawg@ietf.org >> Cc: draft-song-opsawg-...@ietf.org >> Subject: RE: Thoughts on draft-song-opsawg-ntf >> >> Hi Adrian, >> >> Thank you very much for your careful review and comments. >> >> On this discussion: >> "In 1.4 you have >> Since SNMP is poll-based, it incurs >> low data rate and high processing overhead. >> I don't think this is quite fair on SNMP. The protocol also includes > Notifications >> allowing information to be output by a device. Your main point about low data >> rates and high overhead, still stand, but with a different slant." >> >> Do you mean the SNMP trap, which is used for alarm and event? >> I agree, it's push based notification with binary encoding. However, >> 1. no easy CRUD operations >> 2. no customizable periodical and on-change export. So have to use poll >> operation. >> 3. need special definition and support, not apply for any mib data. >> >> Do you think the above are the SNMP defeat for telemetry use? >> >> Or what your thoughts? >> >> Thanks, >> Tianran >> >>> -Original Message- >>> From: Adrian Farrel [mailto:adr...@olddog.co.uk] >>> Sent: Wednesday, October 17, 2018 3:40 AM >>> To: opsawg@ietf.org >>> Cc: draft-song-opsawg-...@ietf.org >>> Subject: Thoughts on draft-song-opsawg-ntf >>> >>> Hi authors and working group. >>> >>> I just had cause to read this document and thought I would share my comments >>> on the list. >>> >>> The draft appears as -00, but it is a little more mature than that implies >>> because it replaces draft-song-ntf-02. >>> >>> I think a foundation document on telemetry would be useful for the IETF, and >>> the OPSAWG may be a good place to discuss and progress that work. >>> This document seems like a reasonable starting point for that work although >>> there will inevitably need to be some additions and modifications. Actually, >>> I found this document pretty complete. >>> >>> My comments are a combination of substantive issues and nits. >>> >>> Hope this helps. >>> >>> Regards, >>> Adrian >>> >>> == Discussion points == >>> >>> In 1.4 you have >>> Since SNMP is poll-based, it incurs >>> low data rate and high processing overhead. >>> I don't think this is quite fair on SNMP. The protocol also includes >>> Notifications allowing information to be output by a device. Your main point >>> about low data rates and high overhead, still stand, but with a different >>> slant. >>> >>> --- >>> >>> Although you talk about IPFIX quite a bit later in the document, I think > that, >>> as part of the scene setting, you might include a paragraph about it early >>> in 1.4. >>> >>> --- >>> >>> The text after Figure 1 did not completely convince me of the need for >>> interaction between the three "telemetry planes". Perhaps you could expand >>> the examples and discussion to highlight/clarify this? >>> >>> --- >>> >>> Clearly you are going to have to write some Security Considerations. >>> There is quite a lot to say about what is a layered security model with > plenty >>> of attack vectors, and substantial risks as the telemetry data can result >>> in operational changes that could harm data delivery and even bring the >>> network down. Furthermore, examination of telemetry data can reveal >>> weaknesses in the network. >>> >>> == Nits == >>> >>> The authors will need to reduce the number of front page names to 5. >>> Move the others to a Contributors section. Might as well do this sooner > rather >>> than later. >>> >>> --- >>> >>> Abstract >>> >>> This document suggests the necessity of an architectural framework >>> for network telemetry in order to meet the current and future network >>> operation requirements. >>> >>> Suggest you change this a little because you actually provide the framework. >>> How about... >>> >>> This document provides an architectural framework for network >>> telemetry in order to meet the current and
