draft-ietf-ippm-alt-mark - Giuseppe Fioccola
Bill Cerveny, IPPM co-chair: Going for last call.
Registry for performance metrics by Al Morton Draft-ietf-ippm-metric-registry-11 & draft-ietf-ippm-metric-registry
Matt Mathis: Actually not getting the measure of protocols, they don’t have control over retransmits.
J.Ignacio Alverez: you talk about instance, one of section in registry in CDN
Al: Let's talk more on this, layer on transport still useful, lets investigate further, TCP setup time,3 way handshake or specify.
Ignacio: place from you connect to the network
Al: excellent point. Last week it was discussed propagation delay has relation to response time.
Brian Trammell: How to separate TCP matrix retransmits vs other protocols like QUIC
Al: Interesting discussion
Philip: Yellow calibration of the output what it is all about
Al: Service provider asked what is going with calibration, registry. It is not complete solution but worth to look at. It is about tiny measurement that you make under service instances.
Draft-ietf-ippm-twamp-yang by Al Morton
Greg Mirsky, ZTE: I have sent some comments a while ago, I didn’t get any response, use of TWAMP is not mandatory. Current model goes together, another observation this model come from LMAP model, we have discussion in list, the role of controller in measurement,
Al: Let's have discussion offline
Greg: If interested I will send the comment again.
Draft-ietf-ippm-twamp-yang-03 by Mahesh Jethanandani
draft-brockners-inband-oam-data by Frank Brockers
Greg: If you are using entropy label you can track the packet, if you use active oam properly you can get proper path information. Large data packet will not follow the same path.Consider support of NTP time stamp. RFC 6374 loss and delay measurement has provision for that. IPPM workgroup has to re-charter to incorporate the IOAM.
Frank: Contrained to a single domain.
Greg: If you limit of your applicability to a single domain, transport will load balance and I will question this proposal. Adding so many bits on the packet will degrade the performance, some level of OAM, the data proposed today is way too large, if any flow is having trouble. Real customer traffic how it will behave. Adopting as working group is good but data model is having some issues, way too large. Scope here to set the tunneling any header any way.
Frank: it will have different tunnel, this have style of carrying the Meta data.
If you add this information, you will not increase the packet any way. Are you adding these in all packets?
Frank: Yes typically 100 percent sure, Space for optimize the data format.
Adrian Farrel: Glad this work has found home, tired of following it in IETF. Any home is a roof we can live under. Last question indicate that what scope is working at, is this oam data is added at the time of encapsulation. I would like to see bit more effort on the requirement document, mail that in working group document, piece itself properly.
Frank: Progress on solution, we can adopt the requirement in this working group.
David: We actually implement this.
Greg: You mention that encoding the bit map, order of the bit shows order of fields, what happen if we have multiple flags. How to reflect that. What happens if the node does not support this feature at all? You cannot introduce this in brown field.
You need to have some IGP to advertise the capability.
Mike mann: Thanks for the efforts, question is implementation how it will work in IPv6. Middle box which didn’t process do you have any comments on it? How to if not extnsion headers, in IPv6?
Frank: Today using extension headers.
Frank: Stack has the ability to do that. Let us not take the debate on here.
Carlos: Just want comment on Greg what is need of capability advertisement by IGP. We support some not all in bit filed. No need to advertise the capability advertisement in IGP.
Frank: I agree if the node is not understanding, it has to ignore it, the end system will decap. If you know your domain what is deployed.
Greg: Knowing your domain, knowing the capability of your node. You still somehow announce your capability, some networks if you don’t know it has to drop it.
Spencer: 2 things: One is knowing your domain, it is good to have text in. second having that it will have good security review, this will encourage security aspect is covered.
Mirja: There is a big difference between trusted node and not trusted node, applying to internet as a whole. You have to ensure that the data is not manipulated.
Brain Trammell: What kind of networks we are talking about. We could limit to tunnel endpoint to other this will avoid the complication.
Brian: Putting my chair hat Greg discussed on the charter to me it looks to me very much this work is covered in paragraph 4 of charter.
Explicit on para 1. This does not look like traditional oam protocols, one way is to fix this is to add is cut in the inband methods of ippm measurement are explicitly in scope. A small tweak in the charter will work.
Greg: Not to use in-band or out of band because it is not qualifying the oam, we call it hybrid type 1.
Nalini: If we need to charter, clearly this kind of work has to do with performance metric, has pdm has the endpoint, for to redo the charter we need to do.
Spencer Dawkins: usually charter updates complicates it goes to their area.
Note: Comment out of order, but associated with relevant draftBill (co-chair): Please express why you are not supporting IOAM. Please send your views to mailing list.
draft-bhaprasud-ippm-pm - Sudhin Jacob
Overview of the draft
Greg Mirsky: zte: when I look at diff Params we are going to combine, there is another terminology to do this. I can ref you to other work in MEF, which has a doc that talks about subscriber services, this seems to be implementation for the UNI.
Greg: if you want to measure on real traffic, you are effectively doing passive monitoring. That doesn't make it active OAM; here you inject special performance packets
Austin: it has active and passive options, the model defines them
Nalini: are you giving any thought to hybrid measurements?
Sudhin: color and COs is one way of doing it
Bill (co-chair): how many have read this draft? 4 hands. One concern is the lack of activity on the list: I'd like to see more activity on the list before we adopt
draft-mirsky-ippm-twamp-light-yang – Greg Mirsky
Al: I don’t understand it can’t possible true, control client and server communication control between them is optional.
Control client is an optional it is not.
Greg: I will go back to RFC.
Al: this is explained in TWAMP lite appendix. This comes as a surprise.
Al: All IETF protocols have security options.
Greg> Using key chain I can’t define authentication security for test, where is the security consideration of using netconf. This document use netconf.
Al: the point that TWAMP control is optional it is not correct.
David Sinicrope, Broadband Forum Liaison Officer to IETF: We are interested in seeing this work progressed, our community will be participating in mailing list.
draft-mizrahi-ippm-multiplexed-alternate-marking - Tal Mizrahi
Nalini> it is very very important, the potential changes in US, I will put PDM in the mailing list. People haven’t go to the OS yet. People have started to implement PDM in linux, PDM does what you want.
Klaus> Best practice trying to get large audience