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
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
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/
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
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
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,
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 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
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
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
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 ;
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
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
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
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
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
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 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:
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-
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
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 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
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 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>>.
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
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
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
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:
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
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
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
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
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:
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
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
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 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:
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:
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 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:
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:
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 Paul,
Thanks a lot. I updated section 5.9.1 as you suggested.
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.
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:
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.
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
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
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
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
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:
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.
-
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
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 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:
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
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
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:
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
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
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 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
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
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
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
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 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.
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:
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.
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
Dear Al,
Thank you very much for the review and the comments. Much appreciated. I merged
them in the next -01 version as following:
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
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
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
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
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
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
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.
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
Dear Greg,
Thanks a lot for the feedback and comments during OPSAWG and the conversation
afterwards.
We are going to change the terminology from "Inband" to "On-Path" Telemetry as
per your suggestion to be inline with IPPM.
Regarding the term "Aggregation" in the slide deck. It refers to RFC
Hi Tianran,
Thanks a lot for the review and comments.
Regarding your question why it is a standards and not a informational document.
We consulted with the IPFIX IE doctors and went for a standards document
because we create a new IPFIX registry: "IPFIX IPv6 SRH Flags" subregistry. We
will
Dear opsawg working group,
draft-tgraf-opsawg-ipfix-srv6-srh defines new IPFIX entities where the SRH and
associated control-plane related dimensions are exposed to enable SRv6
data-plane visibility.
The draft has been introduced and presented at IETF 113 to OPSAWG and SPRING
where we
Dear OPSAWG,
I have read the document and I think it is ready to progress. It is an
important component of the Service Assurance for Intent-based Networking
architecture.
Best wishes
Thomas
From: OPSAWG On Behalf Of Tianran Zhou
Sent: Wednesday, June 8, 2022 12:04 PM
To: opsawg@ietf.org
Dear OPSAWG and SPRING working group,
Thanks for the feedback on slide 7.
https://datatracker.ietf.org/meeting/113/materials/slides-113-opsawg-export-of-segment-routing-ipv6-information-in-ipfix-01
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh-03
We understood it does
Dear OPSAWG and SPRING working group,
Based on the feedbacks I received, I updated the document.
Apart from the small editorial changes, the following points have been addressed
- updated IANA sections according to RFC 8126
- added ipv6SRHSegmentListSection to facilitate immediate export
Dear OPSAWG and SPRING working group,
Based on the feedbacks I received on and off list, I updated the document.
Apart from the small editorial changes, the following points have been addressed
- added ipv6SRHSection to expose the SRH and it's TLV's in one IE
- added ipv6SRHSegmentsLeft to
Hi Greg,
Thanks for bringing that question up. I already considered this aspect.
As described in
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-00.html#section-2,
the compressed-SID container (C-SID container) is 128-bit long and contains a
sequence of C-SIDs.
Dear OPSAWG,
Following up on just released RFC 9160
(https://datatracker.ietf.org/doc/html/rfc9160), IPFIX code points for MPLS
Segment Routing,
https://datatracker.ietf.org/doc/html/draft-tgraf-opsawg-ipfix-srv6-srh has
been submitted for the SRV6 data-plane.
The document aims to be on par
Dear Rob, Med and IESG
Based on Ben's feedback, I submitted the final -11 version.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-11
I think the document is ready now for the RFC editor queue.
Best wishes
Thomas
-Original Message-
From: Benjamin Kaduk
Hi Benjamin,
Thanks for the clarifications and suggestions. Very much appreciated.
> I think it would be good to add a few words to hint at dimensional modeling,
> and maybe also to add a few words to clarify why
> draft-hegde-spring-mpls-seamless-sr is being referenced.
I put additional
Hi Alvaro,
Thanks for the feedback. It appears I need reading glasses.
I added a IANA note for moving the RFC references from the additional
information to the reference column.
Hi Benjamin,
> I'm not sure that draft-hegde-spring-mpls-seamless-sr is at a state of
> maturity to be a good reference here (and thus, that this example is worth
> including).
I agree. The only alternative is to reference
Hi Eric,
Thanks a lot for the review and the comment. I am not sure to which IE you are
referring to. The first encounter in the document is in section 1 where it is
expanded.
In [RFC7012], the Information Element (IE) mplsTopLabelType(46)
identifies which MPLS control plane protocol
Hi Alvaro,
Many thanks for the review and the remarks.
I added the PCEP SR extension to the document version -09 which I haven't
published yet. Here the diff
Hi Rob,
Excellent. Many thanks for the AD review and comments.
I updated and posted the draft -06 version accordingly.
Best wishes
Thomas
-Original Message-
From: Rob Wilton (rwilton)
Sent: Thursday, July 1, 2021 8:17 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ;
Dear Tianran, Med and Tom
Thanks a lot for the discussion wherever the document intend should be standard
or informational.
Also after reviewing RFC 1796 and RFC 2026, I agree that current content and
language of the draft aren't normative enough to qualify to be on the standard
track. To me
Hi Med,
Thanks for the promptly feedback. I updated to -04 version according to your
input.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-04
All lines now within 72 characters. Added the "." as described and reverted
back to the previous paragraph and included
Hi Med,
Many thanks for the shepherd review. I updated the document accordingly into
-03 version.
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-mpls-sr-label-type-03
I included all your suggestions and followed your example in using
abbreviations and changed the term "MPLS Segment
Hi Tianran,
Thanks a lot. Based on the latest feedback from the mailing in the last call I
updated the draft to -02 version.
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-mpls-sr-label-type-02
Best Wishes
Thomas
From: OPSAWG On Behalf Of Tianran Zhou
Sent: Tuesday, June 22,
Hi Tianran,
No, I am not aware of any IPR related to this document.
Best Wishes
Thomas
From: OPSAWG On Behalf Of Tianran Zhou
Sent: Monday, June 21, 2021 10:40 AM
To: Tianran Zhou ; opsawg@ietf.org
Subject: [OPSAWG] IPR question//RE: WG Last call for
1 - 100 of 122 matches
Mail list logo
