Hi Med,
Many thanks for the review. Much appreciated. I will go through them and
include your inputs in the next version.
Best wishes
Thomas
From: OPSAWG On Behalf Of mohamed.boucad...@orange.com
Sent: Tuesday, June 8, 2021 10:14 AM
To: Tianran Zhou ; opsawg@ietf.org
Subject: Re: [OPSAWG] WG
Hi Qin,
Thanks for the feedback. I will include the comments in the next version.
Regarding early IANA allocation. This has been already requested previously on
the list. The chairs suggested to do a last call and see wherever we could go
directly or not.
Regarding
Ø Suggest to add a note
Dear OPSAWG wg,
I support the adoption of draft-claise-opsawg-service-assurance-architecture
and draft-claise-opsawg-service-assurance-yang.
From a network operators point of view I see these two drafts as an important
contribution towards closed-loop automation. Enabling service decomposition
Dear OPSAWG,
I updated the draft according to the mailing list feedback. Thanks to Tom and
Med for the contribution.
Dear OPSAWG chairs,
I like to go ahead now and herby request early IANA allocation of standards
track code points according to RFC 7120 section 3.1
Hi Tom,
Thanks for input.
>3.1 IANA is requested to allocate four code points in the existing
>sub-registry "IPFIX MPLS label type (Value 46)" of the "IPFIX Information
>Elements" registry for IS-IS, OSPFv2, OSPFv3 and BGP Prefix-SID Segment
>Routing extension
> Introducing four new code
Hi Med,
Thanks. Ack. Makes sense. I will include it in -08.
Best wishes
Thomas
From: mohamed.boucad...@orange.com
Sent: Wednesday, March 24, 2021 1:46 PM
To: Graf Thomas, INI-NET-TCZ-ZH1 ;
rwilton=40cisco@dmarc.ietf.org; zhoutian...@huawei.com; opsawg@ietf.org
Subject: RE: Call for
Dear OPSAWG,
As discussed at IETF 110. draft-tgraf-ipfix-mpls-sr-label-type has received a
review from Benoit Claise and been updated to -07 version accordingly. Many
thanks Benoit!
I am looking forward for adoption.
Best wishes
Thomas
-Original Message-
From:
Hi Shuanglong and Rob,
First of all thank you very much for this question. I think they are very valid
and good, but also occurring quiet often. I like share my view in OPSAWG.
Regarding BMP, please involve the GROW working group as well.
The problem space you are describing is addressed in
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
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
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
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
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
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 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
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
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
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
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
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
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
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
101 - 122 of 122 matches
Mail list logo
