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
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.
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:
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:
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!
Not presented. Comments go to the list please.
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
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.
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.
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.
Guofeng Qian presents.
PMTUD may fail if asymmetric routing. Proposes a replication based mechanism.
Please go to the list for discussion since we don't have time.