Subject: [ippm] IPPM WG Status and Agenda for IETF 95 Buenos Aires

From: Brian Trammell <[email-masked]>
Date: Fri, 11 Mar 2016 14:00:54 +0100

Greetings, all,

First, let us congratulate the IPPM working group on its excellent productivity in finally-published-RFC terms: we've seen five(!) documents published since Yokohama:

- RFC 7679 (was draft-ietf-ippm-2679-bis)
 A One-Way Delay Metric for IP Performance Metrics (IPPM)
- RFC 7680 (was draft-ietf-ippm-2680-bis)
 A One-Way Loss Metric for IP Performance Metrics (IPPM)
- RFC 7717 (was draft-ietf-ippm-ipsec)
 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement
 Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
- RFC 7718 (was draft-ietf-ippm-owamp-registry)
 Registries for the One-Way Active Measurement Protocol (OWAMP)
- RFC 7750 (was draft-ietf-ippm-type-p-monitor)
 Differentiated Service Code Point and Explicit Congestion
 Notification Monitoring in the Two-Way Active Measurement
 Protocol (TWAMP)

In addition:

- RFC-to-be 7799 (draft-ietf-ippm-active-passive-06) just entered AUTH48
- draft-ietf-ippm-checksum-trailer-06 has been approved and is in queue

Well done, IPPM!

With that, it's time to consider what to work on next, in order to plan our agenda for the meeting in Buenos Aires. We have a couple of active Working Group drafts:

- draft-ietf-ippm-6man-pdm-option, in WGLC until next Friday.
- draft-ietf-ippm-metric-registry, to be revised on WGLC comments.
- draft-ietf-ippm-model-based-metrics, which needs work before a second WGLC.

We'll want time on the agenda for all three of these.

We've also adopted two new WG documents, for which we expect to see dratf-ietf-ippm- revisions before Monday 21 March:

- draft-cmzrjp-ippm-twamp-yang
- draft-morton-ippm-initial-registry

We'll want time on the agenda for these, too.

Beyond that, we've reviewed discussion on the mailing list to see where the working group's energy seems to be for additional documents. First, we have seen a lot of discussion on what we call the "hybrid/coloring cluster", so I think we should have a discussion about approaches here, how they fit together, and what if anything we should consider adopting in this space:

- draft-tempia-ippm-p3m
- draft-chen-ippm-coloring-based-ipfpm-framework
- draft-fioccola-ippm-rfc6812-alt-mark-ext

We've already talked to Giuseppe Fioccola about these, and would like to propose a single presentation about all three followed by a long discussion slot.

There's also been some discussion on draft-mirsky-ippm-time-format, and it seems like this one might be close enough to make an adoption call for too.

All other drafts: As discussed in Yokohama, we'd like to reserve time for work that's actually already being discussed on the list, so at the end of the agenda we'll have time for discussion of new work without any substantial discussion so far. These will be organized as 5 minute lightning talks, and allocated FCFS in two queues, with completely new drafts having priority over ones that have already been presented.

We're tentatively scheduled for a 2.5 hour slot on Monday morning, but there is discussion about moving us back to a 2 hour slot on Friday, so we'd propose the following agenda, with the last slot being either 15 or 45 minutes long:

10:00: Note well, intro, status, agenda bash (chairs, 10m)
10:10: draft-ietf-ippm-metric-registry
      WGLC discussion completion, as req'd (10m)
10:20: draft-ietf-ippm-6man-pdm-option
      WGLC discussion completion (N. Elkins, 15m)
10:35: draft-ietf-ippm-model-based-metrics
      new revision / second WGLC kickoff (M. Mathis, 10m)
10:45: Coloring/Hybrid Approach Presentation and Discussion (TBD, 45m)
      draft-tempia-ippm-p3m
      draft-chen-ippm-coloring-based-ipfpm-framework
      draft-fioccola-ippm-rfc6812-alt-mark-ext
      Discussion; decision on call to adopt?
11:30: draft-mirsky-ippm-time-format (G. Mirsky, 15m)
      Discussion: decision on call to adopt?
11:45: Lightning talks for new work: two requests received so far:
      draft-bailmir-ippm-twamp-dscp-ctrl-mon-00 (G. Mirsky)
      draft-mirsky-ippm-twamp-light-yang-02 (G. Mirsky)

Authors: please let us know if you have any corrections here. Those with new work to present: please let us know if you'd like a lightning talk slot.

Cheers,

Brian and Bill (chair hats)

---

From: Joachim Fabini <[email-masked]>
Date: Fri, 11 Mar 2016 17:14:04 +0100

Brian, IPPM,

Thumbs up, excellent work and RFC-publishing performance. This brings me
to a somewhat related topic: fixing of legacy shortcomings seems to not
be that thrilling and gains little attention/priority in ippm. The
process of finding new ippm topics may benefit from some
priority-elevation scheme. In particular, we must make sure to advance
work that a) ippm has committed to as part of RFC approval processes
and/or b) approved RFCs depend on.

(co-author hat off) Specifically I'm concerned about the 2330-update for
IPv6 and IP options not even being on the agenda. During the GenArt
review of RFC 7679 and 7680 the IESG asked ippm to fix the missing IPv6
support in RFC2330. When reading
https://www.ietf.org/mail-archive/web/ietf-announce/current/msg14489.html it
is my understanding that these two essential RFCs have passed the
standardization process only because ippm proposed/committed to fix the
RFC2330 shortcomings wrt IPv6 in a separate document. This is
draft-morton-ippm-2330-stdform-typep, which has not been adopted as WG
item and not even on the agenda for IETF-95.

It's a fundamental question of the ippm being credible. The same
question about IPv6 support will be asked again by the IESG latest when
the next IPv6-related ippm draft is in their queue. The active-passive
RFC now is in AUTH48 and references
draft-morton-ippm-2330-stdform-typep, PDM-options may be next, so we
have at least two RFCs and two almost-RFCs that reference and badly need
the IPv6 update.

>From my perspective the ippm work can and must prioritize new topics
that are in the attention and focus of ippm participants. Still, the
fixing of such substantial legacy issues like IPv6 should have at least
the same level of priority. Ippm must prioritize and complete the
homework it has committed to while adopting earlier RFCs to stay
credible vs. the IESG. And it is my feeling that this needs to be
reflected somehow by ippm processes and priorities.

Any opinions?

thanks
Joachim

On 11.03.2016 14:00, Brian Trammell wrote:
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 11 Mar 2016 16:17:24 +0000

+1

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Joachim Fabini
Sent: Friday, March 11, 2016 11:14 AM
To: [email-masked]
Subject: Re: [ippm] IPPM WG Status and Agenda for IETF 95 Buenos Aires

Brian, IPPM,

Thumbs up, excellent work and RFC-publishing performance. This brings me to a somewhat related topic: fixing of legacy shortcomings seems to not be that thrilling and gains little attention/priority in ippm. The process of finding new ippm topics may benefit from some priority-elevation scheme. In particular, we must make sure to advance work that a) ippm has committed to as part of RFC approval processes and/or b) approved RFCs depend on.

(co-author hat off) Specifically I'm concerned about the 2330-update for
IPv6 and IP options not even being on the agenda. During the GenArt review of RFC 7679 and 7680 the IESG asked ippm to fix the missing IPv6 support in RFC2330. When reading https://www.ietf.org/mail-archive/web/ietf-announce/current/msg14489.html it is my understanding that these two essential RFCs have passed the standardization process only because ippm proposed/committed to fix the
RFC2330 shortcomings wrt IPv6 in a separate document. This is draft-morton-ippm-2330-stdform-typep, which has not been adopted as WG item and not even on the agenda for IETF-95.

It's a fundamental question of the ippm being credible. The same question about IPv6 support will be asked again by the IESG latest when the next IPv6-related ippm draft is in their queue. The active-passive RFC now is in AUTH48 and references draft-morton-ippm-2330-stdform-typep, PDM-options may be next, so we have at least two RFCs and two almost-RFCs that reference and badly need the IPv6 update.

>From my perspective the ippm work can and must prioritize new topics
that are in the attention and focus of ippm participants. Still, the fixing of such substantial legacy issues like IPv6 should have at least the same level of priority. Ippm must prioritize and complete the homework it has committed to while adopting earlier RFCs to stay credible vs. the IESG. And it is my feeling that this needs to be reflected somehow by ippm processes and priorities.

Any opinions?

thanks
Joachim

On 11.03.2016 14:00, Brian Trammell wrote:
> - RFC 7679 (was draft-ietf-ippm-2679-bis)  A One-Way Delay Metric for 
> IP Performance Metrics (IPPM)
> - RFC 7680 (was draft-ietf-ippm-2680-bis)  A One-Way Loss Metric for 
> IP Performance Metrics (IPPM)
> - RFC 7717 (was draft-ietf-ippm-ipsec)  IKEv2-Derived Shared Secret 
> Key for the One-Way Active Measurement  Protocol (OWAMP) and Two-Way 
> Active Measurement Protocol (TWAMP)
> - RFC 7718 (was draft-ietf-ippm-owamp-registry)  Registries for the 
> One-Way Active Measurement Protocol (OWAMP)
> - RFC 7750 (was draft-ietf-ippm-type-p-monitor)  Differentiated 
> Service Code Point and Explicit Congestion  Notification Monitoring in 
> the Two-Way Active Measurement  Protocol (TWAMP)
> 
> In addition:
> 

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: <[email-masked]>
Date: Fri, 11 Mar 2016 16:24:44 +0000 (UTC)

+1
IPv6 stats from Google for the United States are 23% access this year - 12% last year.   High growth rate (even considering likely plateaus in the future).
We are actually researching potential additions to PDM with FreeBSD folks.  So, IPv6 is very necessary for us.
Thanks for bringing this up, Joachim.
Nalini 

      From: Joachim Fabini <[email-masked]>
 To: [email-masked] 
 Sent: Friday, March 11, 2016 8:14 AM
 Subject: Re: [ippm] IPPM WG Status and Agenda for IETF 95 Buenos Aires
   
Brian, IPPM,

Any opinions?

thanks
Joachim

---

From: Vinayak Hegde <[email-masked]>
Date: Sat, 12 Mar 2016 02:46:33 +0530

Hi Brian, Bill,

We would like a 15min slot for "Monitoring Service KPIs using TWAMP".
During the remote presentation in Yokohama, we received some feedback
from Al, Nalini and Greg. We are planning to incorporate that feedback
and present a delta of the changes. New draft will be ready by next
weekend. We have already presented this work twice in the IPPM WG and
would like the group to adopt it.

Thanks
Vinayak

---

From: Brian Trammell <[email-masked]>
Date: Sat, 12 Mar 2016 12:21:27 +0100

hi Joachim,

You raise good points.

On the other hand, we have limited face to face agenda time to spend on individual drafts which have not generated much (any?) discussion on the mailing list since the previous face-to-face meeting. When we put the agenda together, we let the mailing list be our guide, as discussed in Yokohama.

On the third hand, there was discussion of this approach in the final processing on the bis drafts, so that kind of counts.

(I'd suggest, personally, that "2330-stdform-typep" is not a very useful draft name for letting people who know they care about IPv6 measurements that this document is important to them. I guess there are two 3's in the document name, and 3 + 3 = 6...?)

As I understand it, what's happened since Yokohama that you'd like face-to-face time to discuss is "document ready, call for adoption"? There seems to be WG support for that, so we can certainly wedge ten minutes in for that between model-based-metrics and the hybrid/coloring cluster.

Cheers,

Brian (chair hat)

> On 11 Mar 2016, at 17:14, Joachim Fabini <[email-masked]> wrote:
> 
> Brian, IPPM,
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 12 Mar 2016 10:55:40 -0500

Hi Brian and all,
please see replies below,

> From: ippm [mailto:[email-masked]] On Behalf Of Brian Trammell
...
> On the other hand, we have limited face to face agenda time to spend on
> individual drafts which have not generated much (any?) discussion on the
> mailing list since the previous face-to-face meeting. When we put the
> agenda together, we let the mailing list be our guide, as discussed in
> Yokohama.
[ACM] 
With the change in agenda-time criteria, my mistake 
(in retrospect) was inviting many of the IPv6-interested 
wg participants as co-authors when starting this draft
last August. The co-authors plus Brian Carpenter and 
Fred Baker discussed this draft at great length during
the rush to prepare the 00 individual. Quickly collecting 
input and experience was more important than having a
pool of reviewers later.

> 
> On the third hand, there was discussion of this approach in the final
> processing on the bis drafts, so that kind of counts.
> 
> (I'd suggest, personally, that "2330-stdform-typep" is not a very useful
> draft name for letting people who know they care about IPv6 measurements
> that this document is important to them. I guess there are two 3's in
> the document name, and 3 + 3 = 6...?)
[ACM] 
Unfortunately, search engines don't seem to offer term addition,
only union and order, maybe others.

We took your advice, but in the title of the draft:
WAS
Updates for IPPM's Active Metric Framework: Packets of Type-P and
                        Standard-Formed Packets
NOW
IP Options and IPv6 Updates for IPPM's Active Metric Framework: Packets
                 of Type-P and Standard-Formed Packets
(this is another case where the co-authors had a lively discussion with
several different proposals... and WG comments on the new title are welcome)

We can change the filename too, if adopted.

> 
> As I understand it, what's happened since Yokohama that you'd like face-
> to-face time to discuss is "document ready, call for adoption"? There
> seems to be WG support for that, so we can certainly wedge ten minutes
> in for that between model-based-metrics and the hybrid/coloring cluster.
> 
[ACM] 
We had a volunteer to review in Yokohama (I can see his face, works for 
Comcast I think, John???)  But we didn't ping him. mea culpa.

Anyway, thanks Joachim for making your well-formulated argument
(because we are a standards body, that means being willing to 
maintain the standards that the wg is responsible for),
and for granting some agenda time, Brian.

regards,
Al

> >> First, let us congratulate the IPPM working group on its excellent
> productivity in finally-published-RFC terms: we've seen five(!)
> documents published since Yokohama:
> >>
> >> With that, it's time to consider what to work on next, in order to
> plan our agenda for the meeting in Buenos Aires. We have a couple of
> active Working Group drafts:
> >>
> >> We've also adopted two new WG documents, for which we expect to see
> dratf-ietf-ippm- revisions before Monday 21 March:
> >>
> >> Beyond that, we've reviewed discussion on the mailing list to see
> where the working group's energy seems to be for additional documents.
> First, we have seen a lot of discussion on what we call the
> "hybrid/coloring cluster", so I think we should have a discussion about
> approaches here, how they fit together, and what if anything we should
> consider adopting in this space:
> >>
> >> - draft-tempia-ippm-p3m
> >> We've already talked to Giuseppe Fioccola about these, and would like
> to propose a single presentation about all three followed by a long
> discussion slot.
> >>
> >> There's also been some discussion on draft-mirsky-ippm-time-format,
> and it seems like this one might be close enough to make an adoption
> call for too.
> >>
> >> All other drafts: As discussed in Yokohama, we'd like to reserve time
> for work that's actually already being discussed on the list, so at the
> end of the agenda we'll have time for discussion of new work without any
> substantial discussion so far. These will be organized as 5 minute
> lightning talks, and allocated FCFS in two queues, with completely new
> drafts having priority over ones that have already been presented.
> >>
> >> We're tentatively scheduled for a 2.5 hour slot on Monday morning,
> but there is discussion about moving us back to a 2 hour slot on Friday,
> so we'd propose the following agenda, with the last slot being either 15
> or 45 minutes long:
> >>
> >> Authors: please let us know if you have any corrections here. Those
> with new work to present: please let us know if you'd like a lightning
> talk slot.
> >>
> >> Cheers,
> >>

---

From: Brian Trammell <[email-masked]>
Date: Sat, 12 Mar 2016 17:52:20 +0100

hi Vinayak,

I haven't seen much discussion on these since Yokohama. Five minutes should be enough to present deltas. We can put you down for a lightning talk in the returning-work queue.

Cheers,

Brian (chair hat)

> On 11 Mar 2016, at 22:16, Vinayak Hegde <[email-masked]> wrote:
> 
> Hi Brian, Bill,
>

---

From: Vinayak Hegde <[email-masked]>
Date: Mon, 14 Mar 2016 00:03:00 +0530

Thanks. That will work.

Regards
Vinayak

---

From: Joachim Fabini <[email-masked]>
Date: Mon, 14 Mar 2016 09:16:22 +0100

Hi Brian,

thanks for your elaborated answer. A short disclaimer as intro: I
intentionally took my co-author hat off when writing my initial post.
Although our draft is the initial trigger, my focus was on pointing out
some extension to improve the proposed process.
Some ippm drafts that do not gather large interest in the group may be
of strategic importance to ippm. It's imho the responsibility of chairs
to prioritize the resolution of such dependencies (and the
responsibility of authors to notify chairs if they spot out such
dependencies ;).
Specific comments inline.

> On the other hand, we have limited face to face agenda time to spend on individual drafts which have not generated much (any?) discussion on the mailing list since the previous face-to-face meeting…

Absolutely agree whenever we talk about typical "new" work. ippm should
focus on protocols that gather interest in the group.

> On the third hand, there was discussion of this approach in the final processing on the bis drafts, so that kind of counts.

Yes, that's what we said to the IESG that we will do.

> (I'd suggest, personally, that "2330-stdform-typep" is not a very useful draft name for letting people who know they care about IPv6 measurements that this document is important to them. I guess th…

Agreed, as you pointed out in Yokohama: someone who has not read 2330 in
detail will never infer from the draft name on its content. If adopted
we must rename it (your proposal reads fine for me).

> As I understand it, what's happened since Yokohama that you'd like face-to-face time to discuss is "document ready, call for adoption"? There seems to be WG support for that, so we can certainly we…

Putting my co-author hat on: Yes, I believe that we must start the work
on the IPv6-update asap. This way we can support (and not unneccessarily
delay) approval of ippm work that is now in the IESG/Editor queue.

Ideally some non-co-author ippm participants should read the (short)
draft and comment at the BA meeting. Any volunteers?

Thanks again,
Joachim

---

From: <[email-masked]>
Date: Mon, 14 Mar 2016 12:51:25 +0000 (UTC)

>of strategic importance to ippm.  

Guys, do we have other older RFCs which need IPv6 support (or something else) added?
Nalini

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 14 Mar 2016 08:54:54 -0400

Hi Nalini,

By augmenting the framework, we should be augmenting
all the metrics RFCs in an efficient way.

OWAMP and TWAMP are v6-ready, afaik.

That might leave something, but ???
Al

From: ippm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 14, 2016 8:51 AM
To: [email-masked]; Brian Trammell
Cc: [email-masked]
Subject: Re: [ippm] IPPM WG Status and Agenda for IETF 95 Buenos Aires

Nalini

---

From: Fioccola Giuseppe <[email-masked]>
Date: Mon, 14 Mar 2016 17:41:41 +0000

Brian and Bill,
Many thanks for the opportunity.
A discussion on next steps for the three "coloring" drafts is a good point.
We are updating the drafts after comments received from mailing list and we will send the presentation soon.

Regards,

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Brian Trammell
Inviato: venerdì 11 marzo 2016 14:01
A: [email-masked]
Oggetto: [ippm] IPPM WG Status and Agenda for IETF 95 Buenos Aires

Greetings, all,

- RFC 7679 (was draft-ietf-ippm-2679-bis)  A One-Way Delay Metric for IP Performance Metrics (IPPM)
- RFC 7680 (was draft-ietf-ippm-2680-bis)  A One-Way Loss Metric for IP Performance Metrics (IPPM)
- RFC 7717 (was draft-ietf-ippm-ipsec)
 IKEv2-Derived Shared Secret Key for the One-Way Active Measurement  Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
- RFC 7718 (was draft-ietf-ippm-owamp-registry)  Registries for the One-Way Active Measurement Protocol (OWAMP)
- RFC 7750 (was draft-ietf-ippm-type-p-monitor)  Differentiated Service Code Point and Explicit Congestion  Notification Monitoring in the Two-Way Active Measurement  Protocol (TWAMP)

In addition:

Well done, IPPM!

- draft-tempia-ippm-p3m

Cheers,

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 15 Mar 2016 09:58:11 +0100

hi Srivathsa,

> On 15 Mar 2016, at 04:20, Srivathsa S <[email-masked]> wrote:
> 
> Hi Brian,
> 
> Just wanted to point out something.
> In the last 2 meetings our drafts were the last to be presented. As the time was less and people were in a hurry to leave/finish the meeting, not much discussion could happen. Infact in the first meeting I just got 3 minutes to brief about the draft...I understand that as chairs you are doing your best to keep discussions on time, but sometimes discussions does take more time...

There are two issues here: we're trying to keep the discussions on time, and we are trying to make better use of the time that we have for current working group documents as well as documents for which there is demonstrated interest in eventual adoption, based on discussion on the mailing list.

> Atleast this time, can you please prioritize our presentation/talk in the middle part of the meeting so that we can take questions and or people would have little more time to ponder over these drafts?

I can't find much substantive discussion on these drafts in the mailing list archive since Yokohama, certainly not as much as those drafts which have been placed in the main part of the agenda. On review of the list archive, the only reply that I can see is an open question as to whether or not TWAMP is appropriate as a basis for the work you're presenting.

> We are trying to give a different dimension to TWAMP so that its full potential can be utilized to measure lot more things which are the need of the hour.

I personally appreciate the goals you've set out for this work. But as chair, I would like to see the question about applicability hashed out a bit more in mailing list discussion to see if there's anything the WG as a whole would like to consider eventually adopting here. Having new work which is on charter is not enough to guarantee eventual adoption: the working group has to consider it useful enough to contribute to and review the documents after adoption, and you have to make the case to the working group as to why it's important.

Until then, I'm sorry, but what we can we can offer is five minutes in the lightning talk session at the end of the agenda to present deltas.

Regards,

Brian

> Regards,
> Srivathsa
> 
> 
> 
> 
> On Mon, Mar 14, 2016 at 12:03 AM, Vinayak Hegde <[email-masked]> wrote:
> Thanks. That will work.
> 
> Regards
> Vinayak
> 
> --
> Srivathsa