Skip to main content

Minutes IETF105: 6man
minutes-105-6man-00

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2019-07-25 19:50
Title Minutes IETF105: 6man
State Active
Other versions plain text
Last updated 2019-07-31

minutes-105-6man-00
6MAN Working Group  - Montreal IETF Meeting

Tuesday, 23 July 2019, Afternoon Session III, 17:10-18:10, Laurier
Thursday, 25 July 2019, Afternoon Session II, 15:50-1720, Duluth

Chairs: Bob Hinden, Ole Trøan

Minute taker: Barbara Stark (both sessions)
Jabber Scribe: Shuping Peng (both sessions)

Jabber Room: 6man@jabber.ietf.org
Meetecho: https://www.meetecho.com/ietf105/6man

======================
Agenda
======================

Agenda - 23 July 2019

Introduction, Agenda Bashing, Document Status, Chairs, 5 min.

Working Group Drafts

Area Director Comments on "IPv6 Segment Routing Header (SRH)",
draft-ietf-6man-segment-routing-header , Suresh Krishnan / Darren Dukes,
15 min.

ICMPv6 errors for discarding packets due to processing limits,
draft-ietf-6man-icmp-limits , Tom Herbert, 15 min.

Active Individual Drafts

Path MTU Hop-by-Hop Option, draft-hinden-6man-mtu-option , Gorry
Fairhurst / Bob Hinden, 15 min.

New Individual Drafts (as time allows)

IPv6 Neighbor Discovery on Wireless Networks,
draft-thubert-6man-ipv6-over-wireless , Pascal Thubert, 5 min.

IPv6 Neighbor Discovery Unicast Lookup, draft-thubert-6lo-unicast-lookup
, Pascal Thubert, 5 min.

Agenda - 25 July 2019

Introduction, Agenda Bashing, Chairs, 5 min.

Working Group Drafts

RFC8200 Fragmentation Errata,  RFC8200 Errata  , Bob Hinden, 15 min.

Discovering PREF64 in Router Advertisements, draft-ietf-6man-ra-pref64 ,
Jen Linkova, 15 min.

Active Individual Drafts

Change Status of RFC 2675 to Historic, draft-jones-6man-historic-rfc2675
, Gorry Fairhurst, 10 min.

SRV6+ Overview and Motivation, Ron Bonica, 15 min.

IPv6 Support for Segment Routing: SRv6+,  draft-bonica-spring-srv6-plus
  The IPv6 Compressed Routing Header (CRH),  draft-bonica-6man-comp-rtg-hdr
  The Per-Path Service Instruction (PPSI) Option, 
  draft-bonica-6man-vpn-dest-opt The Per-Segment Service Instruction (PSSI)
  Option  draft-bonica-6man-seg-end-opt

New Individual Drafts (as time allows)

Operations, Administration, and Maintenance (OAM) in Segment Routing
Networks with IPv6 Data plane (SRv6), draft-ali-6man-spring-srv6-oam ,
Zafar Ali, 5 min.

Service-aware IPv6 Network, draft-li-6man-service-aware-ipv6-network ,
Zhenbin Li, 5 min.

Consideration of IPv6 Encapsulation for SFC and IFIT,
draft-li-6man-ipv6-sfc-ifit , Shuping Peng, 5 min.

Encapsulation of Path Segment in SRv6,
draft-li-6man-srv6-path-segment-encap , Cheng Li, 5 min.

Segment Routing Header encapsulation for In-situ OAM Data,
draft-ali-spring-ioam-srv6 , Zafar Ali, 5 min.

DetNet SRv6 Data Plane Encapsulation, draft-geng-detnet-dp-sol-srv6 ,
Xuesong Geng, 5 min.

=========================
Minutes (Tuesday, July 23)
=========================

Introduction, Agenda Bashing, Document Status

https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessb-introduction-agenda-bashing-document-status-02

On document status slide...

Jen Linkova: Not happy with outcome of IPv6 only flag draft.

Suresh Krishnan: There has been a lot of feedback. Not everyone was happy
with the outcome.

----------------

IPv6 Segment Routing Header (SRH)

Darren Dukes presented, walking through proposed changes to resolve IESG
comments (no slides presented summary of IESG comments and proposed
resolutions).

Suresh: <commented on wording of resolution to one of the issues>

After Darren finished...

Suresh: Send these to the list and I'll will start the IETF last call.

-----------------

ICMPv6 errors for discarding packets due to processing limits

Presentation:
https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessb-icmpv6-errors-for-discarding-packets-due-to-processing-limits-00

Presented by Tom Herbert

Other ICMPv6 changes slide...

Suresh: Question about advisability of problem code.

Tom: I think you're saying this is outside the bounds of normal
behavior. We aren't advocating but it's important to acknowledge.

Suresh: That's fine, but just provide a little more info about it.

Ole:

Tom:

Implementation slide...

Suresh: One thing you can do is go ahead and lock down the errors.

Tom: OK

Ole: How many people are willing to review as part of WGLC? Six people
said they would review.

ACTION:  Chairs will start a working group last call.

------------------

Path MTU Hop-by-Hop Option

Presentation:
https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessb-ipv6-minimum-path-mtu-hop-by-hop-option-02

Presented by Bob Hinden and Gorry Fairhurst

Tim Shepard: The box looking at these headers might not know about the
bottleneck. Just so long as you're aware.

Gorry: If you do things in certain ways, it will work.

Bob: We don't expect this to be magic. We hope it will be useful in some
cases. We need feedback.

Tom Herbert: I like the idea of doing these experiments over the
Internet. Can we make it ongoing to measure status of extension headers
over the Internet?

Gorry: Can we make this about useful headers?

Jen Linkova: I like this, but we'll see how useful it is.

Joel Jaeggli: Maybe this will work on some architectures? I'm not sure
someone can write a hop-by-hop test that will work everywhere.

Geoff Huston: We're getting some high failure rates because of extension
headers. Not sure why. We'll try to publish some statistics more
regularly.

Dave Thaler: My understanding of what you draft is saying: If you don't
understand it, pass it on.

Gorry: It only works if...

Dave: Right. It's an upper bound. What are you going to use this for?

Gorry: PL

Dave: Packetization layer

Erik Kline:

Bob: We also said something like that.

Ole: People in favor of making this a WG draft, please hum now? <some
humming> Violently opposed? <no audible humming>  OK, it sounds like there
is support in favor of adopting the draft.

ACTION:  Chair will confirm adoption of draft on mailing list.

-----------------

IPv6 Neighbor Discovery on Wireless Networks

Presentation:
https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessb-draft-thubert-6man-ipv6-over-wireless-01

Presented by Pascal Thubert

Lorenzo Colitti: This draft isn't really trying to start new work. I
think it's incomplete.

-----------------

IPv6 Neighbor Discovery Unicast Lookup

Presentation:
https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessb-draft-thubert-6lo-unicast-lookup-00

Presented by Pascal Thubert

-----------------

Ole: We will reconvene on Thursday. Please discuss Pascal's questions
(regarding generalizing draft and moving to 6man) on the list.

=========================
Thursday, July 25, 2019
=========================

Introduction, Agenda Bashing, Document Status

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessb-introduction-agenda-bashing-document-status/05/

Ole mentioned the new RFC formats. There was much rejoicing when he said
he could write his surname without slashes.

------------------

IPv6 RFC8200 Fragmentation Errata

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessa-ipv6-rfc8200-fragmentation-errata/00/

Presented by Bob Hinden

Joel Halpern: This [on slide 12] seems like a sensible approach, but I'm
uncomfortable with publishing that thing that appears as an errata.

Bob: See next slide. [slide 13]

Joel: Ah! OK.

Suresh Krishnan: [As AD] I like the option of approving errata and
providing text. It seems like less overhead.

Ole: The problem is there seems to be no direct correlation between the 3
pointing to a fix.

Suresh: Other things can proceed in parallel. I don't want to wait for a
year. Keep this verify and then people can go to the RFC page and see it
as verified.

Ole: OK. So we'll take further discussion to list.

Bob: Not recommended to do 8200bis.

Suresh: Thank you.

Bob: Next step is to send out text to list -- original, proposed, and
diff.  Once there is agreement, Suresh can process the errata.

Ole: It would be great if 2 different people could implement to verify text.

ACTION:  Send proposed text to the list.

------------------

Discovering PREF64 in Router Advertisements

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessa-discovering-pref64-in-router-advertisements/01/

Presented by Jen Linkova

Ole: Who is willing to review as part of WGLC?   Five people
volunteered.  OK, we will start WGLC.

ACTION:  Chairs will start working group last call on mailing list.

------------------

Change Status of RFC 2675 to Historic

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessa-change-status-of-rfc-2675-to-historic/00/

Presented by Gorry Fairhurst

Slide 5 (Questions for 6man) <... and there was a stampede to get to the
microphone>

Brian Carpenter: I don't buy the argument. If you don't support it you
don't have to do anything. I don't see why it's damaging to leave it
alone. But there are people who want to do high packet transfer.

Bob Hinden: [not as chair] Is a problem that there are no links you can
really test this with?

Gorry: I wouldn't want to bet that it worked. The code is not exercised.

Bob: Code that is not used doesn't get better.

Ron Bonica: I recommend moving to historic. There is no need to send a
packet that long. Deprecating something we don't use is a good thing.

Ole: [not as chair] I would second Brian's point. When we tried to
implement in Cisco it was pointed out we had no buffers that could
support.

Gorry: We do have options to recommend only using in controlled
environments.

Ole: You could imagine someone wanting to do certain things with it.

Lorenzo Colitti: The question is, can we un-historicize it if we ever
find it is useful? I don't see using it happening in the next 20 years,
but maybe after that? How much effort is it to make it historic?

Brian: Quoting from text that indicates when jumbo frame option can be
used and that it need not be implemented or understood. I don't
understand why anyone would bother to implement it. I don't understand
why we need to do anything, because no one will implement.

Erik Kline: Even though there might not be implementation support, there
might be loopback.

Gorry: Maybe

David Lamparter: I would rather have it moved to historic.

Suresh: [no hat] I've seen things that could potentially use this. I'd
say let it be. If there's an implementation, then maybe they can fix it.

Suresh: [AD hat] Moving to historic is not a problem. I know the
process. So if the WG wants it done, I'll get it done.

Gorry: There is a problem with people being told they have to support it.

Brian: I would support a short document that would update the RFC that
says "This is what I mean, and don't do it."

Bob: Brian, are you willing to co-author?

Brian: I'll see about that.   [Chairs took that as a yes that Brian will
write a short document clarifying state of Jumbograms.

------------------

IPv6 Support for Segment Routing: SRv6+

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessa-ipv6-support-for-segment-routing-srv6/00/

Presented by Ron Bonica

Bob: This was also presented to spring WG. There didn't seem like a lot
of enthusiasm to take this on in Spring.

Ron: There was discussion.

Suresh: [as AD] What I said in spring -- what we did with SRH is what I'd
like to do with this. Act like a gatekeeper.

Martin Vigoureux: [Routing AD] You should expect a message from the
spring chairs.

Bob: Subscribe to the spring mailing list if you don't already.

------------------

Operations, Administration, and Maintenance (OAM) in Segment Routing Networks
with IPv6 Data plane (SRv6)

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessa-application-aware-ipv6-networking/01/

Presented by Zafar Ali

Greg Mirsky: Operators will appreciate this work. There is some
inconsistency in how the draft is named and what it addresses. I think
OAM is broader than just ping. Maybe target the name more. I think the
draft is ready for adoption (and adoption call).

Zafar: I agree with name change. Please suggest new name.  : Operators do
like this. We have plans.

Ron Bonica: Comment on where you're referencing it from. Not all devices
have state forwarding control plane.

Zafar: We can reword it.

Cheng Li:

Satoru Matsushima: As an operator who already deploys SRv6, I appreciate
this work and hope the draft move forward. And support to keep the name
SRv6-OAM.

Ole: We've discussed where right place is for this. We think it can be
worked here. Please raise hand if you're willing to work on it
here. <hands were raised> Excellent.

Zafar: spring is happy for 6man to work on this.

Bob: It seems mostly about defining data header.

Ole: Objections?

Suresh: No objection but please also take to list.

Ole: Those in favor of adopting hum now. <loud humming> Those opposed?
<no audible humming> Thank you. We will take this to the list as well.

ACTION:  Chairs will confirm adoption on the mailing list.

------------------

Application-aware IPv6 Networking

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessa-application-aware-ipv6-networking/01/

Presented by Zhenbin Li

Lorenzo Colitti: I can see where some people might be concerned.

David Somers-Harris: I'm curious about the same thing.

------------------
IPv6 Encapsulation for IOAM - Enhancement of IPv6 Extension Headers

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessa-ipv6-encapsulation-for-ioam-enhancement-of-ipv6-extension-headers/00/

Presented by: Shuping Peng

Greg Mirsky: I would suggest rather than putting data in packet to look
at proposal in ippm WG that uses the packet to trigger measurements. This
would allow you to tag multiple packets.

Frank Brockners: We had a discussion on encapsulation of IAOM messages in
6man last time and we have another discussion now. I thought conclusion
was to progress in ippm first. This work needs to go to ippm first.

------------------

Path Segment Encapsulation in SRv6

Presentation:
https://datatracker.ietf.org/doc/slides-105-6man-sessa-path-segment-encapsulation-in-srv6/02/

Presented by Cheng Li

Ron Bonica: Which node consumes the data? Why is it not a destination header
option?

Cheng: We can get data very quickly from IP header instead of destination
header. Better processing performance.

Ron: If that's the case, when is it appropriate to use DH?

Cheng: Let's discuss off-line.

Zhenbin Li:

------------------

Segment Routing Header encapsulation for In-situ OAM Data

Presentation:
https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessa-segment-routing-header-encapsulation-for-in-situ-oam-data-00

Presented by Zafar Ali

<there was no feedback from 6man WG at this time>

------------------

DetNet SRv6 Data Plane Encapsulation

Presentation:
https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessa-detnet-srv6-data-plane-encapsulation-00

Presented by Xuesong Geng

Ole: [not as chair] There is a non-WG-forming BoF trying to do something
similar. I think there is a lot of overlap in what they are trying to
solve.

Xuesong: I don't think it's a similar problem.

-------------------

Bob: Thank you and we will see you in Singapore.

-------------------
Meeting Adjourned
-------------------