[OPSAWG] [Technical Errata Reported] RFC9487 (7728)

2023-12-12 Thread RFC Errata System 
The following errata report has been submitted for RFC9487,
"Export of Segment Routing over IPv6 Information in IP Flow Information Export 
(IPFIX)".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7728

--
Type: Technical
Reported by: Ahmed Elhassany 

Section: 5.1.10

Original Text
-
5.1.10.  srhSegmentIPv6LocatorLength

   ElementID:  501
   Name:  srhSegmentIPv6LocatorLength
   Data Type Semantics:  default
   Description:  The length of the SRH segment IPv6 locator specified as
  the number of significant bits.  Together with srhSegmentIPv6, it
  enables the calculation of the SRv6 Locator.
   Additional Information:  See Section 3.1 of [RFC8986] for more
  details about the SID format.
   Reference:  RFC 9487

Corrected Text
--
5.1.10.  srhSegmentIPv6LocatorLength

   ElementID:  501
   Name:  srhSegmentIPv6LocatorLength
   Abstract Data Type:  unsigned8
   Data Type Semantics:  default
   Description:  The length of the SRH segment IPv6 locator specified as
  the number of significant bits.  Together with srhSegmentIPv6, it
  enables the calculation of the SRv6 Locator.
   Additional Information:  See Section 3.1 of [RFC8986] for more
  details about the SID format.
   Reference:  RFC 9487

Notes
-
I'm not an expert on RFC8986, I assumed it's unsinged8 but need help to check 
this is the case indeed

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC9487 (draft-ietf-opsawg-ipfix-srv6-srh-14)
--
Title   : Export of Segment Routing over IPv6 Information in IP 
Flow Information Export (IPFIX)
Publication Date: November 2023
Author(s)   : T. Graf, B. Claise, P. Francois
Category: PROPOSED STANDARD
Source  : Operations and Management Area Working Group
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

Re: [OPSAWG] Network Incident Management Side Meeting Summary

2023-12-12 Thread Adrian Farrel 
[Adding the NMOP list - which is currently called NETMO]

 

It's a month later. 

 

Nigel and I have been working on the first version of key terminology. We've
actually made some progress (perhaps slower than our initial enthusiasm
might have suggested).

 

We're just putting the last polish on our first version that we intent to
share "soon."

 

Cheers,

Adrian

 

From: OPSAWG  On Behalf Of Qin Wu
Sent: 10 November 2023 07:46
To: opsawg@ietf.org
Cc: draft-opsawg-evans-discardmo...@ietf.org;
draft-netana-opsawg-nmrg-network-anomaly-semant...@ietf.org;
draft-feng-opsawg-incident-managem...@ietf.org
Subject: [OPSAWG] Network Incident Management Side Meeting Summary

 

Hi, All:

Thanks all folks who participated in network incident management discussion
on Tuesday afternoon. The side meeting was spent one hour exploring network
incident concepts and use cases; three related drafts were discussed. We
received a lot of great contributions for the following drafts being
discussed:

 

https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management/
(Service Level Incident)

https://datatracker.ietf.org/doc/draft-opsawg-evans-discardmodel/ (Anomaly
Detection, Correlation and Mitigation for Packet Discard) 

https://datatracker.ietf.org/doc/draft-netana-opsawg-nmrg-network-anomaly-se
mantics/ (Network anomaly semantics)

 

It was identified that multi-layer Fault Demarcation is related to POI,
however the network incident model can be defined as generic model used for
many other use cases.

 

A few issues were raised in the meeting:

 

1. Network Incident definitions needs more clarity even though it origins
from TMF specification, e.g., how it is related to symptom, anomaly, etc.

2. Besides SLO violation, how network incident is generated based on other
factors, more usage examples are needed for these.

3. Incident terminology is well-defined and should be consistent across the
drafts and, where possible, synced with other SDO meanings (although the
language may vary)

 

Follow up actions include:

 

1. Nigel and Adrian volunteered to help define key terminology uses and
define terms; 

2. Dan to check with MEF and TMF documentation to check for SLO handling,
including incident and problem coordination and definitions; 

3. Open the network incident draft GitHub to the public and use it for draft
development and tracking issues.

 

-Qin (on behalf of Team)

 

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

[OPSAWG] IOAM, iOAM, and oOAM abbreviations

2023-12-12 Thread 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] [IPv6] IOAM, iOAM, and oOAM abbreviations

2023-12-12 Thread Vasilenko Eduard 
IMHO: It is much better when name gives some additional information about the 
object. Like OAM=Operations, Administration, and Maintenance.
When I saw initially iOAM, I believed that “i” was strictly for marketing: 
mimicking “i” in iPhone or iPad (Cargo cult).
Actually, I still suspect that this is the case.
Ed/
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Wednesday, December 13, 2023 6:13 AM
To: DetNet WG ; mpls ; 6man WG ; 
IETF IPPM WG ; opsawg ; Pascal Thubert 
; Loa Andersson 
Subject: [IPv6] 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)
• 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