Dear Med,
Many thanks for the comprehensive review. Much appreciated. We merged all your
input to the upcoming -01 release.
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-01.txt
The diff to the current -00 version can be found
Hi Med,
Benoit will feedback on your reply.
In the meanwhile I like to take the opportunity to get your feedback on an
additional operational consideration section I added based on an off list
feedback I received from a software developer implementing the draft document.
https://raw.githubuser
Hi Med,
You read my mind. If I read yours correctly you mean that there can be multiple
extension headers which could be exposed each with one IE64
ipv6ExtensionHeaders. What we don't know is how many times each header type
occurs and the order in the packet. What is also missing is the distin
Dear OPSAWG, SPRING and 6MAN,
Version -01 of draft-ietf-opsawg-ipfix-srv6-srh has been published to address
various comments from the lists since IETF 114. Many thanks for all who
reviewed and contributed. This is much appreciated.
We added section 6.3, Multiple Segment Routing Headers in the O
Dear OPSAWG chairs,
We believe that the draft is reaching stable state. At IETF 115 hackathon in
November we will have one open-source and one closed-source implementation of
draft-ietf-opsawg-ipfix-srv6-srh-01.
Therefore we believe we are satisfying the conditions for early allocation of
code
Dear Joe,
My apology for late reply. That works for us.
We are in touch with IANA and the IPFIX doctors to clarify the points raised by
Med in regards to the srhFlagsIPv6 and the srhSegmentEndpointBehavior registry.
Once this has been clarified we will publish -02 version.
We would like t
Dear OPSAWG,
On behalf of the authors. The -02 version includes besides editorial changes
and nits the following updates:
- Expanded the terminology section
- The srhFlagsIPv6 and srhSegmentEndpointBehavior registries have now a
reference to the Segment Routing Header registry. Thanks Med for t
Dear OPSAWG and IPPM,
On behalf of the authors. Thank you very much for the comments at IETF 114 in
Philadelphia and on the list.
We addressed your feedback in a new document version and renamed the draft
document from draft-tgraf-opsawg-ipfix-inband-telemetry to
draft-tgraf-opsawg-ipfix-on-p
Dear Al,
Thank you very much for the review and the comments. Much appreciated. I merged
them in the next -01 version as following:
https://www.ietf.org/rfcdiff?url1=https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-teleme
Dear OPSAWG,
No, I'm not aware of any IPR that applies to this draft.
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Wednesday, November 30, 2022 2:55 PM
To: opsawg@ietf.org
Cc: draft-ietf-opsawg-ipfix-srv6-...@ietf.org
Subject: IPR POLL: draft-ietf-opsawg-ipfix-srv6-srh
Authors and contr
Dear OPSAWG,
Writing as one of the authors. Talking to various network operators deploying
SRv6 and network vendors implementing the document in the last few months,
refining the document steadily and arrived at this stable state, I believe this
document is ready for working group last call.
B
Dear Qin,
Thanks a lot for the detailed review and comments. This is much appreciated. My
answers inline.
I am tracking the changes in here:
https://www.ietf.org/rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-srv6-srh-04.txt&url2=https://raw.githubusercontent.com/graf3net/
Dear Med,
Many thanks for the review and my apology that we missed your input on section
5.9
I updated the document on section 5.9 and 6.3 as per input. Please review and
comment before we submit.
https://author-tools.ietf.org/iddiff?url1=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix
Dear OPSAWG and IPPM,
We received at IETF 115 some feedback and comments. We added a terminology
section, the reference to RFC 9232 Network Telemetry Framework and some minor
editorial changes.
As always, feedback and comments are very welcome.
Looking forward for the adoption call at OPSAWG.
Dear OPSAWG,
I am not aware of any IPR related to this draft.
Best wishes
Thomas
From: Tianran Zhou
Sent: Thursday, December 22, 2022 3:56 AM
To: opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject: IPR Poll on draft-tgraf-opsawg-ipfix-on-path-telemetry
Hi Authors a
Dear Greg,
Thanks a lot for the review and feedback.
* 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 telemet
Dear Zhenqiang,
Thanks a lot for your feedback.
I presume with gRPC you are referring to YANG push (RFC 8639, RFC 8641,
draft-ietf-netconf-udp-notif, draft-ietf-netconf-https-notif). gNMI (gRPC is
the transport of gNMI) has been proposed (draft-openconfig-rtgwg-gnmi-spec) in
2018 but not stand
Dear Zhenqiang,
Thanks a lot for your feedback.
I presume with gRPC you are referring to YANG push (RFC 8639, RFC 8641,
draft-ietf-netconf-udp-notif, draft-ietf-netconf-https-notif). gNMI (gRPC is
the transport of gNMI) has been proposed (draft-openconfig-rtgwg-gnmi-spec) in
2018 but not stand
Dear Jean,
Thanks a lot for the comprehensive review and comments. They all make perfectly
sense.
I merged them into the -02 version
https://raw.githubusercontent.com/graf3net/draft-tgraf-opsawg-ipfix-on-path-telemetry/main/draft-tgraf-opsawg-ipfix-on-path-telemetry-02.txt
And here the diff:
Dear Med,
Also many thanks from my side. Much appreciated. I just submitted the -06
version.
If there aren't any objections anymore I think Joe can go ahead from here.
Best wishes
Thomas
From: Benoit Claise
Sent: Thursday, January 5, 2023 10:08 AM
To: mohamed.boucad...@orange.com; Graf Thom
Dear Tianran,
Thanks a lot for your feedback. I understood that with
draft-zhou-ippm-enhanced-alternate-marking we already have a document which
intends to extend alternat path marking with timestamping. Very well.
Regarding IOAM-DEX. I was refereeing to the Section 3.2 of RFC 9326
(https://da
Dear Tianran,
ZTR> I think I understand how you can achieve. You can add to bits in
"extension-flags" in rfc9326, as the knob to control the existence of
timestamp, just like the flow id and sequence. Right?
Correct. That works as well. Thanks for pointing out.
Best wishes
Thomas
From: Tianra
Dear Zhenqiang,
Thanks a lot for the feedback. Much appreciated.
I do not disagree that YANG push isn't capable of exporting control and
forwarding plane metrics. However it is not the best choice in terms of scale.
Table 1 of RFC 9232 gives a good summary. It even makes the distinction between
https://mailarchive.ietf.org/arch/browse/opsawg/?q=draft-tgraf-opsawg-ipfix-on-path-telemetry-01
Danke! Angekommen π
Sorry fΓΌr den Stress.
Lg Thomas
On 13 Jan 2023, at 07:16, Buchs Yannick, INI-NET-VNC-HCS
wrote:
ο»Ώ
Dear OPSAWG,
I strongly support the adoption of
draft-tgraf-opsawg-ipfix
Dear Tianran,
Thanks a lot. We submitted draft-opsawg-ipfix-on-path-telemetry-00 and awaiting
your approval.
We addressed the working group feedback in -01 version and will submit it right
after.
Best wishes
Thomas
From: Tianran Zhou
Sent: Wednesday, January 18, 2023 4:39 AM
To: opsawg@ietf.
Dear Joe,
My appology. Sure! Just submited with the correct name.
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Thursday, January 19, 2023 6:40 PM
To: Graf Thomas, INI-NET-VNC-HCS ;
zhoutian...@huawei.com; opsawg@ietf.org
Cc: draft-tgraf-opsawg-ipfix-on-path-teleme...@ietf.org
Subject:
Dear opsawg,
I support the adoption and think draft-boucla-opsawg-ipfix-fixes should follow
the adoption call next as well. Both are very valuable to keep the IPFIX
registry up to date.
I agree with the author that IE6 tcpControlBits should mirror the TCP header
flags registry
(https://www.ia
Dear OPSAWG and IPPM working group,
Thanks a lot for the comments during the adoption call. We updated the document
accordingly.
Here in brief the differences to the previous version:
- Extended the introduction and the terminology section with performance
registry relevant information's.
- C
Dear OPSAWG,
We updated the draft document to version -02 by adding the Implementation
Status section. Reflecting what we have been testing/implementing during IETF
116 hackathon.
The hackathon slides describing implementation details and use case be applied
to can be found here:
https://githu
Dear Med and Benoit,
Regarding adding a new IE ipv6ExtensionHeadersFull
(https://datatracker.ietf.org/doc/html/draft-boucadair-opsawg-ipfix-tcpo-v6eh-01#section-3).
I would appreciate if that new IE ipv6ExtensionHeadersFull would support more
than one extension header of the same kind.
Best wi
Dear Joe,
No, I am not aware of any IPR applying to this draft.
Best wishes
Thomas
From: Joe Clarke (jclarke)
Sent: Tuesday, May 2, 2023 12:20 AM
To: Benoit Claise ; jean.quilb...@huawei.com; IGNACIO
DOMINGUEZ MARTINEZ-CASANUEVA ;
diego.r.lo...@telefonica.com; Graf Thomas, INI-NET-VNC-HCS
C
Dear OPSAWG, Med and Benoit
Regarding section 6.2, forwardingStatus
(https://datatracker.ietf.org/doc/html/draft-boucla-opsawg-ipfix-fixes-04#section-6.2).
Section 4.12 of RFC 7270
(https://www.rfc-editor.org/rfc/rfc7270.html#section-4.12) describes that
reduced-size encoding according to Sect
Dear Tero, Med and Rob
Thanks a lot for the SECDIR review. Below the feedback from the authors inline.
Looking forward to your feedback and please let me know if we should proceed to
add suggested paragraph in the security section for the document version.
Best wishes
Thomas
TK> On t
Dear Med and Benoit,
Excellent. Thank you very much for addressing this so quickly. The proposed
changes make perfectly sense and addresses my concerns.
Indeed I was miss leaded by the IANA IPFIX registry indicating unisgned8 where
RFC7270 defined unisgned32 for the IE89 forwardingStatus. There
Dear Jim,
Thank you very much for the review. We addressed your comments together with
some minor editorial nits from Med in version -09 which just has been
published. Below inline the feedback
Best wishes
Thomas
The IETF datatracker status page for this Internet-Draft is:
https://datatracker
Dear Paul,
Thanks a lot for your review and comments. With one minor editorial exception,
all are valid and merged in the coming -10 version of the document.
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-
Dear Paul,
Thanks a lot. I updated section 5.9.1 as you suggested.
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/draft-ietf-opsawg-ipfix-srv6-srh-09.txt&url2=https://raw.githubusercontent.com/network-analytics/d
Dear Paul,
Thank you very much. I merged all your input.
PA> 5.4. srhActiveSegmentIPv6 / Additional Information, Changed from RFC8754 to
RFC8402, is that correct? Please say which section of the RFC is relevant.
TG> That is correct. The active section is specified in Section 2 of RFC 8402
and
Dear Med,
Thanks a lot for your comment on the designated expert in the "IPFIX IPv6 SRH
Segment Type Subregistry" and the removal of the intro section in the "IANA
Considerations"
Here the -10 document:
https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-srv6-srh/main/dr
Dear Paul,
Thanks a lot. I adjusted the indent structure as it was before but under 5.1
since Med added the 5.1 "New SRH Information Elements" section and reference it
in the text, which makes sense to me and addressed your nit.
Here the -10 document:
https://raw.githubusercontent.com/network-
Dear Med,
Thanks a lot.
Regarding your feedback on expert review, for me valid and ok but I am waiting
on Paul's feedback if that make sense to him as well.
Regarding, IPFIX IPv6 SRH Segment Type Subregistry. I believe the section is
related to the srhIPv6ActiveSegmentType section. Therefore
Dear Roman,
Thanks a lot for your review and comment. I merged them into the -11 version.
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-11
A diff from the previous version is available at:
https://author-tools.ietf.org/iddi
Dear Paul and Med,
Excellent. Thanks a lot for your suggestions. I merged them into the -11
version.
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-11
A diff from the previous version is available at:
https://author
Dear Paul and Med,
Makes completely sense. I had the same thoughts. Thanks a lot. I submitted -12.
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-12
Best wishes
Dear Eric,
Thanks for your comments.
With srhIPv6ActiveSegmentType the authors intended to have the operational
experience in SRv6 than we have in MPLS-SR with mplsTopLabelType
https://datatracker.ietf.org/doc/html/rfc9160
https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type
Dear Erik,
Thanks a lot for your review and comment. I added the following sentence in the
-13 revision to make it clear which IEs are needed and where the decoding needs
to be done:
By using described information from srhSegmentIPv6EndpointBehavior and
srhSegmentIPv6LocatorLength the compress
Dear Paul,
Thanks a lot. I addressed both in -13 along with other IESG feedback.
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh-13
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?u
Dear John,
My apology. Your assumption is correct.
In case when the compressed SID container is only used in the IPv6 destination
address of the provider data plane and the SRH is not being present at all, it
would be a zero lenght array.
Best wishes
Thomas
> On 24 May 2023, at 17:32, John S
Dear Lars,
Thanks a lot for the review and comment. I addressed them in -14 version.
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-srv6-srh
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-ipfix-srv6-srh-14
Best wishes
Thomas
-Ori
Dear Andrew,
Thanks a lot for the review and comment. The intent of the authors was never to
violate RFC 8200 but help the implementers of draft-ietf-opsawg-ipfix-srv6-srh
how to deal with multiple SRH by referencing to Section 8 of RFC 7011. However,
I understand from your feedback that multip
Hi Med,
Thanks a lot for this. I am looking very forward to the discussion in the
working group whether/how we will export also the observed occurrences of
Routing Types. I believe with the continuous adoption of IPv6 and SRv6 this
work will become important to network operators.
Best wishes
T
Dear OPSAWG wg,
I support the adoption. I find this work very important to keep the IPFIX
registry up to date. In particular I like to contribute to
draft-boucadair-opsawg-ipfix-tcpo-v6eh since proper visibility of the IPv6
extension headers are a great concern.
Best wishes
Thomas
From: OPSAW
Dear OPSAWG and IPPM wg,
As described at IETF 116, draft-ietf-opsawg-ipfix-on-path-telemetry has been
updated to -03 with an example section. Show an example with
PathDelayMeanDeltaMicroseconds where the mean is already calculated at the
IPFIX export and one with PathDelaySumDeltaMicroseconds w
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 abl
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 conne
Dear Greg,
Thanks a lot. Valid point on connectivity service terminology. The proposed
text works for me. Perfect.
Best wishes
Thomas
On 18 Aug 2023, at 21:53, Greg Mirsky wrote:
ο»Ώ
Hi Thomas,
thank you for the feedback and proposed update. Please find my notes below
tagged by GIM2>>.
Regard
Dear draft-fz-ippm-alt-mark-deployment authors, Dear IPPM working group,
First of all I think draft-fz-ippm-alt-mark-deployment is a valuable document
describing the deployment of Alternat Marking.
I have reviewed
https://datatracker.ietf.org/doc/draft-fz-ippm-alt-mark-deployment/ the Network
Dear netconf and opsawg,
We updated draft-ietf-netconf-distributed-notif to address Benoit's comment on
the use of domain observation id terminology. We believe that by introducing a
new terminology, Message Publisher and Message Publisher ID we have been
addressing his concerns. Looking forwar
Dear Massimo,
My apology for late reply. Both your comments are very valid.
packetDeltaCount(IE2) can be also used for loss measurement. As well
flowEndSeconds(IE151), flowEndMilliseconds(IE153),flowEndMicroseconds(IE155) or
flowEndNanoseconds(IE157) for delay measurement. Both has been added
Dear Chaitanya,
Thanks a lot for the updated document. As previously stated, as a network
operator, I value contributions describing reasons why packets are being
dropped.
I reviewed the latest document revision and have the following comments:
Looking at
https://datatracker.ietf.org/doc/html
Dear netconf and opsawg,
In order to align with the new Message Publisher ID terminology in
draft-ietf-netconf-distributed-notif-08 we updated
draft-tgraf-netconf-notif-sequencing accordingly. Looking forward to feedback
from the working group.
Best wishes
Thomas
-Original Message-
Fr
Dear netconf,
The following two documents have been updated:
Name: draft-tgraf-netconf-notif-sequencing
Revision: 03
Title:Support of Hostname and Sequencing in YANG Notifications
Date: 2024-01-14
Group:Individual Submission
Pages:10
URL:
https://www.ietf.org/arch
Dear opsawg,
We updated the document and replaced the references from Path Tracing
(draft-filsfils-ippm-path-tracing) to Alternate Marking (RFC 9341, RFC 9343,
draft-ietf-ippm-ioam-deployment, draft- fz-spring-srv6-alt-mark) currently
under development at IPPM. Describing with IOAM (RFC 9197,
Dear OPSAWG,
I read the document and think it is very valuable for network operators. I like
that it is defined as information module so later we can see how this would be
applicable in IPFIX and YANG.
Best wishes
Thomas
-Original Message-
From: OPSAWG On Behalf Of Henk Birkhol
Dear Med,
Thanks a lot for addressing all my points.
I updated and submitted my shepherd review:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tsvwg-udp-ipfix/shepherdwriteup/
I agree with your assessment on Joe's comment that having a figure on udp
options packet header and short descrip
Dear OPSAWG,
The Semantic Metadata Annotation for Network Anomaly Detection document was
previously presented at IEPG and NMRG
https://datatracker.ietf.org/meeting/118/materials/slides-118-nmrg-semantic-metadata-annotation-for-network-anomaly-detection-01.pdf
https://youtu.be/zC-R_fWUUEA?si=oAvc
Dear Med and Benoit,
Thanks a lot. The document is very well written and straight forward. As shared
previously during the working group, I believe this document is very valuable
to network operators since it addresses current issues in the observation of
IPv6 headers and TCP options.
I have r
Dear Adrian and Davis,
Nice! Thanks a lot for this document. I think it will help future documents to
chose the correct terms and language.
I reviewed and have some minor input.
Regarding
Change: A modification to the state of a resource in time.
I believe it not only applies to a resource bu
Dear Med,
That was a mistake by me. The idnits showed nothing. All clear. Will update the
shepherd review in the next iteration.
Bets wishes
Thomas
-Original Message-
From: mohamed.boucad...@orange.com
Sent: Tuesday, January 23, 2024 11:02 AM
To: Graf Thomas, INI-NET-VNC-HCS ;
draft-
Dear Med and Benoit,
Thanks a lot. The document is straight forward and is a very valuable
contribution to the Internet community since it updates existing IPFIX entities
to make them consistent, which is for IPFIX data collections which obtain the
information from the IPFIX IANA registry espec
Dear OPSAWG,
As a co-author, I am not aware of any IPR.
Best wishes
Thomas
-Original Message-
From: Henk Birkholz
Sent: Thursday, February 8, 2024 5:00 PM
To: OPSAWG ; draft-feng-opsawg-incident-managem...@ietf.org
Subject: π IPR Call for draft-feng-opsawg-incident-management-04
Be a
Dear Carlos and Adrian,
As the author of draft-ietf-opsawg-ipfix-on-path-telemetry, I care and value
that you are defining OAM terminology. This is much needed. Count me on the
list of people who misused the term inband previously.
I would appreciate of you could add also OAM node type. As an e
Dear Justin, Dear OPSAWG and IPPM working groups
Thanks a lot for the presentation at IPPM. I believe that this work needs
further refinement by defining also IPFIX entities for IOAM which allow a
decomposition of each IOAM dimension fields, thus enabling IPFIX Flow
Aggregation as described in
Dear Reshad,
I am refering to the IOAM data fields described in
https://datatracker.ietf.org/doc/html/rfc9197#section-4. So that those entities
can be decomposed on the network node and not at the data collection. Depending
on IPFIX configuration, some of the dimensions will be key fields, some
Dear Xiao,
I agree that the description and the additional information does not provide
information to distinguish between
ingressInterface, egressInterface
and
ingressPhysicalInterface, egressPhysicalInterface
However from an implementation perspective I have observed that in all cases
ingr
Dear Xiao,
Correct. Obviously this will be exported per flow and the interface entities
have to be key fields as the flow entities as well.
Best wishes
Thomas
On 3 Apr 2024, at 04:54, xiao.m...@zte.com.cn wrote:
ο»Ώ
Be aware: This is an external email.
Correcting the email address i...@ietf.
Dear Joe and Med,
I updated both shepherd writeup's accordingly and adjusted to: that consensus
for introducing a new data type unsigned256 has been achieved.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-tcpo-v6eh/shepherdwriteup/
https://datatracker.ietf.org/doc/draft-ietf-opsawg-t
Dear NMOP and OPSAWG working group,
At IETF 119, I introduced to NMOP below informational overview document.
Describing the YANG-Push integration into Apache Kafka.
https://datatracker.ietf.org/doc/html/draft-netana-nmop-yang-kafka-integration
https://datatracker.ietf.org/meeting/119/materials/s
Dear OPSAWG,
I have read the document and support the adoption in OPSAWG. A OAM terminology
is much needed.
Best wishes
Thomas
-Original Message-
From: OPSAWG On Behalf Of Henk Birkholz
Sent: Wednesday, April 10, 2024 1:06 PM
To: OPSAWG
Subject: [OPSAWG] π WG Adoption Call for
draft-
Dear Joe, Tianran and Henk,
I like to request a 10min presentation slot for
Export of On-Path Delay in IPFIX
draft-ietf-opsawg-ipfix-on-path-telemetry-07
We have been working since IETF 117 on aligning the document to the performance
metrics registry and like to present those changes to the OPS
Dear Mahesh and Rebecca,
Can we also take Carsten's feedback into account and change the first two lines
of Figure 7 to move two characters to the left.
Then everything is perfect.
Best wishes
Thomas
From: Mahesh Jethanandani
Sent: Wednesday, July 10, 2024 8:29 PM
To: Rebecca Vanrheenen
Cc:
Dear Carsten,
Valid input! Thanks a lot for spotting this.
Best wishes
Thomas
-Original Message-
From: Carsten Bormann
Sent: Saturday, July 6, 2024 6:58 PM
To: Benoit Claise
Cc: RFC Errata System ;
pierre.franc...@insa-lyon.fr; opsawg@ietf.org
Subject: [OPSAWG]Re: [Editorial Errata
Dear Rebecca,
Looks perfect. Thats would be all.
Best wishes
Thomas
-Original Message-
From: Rebecca VanRheenen
Sent: Thursday, July 11, 2024 7:09 PM
To: Graf Thomas, INI-NET-VNC-HCS ; Mahesh
Jethanandani
Cc: benoit.cla...@huawei.com; pierre.franc...@insa-lyon.fr; opsawg@ietf.org;
Dear OPSAWG working group and chairs,
On behalf of the authors. We just submitted -12 revision where we addressed the
following feedback
- Paul Aitken, IPFIX designated expert
- Greg Mirsky, IPPM registry designated expert
- IANA
- Med Boucadair and Yannick Buchs, proof-reading the document
As
Hi Zhenqiang and the coauthors,
First of all I have to congratulate to this draft. I share the opinion that BGP
communities are a very powerful information element. Correlated to the
forwarding plane it gives a more detailed and granular view of the network
usage then AS numbers or paths.
Look
Hi Tianran and co-authors,
I support the adoption from a network operator perspective. Thank you very much
that you driving this important topic at IETF.
I agree with the authors that IETF needs to ensure that all activities covered
by Network Telemetry has to be coordinated to allow metric
Dear OPSAWG Chairs,
Even though I missed the deadline to request a time slot for the opsawg virtual
interim, would it be possible to have a 5 minute time slot to present below
draft at OPSAWG working group.
Export of MPLS Segment Routing Label Type Information in IP Flow Information
Export (IP
Hi Joe,
Thanks for the quick response. Yes, please, put me in the queue. That's
perfectly fine. I will upload the slides on time.
Thanks also for input. Ack on all. Will be in the next release.
Looking forward to the working group session and the feedback from the list..
Best Wishes
Thomas
--
Dear opsawg,
Encouraged by the input from the spring list I updated
draft-tgraf-ipfix-mpls-sr-label-type by adding a new additional IPFIX entity
called SrSidType which complements the mplsTopLabelType.
https://tools.ietf.org/html/draft-tgraf-ipfix-mpls-sr-label-type-03
https://www.ietf.org/
Hi Ketan,
Thank you very much for the review and feedback.
* What or how much value be there on determining whether a SR Prefix SID
was signalled/programmed on a node via OSPFv2/OSPFv3/ISIS - what matters and is
more important is that it is a Prefix SID. Hardly any deployments would be
ru
Hi Jeff,
Thanks a lot for the review and feedback.
Please refer to my feedback to Ketan where elaborated more about why for label
protocol migrations IE 46 is useful.
* I'm not sure the FIB is the right place to collect this data though,
since most of meta-data has already been lost (flat
Hi Ketan,
* This helps identification of specific SR-MPLS segment types as well as
differentiating them from LDP, RSVP-TE, etc.
To be precise, the existing MPLS Label Type identifier differentiates from LDP,
RSVP-TE. Not the new SrSidType IPFIX IE being proposed.
* What value is prov
Hi Gyan,
Gyan> IPFIX has been traditionally been used for flow analysis and to that end
all that was required is support of the data plane encapsulation. With your
proposed SR support idea you are really transforming the IPFIX to be used for
not just flow monitoring at that level solely, but n
Hi Qin Wu,
Thanks for feedback. I agree, covering SRv6 as well makes sense and I take this
as action point for the next update of the draft once its being adopted.
The IE SrSidType is actually agnostic to SR-MPLS and SRv6. So the update would
be on IE46 mplsTopLabelType. Adding IPv6 as label p
Hi Qin, Hi Joe,
Please ignore my last email in regards to SRv6 and name change. SRv6 is covered
with draft-patki-srv6-ipfix-00
https://tools.ietf.org/html/draft-patki-srv6-ipfix-00
draft-tgraf-ipfix-mpls-sr-label-type is focusing on MPLS-SR.
Best Wishes
Thomas
-Original Message-
From:
Hi Ketan,
Thank you very much for the feedback.
[KT] Why not extend the existing IPFIX MPLS Label Type (value 46) to add SR
Prefix SID, SR Adjacency SID, SR Binding SID ... (basically the segment types
from RFC8402)? It's a simpler change to an existing element/field that makes it
easier for r
Hi Ketan,
Thanks a lot for the feedback. So far Sergey feedbacked in favor to keep IE46
and SrSidType being separate. Lets see which opinion others have on the list.
* Also, from an operational perspective (looking holistically), we have LSP
ping/trace tools specified for MPLS (including S
Hi Sergey,
Thanks for the feedback. I am fully in line with your comment.
* Maybe we should consider adding a generic type 'Segment Routing' w/o
extra details if this might become an implementation challenge?
I would be interested to understand what extra details you would include in
this
Hi Sabrina, Hi Loa
I would appreciate if you could feedback the following remaining questions
> The "Requester" column refers to the document that the code point requested,
> where the "Reference" column links to the document where the metric value is
> coming from. Please correct me if my unde
Hi Joe and Tianran,
Thanks a lot for the feedback and suggestions. This is much appreciated.
As you pointed out, I received a few feedbacks from LSR, MPLS, SPRING and
OPSAWG. Especially thanks to
Sergey Fomin
Loa Andersson
Sabrina Tanamal
Erik Auerswald
Hannes Gredler
Paolo Lucente
Gyan Mishra
1 - 100 of 165 matches
Mail list logo
