Version: April 1, 2022
WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=detnet
14:30 - 16:30 (+1 CET) – 13:30 - 15:30 (UTC)
Session ICS: https://datatracker.ietf.org/meeting/113/sessions/detnet.ics
Materials: https://datatracker.ietf.org/meeting/113/session/detnet
Notes: https://notes.ietf.org/notes-ietf-113-detnet
Jabber Logs: http://jabber.ietf.org/logs/detnet
YouTube: https://www.youtube.com/watch?v=7Uuo-_6ruqE
Meetecho recording: http://www.meetecho.com/ietf113/recordings#DETNET
10:00 - 12:00 (+1 CET) – 09:00 - 11:00 (UTC)
Session ICS: https://datatracker.ietf.org/meeting/113/sessions/pals.ics
Materials: https://datatracker.ietf.org/meeting/113/session/pals
Notes: https://codimd.ietf.org/notes-ietf-113-pals
Jabber Logs: http://jabber.ietf.org/logs/pals
YouTube: https://www.youtube.com/watch?v=V7DBF9K8cdQ
Meetecho recording: http://www.meetecho.com/ietf113/recordings#PALS
Presenter: Chairs
Lou Berger: Lou presents the traditional introduction; the slides uploaded by meetecho are not latest, agenda is vsible online.
Lou Berger: Question to our AD, John Scudder, do you have any objection to adding “for example” to the proposed charter language change (on uploaded slides)?
John Scudder: No objection to Charter update addition of “for example” text.
Zhenbin Li: Will this new potential queueing work sync with IEEE TSN?
Lou Berger: DetNet allows for alternate queueing mechanisms, so we can always use other subnet queueing methods such as those defined by TSN. We want to coordinate with other SDOs but would need to look at specific proposals. Nothing has been changed in how we work with TSN as a result of this recharter.
Fan Yang: IP OAM doc is updated based on MPLS doc. So why is this submitted before MPLS? Is there something not decided there?
Also I would like clarification: I’m not sure what “enhanced” means WRT DetNet data plane. Would like discussion on this, and submit to IESG.
Lou Berger: Should have said “first OAM doc”, there is no specific order, that’s just a mistake, thanks for catching this.
Regarding enhanced data plane, in DetNet we have had discussion on large scale req’ts and queueing mechanisms. So we had the question of whether to address within RTG area, i.e. in DetNet. So we need the requirements on what to do, and need to be able to propose solutions. So the term “enhanced” allows for this. For example, we will be discussing requirements and solution documents on today’s agenda.
Toerless Eckert: Looks like there is only one doc for each of these areas? We have separate IP and MPLS docs - is that no longer the intent?
Lou Berger: Expect at least one doc for req’ts, this is a “first” solution doc, not necessarily last solution doc.
Toerless Eckert: Depends on use case requirements whether it is necessary to have more than one doc.
Lou Berger: Since we are contribution driven, if we end up with docs that don’t make sense to merge tjem we could have more than one, but for now we are not seeing that. If you see other use cases not covered, bring it up during today’s use case doc discussion.
Toerless Eckert: No single doc could cover all possible use cases. May need more.
Janos Farkas: Summary of broken Status slide: There are two docs for publication requested, a newly adopted document on MPLS over UDP-IP, and OAM framework draft which is not on today’s agenda.
Andy Malis (from chat): The garbled “WG Status” slide is fine on the Datatracker meeting materials page, so you can see it there.
Presenter: Taesang Choi / Scott Mansfield
Liaison receiver: https://datatracker.ietf.org/liaison/1753/
Liaison sent: https://datatracker.ietf.org/liaison/1765/
Scott Mansfield (Links from chat window): https://www.itu.int/en/ITU-T/studygroups/2017-2020/13/Pages/q6.aspx ITU-T Y.3000-series – Network 2030 services: Capabilities, performance and design of new communication services for the Network 2030 applications https://www.itu.int/rec/T-REC-Y.Sup66-202007-I/en Liaison receiver: https://datatracker.ietf.org/liaison/1753/ Liaison sent: https://datatracker.ietf.org/liaison/1765/ 02 - ITU-T Q6/13 recommendation progress
Scott Mansfield: Summary: Study group 13 is on next generation work. Question 6 (“Q6/13”) is about QoS and QoE related to network resource control in large networks, quantum key distribution, etc. Report is on capabilities such as latency. See references above for details.
ITU doc Y.3113 covers terminology, you can find it since it is a public document. E.g. ITU uses terms such as “Large scale networks”, “interdomain networks” which refer to architectures that support capabilities such as bounded latency with or w/o synchronization. Can contact [Scott Mansfield] for additional info or to participate; ITU can provide you with an account to allow you to log into meetings to share your views.
Scott Mansfield: Relation of work to DetNet/IETF: discussing e.g. architecture, up to and beyond 5G. Both orgs must understand terminology of both groups. Docs describe how problem is decomposed. Encourage looking at entire space for deterministic LANs, things DetNet would care about. Are there gaps in protocols? Is it a use case problem, vs framework problem, etc. Should be asking: Are the right questions being asked?
(No discussion from WG)
Presenter: Xuesong Geng
https://datatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework-01
Pascal Thubert: Regarding controller plane for DetNet mechanisms: We are defining functions in architecture which require CP (Control Plane) activity - should this document cover the RAW architecture items also? Question: Do you want to include RAW considerations, or should there be a separate RAW controller plane spec? I think RAW could just be included in DetNet CP draft.
Xuesong Geng: Probably there are more details needed for RAW, so this would just be the top level, with more details in a RAW doc.
Lou Berger: If you have a specific proposal please bring it up.
Carlos Bernardos: I agree with Pascal that we need to agree which group will take up this additional RAW CP specification work (i.e. RAW vs DetNet WG).
Xuesong Geng: As Lou mentioned, a detailed suggestion on list would be helpful. Like which mechanisms or considerations you are asking for.
Toerless Eckert: There was a hybrid CP model discussed at Bangkok meeting, an IEEE document, I don’t see that in this draft? Would be good to have it.
Xuesong Geng (From chat): I have checked the tracker and find that IEEE 802.1 Qcc is one of the references in the original versions, but missed somehow in the latest versions. I will add this.
Toerless Eckert: Previously operator couldn’t decide how much of CP is SDN-like vs distributed control, would like to see this ability for hybrid.
Lou Berger: TEAS architecture allows this hybrid.
Presenter: Greg Mirsky
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-detnet-mpls-oam-07
Lou Berger: How much have you coordinated with the joint PALS/MPLS ODT (open design team) work?
Greg Mirsky: We are closely following and monitoring the discussions of ODT. Since we are following the PW (pseudowire) architecture where control word follows Bottom of Stack label, we are in a protected space so should not affect work of ODT.
Lou Berger: Looks like everyone in room is happy with that statement, good.
Fan Yang: Encoding/Encapsulation of DetNet OAM format: In the IP section, before we define encoding, should we have general consensus on OAM mechanisms? There is already a new encoding, diff’t than what we have in previous OAM mechanisms. Should we discuss mechanism first, before how to encode it?
Greg Mirsky: Re encoding, we propose to re-use encoding as used in PW encapsulation. IP v4, v6 channel types, so DetNet can be followed in various ways, e.g. to use loopback address or as in RFC5884, range for IPv6. Or non-IP encap, such that can follow dACH with TLV to identify source.
Fan Yang: Agree, but for session ID usage, we don’t know this yet?
Greg Mirsky: Good point, we are looking for suggestions and proposals. We think that in this doc we don’t discuss how fields are used, we just define them, with usage to be defined in further docs. E.g. with flags, as you notice, can define some or all, but might take a long time. So more practical to define format of flags now, marked “unused” and allocate later. Analogous to how SRH extension header in IPv6 flag defs are laid out in base RFC, but now there are new proposals for use of these flags for OAM.
Fan Yang: We should continue this discussion on list - this isn’t ready for WG LC yet.
Presenter: Greg Mirsky
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-oam-04
Lou Berger: A sol’n that leverages DetNet over MPLS is good, but need a sol’n for native IP.
Greg Mirsky: Agree. Following data plane encapsulation. DetNet in UDP doesn’t know DetNet Service subnet layer.
Lou Berger: (as contributor) As we discussed, a DetNet flow can operate as 6-tuple, so need a sol’n for that - this proposal only works for UDP, not 6-tuple.
Lou Berger: Why do encapsulation? Why not just fate sharing of aggregate flow? Need to discuss on the list. Need to cover that in this doc.
Pascal Thubert: Regarding how to xport OAM in IPv6. In slide 4 OAM is wrapped in same envelope as data, envelope is network construct to indicate treatment of packet, points to path. Inside that treatment we signal path of OAM. Want to do same thing for IP, w/o UDP. To be discussed in my presentation.
Presenter: Balázs Varga
Draft: https://datatracker.ietf.org/doc/html/draft-varga-detnet-pof-02
Toerless Eckert: The difficult part, which is not approached yet, is a normative YANG doc to expose parameters of POF so in deployments this gives us knowledge to build controller model that will have the required information. Not sure if this is a goal yet, i.e. to expose relevant params?
Balazs Varga: Agree, it would be good not only for POF but other sublayer functions. Currently missing these as extension to existing DetNet YANG model.
Toerless Eckert: A YANG model would be best way to standardize this.
Lou Berger: Any contribution to augment the DetNet YANG model would be appreciated.
Presenter: Pascal Thubert
Draft: https://datatracker.ietf.org/doc/html/draft-pthubert-detnet-ipv6-hbh-07
Greg Mirsky: In 6MAN hopbyhop extension header (HbH) there is requirement/expectation that each node will decide independently if capable of processing hbh extension header; if not, it will just forward it. Result is that processing of hbh is not guaranteed, unless we tighten the requirements on nodes to ensure in DetNet domain with IPv6 this processing is guaranteed.
Pascal Thubert: Problem with IPv6 HbH draft at 6MAN is that it is designed for traversing the Internet. On a limited domain such as DetNet is chartered for, we don’t have that problem. A deployment must ensure that the devices in the network are chosen appropriately to support DetNet. But there may be trouble implementing this if the DetNet signaling is beyond 64 or 128 bytes into packet e.g., for merchant silicon. Placing it in HbH places it right after the IPv6 header and ensures that more routers can support it.
Greg Mirsky: Can discuss on list: Interworking with this mechanism, interaction with other headers e.g. SRH.
Pascal Thubert: There are example encodings in the draft including with SRH.
Lou Berger: This is interesting work, have room in DetNet charter for more advanced mechanisms (i.e. more advanced than 5 tuple).
Pascal Thubert: Problem with flow label is that it is endpoint decision. Need to leave endpoint constructs to endpoint.
Lou Berger: Should also socialize in 6MAN.
Pascal Thubert: Talked about that at 6MAN this morning. Should this, the RPL option and the VTN ID be their own separate HbH header or could we converge VTN ID with DetNet Path information?
Presenter: Peng Liu
Draft: https://datatracker.ietf.org/doc/html/draft-liu-detnet-large-scale-requirements-01
Lou Berger: No time for discussion, please continue on list. We would particularly like to identify any omissions. We would like to consider adoption next month.
Presenter: Toerless Eckert
Draft: https://datatracker.ietf.org/doc/html/draft-eckert-detnet-mpls-tc-tcqf-01
Lou Berger: We will give some time for other solutions to be proposed before considering adoption of this proposal, probably by next IETF.
Quan Xiong: Do we plan to have one specification for each of the three (IP, MPLS, IPv6)? Maybe we will have other queueing solutions, then would have many other solution documents/specifications?
Toerless Eckert: This one would be easiest to justify for specifying first, since it is based on real-world experience. Many others could be proposed, based on research or whatever, but they should not hold up this work.
Lou Berger: @Quan: You are pointing out difference between queuing and marking. Marking is Data Plane specific, should be in its own doc. Queueing is more general. May have multiple documents. If you have any alternatives to propose, would like to see a document on that. Please continue on list.
Presenter: Kehan Yao
Draft: https://datatracker.ietf.org/doc/html/draft-lyy-detnet-ref-delay-measurement-00
Greg Mirsky: Clock sync helps mitigate instabliity of timers. Without clock sync, timers will skew, so won’t be constant difference measurement, will be floating, so this will be a difficulty for your proposal.
Lou Berger: Need to move on now, please continue on list.
Dean Bogdanović (from chat): Per the slide, there is requirement to provide time stamping by the origination and destination point. As Greg correctly pointed out, we can’t rely to have those two end points will be in time sync and don’t know what is the drift on each end. With that the one way delay measurement becomes unreliable.
Kehan Yao (from chat): @Greg, regarding your questions on clock synchronization deployment, sometimes the deployment is not that easy especially places underground. People might need multiple-stratum NTP for time sync. But the precision can not be guaranteed, and the cost might be very high. My proposal assumes a ref pkt been sent in deterministic path where its latency bound is within us (assume this means “microsecond”) level, so every time you want to measure a target pkt, you use the ref pkt for calculation. The sending time interval between both the pkts is very small, so that we could think the offset between both ends is static. And we can just get the OWD based on the mechanism above.
Presenter: Shaofu Peng
Draft: https://datatracker.ietf.org/doc/html/draft-peng-detnet-deadline-based-forwarding-01
Lou Berger: Please make your comments on the list, we are out of time.
Presenter: Quan Xiong
Draft: https://datatracker.ietf.org/doc/html/draft-xiong-pce-detnet-bounded-latency-00
Lou Berger: I suggest you bring this proposal to PCE WG as well. They will probably ask for assurance that DetNet WG feels that this is important work. Then it can be decided whether to do this work in DetNet vs PCE, given that there is support available (i.e. willing contributors) for doing the work.
(Adjourn)
Ethan Grossman