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

[Paolo Lucente]

Hi Tianran,

Thanks for mentioning three standardized protocols that contribute to 
world diversity: ISIS, OSPF and IPFIX.


Paolo


On 12/1/23 03:41, Tianran Zhou wrote:

Hi Zhenqiang and Thomas,

Thanks very much for sharing your experience and the discussion in the 
mailing list.


IMO, whether to use gRPC or IPFIX is not a technique problem, but 
different choice/preference from users.


I agree with Zhenqiang our intention is not to have many options for the 
same feature.


But the world is diverse. Like we always have the same IGP extension for 
both OSPF and ISIS. At present I cannot see the dominance of one protocol.


I have practice on both gRPC and IPFIX. I believe both approaches can 
achieve this case.


Because this is neither large volume nor frequent.

The fast path will process delay per-packet, but the export will only 
work on mean/min/max delay.


Best,

Tianran

*From:*li_zhenqi...@hotmail.com [mailto:li_zhenqi...@hotmail.com]
*Sent:* Wednesday, January 11, 2023 4:23 PM
*To:* Benoit Claise ; 
thomas.g...@swisscom.com; Tianran Zhou ; ippm 


*Cc:* opsawg@ietf.org
*Subject:* Re: Re: [ippm] 回复: FW: WG Adoption Call for 
draft-tgraf-opsawg-ipfix-on-path-telemetry-01


Hello Mr. Claise,

please see my comments beginning with [ZQ].



Best Regards,

Zhenqiang Li

li_zhenqi...@hotmail.com 

*发件人：*Benoit Claise 

*发送时间：* 2023-01-10 05:15

*收件人：*thomas.g...@swisscom.com
; li_zhenqi...@hotmail.com
;
zhoutianran=40huawei@dmarc.ietf.org
; i...@ietf.org


*抄送：*opsawg@ietf.org 

*主题：* Re: [ippm] 回复: FW: WG Adoption Call for
draft-tgraf-opsawg-ipfix-on-path-telemetry-01

Dear all,

I agree with Thomas on a couple of points.

What is important is that, for accounting information, monitored at
high frequency, such as IPFIX flow records metering data plane
traffic, should be exported directly from line cards, without
proxying to the route processor. As such, UDP is the way to go (*).
On top of that, losing an export packet or two is not the end of the
world.
In this case (draft-tgraf-opsawg-ipfix-on-path-telemetry-01), where
we monitor delay over (all packets of) the flow record lifetime,
it's the same principle: we need the UDP-based export. So the IPFIX
protocol.

[ZQ] I don't think it is apropriate to limit the implementation
especailly the internal software and hardware architecture when we
define protocol. Our lab tests show gRPC works well for exporting
the iOAM metrics and gRPC is TCP based. I am not sure whether or not
  our vendors implement this by  proxying the collected data plane
information to the route processor and then packeting and exporting
all the relevant information to the colloctor. Why do we need to
tell the vendors how to do it? From the specification point, IPFIX
does not require UDP,  TCP based SCTP is a valid option.

[ZQ] I agree with you that the packets of iOAM flow should not be
sampled, i.e. all packets of the flow need to be monitored.

Btw, the flow record lifetime is configurable, based on timers... in
case you want to act on the delay (in the flow record) faster... at
the cost of exporting more flow records.

[ZQ] iOAM metrics should be exported in seconds, in minutes is not
acceptable. IPFIX exporting timer is usually in minutes.

Now, if we speak about events, this is a different story, as events
needs to acted upon. So a reliable transport is required here.

Let's keep in mind that we speak about hybrid type I (see
https://www.rfc-editor.org/rfc/rfc7799#section-3.8
), so the issue
of isolating the specific packets to look at at intermediate node is
trivial.

(*) and this is the reason why SCTP, the compulsory export protocol
in RFC 7011 was never a success. See

https://www.claise.be/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/
 


Regards, Benoit

On 1/9/2023 11:06 AM, thomas.g...@swisscom.com
 wrote:

Dear Zhenqiang,

See response inline.

Best wishes

Thomas

*From:*li_zhenqi...@hotmail.com
 

*Sent:* Monday, January 9, 2023 8:43 AM
*To:* Graf Thomas, INI-NET-VNC-HCS 
; Tianran Zhou

; ippm
 

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

[Paolo Lucente]

Hi,

I support adoption of draft-tgraf-opsawg-ipfix-on-path-telemetry-01 and 
intend to validate and implement the data collection in pmacct.


Paolo


On 21/12/22 23:25, 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]  WG LC: Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)

[Paolo Lucente]

Hi,

Speaking with my hat of software developer: I have implemented this in 
the free open-source flow collector pmacct (*) as part of the IETF 115 
hackathon and found no issues. I hence support WGLC of the document.


Paolo

(*) https://github.com/pmacct/pmacct


On 30/11/22 10:53, Joe Clarke (jclarke) wrote:
Hello, WG.  As discussed at IETF 115, we want to conduct a WG LC for 
draft-ietf-opsawg-ipfix-srv6-srh.  The authors believe this work is 
stable and moreover used the 115 hackathon to develop a interoperable 
implementations (linked in Data Tracker) .  Additionally, IANA has 
already weighed in on this work and agree with the considerations approach.


Therefore, we are calling for a two week LC.  We will conclude on 
December 14.


https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-srv6-srh/ 



Please review the current -04 draft, post your comments and/or your 
thoughts on the current text.


Thanks.

Joe


___
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] CALL FOR ADOPTION: draft-tgraf-opsawg-ipfix-srv6-srh

[Paolo Lucente]

Hi,

Having read the draft, i believe the work is valuable and support its WG 
adoption.


Paolo


On 18/8/22 17:14, Joe Clarke (jclarke) wrote:
Hello, WG.  We’d like to begin a two week call for adoption of this 
work.  Even as an individual draft it has already received some reviews 
and has iterated quite a bit.  Based on IETF 114 there does seem to be 
interest in adopting this in opsawg, but we need a formal adoption poll.


Please review and provide your adoption thoughts no later than September 
1, 2022.


Thanks.

Joe


___
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] IPR poll for draft-ietf-opsawg-service-assurance-yang-05 and draft-ietf-opsawg-service-assurance-architecture-03

[Paolo Lucente]

No, I'm not aware of any IPR that applies to this draft.

Paolo


On 9/6/22 08:16, Tianran Zhou wrote:

Dear authors and contributors,

As part of the working group last call, please respond on-list as to 
whether or not you are aware of any IPR that pertains to


draft-ietf-opsawg-service-assurance-yang-05

and

draft-ietf-opsawg-service-assurance-architecture-03.

State either:

"No, I'm not aware of any IPR that applies to this draft."

or

"Yes, I'm aware of IPR that applies to this draft."

If you are aware of IPR, indicate whether or not this has been disclosed 
per IETF IPR rules (see RFCs 3669, 5378, and 8179).


For the OPAWG co-chairs,

Tianran


___
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 Last call for draft-ietf-opsawg-ipfix-mpls-sr-label-type-01

[Paolo Lucente]

I have read the draft: nice work & i'd support publication of this document.

Paolo

On 8/6/21 02:55, Tianran Zhou wrote:

Hi WG,

The following draft is mainly to request some IPFIX IE allocations.

https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-mpls-sr-label-type/ 



We agreed to fast track this draft and move forward.

Now the authors think it’s stable. And we got IE expert reviewed.

This mail we start a two weeks WG last call, before June21.

Please reply your comments on this.

Thanks,

Tianran


___
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-yang-07

[Paolo Lucente]

Dear OPSAWG'ers,

As a believer in draft-claise-opsawg-service-assurance-yang (read also 
co-author) and OPSAWG enthusiast, I do support the adoption of both 
draft-claise-opsawg-service-assurance-architecture and 
draft-claise-opsawg-service-assurance-yang.


Paolo

On 27/4/21 20: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-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

Re: [OPSAWG] Call for adoption: draft-tgraf-ipfix-mpls-sr-label-type-07

[Paolo Lucente]

I find this document useful and support its adoption.

Paolo

On 24/03/2021 07:23, Tianran Zhou wrote:

Hi WG,

As discussed in the IETF110 meeting, we start a two weeks adoption call 
on draft-tgraf-ipfix-mpls-sr-label-type-07:


https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-type/ 



Please respond with your comments and thoughts on this draft.

We will conclude on April 7, 2021.

Thanks,

Tianran as co-chair


___
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] CALL FOR ADOPTION: draft-tgraf-ipfix-mpls-sr-label-type

[Paolo Lucente]

A bit late but i support this work for the increased visibility it 
brings into IPFIX for the MPLS-SR data plane.


Paolo

On 13/08/2020 14:41, Joe Clarke (jclarke) wrote:

Hello, WG members.  During the IETF 108 virtual meeting, we had Thomas present 
this work.  It has been reviewed by SPRING as well as on this list.  The SPRING 
consensus was the work is better suited for opsawg.  The adoption hum during 
the IETF 108 virtual meeting was “Piano” which was middle of the road (though 
given the hum rules that is somewhat inconclusive).

Regardless, the chairs want to hear from the list.  This document aims to 
modernize the IPFIX MPLS label type for segment routing in order to provide 
more visibility for the MPLS-SR data plane.  Does opsawg want to adopt this 
work?

This starts a two-week call for adoption.  It will be concluded on August 27, 
2020.

Joe
___
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] [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community

[Paolo Lucente]

Hi,

With the hat of the developer of a open-source / free IPFIX collector (*, **), 
I would like to express two opposite concerns with regards to this draft - 
loosely related to the very details of the draft itself.

One concern is that this looks a very isolated effort, ie. why communities and 
not as-path? I remember the story of this draft, it comes from field needs and 
that is in short the answer to the cherry-picking.

The second concern, the one going the opposite direction than the previous one, 
is that in future it could be tempting for somebody to repeat the story of this 
draft and add support for as-paths and/or other BGP attributes in IPFIX: here i 
see a mix-up among the original intent to report on data plane information with 
the reporting on control-plane (BGP) information: in other words, is 
(potentially) encapsulating (all) BGP attributes for every sampled packet/flow 
a valid idea? For example, is not BGP/BMP peering at the IPFIX collector itself 
much more efficient instead of moving control-plane info over and over again? 
At this propo, the motivation that roughly 20 years ago it was decided to make 
source and destination ASNs part of NetFlow v5 (and few years later BGP 
next-hop was added as part of NetFlow v9) is a bit weak, IMO; maybe there is 
more to it, and i’d be happy to hear about it. 

On the details of the draft itself instead, i reckon the effort to support 
Extended and Large communities (comment from Ignas Bagdonas last year); i also 
followed the discussion with PJ Aitken about segmentation/fragmentation of 
potentially long communities list and i seem to reckon there is no good 
(simple, straightforward) solution to address that.

Paolo

(*) http://www.pmacct.net/
(**) https://github.com/pmacct/pmacct

> On 23 Jan 2018, at 02:10, Tianran Zhou  wrote:
> 
> Dear GROW WG,
> 
> The OPSAWG started a 2 week WG LC for a BGP related draft:
> https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04
> 
> It would be really helpful and appreciated if you can read it.
> Could you please provide comments (if any) and copy to opsawg@ietf.org?
> 
> Cheers,
> Tianran, as OPSAWG co-chair
> 
> 
> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou
> Sent: Thursday, January 18, 2018 11:07 AM
> To: opsawg@ietf.org
> Cc: opsawg-cha...@ietf.org
> Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community
> 
> Hi WG,
> 
> The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the latest 
> drafts to the mailing list, and believe that the document is ready for LC.
> 
> This starts a 2 week WG LC on
> https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04
> 
> Please read the above draft and send any issues, comments, or corrections to 
> this mailing list. 
> All supports and concerns are welcome and helpful for the authors.
> 
> We are also looking for a document shepherd, best with operator background, 
> to help the following procedures.  
> 
> The WG LC will close on Feb 1, 2018.
> Authors please indicate whether you are aware of any IPR for the draft.
> 
> Thanks,
> Tianran, as OPSAWG co-chair
> 
> ___
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
> 
> ___
> GROW mailing list
> g...@ietf.org
> https://www.ietf.org/mailman/listinfo/grow

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