Mirja - jabber scribe
Brian reported WG Status
Brian reported on milestones
Need milestones and dates for pdm-option and active-passive
Brian put the IPPM Agenda up (10 items, no time for add'l items in this session). 3 are WG drafts, the other 7 are individual drafts.
Mailing list (ippm@ietf.org)
Brian: the work of the WG should be happening on the list.
Needs change, some of the items today have had zero discussion on the
list. New work must be introduced on the list before IETF95
and the working group will not schedule a slot unless that happens.
There has to be a reason for a slot and that now will require
both discussion on the list and a draft update (if it is not new).
Added a couple sections about v6 transition technologies
There is testing of an implementation in FreeBSD
Did an initial test
Geolocate addresses
Question to working group:
Nalini said they’re getting push-back on implementation because there are some complications with some stacks so it's a big change, e.g., currently using global counters. What they probably are willing to do (and some already do) will be to have an API to add an option header.
q: [Brian] Can we do better than IPID?
a: [Nalini] Yes it does better.
Name changed.
One big change is that have multiple categories of hybrid.
Much discussion on the list; A number of updates.
Quite a bit of support and review.
Brian asked if everyone felt their changes were reflected in the document.
Joachim said that he was happy with the changes.
Mike Ackermann said he was very happy with the changes and the clarification on what hybrid was.
Greg Mirsky was not in the room at the time to say if his comments were addressed.
Al: Now we need to figure out all the details to tighten up registry requirements
Al reviewed Registry Draft Updates [see slide]. We need to clarify goals (as stated in slide). Encouraging private registries to use same format as public one. Need to add URLs to the Registry Entries in the draft.
Brian asked how many people have read the draft. 4 people said that they have read the draft.
Brian asked for a hum. There was a strong hum for adoption. There was no hum against. Brian said that it would go to the list.
Brian wondered about using names which could be automatically converted using APIs. Al said that there was some discussion about hierarchical naming. Will talk about this offline.
Will do call for adoption on list. Only one non-coauthor has read it.
Brian suggested that it have '6' somewhere since it is an IPv6 revision. He also suggested that it have IPv6 people review it.
q/comment: [Dave Plonka] suggested giving community hints about why a given aspect of IPPM is sensitive to v4 vs. v6 features (so that a v6 person doesn't need to know all of IPPM).
John Brzozowski from Comcast said he knows IPv6 and that he will review it if he has help from IPPMers.
q: [Mirja Kuehlwind] Definitely interesting to make recommendations about timing,
but could just be a separate informational RFC
rather than an update to RFC 2330
a: [Joachim] It could be, we should effectively define "host time"
q: [Mirja] Maybe 2330bis is an alternative
a: [Joachim] The best might be to connect [all of these] and summarize
q: [Al Morton] agrees, bite of small pieces as a time, and do a full update to 2330
q: [Brian] If we just define "host time" as one of [Joachim's definitions] defining it could be a clean update, but are there some definitions that aren't clean?
q: [Brian] How much of the uncertainties are conceptual vs. fundamental,
i.e., a time that you just can't get (e.g. hardware limitation)?
a: [Joachim] ... It depends.
q: [Brian] Personally, I think this is valuable and do something.
Brian asked for people to read it.
a: [Joachim] WG please give feedback.
Joachim said more discussion would be very valuable.
Kostas said it is quite interesting and has potential. But, he is wondering what is actually host and what part is TWAMP. Original IPPM had a very different implementation. Should continue discussing. Need more feedback from wireless and data center.
q: [unknown] One more vote for getting involved on the list subcomponent break down of the time I would love to work with you on this
q: [unknown] Why is it so important the delay the host incurs from the network delay?
a: [Joachim] b/c contention-based access is temporary/uncertain condition,
but some other effects are systemic affects (like w/timeslots). Sometimes
you can improve by 10ms just by sending at the right time.
q: [unknown] work in MPLS working group on tick/tock could be useful here
Greg Mirsky said to look at work done in TicToc.
Brian (not as chair): Coordinate with TicToc
Kostas asked for WG adoption
Brian asked who had read the draft - 3 people raised their hands.
Brian: Thinks this is probably enough for this type of draft
Brian asked the room for a hum. There was a hum for adoption. No hum for against. Will take to the list.
Brian (as chair): Any comments?
A few people said they've read the draft
q: [Mirja] The draft feels more informational than a general principle
q: [Giuseppe] Now it is very general in the first section later sections are open to define use cases currently only 1 defines characteristics of our implementation.
q: Mirja Kuehlwind said that it still feels like what your company does than a general document
a: Giuseppe: We made our implementation a use case.
q: [Greg Mirsky] In BIER working group, we did get 2-bits for marking method and shows how it can be applied This could be one of the use cases it is based on this document
Brian interjected: There exist an additional draft -alt-mark that you should read and we can talk on the list
Kostas: You only provide a diagram with the session client and session reflector as one
Greg: This is convention used before in other RFCs
Kostas: Between the sessions is there is one negotiation happening?
Brian and Greg: Not much discussion last IETF (Prague) but there was more in Dallas
Brian: any comments?
q: [Al] lets discuss slide "TWAMP Use Case (cont.)" slide
it says reflector can set NTP format?
isn't that the starting place?
a: [Greg] no, the rationale for this came from, folks that support IEEE-1588
they don't have to support NTP timestamp format (in hardware)
If NPU doesn't support NTP, we have a problem.
q: [Al] THat means people would be building systems that will fail.
a: [Greg] No. There are scenarios when supporting this extension that
you must be able to interpret both timestamp formats.
Brian - clarifying - this would update/obsolete the TWAMP spec. b/c
it updates the protocol.
Is the marginal gain here worth the possiblity that an old "TWAMP" reciever
will not work if it isn't NTP capable?
a: [Greg] if you take a box w/o this extension as a sender,
and do this as a reflector, it doesn't work.
Brian - oh, I don't understand yet. Lets follow-up offline.
Vinayak: Said they've separated methodology from implementation
Vinayak gave overview of impelementation [see slide(s)]
Vinayak reviewed Communication diagram [see slides] they've added 4 new KPI commands: REQ, RESP, IND, ACK ...
Vinayak reviewed Next Steps [see slide] wonders how many read the draft
q: [Greg] What services to you envision to be tested with this?
a: [Vinayak] DNS resolution, a whole bunch of transport layer as well as
application KPI ...
it depends on the implementation
q: [Greg] The problem I have with it, if you want to exercise the performance of the service, you probably have to build OAM into the service. This will only exercise the transport to the service, not the service itself.
q: [Greg] I think you're requiring changes of behavior.
TWAMP requires very special processing in the data plane.
Better to have this functionality outside TWAMP.
e.g., OSPF-TE extention, etc. but these don't change the behavior.
This is changing the behavior of TWAMP.
a: [someone unseen] It's not, we're adding new things, piggybacking on it.
q: [Al] I request the authors provide a view of the tested path. The idea that TWAMP is involved in conveying the service PDU and that something add'l is measured... it would be useful to see the test diagram of how TWAMP would be used in this way. I haven't read the draft, but don't see such a diagram in this. I'd like to see the measurement path and how it's assisted by TWAMP.
q: [Nalini] I'm not so familiar with TWAMP, but there is no security section...
it would be nice if you could make it a little clearer about the
differentiation.
a: [Vinayak] Running out of time... skip to next presentation.
Vinayak skipped to, and reviewed, use cases (due to time) [see slide]
Vinayak reviewed Service Latency [see slide]. He suggested this speaks to prior questions about diagram. We need to elaborate on some things in the next update
q: [Vinayak]Does this make things clearer or is more detail needed?
[
Al, Greg, etc.] said this is useful, it's making things clearer.
Vinayak skipped to service load (due to time) [see slide]