[OPSAWG]Re: IETF 120 opsawg minutes posted

[Greg Mirsky]

It's perfect! Thank you!

Regards,
Greg

On Thu, Aug 1, 2024 at 1:50 PM Joe Clarke (jclarke) 
wrote:

> Thanks, Greg.  I updated your comments in HedgeDoc and reimported the
> minutes.
>
>
>
> Joe
>
>
>
> *From: *Greg Mirsky 
> *Date: *Thursday, August 1, 2024 at 16:37
> *To: *Joe Clarke (jclarke) 
> *Cc: *opsawg@ietf.org 
> *Subject: *Re: [OPSAWG]IETF 120 opsawg minutes posted
>
> Hi Joe,
>
> thank you for bringing minutes to the review. I noticed a minor issue with
> reflection of my comment to A YANG Data Model for Network Diagnosis by
> Scheduling Sequences of OAM Tests. I noted that RFC 8913
> <https://datatracker.ietf.org/doc/rfc8913/> that defines the TWAMP YANG
> model, does not allow control of TWAMP Lite (which is non-standard mode of
> TWAMP). Furthermore, in my comment I suggested checking STAMP YANG model
> <https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-yang-12.html> which
> allows for scheduling periodic measurement sessions.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Jul 30, 2024 at 5:35 PM Joe Clarke (jclarke)  40cisco@dmarc.ietf.org> wrote:
>
> Thanks to Jean Quilbeuf for being our minutes-taker at our IETF 120
> opsawg/Ops Area meeting.  I posted those to Data Tracker.  Please review
> and help us correct any issues or fill in any gaps.  There are a few chair
> AIs, which we will start to address in the coming weeks.
>
>
>
> https://datatracker.ietf.org/doc/minutes-120-opsawg-202407231630/
>
>
>
> Joe
>
> ___
> OPSAWG mailing list -- opsawg@ietf.org
> To unsubscribe send an email to opsawg-le...@ietf.org
>
>
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: IETF 120 opsawg minutes posted

[Greg Mirsky]

Hi Joe,
thank you for bringing minutes to the review. I noticed a minor issue with
reflection of my comment to A YANG Data Model for Network Diagnosis by
Scheduling Sequences of OAM Tests. I noted that RFC 8913
 that defines the TWAMP YANG
model, does not allow control of TWAMP Lite (which is non-standard mode of
TWAMP). Furthermore, in my comment I suggested checking STAMP YANG model
 which
allows for scheduling periodic measurement sessions.

Regards,
Greg

On Tue, Jul 30, 2024 at 5:35 PM Joe Clarke (jclarke)  wrote:

> Thanks to Jean Quilbeuf for being our minutes-taker at our IETF 120
> opsawg/Ops Area meeting.  I posted those to Data Tracker.  Please review
> and help us correct any issues or fill in any gaps.  There are a few chair
> AIs, which we will start to address in the coming weeks.
>
>
>
> https://datatracker.ietf.org/doc/minutes-120-opsawg-202407231630/
>
>
>
> Joe
> ___
> OPSAWG mailing list -- opsawg@ietf.org
> To unsubscribe send an email to opsawg-le...@ietf.org
>
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG]Re: I-D Action: draft-ietf-opsawg-ipfix-on-path-telemetry-08.txt

[Greg Mirsky]

Dear Authors,
thank you for updating the draft; I've read it. I hope that adding IPPM WG
to discussion of new performance metrics is reasonable. I appreciate your
consideration of my notes and questions below:

   - If I understand correctly, the delay measurement using on-path
   telemetry is achieved inserting a timestamp into the packet:

   With On-Path Telemetry, described in the Network Telemetry Framework

   [RFC9232] and applied in In-situ OAM [I-D.ietf-ippm-ioam-deployment]

   and Alternate Marking Deployment Framework

   [I-D.ietf-ippm-alt-mark-deployment], the path delay between two

   endpoints is measured by inserting a timestamp in the packet.

Can you clarify which document specifies delay measurement using timestamp
with Alternate Marking.


   - In your opinion, what is the value of references to passport and
   postcard modes considering that the conclusion, with which I fully agree,
   notes:

   In both modes the forwarding path
   exposes performance metrics allowing to determine how much delay has
   been accumulated on which hop.


   - All names of the new performance metrics combine 'hybrid' and
   'passive'. I assume that 'hybrid' refers to the characterization of on-path
   telemetry measurement methods according to RFC 7799. If that is the case,
   what is the interpretation of the 'passive'?
   - Delay measurement method defined as follows:

   The delay is measured by calculating the difference between the

   timestamp imposed with On-Path Telemetry in the packet at the IOAM

   encapsulation node and the timestamp exported in the IPFIX flow

   record from the IOAM transit and decapsulation nodes.


   - I think that the purpose of one-way delay measurement is to produce
   accurate metrics that reflect network conditions as experienced by the
   packet equipped by, e.g., IOAM header. When considering the one-way delay
   measurement, I think that it is essential, among a number of factors, to
   specify when the wall-clock value must be read and the quality of clock
   synchronization used in the forwarding path. AFAIK, RFC 9197 does not
   specify when IOAM Node Data fields Timestamp (seconds and fractions) are
   obtained.
   - When considering an impact of clock synchronization, quality of clock
   synchronization on the accuracy of one-way delay measurement, we may
   consider another IOAM Node Data field that might provide information about
   the delay and support localization of any bottleneck along the path that,
   at the same time, does not depend on the issue of clock synchronization. I
   think that Transit time, a.k.a. Residence Time has advantages compared to
   collecting local timestamps. What are your thoughts?
   - Alternatively, to compensate for systematic and random errors in
   one-way time measurement a system may use calibration, e.g., as described
   in Section 5.4.4 of
   OWPDV_Active_IP-UDP-Periodic_RFC8912sec5_Seconds_95Percentile
   
.
   In your opinion, could calibration be used for delay measurement using IOAM?
   - As I understand it, Section 3.1 lists variation and constant column
   entries in the IANA Performance Metrics registry:

   All column entries besides the ID, Name, Description, and Output

   Reference Method categories are the same
Two notes on that:


   - I cannot find the Output Reference Method column in the referenced
   IANA registry.
   - Furthermore, the Uniform Resource Identifier (URI) column must be
   specific for each new metric (as listed in Section 3.1.1.3)


   - I got confused by the text in 3.4.2.6.  Calibration

   Passive Measurements at an OP could be calibrated against an Active
   Measurement at host A where the Active Measurement represents the
   ground truth.

Would calibration be required on all transit IOAM nodes as well as the
decapsulating IOAM node? Also, could you clarify the "Passive Measurements"
classification. Is it related to IOAM or another measurement method?

Regards,
Greg


On Mon, Jul 8, 2024 at 11:40 AM Benoit Claise 
wrote:

> Dear all,
>
> We reviewed one more time the double IANA registrations, both for the IP
> Performance Registry and for the IPFIX Registry.
> I feel (more) confident (than before) that the IANA procedure on the
> right track.
> This document is ready for WGLC IMO.
>
> I would like to have a 10 min presentation to over the last changes, and
> mainly the IANA aspects.
>
> Regards, Benoit
>
>
> On 7/8/2024 6:33 PM, internet-dra...@ietf.org wrote:
> > Internet-Draft draft-ietf-opsawg-ipfix-on-path-telemetry-08.txt is now
> > available. It is a work item of the Operations and Management Area
> Working
> > Group (OPSAWG) WG of the IETF.
> >
> > Title:   Export of On-Path Delay in IPFIX
> > Authors: Thomas Graf
> >  Benoit Claise
> >  Alex Huang Feng
> > Name:draft-ietf-opsawg-ipfix-on-path-telemetry-08.txt
> >   

[OPSAWG]Re: 🔔 WG Adoption Call for draft-gfz-opsawg-ipfix-alt-mark-01

[Greg Mirsky]

Hi, Henk et al.,
I read the draft and found it well-written. I believe that it addresses the
real issue and provides a viable solution. I support its adoption by the
OPSAWG.

Regards,
Greg

On Wed, Jun 26, 2024 at 2:58 AM Henk Birkholz 
wrote:

> Dear OPSAWG members,
>
> this email starts a call for Working Group Adoption of
>
> > https://datatracker.ietf.org/doc/html/draft-gfz-opsawg-ipfix-alt-mark-01
>
> ending on Saturday, July 6th. That is a little bit of an odd duration,
> but the I-D is crisp and concise and if there is rough consensus after
> that time, this work may become a WG item before the upcoming cut-off.
>
> As a reminder, this I-D specifies IPFIX Information Elements for the
> Alternate-Marking Method as defined in RFC9341 & RFC9342; a technique
> for measuring packet loss, delay, and jitter of packets in-flight.
>
> The chairs acknowledge positive feedback and some review on the list and
> we would like to gather feedback from the WG if there is interest to
> further contribute and review.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> ___
> OPSAWG mailing list -- opsawg@ietf.org
> To unsubscribe send an email to opsawg-le...@ietf.org
>
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

[OPSAWG] Notes on draft-gfz-opsawg-ipfix-alt-mark

[Greg Mirsky]

Dear, Authors et al.,
thank you for your continued work on the Alternate Marking method. In my
opinion, draft-gfz-opsawg-ipfix-alt-mark provides an essential IEs making
the use of IPFIX operationally viable option for the Alternate Marking
method. While I've read the document, it seems that its current track,
Informational, may not be consistent with the request for specific actions
from IANA. Could it be that the Standard track is more appropriate for the
draft?

Regards,
Greg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Med,
thank you for sharing your thoughts about the draft. I've added my notes
below under GIM>> tag.

Regards,
Greg

On Tue, Apr 16, 2024 at 2:01 PM  wrote:

> Hi Greg, all,
>
>
>
> Having this discussion is by its own sufficient to justify why we need to
> amend rfc6291 with terms that reflect recent needs/usages in a manner that
> can be easily and generally visible to the target audience.
>
GIM>> I don't think that the proposed updates are in any way related to the
scope of RFC 6291. In fact, they are only affecting RFC 7799, which is the
product of the IPPM WG.

>
>
> For example, Michael indicated that he wished he had a better name for
> "Virtual In-Band OAM" (I still don’t digest what does that mean actually).
>
GIM>> I've read the definitions of 'in-band' and "out-of-band" in RFC 8994.
I agree with these definitions with a note that "in-band" also includes
sharing the same schedulers as the data flow(s) being managed/controlled
using management/control plane. In other words, the management and control
plane receive the same QoS as the data plane.

I also indicated that I wished I had terms for the following when I edited
> RFC 9451:
>
>- “OAM packet that exclusively includes OAM data”
>- “OAM packet that includes user data”
>
> GIM>> RFC 7799, AFAICS, defines the first case as an active OAM, i.e.,
using specifically constructed synthetic packet. The second case - an
example of hybrid OAM method as it combines elements of Active (inclusion
of OAM-specific construct in a data packet) with Passive . Of course, RFC
9451 could have defined its own terms and explicitly list in Terminology
section.

>
>
> I think that we can leverage some definition entries in various documents
> out there (detnet, for example) when this makes sense. Some of the existing
> terms, although used in RFCs, fail to unambiguously convey the intended
> meaning. I don’t think it is problematic to acknowledge that fact and
> consider alternate terms.
>
GIM>> As I've noted before, a term cannot be expected to be
self-explanatory. That is the responcibility of the authors, WG, and all of
us to have explicitly defined dictionary being used in our documents.

>
>
> Of course, this is a cross-WG effort and a pre-requisite I expect for it
> is that the authors commit in soliciting the feedback from relevant WGs.
>
>
>
> I don’t think it is premature to consider adopting this work here in
> OPSAWG. As you know, the content is not frozen given that this is simply a
> call for adoption, not a Last Call.
>
GIM>> I think that we have different perspective and expectations of the
process. That's is okay. I believe that WG Chairs and the Responcible AD
will find the way forward to further advance the development of Internet
and technologies that enable its continuous growth.

>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG  *De la part de* Greg Mirsky
> *Envoyé :* mardi 16 avril 2024 10:11
> *À :* Carlos Pignataro 
> *Cc :* OPSAWG 
> *Objet :* Re: [OPSAWG] 🔔 WG Adoption Call for
> draft-pignataro-opsawg-oam-whaaat-question-mark-03
>
>
>
> Dear Carlos,
>
> thank you for making my point even clearer. I do believe that a term may
> have interpretation in different scopes - a document, a series of
> documents, or across all IETF documents. RFC 9551 established the
> interpretation of terms for all DetNet OAM documents. The document under
> discussion, draft-pignataro-opsawg-oam-whaaat-question-mark, as I
> understand its intention, is to establish the scope across all IETF
> documents. That, IMHO, imposes on the decision already made by the DetNet
> WG (and, AFAICS, shared by several other WGs). That is why I consider the
> WG AP premature and encourage the authors to reach out across the WG and
> Area boundaries to socialize the document more before taking any steps to
> progress it.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Apr 16, 2024 at 4:52 AM Carlos Pignataro 
> wrote:
>
> Greg,
>
>
>
> Repeating something does not make it so…
>
>
>
> You had argued that those were definitions only within the context of
> DetNet, and each context can have different ones. You really cannot have it
> both ways. This is confusing.
>
>
>
> I-Ds follow causality — lots of things were approved to then be corrected.
>
>
>
> In-band — out-of-band — what do they really mean when…
>
>
>
> There is no “band”
>
>
>
>
>
>
>
> C
>
>
>
> Thumb typed by Carlos Pignataro.
>
> Excuze typofraphicak errows
>
>
>
> On Apr 15, 2024, at 09:03, Greg Mirsky  wrote:
>
> 
>
> Hi Carlos,
>
> I have t

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Michael,
I don't think that every term must and can be self-explanatory. We develop
our dictionary through the development of explicitly defined terms. That is
what we use Terminology section in our drafts for. And, AFAICS, it is
normal to expect that anyone interested in the field, in the particular
application or protocol, read all the relevant documents to learn about the
principles as well as the dictionary used.

Regards,
Greg

On Tue, Apr 16, 2024 at 3:20 PM Michael Richardson 
wrote:

>
> mohamed.boucad...@orange.com wrote:
> > For example, Michael indicated that he wished he had a better name
> for
> > "Virtual In-Band OAM" (I still don’t digest what does that mean
> > actually). I also indicated that I wished I had terms for the
> following
> > when I edited RFC 9451:
>
> The fact that you don't know what it means from the term means that we got
> something wrong in the name in my opinion :-)
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> 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] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Dear Carlos,
thank you for making my point even clearer. I do believe that a term may
have interpretation in different scopes - a document, a series of
documents, or across all IETF documents. RFC 9551 established the
interpretation of terms for all DetNet OAM documents. The document under
discussion, draft-pignataro-opsawg-oam-whaaat-question-mark, as I
understand its intention, is to establish the scope across all IETF
documents. That, IMHO, imposes on the decision already made by the DetNet
WG (and, AFAICS, shared by several other WGs). That is why I consider the
WG AP premature and encourage the authors to reach out across the WG and
Area boundaries to socialize the document more before taking any steps to
progress it.

Regards,
Greg

On Tue, Apr 16, 2024 at 4:52 AM Carlos Pignataro  wrote:

> Greg,
>
> Repeating something does not make it so…
>
> You had argued that those were definitions only within the context of
> DetNet, and each context can have different ones. You really cannot have it
> both ways. This is confusing.
>
> I-Ds follow causality — lots of things were approved to then be corrected.
>
> In-band — out-of-band — what do they really mean when…
>
> There is no “band”
>
> [image: image]
>
> C
>
> Thumb typed by Carlos Pignataro.
> Excuze typofraphicak errows
>
> On Apr 15, 2024, at 09:03, Greg Mirsky  wrote:
>
> 
> Hi Carlos,
> I have to repeat that the definitions of terms "in-band OAM", "out-of-band
> OAM", and "on-path telemetry"
>In-band OAM:  an active OAM method that is in band within the
>   monitored DetNet OAM domain when it traverses the same set of
>   links and interfaces receiving the same QoS and Packet
>   Replication, Elimination, and Ordering Functions (PREOF) treatment
>   as the monitored DetNet flow.
>
>Out-of-band OAM:  an active OAM method whose path through the DetNet
>   domain may not be topologically identical to the path of the
>   monitored DetNet flow, its test packets may receive different QoS
>   and/or PREOF treatment, or both.
>
>On-path telemetry:  on-path telemetry can be realized as a hybrid OAM
>   method.  The origination of the telemetry information is
>   inherently in band as packets in a DetNet flow are used as
>   triggers.  Collection of the on-path telemetry information can be
>   performed using in-band or out-of-band OAM methods.
>
> have been adopted by DetNet WG, approved by IESG and published as part of RFC
> 9551 <https://datatracker.ietf.org/doc/rfc9551/>. I believe that a
> constructive approach would be to use the already accepted terminology, not
> to attempt to negate what has already been achieved in building up the IETF
> dictionary, particularly in the OAM area.
>
> Regards,
> Greg
>
> On Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro 
> wrote:
>
>> Dear Greg,
>>
>> Thank you for the input.
>>
>> It appears that much of what you write below was already discussed at
>> https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/
>>
>>
>> Am I to understand you might be keen on continuing using "in-band OAM"
>> with different meanings depending on the WG or context?
>>
>> Please find some follow-ups inline below:
>>
>> On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky 
>> wrote:
>>
>>> Dear All,
>>> I've read the latest version of the draft, Please find my notes and
>>> questions below:
>>>
>>>- All SDOs that standardize methods and/or protocols in the field of
>>>OAM recognize that, in the FCAPS network management model, OAM is
>>>addressing the 'F' and 'P', i.e., Fault Management and Performance
>>>Monitoring methods and protocols. Furthermore, OAM is understood as a
>>>collection of various methods and protocols, rather than a single 
>>> protocol,
>>>method, or tool. Hence, it seems like the document must use the same more
>>>granular approach in characterizing this or that OAM mechanism, including
>>>the possible variance in the application of that mechanism.
>>>
>>> CMP: This document intends to Update RFC 6291, a product of the IETF
>> about OAM language usage, with support from its lead editor.
>>
>>>
>>>- I was under the impression that the discussion about the
>>>unfortunate choice of the original extended form of IOAM, "In-band OAM",
>>>has been put to rest with the agreement to extend it as "In-situ OAM". 
>>> Why
>>>bring that discussion back? To revisit the de

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Michael,
thank you for the update. I'm glad that you found the definition in RFC
9551 working for ANIMA's Autonomic Control Plane as well. I will read RFC
8994 to educate myself about it.

Regards,
Greg

On Mon, Apr 15, 2024 at 5:54 PM Michael Richardson 
wrote:

>
> Greg Mirsky  wrote:
> > I have to repeat that the definitions of terms "in-band OAM",
> "out-of-band
> > OAM", and "on-path telemetry"
>
> > In-band OAM:  an active OAM method that is in band within the
> > monitored DetNet OAM domain when it traverses the same set of
> > links and interfaces receiving the same QoS and Packet
> > Replication, Elimination, and Ordering Functions (PREOF) treatment
> > as the monitored DetNet flow.
>
> > Out-of-band OAM:  an active OAM method whose path through the DetNet
> > domain may not be topologically identical to the path of the
> > monitored DetNet flow, its test packets may receive different QoS
> > and/or PREOF treatment, or both.
>
> On the topic of RFC8994's overlay management network, which we described as
> virtual out-of-band.  It would seem to fit into the above definition, since
> the overlay packets might go another route, and might get a different QoS
> treatment.
>
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Carlos,
I have to repeat that the definitions of terms "in-band OAM", "out-of-band
OAM", and "on-path telemetry"
   In-band OAM:  an active OAM method that is in band within the
  monitored DetNet OAM domain when it traverses the same set of
  links and interfaces receiving the same QoS and Packet
  Replication, Elimination, and Ordering Functions (PREOF) treatment
  as the monitored DetNet flow.

   Out-of-band OAM:  an active OAM method whose path through the DetNet
  domain may not be topologically identical to the path of the
  monitored DetNet flow, its test packets may receive different QoS
  and/or PREOF treatment, or both.

   On-path telemetry:  on-path telemetry can be realized as a hybrid OAM
  method.  The origination of the telemetry information is
  inherently in band as packets in a DetNet flow are used as
  triggers.  Collection of the on-path telemetry information can be
  performed using in-band or out-of-band OAM methods.

have been adopted by DetNet WG, approved by IESG and published as part of RFC
9551 <https://datatracker.ietf.org/doc/rfc9551/>. I believe that a
constructive approach would be to use the already accepted terminology, not
to attempt to negate what has already been achieved in building up the IETF
dictionary, particularly in the OAM area.

Regards,
Greg

On Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro  wrote:

> Dear Greg,
>
> Thank you for the input.
>
> It appears that much of what you write below was already discussed at
> https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/
>
> Am I to understand you might be keen on continuing using "in-band OAM"
> with different meanings depending on the WG or context?
>
> Please find some follow-ups inline below:
>
> On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky 
> wrote:
>
>> Dear All,
>> I've read the latest version of the draft, Please find my notes and
>> questions below:
>>
>>- All SDOs that standardize methods and/or protocols in the field of
>>OAM recognize that, in the FCAPS network management model, OAM is
>>addressing the 'F' and 'P', i.e., Fault Management and Performance
>>Monitoring methods and protocols. Furthermore, OAM is understood as a
>>collection of various methods and protocols, rather than a single 
>> protocol,
>>method, or tool. Hence, it seems like the document must use the same more
>>granular approach in characterizing this or that OAM mechanism, including
>>the possible variance in the application of that mechanism.
>>
>> CMP: This document intends to Update RFC 6291, a product of the IETF
> about OAM language usage, with support from its lead editor.
>
>>
>>- I was under the impression that the discussion about the
>>unfortunate choice of the original extended form of IOAM, "In-band OAM",
>>has been put to rest with the agreement to extend it as "In-situ OAM". Why
>>bring that discussion back? To revisit the decision of the IPPM WG? If so,
>>then, as I imagine, that must be discussed in the IPPM WG.
>>
>> CMP: Not really, as explained in the draft already, clearly. See
> https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/
>
>>
>>- "Within the IETF, the terms "in-band" and "out-of-band" cannot be
>>reliably understood consistently and unambiguously." That is a very strong
>>and powerful statement that, in my opinion, requires serious analysis. For
>>example, a survey of the IETF community that undoubtedly demonstrates the
>>existence of multiple confronting interpretations that cannot be resolved
>>by a mere wordsmithing. Can the authors cite such a survey and its 
>> results?
>>
>>
> CMP: The document already contains that analysis. It explains why those
> terms cannot be reliably understood consistently and unambiguously.
>
>>
>>- And closely following that statement "the terms are not
>>self-defining any more and cannot be understood by someone exposed to them
>>for the first time" seems to break the very foundation of IETF TAO - 
>> learn,
>>learn, and learn. I find the expectation of a first-comer to any IETF
>>discussion to be able to fully master all the dictionary and terminology 
>> of
>>that group to be, in my experience, a misguided. Through years, I've been
>>suggesting anyone interested in joining and contributing to IETF work to
>>first read (drafts, RFCs) and, most of all, the mail archive. Probably,
>>I've been wasti

Re: [OPSAWG] 🔔 WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Dear All,
I've read the latest version of the draft, Please find my notes and
questions below:

   - All SDOs that standardize methods and/or protocols in the field of OAM
   recognize that, in the FCAPS network management model, OAM is addressing
   the 'F' and 'P', i.e., Fault Management and Performance Monitoring methods
   and protocols. Furthermore, OAM is understood as a collection of
   various methods and protocols, rather than a single protocol, method, or
   tool. Hence, it seems like the document must use the same more granular
   approach in characterizing this or that OAM mechanism, including the
   possible variance in the application of that mechanism.
   - I was under the impression that the discussion about the unfortunate
   choice of the original extended form of IOAM, "In-band OAM", has been put
   to rest with the agreement to extend it as "In-situ OAM". Why bring that
   discussion back? To revisit the decision of the IPPM WG? If so, then, as I
   imagine, that must be discussed in the IPPM WG.
   - "Within the IETF, the terms "in-band" and "out-of-band" cannot be
   reliably understood consistently and unambiguously." That is a very strong
   and powerful statement that, in my opinion, requires serious analysis. For
   example, a survey of the IETF community that undoubtedly demonstrates the
   existence of multiple confronting interpretations that cannot be resolved
   by a mere wordsmithing. Can the authors cite such a survey and its results?
   - And closely following that statement "the terms are not self-defining
   any more and cannot be understood by someone exposed to them for the first
   time" seems to break the very foundation of IETF TAO - learn, learn, and
   learn. I find the expectation of a first-comer to any IETF discussion to be
   able to fully master all the dictionary and terminology of that group to
   be, in my experience, a misguided. Through years, I've been suggesting
   anyone interested in joining and contributing to IETF work to first read
   (drafts, RFCs) and, most of all, the mail archive. Probably, I've been
   wasting their time..
   - The following passage brings additional question:

The guidance in this document is to avoid the terms "*-band" and instead
find finer-granularity descriptive terms. The definitions presented in this
document are for use in all future IETF documents that refer to OAM, and
the terms "in-band OAM" and "out-of-band OAM" are not to be used in future
documents.


   - Is such an overreaching scope of the OPSAWG WG in its charter?
   - I found a number of references to DetNet OAM that, regrettably,
   misinterpreted documents approved by DetNet WG and some already published
   as RFCs. I can only encourage an open communication between the proponents
   of this work and the DetNet WG rather than an attempt to force something
   foreign to the essence of Deterministic Networking and the application of
   OAM in DetNet.
   - It appears that the term "Combined OAM", introduced in this document,
   allows for a combination of "Non-Path Congruent OAM" with
   "Equal-QoS-Treatment OAM". If that is the case, what do you see as the
   value of using such "combined OAM"?
   - In my reading of Section 3 and references to RFC 7799, I find it
   getting close to benign misinterpretation of RFC 7799:
  - Firstly, RFC 7799 appropriately discusses OAM methods and metrics,
  i.e., elements of OAM. Hence, because of, what seems like, a
  misunderstanding of how OAM is composed, the document dismisses RFC 7799
  even though that is the fundamental document with 16 references by IETF
  documents and more by documents in other SDOs.
  - In the definition of the "Compound OAM" it is suggested that a
  combination of Active and Hybrid OAM methods or of Passive and Hybrid OAM
  methods are distinct examples of Compound OAM. If that is the intention,
  how to reconcile that with the definition of a Hybrid OAM method in RFC
  7799:

   Hybrid Methods are Methods of Measurement that use a combination of
   Active Methods and Passive Methods, to assess Active Metrics, Passive
   Metrics, or new metrics derived from the a priori knowledge and
   observations of the stream of interest.

It does appear, that unless this document updates or obsoletes RFC 7799, a
combination of Active and Hybrid or Passive and Hybrid methods will still
be a Hybrid OAM method. Actually, according to the following assesment:
[RFC7799] adds to the confusion by describing "passive methods" as "out of
band". Following the guidelines of this document, OAM may be qualified
according to the terms described in Sections 2 and 3 of this document, and
the term "out of band OAM" is not to be used in future documents.

updating RFC 7799 is the intention of this document. Or am I missing
something here?


As the conclusion. Although the document is well-written, I don't find it
addressing a real problem, nor offering a viable, useful solution. Henc

Re: [OPSAWG] Fwd: [mpls] New Liaison Statement, "LS on the consent of draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr) Requirements and Reference Model for optimized traceroute of joint Internet Pro

[Greg Mirsky]

Hi Loa,
thank you for bringing to the discussion this liaison. I've looked through
the prescribed processing and I have concerns about the scenario when an
ICMP packet arrives at PE1 with the TTL=3. If I understand the process
correctly, IP TTL is decremented and since it is non-zero, the ICMP packet
is encapsulated in MPLS with MPLS TTL set to 2. If the MPLS network has
more than one P node, that MPLS TTL expires at the second downstream P
node. That node discovers the ICMP packet with TTL=2. And here I see two
cases:

   - IP Dst is unknown to the P node
   - IP Dst is, somehow, known to the P node

In the latter case, the P node will route the ICMP packet. In the former,
as I understand it, will drop its ICMP Host unreachable. Either case is
troublesome.
Am I missing something in the process described in the liaison? Do you see
a mistake in my thinking?

Regards,
Greg

On Fri, Feb 16, 2024 at 2:08 AM  wrote:

> All,
>
> We have the liaison:
>
> "LS on the consent of draft Recommendation ITU-T Q.3962 (ex. Q.joint_tr)
> Requirements and Reference Model for optimized traceroute of joint
> Internet Protocol/Multi-Protocol Label Switching".
>
> I have tried to read the Recommendation, still have some concerns and
> questions.
>
> The liaison was addressed to the OPSAWG, but Tianran (OPSAWG co-chair)
> sent this to the MPLS WG that seem better fitted to respond if we want to.
>
> One questions for the OPSAWG is that if the MPLS WG decides to respond
> would the OPSAWG want to join in on the response?
>
> My concerns at moment are (possible there will be more) are rather  high
> level.
>
> The consented document is about "IP/MPLS" traceroute. This is core IETF/IP
> areas, and within the IETF design authority.. If the intention is to
> align SG-11 protocols with IETF technology that is OK.
>
> If it is it is a bit odd that neither STD5  (which include ICMP) nor  RFC
> 8029 are mentioned. In fact a consented Recommendation on IETF core
> technology does not mention a single RFC.
>
> If the intention is to create an ITU-T owned version of traceroute we are
> back in the discussion on honoring design authorities.
>
> The terminology is not well aligned with the IETF RFC. There are
> "MultiProtocol Label Switch" rather than "MultiProtocol Label Switching",
> MPLS tags (sic!), CE is said to be expanded as "Customer Equipment", while
> the common IETF usage is "Customer Edge", and there is more.
>
> Figure 6-1 deserves some scrutiny
>
> - the PEs seem to belong to both carrier and enterprise network
> - half of the CE seem to belong to the enterprise network and the
>   other half to something undefined.
>
> Also figure 6-1, a normal MPLS network deployment would have IP
> connectivity end to end and traceroute would just work over IP.
>
> Havin said that there is not always IP, e.g. MPLS-TP is built on the
> assumption. that IP connectivity is not necessary.
>
>
> I think we have good reason to respond even though the Liaison is "For
> Information".
>
> I don't know where the responsibility for STD5/ICMP lies, but possibly
> someone that know could forward.
>
> And I think it would be a good idea to call on Scott to coordinate a
> response.
>
> /Loa
>
>
> >  > id="lineBreakAtBeginningOfSignature">Sent from my
> iPhoneBegin forwarded
> > message: dir="ltr">From:
> > Greg Mirsky <gregimir...@gmail.com>Date: 29 October
> 2023
> > at 04:21:17 GMT+8To: Tony Li
> > <tony...@tony.li>Cc: m...@ietf.org, Henk Birkholz
> <henk.birkh...@sit.fraunhofer.de>, liaison-coordinat...@iab.org,
> Tianran Zhou <zhoutianran=40huawei@dmarc.ietf.org>, Warren
> Kumari <war...@kumari.net>, Joe Clarke <jcla...@cisco.com>,
> mpls-cha...@ietf.org, Robert Wilton <rwil...@cisco.com>,
> > itu-t-liai...@iab.org, rtg-...@ietf.orgSubject: Re: [mpls]
> New Liaison Statement, "LS on the consent of draft Recommendation ITU-T
> Q.3962 (ex. Q.joint_tr) “Requirements and Reference Model for
> optimized
> > traceroute of joint Internet Protocol/Multi-Protocol Label
> > Switching”" dir="ltr">Hi Tony,it appears to me that what this
> recommendations describes is Uniform tunneling model ( > href="https://datatracker.ietf.org/doc/html/rfc3443";>RFC 3443) for
> treating ICMP over MPLS (not sure whether the proponents of the
> recommendation argue for using the uniform model for subscriber traffic in
> >
> general).Regards,Greg class="gmail_quote">On Sat, Oct 28, 2023
> > at 10:35 AM Tony Li < > href="mailto:tony...@tony.li";>tony...@tony.li>
> > wrote:

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Greg Mirsky]

Dear Carlos,

thank you for sharing your thoughts and responding to my notes. I have
added follow-up notes and questions below under the GIM2>> tag. But before
I go to the specific topics of our discussion, it is essential to bring
forward the question of not how the 'OAM' abbreviation is expanded but how
we interpret it, whether in the expanded or abbreviated form. RFC 7276
<https://datatracker.ietf.org/doc/rfc7276/> in the Abstract gives the
following explanation of the scope of OAM:

  Operations, Administration, and Maintenance (OAM) is a general term

  that refers to a toolset for fault detection and isolation and for

  performance measurement.

Hence, based on that definition, we can expect that an OAM toolset includes
tools that use different methods classified in RFC 7799, i.e., active,
passive, and hybrid. Of course, some operators might build their OAM
toolsets only using mechanisms of the same type, i.e., only active or
hybrid. But such choices don't make OAM active or passive. Thus, I suggest
that the document clarify that and refer to "an active OAM method" rather
than "active OAM" (and so on for other types).


Regards,

Greg

On Tue, Jan 16, 2024 at 2:41 PM Carlos Pignataro  wrote:

> Dear Greg,
>
> Thank you for your interest in our draft, and the associated extensive
> comments! All welcome!
>
> *CMP: Please find some additional follow-ups.*
>
> On Sat, Jan 13, 2024 at 7:52 PM Greg Mirsky  wrote:
>
>> Hi Adrian,
>> thank you for your kind consideration of my notes. Please find my
>> follow-up notes below tagged by GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Fri, Jan 12, 2024 at 11:25 AM Adrian Farrel 
>> wrote:
>>
>>> Hi Greg,
>>>
>>>
>>>
>>> Thanks for your thoughtful inspection of our draft.
>>>
>>>
>>>
>>> Carlos and I wanted to be sure that all of the discussions of this draft
>>> were indexed on one list, and we wanted to avoid multiple copies going to
>>> people who are subscribed to multiple lists. So we asked that follow-ups
>>> went only to OPSAWG. I have moved IPPM, MPLS, SPRING, and DetNet to BCC on
>>> this email.
>>>
>> GIM>> Thank you.
>>
>>>
>>>
>>> It was certainly not our intent to disparage any work that was being
>>> done in any other working group, and I understand the effort that has gone
>>> into the DetNet OAM Framework to ensure that the terminology is clear and
>>> unencumbered in the DetNet context.
>>>
>>>
>>>
>>> Our concern was, however, that different contexts are applying different
>>> definitions of the terms “in-band” and “out-of-band”. Those definitions are
>>> (often) clear and precise, but they are not consistent across contexts.
>>> Thus, a water-tight definition in the DetNet context is not universally
>>> applicable, and a reader coming to DetNet from another context may bring
>>> with them their own understanding of the terms.
>>>
>> GIM>> Although the wording in the DetNet OAM Framework is indeed specific
>> for DetNet environment, for example, the reference to DetNet service
>> sub-layer and PREOF, the authors and the WG strived to make the definitions
>> generic. I believe that we achieved a reasonable level of generality
>> because the interpretation of "in-band/out-of-band" terminology in RAW OAM
>> was based on our work in DetNet. I believe that it could be a reasonable
>> way of building common understanding through a discussion of existing terms
>> instead of fork-lifting and trying to invent something different that has
>> not been used by any WG.
>>
>
> CMP: The set of challenges continues to be that
> *(1) these are still context-dependent re-definitions of
> "in-band". draft-ietf-detnet-oam-framework says "*In-band OAM is [...]
> within the monitored DetNet OAM domain [... long set of conditions ...]*".
> Clearly, these are only within a DetNet context. These are not portable nor
> generic or generalizable.*
>
GIM2>> The only context that is essential for OAM is the monitored data
flow. The data flow has two characteristics:

   - the rendered path, i.e., nodes and links traversed by a data packet
   - QoS experienced by the data packet

Any OAM method, whether for fault management or performance monitoring, to
monitor a particular data flow must have the same characteristics, i.e.,
the same rendered path and QoS. These characteristics cannot be separated
to have a useful presentation of the conditions experienced by the packets
of the monitored data flow. Consider a scenario when only the ren

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Greg Mirsky]

Hi Adrian,
thank you for your kind consideration of my notes. Please find my follow-up
notes below tagged by GIM>>.

Regards,
Greg

On Fri, Jan 12, 2024 at 11:25 AM Adrian Farrel  wrote:

> Hi Greg,
>
>
>
> Thanks for your thoughtful inspection of our draft.
>
>
>
> Carlos and I wanted to be sure that all of the discussions of this draft
> were indexed on one list, and we wanted to avoid multiple copies going to
> people who are subscribed to multiple lists. So we asked that follow-ups
> went only to OPSAWG. I have moved IPPM, MPLS, SPRING, and DetNet to BCC on
> this email.
>
GIM>> Thank you.

>
>
> It was certainly not our intent to disparage any work that was being done
> in any other working group, and I understand the effort that has gone into
> the DetNet OAM Framework to ensure that the terminology is clear and
> unencumbered in the DetNet context.
>
>
>
> Our concern was, however, that different contexts are applying different
> definitions of the terms “in-band” and “out-of-band”. Those definitions are
> (often) clear and precise, but they are not consistent across contexts.
> Thus, a water-tight definition in the DetNet context is not universally
> applicable, and a reader coming to DetNet from another context may bring
> with them their own understanding of the terms.
>
GIM>> Although the wording in the DetNet OAM Framework is indeed specific
for DetNet environment, for example, the reference to DetNet service
sub-layer and PREOF, the authors and the WG strived to make the definitions
generic. I believe that we achieved a reasonable level of generality
because the interpretation of "in-band/out-of-band" terminology in RAW OAM
was based on our work in DetNet. I believe that it could be a reasonable
way of building common understanding through a discussion of existing terms
instead of fork-lifting and trying to invent something different that has
not been used by any WG.

>
>
> Our intent, therefore, is to select a finer-grained set of terms that have
> universal applicability and that can be selected within a context without
> loss of generality.
>
GIM>> I agree with that wholeheartedly.

>
>
> This is a tricky little subject and I know that Carlos and I expected it
> to generate more than a little discussion. If we end up with “everything is
> OK and nothing needs to change” that will be OK with us. If we discover
> that some work is using terms too generally, while others already have
> perfect definitions, that will lead to something similar to this document
> to bring the good into the light.
>
>
>
> Further comments in line…
>
>
>
>
>
> *From:* Greg Mirsky 
> *Sent:* 12 January 2024 00:09
> *To:* Carlos Pignataro ; Adrian Farrel <
> adr...@olddog.co.uk>
> *Cc:* Ops Area WG ; IETF IPPM WG ; mpls <
> m...@ietf.org>; spring ; DetNet WG 
> *Subject:* Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"
>
>
>
>- Hi Carlos and Adrian,
>
> thank you for starting this work. I believe that having a common
> dictionary helps in having more productive discussions. I took the liberty
> of inviting all the WGs which you invited to review the document and added
> DetNet WG. Please feel free to trim the distribution list.
>
> I've read the document and have several general questions to start our
> discussion:
>
>- It seems that the motivation of this document is the assumption that
>"in-band OAM" and "out-of-band OAM" are not representative or cannot be
>understood or correctly attributed, interpreted by the IETF community. Is
>that correct?
>
> I think the wording here would be “cannot be reliably understood
> consistently”. That is, without looking at a context-specific definition
> (such as that which you supply in the DetNet OAM Framework), the use of the
> terms may be misinterpreted.
>
> This is an assertion, but one (we think) is founded on observation of
> recent conversations on mailing lists, and also of witnessing many years of
> people talking passed each other.
>
>- As we discuss and try to establish (change) the IETF dictionary, it
>is important to analyze the terminology used by other SDOs. I believe that
>it is beneficial to maintain consistent terminology which will minimize
>misunderstandings among experts with different experiences of working at
>different centers of technological expertise.
>
> This is a good point. It is certainly true that if other SDOs working with
> packet networks have established terminology that we can agree with and
> which is not, itself, subject to context-specific definitions, then there
> is no reason to choose other terms. Do you have any sugg

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Greg Mirsky]

   - Hi Carlos and Adrian,

thank you for starting this work. I believe that having a common dictionary
helps in having more productive discussions. I took the liberty of inviting
all the WGs which you invited to review the document and added DetNet WG.
Please feel free to trim the distribution list.
I've read the document and have several general questions to start our
discussion:

   - It seems that the motivation of this document is the assumption that
   "in-band OAM" and "out-of-band OAM" are not representative or cannot be
   understood or correctly attributed, interpreted by the IETF community. Is
   that correct?
   - As we discuss and try to establish (change) the IETF dictionary, it is
   important to analyze the terminology used by other SDOs. I believe that it
   is beneficial to maintain consistent terminology which will minimize
   misunderstandings among experts with different experiences of working at
   different centers of technological expertise.
   - I that DetNet OAM Framework
   
   provides sufficiently clear interpretation of terms that can be generalized
   for non-DetNet networks:

   *  In-band OAM is an active OAM that is in-band within the monitored
  DetNet OAM domain when it traverses the same set of links and
  interfaces receiving the same QoS and Packet Replication,
  Elimination, and Ordering Functions (PREOF) treatment as the
  monitored DetNet flow.

   *  Out-of-band OAM is an active OAM whose path through the DetNet
  domain is not topologically identical to the path of the monitored
  DetNet flow, or its test packets receive different QoS and/or
  PREOF treatment, or both.

As can be seen, the interpretation of "in-band" accepted by the DetNet WG
includes not only topological equivalence between the monitored data flow
and path traversed by active OAM but also QoS equivalence between them. I
believe that is essential in differentiating in-band OAM from out-of-band
OAM.


   - I find the use of "path congruence" in inherently meshed
   packet-switched networks confusing if not misleading. (Note that RFC 6669
    explains congruence by using
   in-band term.) Is there evidence of the term being used besides a single
   case in RFC 6669?
   - Similarly, "in-packet" vs. "dedicated packet". I believe that RFC 7799
    has that addressed by using
   "active", "passive", and "hybrid" terminology. Although these terms applied
   to measurement methods, i.e., performance monitoring component of OAM, but,
   in my opinion, can be extended to fault management OAM.
   - It seems like the definition of Compound/Combined misses the point
   that RFC 7799 already defines a hybrid measurement method (not OAM but
   measurement methods) as a method in which elements of active and
   passive measurement methods are used. Hence, hybrid is already a
   combination of active and passive measurement methodologies and the
   introduction of compound or combined terms is unnecessary, a duplication of
   the existing and accepted terminology (at least in IPPM WG). And
   "Active-Hybrid-Passive OAM" is the result of that omission because,
   according to the definition in RFC 7799, Active-Passive is Hybrid. Thus,
   Active-Hybrid-Passive is nothing else but Hybrid-Hybrid. Does that make
   sense?
   - I cannot agree that RFC 7799 "adds to the confusion" by pointing that

   Passive performance metrics are assessed independently of the packets
   or traffic flows, and solely through observation.  Some refer to such
   assessments as "out of band".

Indeed, passive measurement methods are not required to use packets that
are in-band with the monitored data flow. Usually, the management plane
protocol is used to collect, to perform the observation function. In some
cases, in-band active OAM packets may be used, e.g., direct loss
measurement in ETH-OAM.

FWIW, I believe that RFC 7799 and DetNet OAM Requirements already provide a
clear terminology for OAM in general and its elements, i.e., Fault
Management and Performance Monitoring.

Regards,
Greg

On Fri, Jan 5, 2024 at 12:39 PM Carlos Pignataro  wrote:

> Hi, Ops Area WG,
>
> Every now and again, there are discussions on how to best characterize or
> qualify a particular kind of "OAM", as well as misunderstandings due to
> having different definitions and contexts for a given term. A case in point
> is "in-band" or "out-of-band" OAM, as recently surfaced at
> https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/.
>
> To alleviate this issue, Adrian and I wrote a short I-D to provide
> forward-looking guidance on "foobar OAM".
>
> We would appreciate feedback and input on this position, which aims at
> updating the guidelines for the "OAM" acronym, with unambiguous guidelines
> for their modifiers.
>
> Guidelines for Charactering "OAM":
>
> https://datat

Re: [OPSAWG] [Detnet] [ippm] IOAM, iOAM, and oOAM abbreviations

[Greg Mirsky]

Hi Florian,
I probably confused the matter more than necessary by mapping out-of-band
OAM to be a passive measurement method. Let me correct myself. We know
active OAM protocols, e.g., CFM and STAMP, that support the direct loss
measurement functionality. Because the test frame/packet that is used to
collect the counters is specifically constructed, that would be an example
of active OAM. However, because the frame/packet is not used to perform the
measurement, it can be out-of-band relative to the monitored flow. Sorry
for the confusion I've caused.

Regards,
Greg

On Wed, Dec 13, 2023 at 12:41 PM Florian Kauer 
wrote:

> Hi Greg,
> thanks a lot for the explanation, find my comments under FK>>
>
> On 13.12.23 21:14, Greg Mirsky wrote:
> > Hi Florian,
> > thank you for your questions. I added my notes below under the GIM>> tag.
> >
> > Regards,
> > Greg
> >
> > On Wed, Dec 13, 2023 at 3:06 AM Florian Kauer <
> florian.ka...@linutronix.de <mailto:florian.ka...@linutronix.de>> wrote:
> >
> > Hi,
> > so does in-band OAM (RAW architecture) actually mean exactly the
> same as In-situ OAM (RFC 9197)?
> > If yes, both should be named and abbreviated exactly the same way
> and since RFC 9197 is already published, it should probably be In-situ OAM
> (IOAM). (But the question then is what is out-of-band OAM? Out-situ OAM?
> ;-) )
> >
> > GIM>> The intention of introducing "in-band OAM" and "out-of-band OAM"
> terms is to stress that some performance measurements can be performed
> without traversing the same set of links and nodes as the monitored flow.
> For example, direct loss measurement, which is collecting counters of
> in-profile frames/packets, can be out-of-band. These measurement methods
> are classified as passive per RFC 7799. Examples of in-band OAM, in our
> view, can be found among active and hybrid (per RFC 7799) measurement
> methods.
>
> Fk>> I am a little confused: After reading this explanation I thought
> "out-of-band OAM == passive OAM" and "in-band OAM == active and hybrid
> OAM". But draft-ietf-raw-architecture-16 explicitly writes "Out-of-band OAM
> is an active OAM". What do I get wrong here?
>
> >
> > If no, PLEASE don't use the same abbreviation for slightly different
> things, even in slightly different contexts. I acknowledge the preference
> of those working on a very specific topic to keep their daily used
> terminology as concise as possible, but as someone who tries to get into
> all those topics to understand the bigger picture or to actually implement
> something, specific abbreviations are always a hurdle, especially when they
> have different meanings in slightly different contexts.
> >
> > So I really like inb-OAM and oob-OAM, because you can really "see"
> the origin in it without repeatedly asking yourself if "i" stands for
> in-situ, in-band, internet, industrial, intelligent...
> >
> > GIM>> Thank you.
> >
> >
> > If you need a whole new section in an RFC just to explain the
> different uses of I in an abbreviation, you will likely spend more key
> strokes on that section, than on the additional "nb-"s ;-)
> >
> > Just my two cents.
> >
> > Greetings,
> > Florian
> >
> >
> > On 13.12.23 11:54, Frank Brockners (fbrockne) wrote:
> > >
> > >
> > > When IPPM started working on IOAM, there was a long discussion on
> naming – and the conclusion was that “in-band” as not appropriate for OAM
> information being piggybacked on top of user traffic. This is why the IPPM
> WG concluded to use “In-situ OAM” – or “IOAM” for short, which is what is
> used in RFC9197 and all related documents.
> > >
> > > Frank
> > >
> > >
> > >
> > > *From:*ippm mailto:ippm-boun...@ietf.org>>
> *On Behalf Of *Greg Mirsky
> > > *Sent:* Wednesday, 13 December 2023 04:13
> > > *To:* DetNet WG mailto:det...@ietf.org>>; mpls <
> m...@ietf.org <mailto:m...@ietf.org>>; 6man WG  i...@ietf.org>>; IETF IPPM WG mailto:i...@ietf.org>>;
> opsawg mailto:opsawg@ietf.org>>; Pascal Thubert <
> pascal.thub...@gmail.com <mailto:pascal.thub...@gmail.com>>; Loa
> Andersson mailto:l...@pi.nu>>
> > > *Subject:* [ippm] IOAM, iOAM, and oOAM abbreviations
> > >
> > >
> > >
> > > Dear All,
> > >
> > > Loa and I have discussed these abbreviations to help us fi

Re: [OPSAWG] [Detnet] [ippm] IOAM, iOAM, and oOAM abbreviations

[Greg Mirsky]

Hi Florian,
thank you for your questions. I added my notes below under the GIM>> tag.

Regards,
Greg

On Wed, Dec 13, 2023 at 3:06 AM Florian Kauer 
wrote:

> Hi,
> so does in-band OAM (RAW architecture) actually mean exactly the same as
> In-situ OAM (RFC 9197)?
> If yes, both should be named and abbreviated exactly the same way and
> since RFC 9197 is already published, it should probably be In-situ OAM
> (IOAM). (But the question then is what is out-of-band OAM? Out-situ OAM?
> ;-) )
>
GIM>> The intention of introducing "in-band OAM" and "out-of-band OAM"
terms is to stress that some performance measurements can be performed
without traversing the same set of links and nodes as the monitored flow.
For example, direct loss measurement, which is collecting counters of
in-profile frames/packets, can be out-of-band. These measurement methods
are classified as passive per RFC 7799. Examples of in-band OAM, in our
view, can be found among active and hybrid (per RFC 7799) measurement
methods.

>
> If no, PLEASE don't use the same abbreviation for slightly different
> things, even in slightly different contexts. I acknowledge the preference
> of those working on a very specific topic to keep their daily used
> terminology as concise as possible, but as someone who tries to get into
> all those topics to understand the bigger picture or to actually implement
> something, specific abbreviations are always a hurdle, especially when they
> have different meanings in slightly different contexts.
>
> So I really like inb-OAM and oob-OAM, because you can really "see" the
> origin in it without repeatedly asking yourself if "i" stands for in-situ,
> in-band, internet, industrial, intelligent...
>
GIM>> Thank you.

>
> If you need a whole new section in an RFC just to explain the different
> uses of I in an abbreviation, you will likely spend more key strokes on
> that section, than on the additional "nb-"s ;-)
>
> Just my two cents.
>
> Greetings,
> Florian
>
>
> On 13.12.23 11:54, Frank Brockners (fbrockne) wrote:
> >
> >
> > When IPPM started working on IOAM, there was a long discussion on naming
> – and the conclusion was that “in-band” as not appropriate for OAM
> information being piggybacked on top of user traffic. This is why the IPPM
> WG concluded to use “In-situ OAM” – or “IOAM” for short, which is what is
> used in RFC9197 and all related documents.
> >
> > Frank
> >
> >
> >
> > *From:*ippm  *On Behalf Of *Greg Mirsky
> > *Sent:* Wednesday, 13 December 2023 04:13
> > *To:* DetNet WG ; mpls ; 6man WG <
> i...@ietf.org>; IETF IPPM WG ; opsawg ;
> Pascal Thubert ; Loa Andersson 
> > *Subject:* [ippm] IOAM, iOAM, and oOAM abbreviations
> >
> >
> >
> > Dear All,
> >
> > Loa and I have discussed these abbreviations to help us find a solution
> that avoids the confusion we found when we came across them. Firstly, what
> they stand for:
> >
> >   * IOAM - In-situ OAM (RFC 9197 <
> https://datatracker.ietf.org/doc/rfc9197/>)
> >   * iOAM - in-band OAM (RAW architecture <
> https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13>)
> >   * oOAM - out-of-band OAM (RAW architecture <
> https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13>)
> >
> > We discussed the issue with Pascal and came to slightly different
> abbreviations for the last two:
> >
> >   * inb-OAM
> >   * oob-OAM
> >
> > We also discord these abbreviations with the RFC Editor. Resulting from
> that, RFC Editor agreed to add IOAM to the RFC Editor Abbreviation List <
> https://www.rfc-editor.org/materials/abbrev.expansion.txt>. The other two
> abbreviations cannot be added at this time. If that is needed, we can ask
> the RFC Editor to add them once the respective RFC is published.
> >
> > We are seeking your feedback on the following:
> >
> >   * Do you see the benefit of introducing two new abbreviations for
> in-band OAM and out-of-band OAM?
> >   * Which set of abbreviations (iOAM/oOAM vs. inb-OAM/oob-OAM) do you
> prefer for being used in IETF?
> >   * Or would you propose another set of abbreviations?
> >
> > Regards,
> >
> > Loa and Greg
> >
> >
> >
> >
> > ___
> > detnet mailing list
> > det...@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] IOAM, iOAM, and oOAM abbreviations

[Greg Mirsky]

Dear All,
Loa and I have discussed these abbreviations to help us find a solution
that avoids the confusion we found when we came across them. Firstly, what
they stand for:

   - IOAM - In-situ OAM (RFC 9197
   )
   - iOAM - in-band OAM (RAW architecture
   )
   - oOAM - out-of-band OAM (RAW architecture
   )

We discussed the issue with Pascal and came to slightly different
abbreviations for the last two:

   - inb-OAM
   - oob-OAM

We also discord these abbreviations with the RFC Editor. Resulting from
that, RFC Editor agreed to add IOAM to the RFC Editor Abbreviation List
. The other two
abbreviations cannot be added at this time. If that is needed, we can ask
the RFC Editor to add them once the respective RFC is published.
We are seeking your feedback on the following:

   - Do you see the benefit of introducing two new abbreviations for
   in-band OAM and out-of-band OAM?
   - Which set of abbreviations (iOAM/oOAM vs. inb-OAM/oob-OAM) do you
   prefer for being used in IETF?
   - Or would you propose another set of abbreviations?

Regards,
Loa and Greg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

[Greg Mirsky]

Hi Thomas,
thank you for the feedback and proposed update. Please find my notes below
tagged by GIM2>>.

Regards,
Greg

On Fri, Aug 18, 2023 at 6:56 AM  wrote:

> Dear Greg,
>
>
>
> Thanks a lot for addressing my comments.
>
>
>
> GIM> It could be easier to take out "flow" altogether. WDYT?
>
>
>
> TG> Let me propose something else:
>
>
>
> Change from
>
>
>
> "When analyzing the availability metrics of a service flow between two
> nodes"
>
>
>
> To
>
>
>
> "When analyzing the availability metrics of a connectivity service between
> two measurement points"
>
GIM2>> Prior to IETF-117 the authors extensively discussed the definition
of a connectivity service. Because we couldn't find it being formulated in
published documents we agreed to avoid referencing it in the PAM document.
I hope that you will agree to the following update:
OLD TEXT:
   When analyzing the availability metrics of a service flow between two
   nodes, a time interval as the unit of PAM needs to be selected.
NEW TEXT:
   When analyzing the availability metrics of a service between two
   measurement points, a time interval as the unit of PAM needs to be
   selected.

>
>
> GIM>> I agree. Check the attached diff.
>
>
>
> TG> Perfect thanks!
>
GIM2>> Great!

>
>
> Best wishes
>
> Thomas
>
>
>
> *From:* Greg Mirsky 
> *Sent:* Monday, August 14, 2023 10:33 PM
> *To:* Graf Thomas, INI-NET-VNC-HCS 
> *Cc:* opsawg@ietf.org; i...@ietf.org
> *Subject:* Re: [OPSAWG] draft-ietf-ippm-pam-04,
> draft-clemm-opsawg-pam-ipfix-00
>
>
>
> Hi Thomas,
>
> thank you for supporting this work and for your helpful comments. Please
> find my notes inlined below tagged by GIM>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jul 26, 2023 at 2:24 PM  wrote:
>
> Dear Alex and Greg,
>
>
>
> I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and
> have some comments and questions.
>
>
>
> Section 3.1 of draft-ietf-ippm-pam-04 (
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-pam-04#section-3.1)
> mentions the term "service flow".
>
>
>
> I haven't been able to find in any IETF document describing/defining the
> term. I suggest to describe it in the terminology section 2.1 and specify
> it as an IPFIX and YANG element.
>
> GIM>> I checked and found that "service flow" is used only once in the
> document:
>
>
>
>When analyzing the availability metrics of a service flow between two
>
>nodes, a time interval as the unit of PAM needs to be selected.
>
>
>
> It could be easier to take out "flow" altogether. WDYT?
>
>
>
> Section 3.3 of draft-ietf-ippm-pam-04 specifies an "Unavailability
> threshold". I suggest to specify in Section 3.1 of
> draft-clemm-opsawg-pam-ipfix-00 (
> https://datatracker.ietf.org/doc/html/draft-clemm-opsawg-pam-ipfix-00#section-3.1)
> this as IPFIX element as well.
>
>
>
> The "service flow" describes that the SLO metrics are measured between two
> nodes. However in draft-clemm-opsawg-pam-ipfix the SLO metrics are measured
> and export on one node. I would appreciate if you could describe how this
> information is being measured. Presumably by leveraging of probing.
>
> GIM>> The PAM document will not specify how to measure but where and what
> to be measured. We will work on clarifying that all PAM metrics are
> measured between two Measurement Points in the PAM IPFIX draft.
>
>
>
> In general I feel that draft-ietf-ippm-pam-04 would benefit of having a
> reference to the Performance Metrics Registry defined in RFC 8911/8912.
>
>  GIM>> I agree. Check the attached diff.
>
>
>
> I would be interested to understand wherever the authors intend to create
> a draft document describing a service YANG module.
>
> GIM>> That's a great suggestion, thank you. Let us discuss it.
>
>
>
> Best wishes
>
> Thomas
>
> ___
> 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] draft-ietf-ippm-pam-04, draft-clemm-opsawg-pam-ipfix-00

[Greg Mirsky]

Hi Thomas,
thank you for supporting this work and for your helpful comments. Please
find my notes inlined below tagged by GIM>>.

Regards,
Greg

On Wed, Jul 26, 2023 at 2:24 PM  wrote:

> Dear Alex and Greg,
>
>
>
> I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and
> have some comments and questions.
>
>
>
> Section 3.1 of draft-ietf-ippm-pam-04 (
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-pam-04#section-3.1)
> mentions the term "service flow".
>
>
>
> I haven't been able to find in any IETF document describing/defining the
> term. I suggest to describe it in the terminology section 2.1 and specify
> it as an IPFIX and YANG element.
>
GIM>> I checked and found that "service flow" is used only once in the
document:


   When analyzing the availability metrics of a service flow between two

   nodes, a time interval as the unit of PAM needs to be selected.


It could be easier to take out "flow" altogether. WDYT?

>
>
> Section 3.3 of draft-ietf-ippm-pam-04 specifies an "Unavailability
> threshold". I suggest to specify in Section 3.1 of
> draft-clemm-opsawg-pam-ipfix-00 (
> https://datatracker.ietf.org/doc/html/draft-clemm-opsawg-pam-ipfix-00#section-3.1)
> this as IPFIX element as well.
>
>
>
> The "service flow" describes that the SLO metrics are measured between two
> nodes. However in draft-clemm-opsawg-pam-ipfix the SLO metrics are measured
> and export on one node. I would appreciate if you could describe how this
> information is being measured. Presumably by leveraging of probing.
>
GIM>> The PAM document will not specify how to measure but where and what
to be measured. We will work on clarifying that all PAM metrics are
measured between two Measurement Points in the PAM IPFIX draft.

>
>
> In general I feel that draft-ietf-ippm-pam-04 would benefit of having a
> reference to the Performance Metrics Registry defined in RFC 8911/8912.
>
 GIM>> I agree. Check the attached diff.

>
>
> I would be interested to understand wherever the authors intend to create
> a draft document describing a service YANG module.
>
GIM>> That's a great suggestion, thank you. Let us discuss it.

>
>
> Best wishes
>
> Thomas
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
<<< text/html; charset="US-ASCII"; name="draft-ietf-ippm-pam-06.diff.html": Unrecognized >>>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WG Adoption Call for draft-tgraf-opsawg-ipfix-on-path-telemetry-01

[Greg Mirsky]

Dear All,
I read the latest version of the draft. I appreciate the work authors put
into making the document clear and easy to read. Proposed IEs are essential
for further developing an out-of-band collection of telemetry information.
I strongly support the adoption of this work by the OPSAWG.
I have two notes to discuss (clearly non-blocking):

   - as I understand it, the scope of this document is on reporting
   delay-related metrics based on the use of IOAM specifically. Is that
   correct understanding? If it is, reflecting that in the title might be
   helpful as other op-path telemetry methods, for example, Alternate Marking,
   might use a different set of IEs.
   - I appreciate you using a picture (Figure 1) to illustrate the use case
   for IEs. It might be helpful for an operator to add more information about
   how IOAM is expected to be used. For example:
  - IOAM Option Types that are applicable to the defined IEs;
  - any special considerations using different IOAM Trace Option-Types;
  - mandatory IOAM Trace-Type.

Regards,
Greg

On Wed, Dec 21, 2022 at 6:26 PM Tianran Zhou  wrote:

> Hi WG,
>
>
>
> This mail starts a WG Adoption Call for
> draft-tgraf-opsawg-ipfix-on-path-telemetry-01.
>
>
> https://datatracker.ietf.org/doc/draft-tgraf-opsawg-ipfix-on-path-telemetry/
>
>
>
> Please reply your supports or objections.
>
> We would really appreciate your comments.
>
>
>
> Since there are holidays, this call will last for 3 weeks, and end on
> Thursday, Jan 12, 2023.
>
>
>
> Cheers,
>
> Tianran (as 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] [ippm] Heads up on draft-ietf-opsawg-yang-vpn-service-pm

[Greg Mirsky]

Hi Bo,
thank you for your quick response to my comment and clarification. The
updates fully address my comments.

Regards,
Greg

On Thu, May 5, 2022 at 5:46 AM Wubo (lana)  wrote:

> Hi Greg,
>
>
>
> Thanks for the comments. STAMP referenced as RFC 8762 has been added as
> one of PM measurement protocol.
>
> Please be aware this model is a network model and does not specifies the
> details of STAMP.
>
> Please check whether rev-08 addresses your concerns:
>
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-yang-vpn-service-pm-08
>
>
>
> Thanks,
>
> Bo
>
> *From:* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Sent:* Wednesday, May 4, 2022 4:54 AM
> *To:* Adrian Farrel 
> *Cc:* IETF IPPM WG ; opsawg ;
> draft-ietf-opsawg-yang-vpn-service...@ietf.org
> *Subject:* Re: [ippm] Heads up on draft-ietf-opsawg-yang-vpn-service-pm
>
>
>
> Hi Adrian,
>
> thank you for bringing this work to my attention. I've read and shared my
> comments earlier. The authors responded promptly and we've worked together
> to address my comments. After reading the current version I have a question
> about the importance of identifying the particular active measurement
> protocol used to measure the reported performance metrics. If reporting the
> protocol used for the performance measurement is deemed essential to
> characterize the accuracy of the measurement method, then I would propose
> to consider several additions to the model:
>
> · adding STAMP described in RFCs 8762 and 8972 to the list of
> active measurement methods
>
> · adding Error Estimate for Session-Sender and
> Session-Reciever/Session-Reflector for OWAMP, TWAMP, and STAMP
>
> Thank you for your kind consideration.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Apr 29, 2022 at 2:48 PM Adrian Farrel  wrote:
>
> Hi,
>
> I'm the document shepherd for draft-ietf-opsawg-yang-vpn-service-pm. It has
> completed WG last call in the OPSAWG.
>
> The work may be of interest to IPPM and you might want to watch out for the
> IETF last call which will be along in due course.
>
> But I'm sure that the authors would welcome any comments you have at any
> time.
>
> Best,
> Adrian
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [ippm] Heads up on draft-ietf-opsawg-yang-vpn-service-pm

[Greg Mirsky]

Hi Adrian,
thank you for bringing this work to my attention. I've read and shared my
comments earlier. The authors responded promptly and we've worked together
to address my comments. After reading the current version I have a question
about the importance of identifying the particular active measurement
protocol used to measure the reported performance metrics. If reporting the
protocol used for the performance measurement is deemed essential to
characterize the accuracy of the measurement method, then I would propose
to consider several additions to the model:

   - adding STAMP described in RFCs 8762 and 8972 to the list of active
   measurement methods
   - adding Error Estimate for Session-Sender and
   Session-Reciever/Session-Reflector for OWAMP, TWAMP, and STAMP

Thank you for your kind consideration.

Regards,
Greg

On Fri, Apr 29, 2022 at 2:48 PM Adrian Farrel  wrote:

> Hi,
>
> I'm the document shepherd for draft-ietf-opsawg-yang-vpn-service-pm. It has
> completed WG last call in the OPSAWG.
>
> The work may be of interest to IPPM and you might want to watch out for the
> IETF last call which will be along in due course.
>
> But I'm sure that the authors would welcome any comments you have at any
> time.
>
> Best,
> Adrian
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] A question on the definitions of SDP and SAP

[Greg Mirsky]

Hi Med,
thank you for the additional information. In my understanding, please
correct me if it is off, L3 and L2 VPNs are technologies that can be used
to realize an IETF Network Slice. If that is the case, then the SAP in, for
example, an L3 VPN is also SDP of the IETF Network Slice. Am I
missing something?

Kind regards,
Greg

On Tue, Mar 22, 2022 at 5:43 AM  wrote:

> Hi Greg,
>
>
>
> Other examples can be an L3 VPN network access (RFC9182) or L2 VPN network
> access (draft-ietf-opsawg-l2nm).
>
>
>
> FWIW, the SAP spec include these notes:
>
>
>
> (1)
>
>
>
>For example,
>
>this concept is used to decide where to attach and, thus, deliver the
>
>service in the Layer 3 VPN Service Model (L3SM) [*RFC8299*] and the
>
>Layer 2 VPN Service Model (L2SM) [*RFC8466*].  It can also be used to
>
>retrieve where services, such as the Layer 3 VPN Network Model (L3NM)
>
>[*RFC9182*], and the Layer 2 VPN Network Model (L2NM)
>
>[*I-D.ietf-opsawg-l2nm*], are delivered to customers.
>
>
>
> (2)
>
>
>
>   For example, 'sap-id' may be the VPN network access identifier in
>
>   *Section 7.6 of [RFC9182]*.  An example to illustrate the use of
>
>   this attribute during service creation is provided in *Appendix D*.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky 
> *Envoyé :* mardi 22 mars 2022 10:34
> *À :* BOUCADAIR Mohamed INNOV/NET 
> *Cc :* Adrian Farrel ; TEAS WG ;
> opsawg 
> *Objet :* Re: A question on the definitions of SDP and SAP
>
>
>
> Hi Med,
>
> thank you for pointing this out to me. I have a follow-up question. If I
> understand that note correctly, SDP is positioned as an example, a
> realization of SAP in IETF Network Slice. What could be other examples or
> realizations of SAP?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Mar 21, 2022 at 4:50 AM  wrote:
>
> Hi Greg,
>
>
>
> The slice draft already says the following:
>
>
>
>   An SDP may be abstracted as a Service Attachment Point (SAP)
>
>   [I-D.ietf-opsawg-sap] for the purpose generalizing the concept
>
>   across multiple service types and representing it in management
>
>   and configuration systems.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky 
> *Envoyé :* lundi 21 mars 2022 12:17
> *À :* Adrian Farrel ; TEAS WG ;
> opsawg ; BOUCADAIR Mohamed INNOV/NET <
> mohamed.boucad...@orange.com>
> *Objet :* A question on the definitions of SDP and SAP
>
>
>
> Hi Adrian,
>
> I've read the draft-ietf-teas-ietf-network-slices
> <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/> (many
> thanks for all your work on it!) and I've got a question. It appears to me
> that the definition of a Service Demarcation Point section 2.1) as the
> point of where the IETF Network Slice service is delivered by the provider
> to a customer is similar to the definition of a Service Attachment Point in
> draft-ietf-opsawg-sap
> <https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/> as an
> "abstraction of the network reference points where network services can be
> delivered to customers." Hence my question. Is there an intended difference
> between SDP and SAP that is indicated by using different terms?
>
>
>
> Regards,
>
> Greg
>
> _
>
>
>
> 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.
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des infor

Re: [OPSAWG] A question on the definitions of SDP and SAP

[Greg Mirsky]

Hi Med,
thank you for pointing this out to me. I have a follow-up question. If I
understand that note correctly, SDP is positioned as an example, a
realization of SAP in IETF Network Slice. What could be other examples or
realizations of SAP?

Regards,
Greg

On Mon, Mar 21, 2022 at 4:50 AM  wrote:

> Hi Greg,
>
>
>
> The slice draft already says the following:
>
>
>
>   An SDP may be abstracted as a Service Attachment Point (SAP)
>
>   [I-D.ietf-opsawg-sap] for the purpose generalizing the concept
>
>   across multiple service types and representing it in management
>
>   and configuration systems.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky 
> *Envoyé :* lundi 21 mars 2022 12:17
> *À :* Adrian Farrel ; TEAS WG ;
> opsawg ; BOUCADAIR Mohamed INNOV/NET <
> mohamed.boucad...@orange.com>
> *Objet :* A question on the definitions of SDP and SAP
>
>
>
> Hi Adrian,
>
> I've read the draft-ietf-teas-ietf-network-slices
> <https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/> (many
> thanks for all your work on it!) and I've got a question. It appears to me
> that the definition of a Service Demarcation Point section 2.1) as the
> point of where the IETF Network Slice service is delivered by the provider
> to a customer is similar to the definition of a Service Attachment Point in
> draft-ietf-opsawg-sap
> <https://datatracker.ietf.org/doc/draft-ietf-opsawg-sap/> as an
> "abstraction of the network reference points where network services can be
> delivered to customers." Hence my question. Is there an intended difference
> between SDP and SAP that is indicated by using different terms?
>
>
>
> Regards,
>
> Greg
>
> _
>
> 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.
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] A question on the definitions of SDP and SAP

[Greg Mirsky]

Hi Adrian,
I've read the draft-ietf-teas-ietf-network-slices
 (many
thanks for all your work on it!) and I've got a question. It appears to me
that the definition of a Service Demarcation Point section 2.1) as the
point of where the IETF Network Slice service is delivered by the provider
to a customer is similar to the definition of a Service Attachment Point in
draft-ietf-opsawg-sap
 as an
"abstraction of the network reference points where network services can be
delivered to customers." Hence my question. Is there an intended difference
between SDP and SAP that is indicated by using different terms?

Regards,
Greg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [spring] New Version Notification for draft-tgraf-opsawg-ipfix-srv6-srh-00.txt

[Greg Mirsky]

Hi Thomas, et al.,
what do you think of the new SPRING WG draft that introduces two methods of
the compressed SRv6 SID list encoding in the SRH

?

Regards,
Greg

On Sat, Feb 12, 2022 at 12:10 AM  wrote:

> Dear Yao,
>
> Thanks a lot for the detailed description. Both understood,  acknowledged
> and being merged to the -01 version. Feedback welcome.
>
>
> https://www.ietf.org/rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-00.txt&url2=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-tgraf-opsawg-ipfix-srv6-srh-01.txt
>
> I will publish -01 in the upcoming weeks before IETF 113.
>
> Best wishes
> Thomas
>
> -Original Message-
> From: liu.ya...@zte.com.cn 
> Sent: Monday, February 7, 2022 10:42 AM
> To: Graf Thomas, INI-NET-TCZ-ZH1 
> Cc: spr...@ietf.org
> Subject: Re:[spring] New Version Notification for
> draft-tgraf-opsawg-ipfix-srv6-srh-00.txt
>
> Hi Thomas,
>
> Sorry for the late reply. Please see inline [Yao2].
> > [Yao] Segments left is one of the elements to identify an SRH. For
> example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB)
> (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also
> useful when exporting SRv6 information.
> Would you agree that ipv6SRHSegmentList at node egress would be equal to
> Segments left? Or in other words segments left would only differ at ingress
> to ipv6SRHSegmentList. Correct? If yes, than I think I got your point.
> Would you please describe me what kind of use case you have in mind.
> [Yao2] I mean without segment left, it's difficult to distinguish between
> packets of the same segment list in some cases.
> Below is one scenario I can think of. The corresponding segment list of
> path 1--A--2--3--1--A--4 is .
> 3
>   /   \
>  / \
> 1   2
>  \ /
>   \   /
> A-4
> The flow passes node A twice.
> The first time, the packet is
> (SA,DA=SID-A).
> The second time, the packet is
> (SA,DA=SID-A).
> If one wants to collect the info of these two traffic separately, the
> segment left element is needed.
> But to be honest, I'm not sure whether this requirement is strong.
>
> > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while
> other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are
> defined. What if the user want to export the SRH TLV info of the packets?
> You mean the entire SRH header without disassemble the dimensions into
> IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this
> makes a lot of sense and I consider this to the -01 version of the
> document.
> [Yao2] Yes, that's what I mean.
>
> Best Regards,
> Yao
>
>
>
>
>
> --原始邮件--
> 发件人：thomas.g...@swisscom.com
> 收件人：刘尧00165286;
> 抄送人：spr...@ietf.org;
> 日 期 ：2022年01月30日 14:17
> 主 题 ：Re: [spring] New Version Notification for
> draft-tgraf-opsawg-ipfix-srv6-srh-00.txt
> Hi Yao
> Thanks a lot for your input.
> > [Yao] Segments left is one of the elements to identify an SRH. For
> example, (SA,DA=SIDB) (SIDB,SIDC,SIDB,SIDA; SL=2) and (SA,DA=SIDB)
> (SIDB,SIDC,SIDB,SIDA; SL=0) are different. So I think segments left is also
> useful when exporting SRv6 information.
> Would you agree that ipv6SRHSegmentList at node egress would be equal to
> Segments left? Or in other words segments left would only differ at ingress
> to ipv6SRHSegmentList. Correct? If yes, than I think I got your point.
> Would you please describe me what kind of use case you have in mind.
> > [Yao] I mean that IPFIX IE for SRH TLV is not defined in the draft while
> other main elements of SRH(SRHFlags,SRHTag,ipv6SRHSegmentList...) are
> defined. What if the user want to export the SRH TLV info of the packets?
> You mean the entire SRH header without disassemble the dimensions into
> IPFIX entities. Like IE 316 mplsLabelStackSection. Correct? I think this
> makes a lot of sense and I consider this to the -01 version of the document.
> Looking forward to your clarifications.
> Best wishes
> Thomas
> -Original Message-
> From: liu.ya...@zte.com.cn 
> Sent: Tuesday, January 25, 2022 10:27 AM
> To: Graf Thomas, INI-NET-TCZ-ZH1 
> Cc: spr...@ietf.org
> Subject: Re:[spring] New Version Notification for
> draft-tgraf-opsawg-ipfix-srv6-srh-00.txt
> Hi Thomas,
> Please see inline [Yao].
> Best Regards,
> Yao
> --原始邮件--
> 发件人：thomas.g...@swisscom.com
> 收件人：刘尧00165286;
> 抄送人：spr...@ietf.org;
> 日 期 ：2022年01月23日 01:16
> 主 题 ：Re: [spring] New Version Notification for
> draft-tgraf-opsawg-ipfix-srv6-srh-00.txt
> Hi Yao,
> Many thanks for the review and feedback.
> > 1) But this draft describes the routing protocol where the last SRv6
> segment has been learned from, instead of the SRv6 segment to be processed
> by the current hop.
> I am going to rephrase the sentences to refe

Re: [OPSAWG] A review of draft-ietf-opsawg-yang-vpn-service-pm-01

[Greg Mirsky]

Hi Adrian, the Authors, and All,
thank you Adrian for reviewing the draft and inviting further discussion.
I've commented on this work earlier suggesting considering the performance
metrics listed in the STAMP YANG data model. I appreciate that the Authors
have found them helpful and included them in this model. But I still wonder
what, if anything, is special for a VPN service from a performance
metrics perspective compared to, for example, an underlay? Would it be
possible and simpler to have a single PM data model applicable to any
underlay or overlay network?

Regards,
Greg

On Sun, Jan 16, 2022 at 8:16 AM Adrian Farrel  wrote:

> Hi authors,
>
> This draft has been safely inside the OPSAWG for a while, so I though
> it was probably due a review.
>
> "The usual" two top-level issues:
>
> - The draft expired earlier this month, so you need at a least a
>   keep-alive version.
>
> - The draft has more than five front-page authors so the AD or RFC
>   Editor will object. It is probably best for you to resolve this issue
>   sooner rather than later.
>
> Otherwise, my comments are a collection of small nits and nothing
> alarming.  Thanks for your work on this document.
>
> Best,
> Adrian
>
> == Questions ==
>
> Looking at Figure 1, an obvious question is why this model doesn't
> augment the L2/L3NM or the common VPN model. It is OK (for me) that you
> have chosen to augment the network topology model, but it is not clear
> to the reader why you have done this.
>
> ---
>
> I wonder whether the work in this document would benefit from using
> data tags (draft-ietf-netmod-node-tags). I might be wrong, but it seems
> particularly related and useful.
>
> ---
>
> If, in Figure 3, VPN1 is configured as hub and spoke with S1A as the
> hub, why is there a link in the virtual network between VN2 and VN3?
>
> ---
>
> 5.
>
> General question about counters based on my memory of how we did MIBs
> (So I am old! Quite possible that YANG does this differently.) Don't
> you need something to handle resets? That is, to distinguish between
> wrapping and resetting, we used to include a timestamp for when the
> counters were last reset. Sometimes this was a timestamp per counter,
> but usually enough for one timestamp across all counters.
>
> (This probably makes a difference to the gauges and percentiles, too.)
>
> Re-reading, it is possible that this is covered by 'reference-time' and
> 'measurement-interval'.  If so, this could be a lot clearer in 4.4.
>
> ---
>
> 5.
>
>   leaf pm-source {
> type string;
> config false;
> description
>   "The OAM tool used to collect the PM data.";
>   }
>
> I'm not convinced that using a string here is helpful. How does the
> device know what string to use to convey meaning to the application?
>
> Or is the point that this is just printable information for display and
> human consumption? If so, perhaps a note to this effect in Section 4.4.
>
> == Nits ===
>
> Abstract
>
> It would be nice to say what the model in 8345 is. So...
>
>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.
>
> ---
>
> Abstract
>
> I think PM stands for 'performance monitoring' not 'network performance
> monitoring', so for the avoidance of doubt...
>
>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.
>
> ---
>
> 2.
>
> You have the BCP 14 boilerplate, but the uses of "should" and "must" in
> the document are in lower case. There is one use of upper case "MAY" in
> the Security Considerations which should be, I think, lower case since
> it is a statement of fact not guidance to an implementer of this spec.
>
> ---
>
> 3.
>
> s/Such an information/Such information/
> s/should be setup/should be set up/
> s/using network performance/using a network performance/
> s/information from Traffic/information from the Traffic/
>
> ---
>
> The Legend for Figure 3 could usefully add
>S:Site
>
> It might also help to indicate the difference between links that are
> shown as | and mappings that are shown as :
>
> ---
>
> 4.2
>
> s/do not need to be extended./does not need to be extended./
>
> ---
>
> 4.2, 4.3
>
> Figures 4 and 5 should be referred to from the text.
>
> ---
>
> 4.4
>
> OLD
>   Setting a percentile into
>   0.00 indicates the client is not interested in receiving
>   particular percentile.
> NEW
>   Setting a percentile to
>   0.00 indicates the client is not interested in receiving
>   that particular percentile.
> END
>
> s/metric (e.g./metric (e.g.,/
>
> OLD
>"reference-time" "measurement-interval"
> NEW
>"reference-time" and "measurement-interval"
> END
>
> ---
>
> 5.
>
>The "ietf-networ

Re: [OPSAWG] A question on the use of "direction" in draft-ietf-opsawg-yang-vpn-service-pm

[Greg Mirsky]

Hi Bo,
thank you for carefully considering my notes. Please find my follow-up
notes in-lined below under the GIM>> tag.

Regards,
Greg

On Thu, Nov 4, 2021 at 5:14 AM Wubo (lana)  wrote:

> Hi Greg,
>
>
>
> Thanks for the comments. Please see inline.
>
>
>
> Thanks,
>
> Bo
>
>
>
> *发件人:* Greg Mirsky [mailto:gregimir...@gmail.com]
> *发送时间:* 2021年11月4日 4:03
> *收件人:* opsawg ;
> draft-ietf-opsawg-yang-vpn-service...@ietf.org
> *主题:* A question on the use of "direction" in
> draft-ietf-opsawg-yang-vpn-service-pm
>
>
>
> Dear Authors,
>
> thank you for your work on this model. I read the document and have one
> question and a single suggestion for your consideration:
>
>- I find the description of the "direction" somewhat confusing. Can
>you give an example when the "direction" is set to "two-way". In that case,
>how that affects the reported performance metrics. I can imagine that in
>some cases, a performance metric calculated using a round-trip measured
>value. In that case, it is helpful to indicate the source of the metric as
>RT/2 vs. one-way.
>
> *[Bo] Thanks. This makes sense.  Instead of “direction” definition, I
> suggest to directly define “ two-way-delay”, so when the “pm-source” uses
> two-way measurement, it is easier to read.*
>
GIM>> I am not sure that would be useful. If all reportable performance
metrics are for an ordered pair of measurement points, then, as I see it, a
metric is always unidirectional, i.e., one-way. I agree that it may be
obtained using a one-way or two-way measurement method. What seems
important to indicate, is whether the reported metric is using or based on
a one-way measurement or calculated using a round-trip measurement. I agree
that re-naming the "direction" definition is helpful and I might propose it
changed to "source", which is "one-way" or "round-trip".

> I may suggest changing default values for percentiles. Based on the
> feedback we've received, the STAMP YANG model uses p95, p99, and p99.9 as
> default values for low, middle, and high percentile respectively.
>
> *[Bo] Thanks for the suggestion. Looking at STAMP YANG, I can’t find the
> description on this. Could you elaborate on why these values are defined?*
>
GIM>> As I recall it, we had comments on the IPPM WG mailing list and at a
meeting in the course of presenting the work. I also used feedback received
in discussing IP Services SOAM at MEF.

Regards,
>
> Greg
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] A question on the use of "direction" in draft-ietf-opsawg-yang-vpn-service-pm

[Greg Mirsky]

Dear Authors,
thank you for your work on this model. I read the document and have one
question and a single suggestion for your consideration:

   - I find the description of the "direction" somewhat confusing. Can you
   give an example when the "direction" is set to "two-way". In that case, how
   that affects the reported performance metrics. I can imagine that in
   some cases, a performance metric calculated using a round-trip measured
   value. In that case, it is helpful to indicate the source of the metric as
   RT/2 vs. one-way.
   - I may suggest changing default values for percentiles. Based on the
   feedback we've received, the STAMP YANG model uses p95, p99, and p99.9 as
   default values for low, middle, and high percentile respectively.

Regards,
Greg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Hi Med,
thank you for your thoughtful consideration of my comments. I have another
question about the significance of the local-multiplier (formerly
detection-multiplier). The description seems not changed and it states:
"The detection interval for the BFD session
 is calculated by multiplying the value of
 the negotiated transmission interval by
 the detection multiplier value.";
I will note that the detection multiplier value used by a BFD system to
calculate the Detection Time is not its local Detection Multiplier but the
value of the Detect Mult field in the received BFD control packet. In other
words, that is the local-multiplier of the remote BFD peer. Section 6.8.4
in RFC 5880 <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.4>
describes how the Detection Time is calculated for "classic" p2p BFD. Note,
the Detection Time for a MultipointTail in p2mp session is calculated
differently, according to Section 5.11 RFC 8562.

Regards,
Greg

On Fri, Sep 3, 2021 at 12:35 AM  wrote:

> Hi Greg,
>
>
>
> FWIW, the agreed changes are now implemented in the module. You can track
> them at:
>
>
> https://github.com/IETF-OPSAWG-WG/lxnm/commit/9b97016743a355f2b7737288dfaedebcdc47c9b8
>
>
>
> Also, made the companion changes to the I-D:
> https://tinyurl.com/l3nm-latest
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Envoyé :* mercredi 1 septembre 2021 15:25
> *À :* BOUCADAIR Mohamed INNOV/NET 
> *Cc :* Jeffrey Haas ; draft-ietf-opsawg-l3sm-l...@ietf.org;
> opsawg ; rtg-bfd WG 
> *Objet :* Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
>
>
>
> Hi Med,
>
> thank you for your thoughtful consideration of my late comments.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Sep 1, 2021 at 6:21 AM  wrote:
>
> Re-,
>
> The IETF LC was actually closed since 2021-08-06.
>
> Even if the IETF LC is closed, the current BFD comments will be part of
> the comments we will be addressing in the next iteration. For your record,
> we have already recorded the name alignment fix, the missing default
> clause, holdtime explanation, and session type indication.
>
> If there are any other comments, please let us know.
>
> Thank you.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Jeffrey Haas [mailto:jh...@pfrc.org]
> > Envoyé : mercredi 1 septembre 2021 14:38
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : Greg Mirsky ; draft-ietf-opsawg-l3sm-
> > l...@ietf.org; opsawg ; rtg-bfd WG  > b...@ietf.org>
> > Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
> >
> > Med,
> >
> > On Wed, Sep 01, 2021 at 06:48:43AM +,
> > mohamed.boucad...@orange.com wrote:
> > > Hi Jeff,
> > >
> > > Actually, except local-multiplier that we call detection-
> > multiplier,
> > > the same names are used in both drafts. We can fix that one.
> >
> > Certainly a start.
> >
> > > Please note that we are not using the interval-config-type choice
> > > given that the single case can be covered by setting
> > > desired-min-tx-interval and required-min-rx-interval to the same
> > value.
> >
> > This is true.  It's also true that that style entered the BFD YANG
> > model because a unified-only mechanism is what some vendors have
> > implemented.  If their implementations don't cover the split mode
> > you're requiring them to create a deviation.
> >
> > > It is then straightforward to
> > > map it the device module depending whether single-minimum-interval
> > > feature is supported or not. We don't want to complicate the
> > network
> > > view of the service with such device-level features.
> >
> > There is always a tension between service models and the needs of
> > the underlying device model.
> >
> > That said, you're losing the benefits of work already done.  As an
> > example, you're missing the default detection multiplier because
> > you're doing the work yourself rather than leveraging other work.
> > This means you're requiring the model users to always provision a
> > paramter that is usually left as a default.
> >
> > Clearly the BFD Working Group can't force you to use our work in
> > your model, especially if there are features that aren't a clean
> > fit.  That said, when it comes IETF review time, the choice to go-
> > it-alone will be noted so that the YANG doctors can do an
> &

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Hi Med,
thank you for your thoughtful consideration of my late comments.

Regards,
Greg

On Wed, Sep 1, 2021 at 6:21 AM  wrote:

> Re-,
>
> The IETF LC was actually closed since 2021-08-06.
>
> Even if the IETF LC is closed, the current BFD comments will be part of
> the comments we will be addressing in the next iteration. For your record,
> we have already recorded the name alignment fix, the missing default
> clause, holdtime explanation, and session type indication.
>
> If there are any other comments, please let us know.
>
> Thank you.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Jeffrey Haas [mailto:jh...@pfrc.org]
> > Envoyé : mercredi 1 septembre 2021 14:38
> > À : BOUCADAIR Mohamed INNOV/NET 
> > Cc : Greg Mirsky ; draft-ietf-opsawg-l3sm-
> > l...@ietf.org; opsawg ; rtg-bfd WG  > b...@ietf.org>
> > Objet : Re: A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
> >
> > Med,
> >
> > On Wed, Sep 01, 2021 at 06:48:43AM +,
> > mohamed.boucad...@orange.com wrote:
> > > Hi Jeff,
> > >
> > > Actually, except local-multiplier that we call detection-
> > multiplier,
> > > the same names are used in both drafts. We can fix that one.
> >
> > Certainly a start.
> >
> > > Please note that we are not using the interval-config-type choice
> > > given that the single case can be covered by setting
> > > desired-min-tx-interval and required-min-rx-interval to the same
> > value.
> >
> > This is true.  It's also true that that style entered the BFD YANG
> > model because a unified-only mechanism is what some vendors have
> > implemented.  If their implementations don't cover the split mode
> > you're requiring them to create a deviation.
> >
> > > It is then straightforward to
> > > map it the device module depending whether single-minimum-interval
> > > feature is supported or not. We don't want to complicate the
> > network
> > > view of the service with such device-level features.
> >
> > There is always a tension between service models and the needs of
> > the underlying device model.
> >
> > That said, you're losing the benefits of work already done.  As an
> > example, you're missing the default detection multiplier because
> > you're doing the work yourself rather than leveraging other work.
> > This means you're requiring the model users to always provision a
> > paramter that is usually left as a default.
> >
> > Clearly the BFD Working Group can't force you to use our work in
> > your model, especially if there are features that aren't a clean
> > fit.  That said, when it comes IETF review time, the choice to go-
> > it-alone will be noted so that the YANG doctors can do an
> > appropriately thorough audit.
> >
> > The BFD Working Group is also happy to help with review once it's
> > time.
> >
> > -- Jeff
>
>
> _
>
> 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.
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Hi Med,
thank you for your detailed feedback; much appreciated. I think that I now
understand better the philosophy of the model. But I will note that RFC
5880 does not cover RFC 7880 and 8562 (both have updated RFC 5880). It
seems that adding bfd-session-type could be a very useful enhancement to
the OAM container. Values for the new parameter should reflect values
defined for bfd.SessionType in RFCs 7880, 8562, and 8563:

   - SBFDInitiator;
   - SBFDReflector;
   - PointToPoint;
   - MultipointHead;
   - MultipointTail;
   - MultipointClient

And my apologies for my late comments.

Regards,
Greg

On Mon, Aug 30, 2021 at 5:19 AM  wrote:

> Hi Greg,
>
>
>
> Thank you for checking the OAM part and for sharing this comment.
>
>
>
> As you can read in both sections 4 and 5, this model is ** not a device
> configuration model **. The focus is on aspects that can be triggered by
> service requests and managed by the network controller. This network view
> of the service will be then enriched (with other sources such as local
> templates/profiles/defaults) to derive the exhaustive configuration that
> will be enforced in involved devices to deliver the requested service.
>
>
>
> With that rationale in mind, you can understand why we don’t import device
> models but point to the authoritative RFCs for aspects that we think make
> sense to be tweaked at the network-level.
>
>
>
> Thanks.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Envoyé :* samedi 28 août 2021 04:56
> *À :* draft-ietf-opsawg-l3sm-l...@ietf.org; opsawg ;
> rtg-bfd WG 
> *Objet :* A question on OAM section in draft-ietf-opsawg-l3sm-l3nm
>
>
>
> Dear Authors,
>
> thank you for your work on this document. I've read the draft and have a
> question, and a suggestion. Section 7.6.4
> <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4>
>  describes
> how BFD is controlled in vpn-common. I've noticed that you use references
> to RFC 5880. While that is the basis for all subsequent BFD documents, for
> BFD YANG data model draft-ietf-bfd-yang
> <https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more
> useful. Perhaps the container oam can re-use grouping base-cfg-parms.
>
> What are your thoughts?
>
>
>
> Regards,
>
> Greg
>
> _
>
> 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.
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Hi Tom,
I understand that the missref that the BFD YANG data model got into for so
long caused some frustration and uncertainty. As of late, the authors, WG
Chairs and the AD have taken actions to untangle the situation and progress
most of the data models leaving a smaller part in missreff. I don't have
first-hand information on how close to the publication of the updated main
body of the BFD YANG data model is. I hope it is not too far.
I have several questions about the BFD container
in draft-ietf-opsawg-l3sm-l3nm. I hope I can use the opportunity and ask
them even we're past the LC phase:

   - Which mode of a BFD session is assumed for the model? For example, is
   it Asynchronous or Demand; with Echo or without; single-hop or multi-hop?
   - Which BFD session types the data model is required to support? For
   example, "classic" RFC 5880, S-BFD per RFC 7880, or BFD for multipoint
   networks?
   - What behavior of a BFD system is controlled by the holdtime? Can you
   point to the text in RFC 5880 that defines the expected behavior?


Regards,
Greg

On Sat, Aug 28, 2021 at 5:07 AM tom petch  wrote:

> From: Rtg-bfd  on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> Sent: 28 August 2021 03:56
>
> Dear Authors,
> thank you for your work on this document. I've read the draft and have a
> question, and a suggestion. Section 7.6.4<
> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-l3sm-l3nm#section-7.6.4>
> describes how BFD is controlled in vpn-common. I've noticed that you use
> references to RFC 5880. While that is the basis for all subsequent BFD
> documents, for BFD YANG data model draft-ietf-bfd-yang<
> https://datatracker.ietf.org/doc/draft-ietf-bfd-yang/> may be more
> useful.
>
> 
> Greg
>
> I think that the authors have got this one right (although I disagree with
> much else as I have commented on Last Call:-(,   If you look at the history
> of bfd-yang you will see that nothing has happened to it for over three
> years despite concerted efforts to get it moving, so in the interests of
> this becoming an RFC within the next three years (!), I would not want to
> see the reference changed.
>
> Tom Petch
>
> Perhaps the container oam can re-use grouping base-cfg-parms.
> What are your thoughts?
>
> Regards,
> Greg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] A question on OAM section in draft-ietf-opsawg-l3sm-l3nm

[Greg Mirsky]

Dear Authors,
thank you for your work on this document. I've read the draft and have a
question, and a suggestion. Section 7.6.4

describes
how BFD is controlled in vpn-common. I've noticed that you use references
to RFC 5880. While that is the basis for all subsequent BFD documents, for
BFD YANG data model draft-ietf-bfd-yang
 may be more useful.
Perhaps the container oam can re-use grouping base-cfg-parms.
What are your thoughts?

Regards,
Greg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] A question about relationship between draft-song-opsawg-ifit-framework and draft-wang-idr-bgp-ifit-capabilities

[Greg Mirsky]

Dear OPSAWG and IDR WGs,
I've been following the discussion of draft-song-opsawg-ifit-framework
 in the
OPSAWG. The on-path telemetry is a very important element of the OAM
toolset. The IFIT framework discussion is helping to better understand how
the op-path telemetry can help operators. As you can see, that document is
not yet been adopted by the WG.
I've read draft-wang-idr-bgp-ifit-capabilities and have noticed that though
it defines elements of the control plane for the IFIT, it does not
reference the IFIT Framework document. That seems like an unfortunate
omission. Also, it might be appropriate to get the IFIT framework
progressed before advancing documents on the control plane extensions
supporting functionalities defined in the framework.
What are your opinions?

Regards,
Greg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-yang-07

[Greg Mirsky]

Dear All,
I've read the draft and support its adoption by the OPSAWG.

Regards,
Greg

>
>
> -Original Message-
> From: OPSAWG  on behalf of Henk Birkholz <
> henk.birkh...@sit.fraunhofer.de>
> Date: Tuesday, 27 April 2021 at 20:02
> To: opsawg 
> Subject: [OPSAWG] 🔔 WG Adoption Call for
> draft-claise-opsawg-service-assurance-yang-07
>
> Dear OPSAWG members,
>
> this starts a call for Working Group Adoption for
>
> >
> https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-yang-07
>
> ending on Tuesday, May 18th.
>
> As a reminder, this I-D describes YANG modules intended to facilitate
> the aggregation of an assurance graph about the health of services and
> sub-services in a system of interconnected network devices. To achieve
> that, the I-D defines modules for graph updates about (sub-)services
> and
> corresponding health and symptom knowledge acquired via assurance
> telemetry.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> ___
> 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 mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

[Greg Mirsky]

Dear All,
I've read the draft and support its adoption by the OPSAWG. The proposed
approach to service assurance is powerful and extensible.
I have several questions for the authors and appreciate their consideration:

   - Is the architecture intended to quantify service degradation?
   - A health score of 100 signifies a perfectly operational sub-service
   according to the definition. If, for example, the sub-service is an
   interface. how the "perfect operational level" can be defined for packet
   drops?
   - Section 3.9 is stated:

The SAIN architecture requires the Network Time Protocol (NTP) ...

I agree that for the correlation of the information collected from agents,
clocks must be synchronized. And in fact, NTP is broadly used to
synchronized instances of the control and management plane. But, on the
other hand, other protocols are used, e.g. IEEE-1588v2, a.k.a. PTP, to
synchronize devices on the data plane. It appears that it could be easier
to indicate the format of a timestamp used by the agent. Then the SAIN
orchestrator can convert timestamps as needed and correlate regardless of
the clock synchronization protocol and format used.


Regards,
Greg

>
>
> On 4/27/21 14:01, Henk Birkholz wrote:
> > Dear OPSAWG members,
> >
> > this starts a call for Working Group Adoption for
> >
> >>
> https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05
> > ending on Tuesday, May 18th.
> >
> > As a reminder, this I-D describes the health of an interconnected system
> > of network devices and (sub-)services located in that system. A degraded
> > health status is explained via symptom descriptions and the resulting
> > interconnected knowledge is aggregated in an assurance graph.
> >
> > Please reply with your support and especially any substantive comments
> > you may have.
> >
> >
> > For the OPSAWG co-chairs,
> >
> > Henk
> >
> > ___
> > 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 mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] WGLC: Comments on draft-opsawg-ntf

[Greg Mirsky]

Hi Haoyu,
thank you for your kind consideration of my comments.
I apologize for the confusion in the last comment

Information collected in Figure 3 (could be tagged as a table) is very
interesting. I think that it would be beneficial to add more explanation to
the content of the table.

I meant to reference Figure 2, thank you for catching that and asking for
the clarification.

Regards,
Greg

On Wed, Oct 7, 2020 at 1:34 PM Haoyu Song  wrote:

> Hi Greg,
>
>
>
> Thank you very much for the review and comments!
>
> We agree that network telemetry doesn’t contradict with OAM, and in fact,
> OAM is an important part of network telemetry. We will take your insight
> and reword the corresponding paragraphs for clarification. Please see
> inline for more response.
>
>
>
> Best regards,
>
> Haoyu
>
>
>
> *From:* OPSAWG  *On Behalf Of *Greg Mirsky
> *Sent:* Tuesday, October 6, 2020 6:05 PM
> *To:* draft-opsawg-...@ietf.org; opsawg@ietf.org
> *Subject:* [OPSAWG] WGLC: Comments on draft-opsawg-ntf
>
>
>
> Dear Authors,
>
> thank you for your work on this document. I believe that it is important
> to analyze and explain what is network telemetry, how it relates to the
> established tools that support network operations, administration, and
> maintenance (OAM).
>
>
>
> Traditionally, OAM tools support two components of the FCAPS network
> management model - Fault Management (FM) and Performance Monitoring (PM).
> The former, FM, in addition to a failure detection tool, may include, for
> example, a protection switchover coordination protocol. Both FM and PM,
> when in use, produce information that reflects the state of the network.
>
>
>
> Network telemetry may be viewed in two aspects - telemetry information
> that reflects the state of the network and methods used to collect and
> transport telemetry information.
>
>
>
> At this point, I believe, we see that OAM and telemetry have something in
> common - information that characterizes the state of the network, a part of
> the network. If that is the case, then I think that statements about the
> relationship between OAM and telemetry:
>
>As evidenced by the defining
>characteristics and industry practice, network telemetry covers
>technologies and protocols beyond the conventional network
>Operations, Administration, and Management (OAM).  Network telemetry
>promises better flexibility, scalability, accuracy, coverage, and
>performance and allows automated control loops to suit both today's
>and tomorrow's network operation requirements.
>
> or
>
>One difference between the network telemetry and the network OAM is
>that the network telemetry assumes machines as data consumer, while
>the conventional network OAM usually assumes human operators.
>
> are arguable, at the minimum. I believe that there's no contradiction
> between OAM protocols and telemetry collection methods. On the contrary,
> each is essential and is complementary to the other, especially when
> detecting a network failure. To illustrate the latter, I can offer a case
> of monitoring a standby path that protects a working path. While an on-path
> method of collecting information can be used to monitor the condition of
> the working path, the standby can be monitored, in my opinion, only using
> an active OAM method injecting specially constructed test probes.
>
>
>
> Another, rather general comment I have is on using RFC 7799 classification
> of PM methods. I think that the first reference to RFC 7799 is appropriate
> in or before Section 2.4.
>
>
>
> [HS] will do.
>
>
>
> Further, in Section 3, the document differentiates between Event-triggered
> Data and Streaming Data. I think that, based on the current definitions,
> there's little if anything that differentiates these two. Consider the
> definition of Streaming Data:
>
>Streaming Data:  The data are continuously or periodically generated.
>   It can be time series or the dump of databases.  The streaming
>   data reflect realtime network states and metrics and require large
>   bandwidth and processing power.
>
> Can timer expiration be viewed as an event? Also, If the timer that
> defines the frequency of data set export is long, is the information truly
> real-time? Or, doesn't Event-triggered Data reflects the state in real-time?
>
>
>
> [HS] I think I see your point. Timer expiration is an event for sure. I
> think the difference is subtle.  For example, event-triggered data can be
> actively pushed (so it’s real-time) or passively polled (so it’s not
> real-time), but streaming data are always pushed. I’ll make the definition
> and de

[OPSAWG] WGLC: Comments on draft-opsawg-ntf

[Greg Mirsky]

Dear Authors,
thank you for your work on this document. I believe that it is important to
analyze and explain what is network telemetry, how it relates to the
established tools that support network operations, administration, and
maintenance (OAM).

Traditionally, OAM tools support two components of the FCAPS network
management model - Fault Management (FM) and Performance Monitoring (PM).
The former, FM, in addition to a failure detection tool, may include, for
example, a protection switchover coordination protocol. Both FM and PM,
when in use, produce information that reflects the state of the network.

Network telemetry may be viewed in two aspects - telemetry information that
reflects the state of the network and methods used to collect and transport
telemetry information.

At this point, I believe, we see that OAM and telemetry have something in
common - information that characterizes the state of the network, a part of
the network. If that is the case, then I think that statements about the
relationship between OAM and telemetry:
   As evidenced by the defining
   characteristics and industry practice, network telemetry covers
   technologies and protocols beyond the conventional network
   Operations, Administration, and Management (OAM).  Network telemetry
   promises better flexibility, scalability, accuracy, coverage, and
   performance and allows automated control loops to suit both today's
   and tomorrow's network operation requirements.
or
   One difference between the network telemetry and the network OAM is
   that the network telemetry assumes machines as data consumer, while
   the conventional network OAM usually assumes human operators.
are arguable, at the minimum. I believe that there's no contradiction
between OAM protocols and telemetry collection methods. On the contrary,
each is essential and is complementary to the other, especially when
detecting a network failure. To illustrate the latter, I can offer a case
of monitoring a standby path that protects a working path. While an on-path
method of collecting information can be used to monitor the condition of
the working path, the standby can be monitored, in my opinion, only using
an active OAM method injecting specially constructed test probes.

Another, rather general comment I have is on using RFC 7799 classification
of PM methods. I think that the first reference to RFC 7799 is appropriate
in or before Section 2.4.

Further, in Section 3, the document differentiates between Event-triggered
Data and Streaming Data. I think that, based on the current definitions,
there's little if anything that differentiates these two. Consider the
definition of Streaming Data:
   Streaming Data:  The data are continuously or periodically generated.
  It can be time series or the dump of databases.  The streaming
  data reflect realtime network states and metrics and require large
  bandwidth and processing power.
Can timer expiration be viewed as an event? Also, If the timer that defines
the frequency of data set export is long, is the information truly
real-time? Or, doesn't Event-triggered Data reflects the state in real-time?

Information collected in Figure 3 (could be tagged as a table) is very
interesting. I think that it would be beneficial to add more explanation to
the content of the table.

Regards,
Greg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] I,Scope of FIT Capability: a node or a link?

[Greg Mirsky]

Dear All,
I've read these two drafts with interest. In light of the discussion on the
LSR WG list, I've been thinking about the scenarios where IFIT is being
used.
draft-song-opsawg-ifit-framework defines the overall IFIT architecture
that, as I understand it, applicable to different methods of collecting and
transporting telemetry
information. draft-wang-lsr-ifit-node-capability-advertisement is based on
the view that IFIT is a node-wide capability advertised as a binary flag
for each listed method of collecting telemetry information (Option-Type
enabled Flag). On-path telemetry collection is performed in the fast path,
i.e., at a link layer. But a node might include ports with different
capabilities. How such a heterogeneous, IFIT-wise, node will advertise IFIT
Capability? To better use available resources for telemetry information
collection, it might be helpful to advertise IFIT as a capability of a
link, not of a node?
What do you think?

Regards,
Greg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Questions regarding the draft-wu-model-driven-management-virtualization

[Greg Mirsky]

Hi Med,
much appreciate your kind consideration of my comments, detailed responses
to all questions. Few followup notes in-line tagged GIM2>>.

Regards,
Greg

On Mon, Jun 17, 2019 at 8:22 PM  wrote:

> Hi Greg,
>
>
>
> Thank you for the comments.
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky [mailto:gregimir...@gmail.com]
> *Envoyé :* mardi 9 avril 2019 15:33
> *À :* draft-wu-model-driven-management-virtualizat...@ietf.org; RTGWG
> *Objet :* Questions regarding the
> draft-wu-model-driven-management-virtualization
>
>
>
> Dear Authors,
>
> I have some questions related to OAM aspect of service and network
> management automation and much appreciate your consideration:
>
>- I couldn't find Networking Working Group to which the draft seems to
>be attributed. In your opinion, in which of IETF WGs you see this work to
>be the most relevant?
>
> [Med] OPSAWG is a candidate target.
>
>- I couldn't find any reference to the process of Sevice Activation
>Testing (SAT) in the document. Are you planning to cover it later or
>see the absence of any SAT work at IETF as an obstacle to completing the
>closed-loop lifecycle for a service?
>
> [Med] We do explicitly refer to:
>
>o  Dynamic feedback mechanisms that are meant to assess how
>
>   efficiently a given policy (or a set thereof) is enforced from a
>
>   service fulfillment and assurance perspective.
>
> Models that fall under that item can be listed, if any.
>
>- Figure in Section 3 "Network Service and Resource Models" refers to
>OAM and PM separately. Do you see PM not being part of overall OAM
>toolset?
>
> [Med] It is part of OAM. A better name could be used. That’ said, the
> intent was to cover connectivity check matters separately from PM.
>
GIM2>> I'd propose to use "Fault Management OAM". Continuity Check and
Connectivity Verification tools usually viewed as part of a Fault
Management OAM toolset. These tools can further be characterized as
proactive or on-demand (some may be used in both modes). An example of the
former in IETF is, clearly, BFD, and in the latter group are all variances
of echo request/reply method.

>
>- in Section 3.1.2 in regard to LIME models, you've stated: "These three
>models can be used to provide consistent reporting, configuration and
>representation." Do you have evidence in support of this statement?
>
> [Med] That is what the lime effort was about; hence the “can”.
>
GIM2>> Without the evidence of its use (I recall that the LIME WG published
three models) I'd use less assertive language. Perhaps "may be" or "is
intended to".

>
>- Figure 2 lists BFD, LSP Ping, and MPLS-TP models under OAM. In your
>opinion, are these three models sufficient to perform 'F' and 'P' of FCAPS
>network management, i.e., Fault Management and Performance Monitoring,
>adequately? (Should note that LSP Ping and MPLS-TP YANG models are only
>individual drafts);
>
> [Med] Obviously, that list is not exhaustive.
>
> Regards,
>
> Greg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Call for operator's input on use case that requires Network Management Automation.

[Greg Mirsky]

Dear All,
I would propose that IETF send liaison to MEF LSO Committee, and probably
other SDOs, notifying them of the discussion and inviting to share their
comments.

Regards,

On Thu, Mar 28, 2019, 11:24 Qin Wu  wrote:

> Hi, folks:
>
> I would like to draw you attention to IETF YANG automation Framework that
> will be discussed in opsawg WG session 4:10~6:10pm Thursday.
>
> It has already been discussed in rtgwg Tuesday morning session and got a
> few feedback from operators.
>
>
>
> We would like to discuss this work again in opsawg session to further
> solicit feedback on the IETF YANG issues we raised.
>
>
>
> The goal is call for operator’s input on use case that requires network
> management automation and come up approaches or ways to addresses
>
> Challenge issues faced by IETF YANG model standardization.
>
>
>
> The relevant draft is available at:
>
>
> https://datatracker.ietf.org/doc/draft-wu-model-driven-management-virtualization/
>
> The presentation slides is available at:
>
>
> https://datatracker.ietf.org/meeting/104/materials/slides-104-opsawg-draft-wu-model-driven-management-virtualization-00
>
>
>
> Your comments and suggestions are welcome, see you in opsawg session in
> this afternoon.
>
>
>
> -Qin Wu
> ___
> rtgwg mailing list
> rt...@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [nvo3] YANG models for OAM

[Greg Mirsky]

Hi Tissa,
I feel that clear definition of the scope of work is important. From
reading the documents, my impression, is that on-demand OAM tools that
support detection and localization of Loss of Continuity defect are in
scope while the rest of OAM is for further study. I think that it would
benefit the documents and discussion if scope be firmly set.

Regards,
Greg


On Thu, Jul 31, 2014 at 3:53 PM, Tissa Senevirathne <
tissasenevirat...@yahoo.com> wrote:

> Greg
>
> Yes it is, generic YANG model steup the base framework. It can be extended
> to add tools as well as other elements as well technology deviations.
> Alarms etc either be part of this document will be a separate document that
> specifies them. That is the reason we have designed the model as modular as
> possible and extensible as possible.
>
> Please let us know if any of the parts are not extensible or not modular
> enough.
>
> Thanks
> Tissa
>
>
>   On Thursday, July 31, 2014 3:17 PM, Greg Mirsky 
> wrote:
>
>
> Hi Tissa, authors, et. al,
> I've read documents and would like to clarify scope of these documents.
> OAM is not limited to ping and traceroute functions. It even not limited to
> continuity check. And in connectionless networks there would not be
> connectivity verification. And the performance measurement is the big part
> of OAM as well as protection coordination, defect alarms, and etc. Hence my
> question, is it in plans of the authors to address all of OAM in respective
> documents?
>
> Regards,
> Greg
>
>
> On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <
> tsene...@cisco.com> wrote:
>
>  All
>
> We have published YANG model for OAM. #1 draft below place the generic
> framework for OAM, that can be augmented for different technologies. #2 and
> #3 are application of the concept to NVO3 and TRILL,
>
> 1.  http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/
> 2.  http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/
> 3.  http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/
>
> Please review and share your comments
>
> Thanks
> Tissa
>
>
>
> ___
> nvo3 mailing list
> n...@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [nvo3] YANG models for OAM

[Greg Mirsky]

Hi Don,
thank you for the reference. And I'd point that ITU SG15 is working on
standardizing "generic protocol-neutral management information model" for
transport network, including OAM. Hence my question, What is the scope of
these documents?

Regards,
Greg


On Thu, Jul 31, 2014 at 4:31 PM, O'Connor, Don 
wrote:

>  Tissa, Greg, all
>
>
>
> Metro Ethernet Forum has already standardized Yang Modules for Ethernet
> Service OAM Performance Monitoring and Fault Management. Please see MEF 38
> and 39
>
>
>
> http://metroethernetforum.org/carrier-ethernet/technical-specifications
>
>
>
> Regards
>
>
>
> Don
>
>
>
> *From:* L2vpn [mailto:l2vpn-boun...@ietf.org] *On Behalf Of *Tissa
> Senevirathne
> *Sent:* Thursday, July 31, 2014 5:53 PM
> *To:* Greg Mirsky; Tissa Senevirathne (tsenevir)
>
> *Cc:* l2...@ietf.org; opsawg@ietf.org; n...@ietf.org; net...@ietf.org;
> tr...@ietf.org
> *Subject:* Re: [nvo3] YANG models for OAM
>
>
>
> Greg
>
>
>
> Yes it is, generic YANG model steup the base framework. It can be extended
> to add tools as well as other elements as well technology deviations.
> Alarms etc either be part of this document will be a separate document that
> specifies them. That is the reason we have designed the model as modular as
> possible and extensible as possible.
>
>
>
> Please let us know if any of the parts are not extensible or not modular
> enough.
>
>
>
> Thanks
>
> Tissa
>
>
>
> On Thursday, July 31, 2014 3:17 PM, Greg Mirsky 
> wrote:
>
>
>
> Hi Tissa, authors, et. al,
>
> I've read documents and would like to clarify scope of these documents.
> OAM is not limited to ping and traceroute functions. It even not limited to
> continuity check. And in connectionless networks there would not be
> connectivity verification. And the performance measurement is the big part
> of OAM as well as protection coordination, defect alarms, and etc. Hence my
> question, is it in plans of the authors to address all of OAM in respective
> documents?
>
> Regards,
>
> Greg
>
>
>
> On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <
> tsene...@cisco.com> wrote:
>
> All
>
>
>
> We have published YANG model for OAM. #1 draft below place the generic
> framework for OAM, that can be augmented for different technologies. #2 and
> #3 are application of the concept to NVO3 and TRILL,
>
>
>
> 1.  http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/
>
> 2.  http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/
>
> 3.  http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/
>
>
>
> Please review and share your comments
>
>
>
> Thanks
>
> Tissa
>
>
>
>
>
>
> ___
> nvo3 mailing list
> n...@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] [nvo3] YANG models for OAM

[Greg Mirsky]

Hi Tissa, authors, et. al,
I've read documents and would like to clarify scope of these documents. OAM
is not limited to ping and traceroute functions. It even not limited to
continuity check. And in connectionless networks there would not be
connectivity verification. And the performance measurement is the big part
of OAM as well as protection coordination, defect alarms, and etc. Hence my
question, is it in plans of the authors to address all of OAM in respective
documents?

Regards,
Greg


On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <
tsene...@cisco.com> wrote:

>  All
>
>
>
> We have published YANG model for OAM. #1 draft below place the generic
> framework for OAM, that can be augmented for different technologies. #2 and
> #3 are application of the concept to NVO3 and TRILL,
>
>
>
> 1.  http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/
>
> 2.  http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/
>
> 3.  http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/
>
>
>
> Please review and share your comments
>
>
>
> Thanks
>
> Tissa
>
>
>
>
>
> ___
> nvo3 mailing list
> n...@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg