6MAN Working Group - IETF 112

Tuesday, November 9, 2021 16:00-18:00 UTC

Meetecho:

Agenda

Tuesday, November 9, 2021 16:00-18:00 UTC

Minutes

Introduction and Document Status

Bob Hinden presented. Slides: Introduction, Agenda Bashing

Ole asked if anyone wanted to bash the agenda. No-one asked for any changes to the agenda.

Bob mentioned the Friday joint session with v6ops WG. Agenda link: IPv6 Operations

Ole presented the slide on document status. There was some discussion on document status of various documents, involving Erik Kline (AD) and Jen Linkova.

SID & IPv6 addressing

Erik Kline presented. Slides: SRv6 SIDs

Suresh Krishnan presented Next Steps.

Erik Kline: Thank you to Suresh for bringing clarity to what the issues are.

Ron Bonica: Would you like to comment on the 6man and Spring mailing lists?

Suresh: Prefer 6man. But following Spring, too.

Ole: Thank you.

IPv6 Application of the Alternate Marking Method

Giuseppe Fioccola presented. Slides: IPv6 Application of the Alternate Marking Method

Ole: it seems that we are making progress. Any comments? No. Hopefully it won't take too much longer.

Carrying VTN Identifier in IPv6 Extension Header

Presented by Jie Dong. Slides: Carrying VTN-ID in IPv6 Extension Header

Ole: Thank you. Comments?

Jie has asked if we could put this draft out for adoption call.

Will run a quick poll to determine interest from WG. Poll results are Raise Hand: 11; Do Not Raise Hand: 33.

Bob: The "11" raised hands appeared to be a stable number (was not increasing). The "Do Not Raise Hand" had still been increasing when the poll ended.

ICMPv6 Extensions for IOAM Capabilities Discovery

Xiao Min presented. Slides: ICMPv6 Extensions for IOAM Capabilities Discovery

Presentation deferred to end due to poor audio from presenter.

ND Prefix Robustness Improvements

Presented by Eduard Vasilenko. Slides: ND Prefix Robustness Improvements

Ole: A lot of comments on chat. Comments?

Jen Linkova: I'm confused. Host switch supports rule 5.5? (abrupt router
change)? We believe this is not needed. We already have mechanisms to
solve this, but host implementations do not care (yet).

Eduard Vasilenko: We believe no. It is not the case. It has good recommendation. But not details. Just good guidance. No explanation on what to do.

Jen: It's about cost and not about changes in new products. There are not many implementations of host side. We do not see this problem in real life.

Eduard Vasilenko: this host selection is related with ND. Two
stages. RFC8028 gave recommendations. We follow it not contradict
it. More details are still needed.

Ole: Continue to discuss on list.

Bob: We need agreement on the problems that need to be solved first, before identifying solutions.

IPv6 Fragment Retransmission

Fred Templin presented. Slides: IPv6 Fragment Retransmission

Bob: Comments? Nobody?

There were no comments.

Ole: We can do a poll to see if there is interest.

Fred: The most important part is chart 2.

Ole: Is that in inherent aspect of fragmentation?

Fred: Bursty nature of sending 1 large packet is what allows greater utilization for same time period by leveraging fragmentation bursts.

Ole: OK it solves some problems.

Bob: A lot of discussion in chat. There will be interactions with transport protocols if IP protocol is doing retransmissions and transport protocol is doing retransmissions.

Fred: It is not correct. Transport retransmission is imperfect.

Bob: In IPv6 it is the endpoint that performs fragmentation.

Erik Kline: As individual, are some of these things separable? Is there something valuable in just the soft error?

Fred: Definitely more there in soft error. More in the draft.

Erik Kline: Maybe that is more useful than other components of the draft.

Poll results are Raise Hand: 12; Do Not Raise Hand: 24.

ICMPv6 Extensions for IOAM Capabilities Discovery

Xiao Min presented. Slides: ICMPv6 Extensions for IOAM Capabilities Discovery

This presentation had been deferred from earlier in the agenda. Audio was much improved.

Cheng Li: Can hosts outside of a domain send an ICMP packet to trigger the IOAM capability?

Xiao Min: Do you mean the host? Yes.

Cheng: What if I am a hacker and send a lot of DDOS packets to get IOAM info from your network? You're saying we can use IPsec for security. But if you want to provide this kind of prtection you need full IPsec mesh in your network. Is this possible?

Xiao Min: This draft provides security mitigate methods. You can also ask network operator to establish policies.

Cheng: But in real network, IPsec is very heavy. It's hard for implementation/usage/deployment. To protect IOAM, we must build up any-to-any IPsec mesh. That's not realistic. You could do some rate limiting for preventing DDOS. I agree with that.

Xiao Min: IPSec is not a MUST.

Eduard V: it is HBH or end-to-end? IOAM is more useful when HBH. How much will it be useful if not HBH?

Xiao: In this draft ICMPv6 echo request is not just E2E. It can be sent to intermediary nodes in path. Intermediate nodes can send replies to host.

Eduard V: Seperate probe for seperate host. Understood.

Eric Vyncke: This draft relies on IPPM draft. Can you say some words about that draft? Is it in WGLC?

Xiao: It is adopted this year in July. 01 working group draft.

Erik Kline: How large do you think these messages are going to be?

Xiao: For the echo request, the message will not be too big. The reply may exceed the MTU limit. We have the big reply message.

Erik: You have a truncation plane?

Xiao: Scoll to slide 3. If the message is too big and exceed the MTU
limit, the value can be set to indicate the message it is too big.

Bob: Thank you. I think this needs more discussion. And we would like to hear from IPPM WG and how this fits into what they're doing. This needs to fit into a larger use case.

Meeting Adjourned

Thank you.