Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
On Mon, Mar 4, 2024 at 8:53 AM Michael Richardson wrote: > > > Erik Kline via Datatracker wrote: > > ## Comments > > I got your nits in my copy. > > > * I suggest finding some text to point to that defines what a > > "geofenced" name is. Right now this feels like the kind of thing that > > everyone "just knows what it means", but could use some formal > > description. > > Ugh. I don't think we have any RFC that defines it. It's not in 8499bis. > Maybe someone else has an idea for a good reference. I asked on a DNS directorate + wg chairs sync earlier today and nobody seemed to have in mind either (a) a single good reference nor (b) a single good definition for a "geofenced name". Perhaps we can begin by clarifying what it means to you? In mind there were two alternatives; roughly: [a] a name for which a DNS authoritative will hand out different RRs depending on the client src IP (conceptual proxy for geolocation), or [b] a name for which a DNS authoritative will either hand out some RRs **or** return NODATA or some kind of error to others, as a function of client IP. Are either of those close to what you mean? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [E-impact] Review of Green Networking Metrics, draft-cx-opsawg-green-metrics
Hello Jari,
many thanks for your review comments, much appreciated! I just posted
an updated revision -02 which takes your comments into account, here:
https://datatracker.ietf.org/doc/html/draft-cx-opsawg-green-metrics-02.
Some quick inline replies below. I am cc'ing opsawg, since this is the
WG that will hopefully serve as a landing spot.
--- Alex
On 2/15/2024 6:11 AM, Jari Arkko wrote:
Hi,
I gave a quick read to
https://datatracker.ietf.org/doc/html/draft-cx-opsawg-green-metrics-01 and
had some questions and comments:
Overall, an interesting and useful document.
We furthermore distinguish between primary metrics which are
directly measured, and derived metrics which are computed from
multiple factors.
Question: is there also ”stated” metrics vs. measured metrics, e.g.,
per the manufacturer’s declaration, the (idle) power consumption of
this device is X kWh? Later in S3.1.1 you talk about energy ratings
and data sheets for instance.
This is already alluded to by the discussion of certification.
We expanded that paragraph to make it clearer. ("It should be noted
that just because a metric is stated does not necessarily mean in all
cases that it is accurate or true. Where this can be a concern, they
should ideally be certified.")
implementation of packet classification of Ternary
Content-Addressable Memory (TCAM) and the size of TCAM
These seem a bit specific. In another device it might be something
totally different that’s central to the power consumption, e.g., on
wireless the radios.
True, but it was meant as an example. Expanded on this to
mention the wireless radio. ("Depending on the type of device, there
may also be other factors, such as radios in case of equipment
supporting wireless transmission.")
Generally, the cost of the first bit could be considered very
high, as it requires powering up a device, port, etc.
Perhaps this is a bit too broad statement, given that the costs are
actually dependent also on the speed at which things can be powered up
or down. Entire devices… often takes long. Some link types… can take
long. Others, maybe less so. Some CPUs and other architectures also
have very dynamic sleep state models that can react at a quick pace.
As a general statement, I do think this is true - but you are
correct that there are many dependencies and specifics depend on the
particular case. Expanded the discussion to mention that. ("Of course,
precise numbers vary greatly between different devices and device
architectures, some of which may support dynamic sleep state models
that are able to transition quickly with limited overhead, thus
mitigating some of those effects.")
Current power consumption / kB (or gB)
Some consideration should be given for different tasks and classes of
devices. A Bluetooth transmission != 100-km fiber transmission != WAN
radio to a mobile device.
Sure, but even where the actual values may differ greatly, the
metric itself remains the same. The possibility that you can perform
further differentiation by device component is already discussed in
section 3.1.1. I am not sure what other textual update we would need
here?
An important aspect concerns the device's power source.
Yes. Maybe you could have some discussion of where this information
resides, e.g., it could be that some local information distribution
could make the device aware of this, or is this something that is fed
from separate backend systems to the network management algorithms?
I think there is a risk here of getting sidetracked into a
discussion of technical solutions, as opposed to the metrics
themselves. That being said, I added some text to take your comment
into account: "Even in cases where a power source does not independently
provide such data, it is conceivable to use controllers and/or
management systems to provision certain devices with it to make those
device and the network aware of it to allow network-embedded algorithms
to take such information into account."
3.1.3. Virtualization Considerations
Nice! Liked in particular the CPU power proportionality observation.
3.2. Green Metrics related to Flows
Some discussion related to usefulness of measurements vs. effort and
power consumption needed for a measurement might be in order here. I
guess sampling _some_ flows and not all will be a way to go, but
perhaps that should be stated? Thoughts?
I don't think we need to get into how we would conduct the actual
measurement. However, you are correct that of course the benefit of an
accurate reading of a metric must outweigh the cost of obtaining it.
For this particular item, I think the text does imply that we would not
measure things on a packet-by-packet basis but can be obtained
differently (compute the proportion of flow traffic to overall traffic,
multiple this with the total energy consumption incurred by the device
during that time), hence I don't think the sampling consideration
Re: [OPSAWG] Erik Kline's No Objection on draft-ietf-opsawg-mud-iot-dns-considerations-12: (with COMMENT)
Erik Kline via Datatracker wrote: > ## Comments I got your nits in my copy. > * I suggest finding some text to point to that defines what a > "geofenced" name is. Right now this feels like the kind of thing that > everyone "just knows what it means", but could use some formal > description. Ugh. I don't think we have any RFC that defines it. It's not in 8499bis. Maybe someone else has an idea for a good reference. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] I-D Action: draft-ietf-opsawg-teas-attachment-circuit-07.txt
Internet-Draft draft-ietf-opsawg-teas-attachment-circuit-07.txt is now available. It is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title: YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) Authors: Mohamed Boucadair Richard Roberts Oscar Gonzalez de Dios Samier Barguil Giraldo Bo Wu Name:draft-ietf-opsawg-teas-attachment-circuit-07.txt Pages: 111 Dates: 2024-03-04 Abstract: This document specifies a YANG service data model for Attachment Circuits (ACs). This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a service model for managing bearers over which ACs are established. Also, the document specifies a set of reusable groupings. Whether other service models reuse structures defined in the AC models or simply include an AC reference is a design choice of these service models. Utilizing the AC service model to manage ACs over which a service is delivered has the advantage of decoupling service management from upgrading AC components to incorporate recent AC technologies or features. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-teas-attachment-circuit/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-attachment-circuit-07.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-teas-attachment-circuit-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] AD review of draft-ietf-opsawg-mud-iot-dns-considerations-08
Rob Wilton (rwilton) wrote: > The TD;LR is I think that your latest changes are good and I’ll send > -12 to IETF LC. I think that I got the rest of your nits as well in the version I posted yesterday. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-collected-data-manifest-03.txt
Dear All, This new version aligns with draft-kll-yang-label-tsdb for the example in Appendix A. It also briefly references draft-jouqui-netmod-full-include as a solution for reusing existing YANG modules into a new one. Best, Jean https://datatracker.ietf.org/doc/draft-kll-yang-label-tsdb/ https://datatracker.ietf.org/doc/draft-jouqui-netmod-yang-full-include/ > -Original Message- > From: OPSAWG On Behalf Of internet- > dra...@ietf.org > Sent: Monday, March 4, 2024 1:52 PM > To: i-d-annou...@ietf.org > Cc: opsawg@ietf.org > Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-collected-data-manifest-03.txt > > Internet-Draft draft-ietf-opsawg-collected-data-manifest-03.txt is now > available. > It is a work item of the Operations and Management Area Working Group > (OPSAWG) WG of the IETF. > >Title: A Data Manifest for Contextualized Telemetry Data >Authors: Benoit Claise > Jean Quilbeuf > Diego R. Lopez > Ignacio Dominguez > Thomas Graf >Name:draft-ietf-opsawg-collected-data-manifest-03.txt >Pages: 53 >Dates: 2024-03-04 > > Abstract: > >Network platforms use Model-driven Telemetry, and in particular YANG- >Push, to continuously stream information, including both counters and >state information. This document documents the metadata that ensure >that the collected data can be interpreted correctly. This document >specifies the Data Manifest, composed of two YANG data models (the >Platform Manifest and the Data Collection Manifest). These YANG >modules are specified at the network (i.e. controller) level to >provide a model that encompasses several network platforms. The Data >Manifest must be streamed and stored along with the data, up to the >collection and analytics system in order to keep the collected data >fully exploitable by the data scientists. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-collected-data- > manifest-03 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-collected-data- > manifest-03 > > 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
[OPSAWG] I-D Action: draft-ietf-opsawg-collected-data-manifest-03.txt
Internet-Draft draft-ietf-opsawg-collected-data-manifest-03.txt is now available. It is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title: A Data Manifest for Contextualized Telemetry Data Authors: Benoit Claise Jean Quilbeuf Diego R. Lopez Ignacio Dominguez Thomas Graf Name:draft-ietf-opsawg-collected-data-manifest-03.txt Pages: 53 Dates: 2024-03-04 Abstract: Network platforms use Model-driven Telemetry, and in particular YANG- Push, to continuously stream information, including both counters and state information. This document documents the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the Data Collection Manifest). These YANG modules are specified at the network (i.e. controller) level to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics system in order to keep the collected data fully exploitable by the data scientists. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-collected-data-manifest-03 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-collected-data-manifest-03 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
