# 6MAN Working Group - IETF 113 Chairs: Bob Hinden, Ole Trøan Minute taker: Peng Shuping, Pascal Thubert Jabber Scribe: TBD Jabber Room: 6man@jabber.ietf.org Meetecho: https://meetings.conf.meetecho.com/ietf113/?group=6man&short=&item=1 ## Tuesday, 22 March 2021, 09:00-11:00 UTC (10:00 - 12:00 CET) ###Introduction and Document Status, Chairs, 10 min. Bob presented the introduction slides, Zulip experimentation active in the group. Tom Herbert will not be able to present his slides, will apreciate feedback on his IPv6 EH draft in the list. A number of new drafts are introduced in the end of the meeting. Ole presented the Document Status slides. Published RFC 9131 on Gratuitous ND. 3 drafts submitted to IESG, a few IESG Discusses. Erik Kline: For the Alternate Marking draft, there is a normative dependancy. Martin Duke is AD sponsoring RFC8321bis/RFC8889bis documents. SRv6 OAM draft (Zafar Ali speaking): DISCUSS from Ben, addressed in rev 13. Waiting on Ben to clear Discuss. Four Drafts were adopted as working group documents. ## Working Group Drafts ### IPv6 Hop-by-Hop Options Processing Procedures * draft-ietf-6man-hbh-processing, Gorry Fairhurst, Bob Hinden, 20 min. Gorry Fairhurst presents. Now it is 01 version after some tweaking. Fact is that HbH is not working on the Internet. RFC 8200 describes a practice but not necessarily a desired future state. From jabber: * MichaelRichardson: RFC8200 hasn't had enough time. * MichaelRichardson: It did impact the work at ROLL, mind you. * Pascal Thubert: indeed it did Slide 3 has the changes made. Concept of fast path is no more as clear as it would (see slide 8). Need to differentiate what can be done at line speed and what takes more processing. Captured all issues during adoption call at https://github.com/ietf-6man/hbh-processing/issues On Issue #5 Gorry: Moving away from term "fast path" and proposed "full forwarding rate" Toerless Eckert: Is it reasonable to expect? Better to skip the extension headers to directly look into the transport layer. Kireeti Kompella: Not a good term. Why would you even bother? What is the value of progressing the HBH? If it is worth processing, it does not have to be in the full forwarding rates. Ben Madson: Not necessarily about the terms but the performance. The thing is about the deterministic processing. As an operator I would not push the processing to the edge but process where I can in the middle of the network. Toerless Eckert: put together the experience we got before we give a name; multicast takes 4x the performance of unicast. But that is mostly large video packets and that helps. Need offset of EH that the platform ignores. Gorry: I'm more on deterministic processing. On Issue #12 Ole: I'm working on an engine that has only fast path and that is indeterministic; Not sure that makes any difference. Kireeti: For a real router there will be a huge difference between the fast and slow path. When it becomes VM the difference will become less. Gorry: Size of the router is another dimension. We need to consider what the router is. Jabber10:29 From jabber: * Suresh Krishnan: I have also heard normal vs exception path used in some contexts but not sure if that is better or not? Ben Madson: There will be still the difference. The path on which things will be asked to wait till this packet is done with its decision tree Toreless: There are a lot inside games inside these gears. We should write the terms down. It is a lot more complicated than just calling it slow or fast. Kireeti: Echo to Toreless. Something similar in MPLS. It is important to find the balance. From jabber: * Loba Olopade: I prefer the normal/exception terminology to fast/slow path Gorry: Are the terms needed? Bob: Yes, but they need to be described carefully. Gorry: We will further work on these terms. On Issue #17 Toreless: Must be able to ignore. Ole: You have got enough questions and comments. Bob: That is good. Thank you all! ### Limits on Sending and Processing IPv6 Extension Headers * draft-ietf-6man-eh-limits, Tom Herbert, 15 min. Not presented. Comments go to the list please. ### Carrying VTN Identifier in IPv6 Extension Header * draft-ietf-6man-enhanced-vpn-vtn-id, Jie Dong, 15 min. Jie Dong presents. RPN (Network Resource Partition) and VTN (Virtual Transport Network) ID mean the same thing. TEAS to work on terms. Jie goes through the slides, see the slides Pascal: Using a HbH option to identify a logical topology and associated state / processing was identified in several places, e.g., the RPL option. Jie: From the beginning of this document, the idea was to use the option to identify the resources associated with the VTN. During the adoption call we received the comment on whether we should generalize it. We are open to this option. Pascal: A comment to the room. Do we have a preference? Either a collapsed one or many options? Bob: Good questions ## Active Individual Drafts ### Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers * draft-carpenter-6man-rfc6874bis, Brian Carpenter, 10 min. Playing Brian's video. See: https://youtu.be/2y7i2xghjFs Brian lists the issues with RFC 6874, suggests a simplified format. Bob: Then wait and see if the community push leads to browser implementation. Mike Ackermann: Great work. This is not a minor issue. This is an inhibitor. Bob: It is a good point. Mike Ackermann: I want to do IPv6. We can give a help. What can we do to help? Michael Richardson: Brian convinced me it is useful. Chicken and egg problem: No IoT support till browsers support this. A Home being renumbered as new owner moves in could be a use case. Ben Madson: No use case, guess it's useful to someone. Data gathering on a back door. Any thoughts whether this is inherently less trustable depending on source. Can of worms there? Bob: We don't think about it. Thank you! Lorenzo Colitti: Value in documenting correct format. URL reaches HTTP server, which does not know the interface. Normal users will not type addresses. Maybe useful for debugs. Ben Madson: Michael Richardson: You need to get the beginning page. understanding URL is a cross site scripting issue, not specific to this draft. ### Segment Identifiers in SRv6 * draft-krishnan-6man-sids Suresh Krishnan, 15 min. The SPRING Chairs asked the opinions from the 6man on the relationship of SRv6 SIDs to the IPv6 addressing architecture. Suresh Krishnan presents. Came out after discussions between SPRING and 6MAN chairs and ADs. One topic came out the SRH SID list, compliance with RFC 4291 LOC:FUNCT:ARG not suitable for host assignment to interfaces. Look at it as a prefix used only for forwarding Request allocation of GUA for SIDs so they can be isolated. Jen Linkova: GUA? you mean to take it from 200::/3? Suresh: It is not coming from 200::/3. It is new. Please send me some text. Ron: The scope of the draft. The focus on the architecture. Some problems in RFC 8200. Should we talk about it in this document? Suresh: Ready to have a discussion. Ron: We can do it offline. Bob: We will start the adoption call next week. ### Source Address Selection for ULAs * (presentation only, no draft), Ted Lemon, 20 min. Ted Lemon presents: This is about SAS for foreign ULAs. Slide 2 has the scenario. In that scenario SAS breaks comms. Should we do something? Michael Richardson: It should have been broken always, so what changed? There seem to be some misconfigurations. Ted Lemon: We should get the clear problem statement. Martin Hunek: It is probably configuration issue. Ted Lemon: Point is that it is valid configuration, do we care or not? Lorenzo Colitti: Ted: Any soho network can be configured in this way. Mike Ackermann: I think this is a good work and I would like to see it continues. Jen Linkova: Don't think it is a configuration issues. It's trying to use RA as a routing protocol. Erik Kline: Will talk offline. Ted: If we do that in this way, it will probably not work. ## New Internet Drafts and Drafts without apparent W.G. Support (if time allows) ### IPv6 Minimum Multipath MTU Detection * draft-qian-6man-ipv6-multipath-mtu-detection, Guofeng Qian, 5 min. Guofeng Qian presents. PMTUD may fail if asymmetric routing. Proposes a replication based mechanism. ### ND Prefix Robustness Improvements * draft-vv-6man-nd-prefix-robustness, Paolo Volpato, 5 min. Please go to the list for discussion since we don't have time. ### Multicast using Multicast Routing Header * draft-chen-pim-mrh6, Huaimo Chen, 5 min. ### Application-aware IPv6 Networking (APN6) Encapsulation * draft-li-apn-ipv6-encap ### Application-aware Networking (APN) Header * draft-li-apn-header, Zhenbin Li, Shuping Peng, 5 min. ### RBS (Recursive BitString Structure) for Multicast Source Routing over IPv6 * draft-xu-msr6-rbs ### Multicast using Multicast Routing Header * draft-chen-pim-mrh6, Toerless Eckert, 5 min. ## Meeting Adjourned