Minutes IETF111: 6man
minutes-111-6man-14

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2021-07-27 19:00
Title Minutes IETF111: 6man
State Active
Other versions markdown
Last updated 2021-07-29

minutes-111-6man-14

6MAN Working Group - IETF 111

Tuesday, July 27, 2021 12:00-14:00 PDT (19:00-21:00 UTC)
Chairs: Bob Hinden, Ole Trøan
Minute taker: Barbara Stark, Peng Shuping
Jabber Scribe: None

Jabber Room: 6man@jabber.ietf.org

Meetecho:

Tuesday Session:

Meetecho Link

Tuesday, July 27, 2021 12:00-14:00 PDT (19:00-21:00 UTC)

Agenda

Minutes

Introduction, Agenda Bashing

Slides

Ole and Bob presented. There was no bashing of the agenda.

IPv6 Minimum Path MTU Hop-by-Hop Option

Slides

Toerless Eckert: Very nice. Any experience from ECN experimental?

Gorry Fairhurst: ECN is standards. Second generation of ECN. Unable to
help.

Gorry Fairhurst: Original is currently proposed standards.

Toerless Eckert: I think we could be consistent on that. You made it
experimental because you don't want to explore some things?

Gorry Fairhurst: Original ECN appears to be more unexperimental. We can
do whatever 6man wants us to.

Geoff Huston: Not everybody can do it overnight. It effects every router
along the path. The real question is that how partial deployment will
impact.

Bob Hinden: Agreed, we expect there will be mixed implementations for a
while. Gorry do you want to say more?

Gorry Fairhurst: Not replace the PMTU discovery. If you have some routers
that can discover, then this is a way to probe. Provides a first guess of
what to probe for. This will be faster.

Toerless Eckert: Routers even don't understand. The router will punt them
to the slow path. Some thoughts are to test about the impact on the
latency about the punting.

Gorry Fairhurst: The draft suggests you probe the path occasionally. You
would not add to every packet. You should add to sacrificial
packets. Maybe a few to start the flow and a few now and then.
Toerless: What percentage of the packets are punt?

Ole Trøan: More presentations and drafts on that the routers should not
punt.

Jen Linkova: Why does draft say it is supposed to be used in data center
and closed environment; and how does application know what environment it
is in? How does the host know which connection to use? Maybe the draft
could say more about how it should be used in various environments?

Bob Hinden: Good comment for last call. The first version was the
controlled environment. We can address.

Ole Trøan: The next step would be to last call of this draft. It is
probably the first HBH option to be tested in the wide Internet and we
wait to see the test result. Any objections to do the last call after
this meeting?

Erik Kline: last call as experimental?

Ole Trøan: Yes, or IESG can change it later?

Erik Kline: Changing later would mean another IETF LC.

Bob Hinden: It is not a problem to keep it as experimental. Someone once
referred IPv6 as a "science experiment" intended as a criticism, I took it as a
compliment.

Ole Trøan: Excellent. Thanks.

IPv6 Hop-by-Hop Options Processing Procedures

Slides

Tom Herbert: Some discussions on the list, a lot of questions on the
second point, that is, the HBH option MUST be processed (slide 7) whether
it is practical because a lot of deployed routers may just ignore the HBH
options.

Bob: Let's wait to answer this when we get to the slides on issues.

Bob continues with slides

Dave Thaler: Slide 8, the first HBH option is special. What happens if
everyone wants to put this one has to be the first in two specs.

Gorry: One of the approaches might be that you send separate packets. It
depends on what you're going to use the option for. Sending two packets
may be the right way.

Dave Thaler: Is it written in the document?

Bob: It will be in the issue slide. If the HBH options don't need per
packet it works well. If it has to be in every packet, we are there is an
issue.

Dave: I think as long as you do that in the draft it may not be a
showstopper. Expect it would be an issue. But you need to include the
discussion of that in the document. Need to provide guidance. It is what
we need.

Bob: Completely agree.

Suresh: Will get back in line when audio is better.

Toreless Eckert: The must-be processed HBH option, how about NEW HBH
option? Changing the exiting behaviour would be difficult, but the new
options would be easier.

Bob: Yes, I agree. There is some discussions about criteria for new
options in the document. This can go there.

Warren Kumari: Reminder. Capacity and cost stopped people from doing
so. You need to know how to handle the HBH option in the fast path. You
will need to design the ASIC and hardware.

Gorry: Maybe you could have a configuration that says which one you want
to support. You can only deal with one of them. Match against a table.

Bob: RFC8200 and this draft discuss per option configuration
on whether they are supported and what to do if they are not. The options
that are long and complicated are not going to be widely supported. HBH
options that will be useful will need to have a a compelling use.

Suresh: I like what Dave said about first option thing. And this isn't
really a new issue. Not having it in every packet will be useful. Please
refer to RFC7037.

Bob: The important thing is that the current number is now effectively
zero. We want to change it to one.

Kireeti Kompella: Similar to MPLS work where we are thinking about where
to put the labels after the stack before the payload. Need to take into
account that we have more processing power today and it's very different
on what we can do today. If multiple HBH or E2E things in the stack, how
much of it should/must process or may be processed. If you could not
process what you need to do. Ron and I have talked about HBH options in
IPv6 and I see that is in parallel with this even the terminologies. We
have a DT in MPLS WG. There are some information there that you could
refer to.

Bob: Thank you.

Eduard Vasilenko: Clarification. An example say there are six options
that one in slow path but 5 in fast path. If the vendor could not support
one option processing as a MUST. Does it mean the vendor does not support
IPv6 properly? What would be consequence if a vendor can only support a
small number of HBH options on the slow path?

Bob: We continue the notion that a router will have a config table for
which options it does in fast path. Obviously you can set that to state
you don't support any, which will be compliant. This does not
change 8200. You can claim compliance to 8200 and not support any options.

Eduard: Slide says must support. There is difference between must
disclose support and must support. It should not be should or must. That
is a requirement to disclose.

Bob: The draft is clear on the configurations on each option. Please look
at what the draft says and not just the slide. The presentation is a
summary.

Eduard: There is a difference between Must support and Must disclose
support.

Bob: What does the disclose support mean?

Gorry: We do want the right terminology. It does change the IPv6 core
spec in addition. We hope it will work. We love to get feedback on the
wording.

Adrian Farrel: RFC6398 recommends against the Router Alert especially in
new protocols.

Gorry: Yes, I can reiterate that one. It's for doing Router Alert (RA)
different.

Toerless: Also read it. Better to support Route Alert we should have a
new HBH header code point for it. Don't touch the existing stuff.

Ron Bonica: He said there are few protocols that use RA option. Actually
there is exactly one. Since we have an RFC recommending against using,
maybe we should deprecate it?

Bob: makes sense to me. I don't think deprecating Router Alert is
something we want to do it in this draft.

Ron: Agreed not in this document. Probably a different one.

Kireeti Kompella: Don't try to make RA work to ruin what you really want
to do here. Fix the RA elsewhere and just focus on making the HBH work.

Bob: OK.

Toerless Eckert: In multi path we had 2 protocols we were using and we
were able to make it work. In RSVP we had better hardware and were able
to make it work. Maybe we are obsoleting all the old uses of RA and can
obsolete it now.

Bob continues with slides. Slide 11. Comments on Slide 12?

Kireeti: Dealing with legacy routers. I like the second way of putting
this "If a node is configured to process HBH options, Node MUST
examine...". Slide 12.

Bob: Yes, I think that is the common factor.

Kireeti: Would keep slow path processing. Dont know what will come up in
the future. It may be useful.

Bob: OK.

Toerless: Why not specify in this doc specifically whether an option is
slow path or fast path?

Tom Herbert: Clearly know which options are slow and which ones are fast.
Bob: We agree with that.

Ole: 8 minutes over time.

Bob: Let's go through the rest of the slides.

Ole: Next step will be to do call for adoption on the mailing list.

Limits on Sending and Processing IPv6 Extension Headers

Slides

Jen Linkova: The draft says that host must not send unless it got the
knowledge of the limitation. In the future, with the probe mechanisms,
the host might sense this information.

Tom: Can we defer that? I do have some comments about that on another slide.

Tom continues presenting.

Toerless: I think it's 50/50. I think it's a great analogy for people
trying to define extension headers. But putting analogies in MUST and
SHOULD statements is dangerous. As Jen was saying -- if we do have a
control thing that can figure out and orchestrate what a path is doing,
why do we need some of this? Your control plane must be able to provide
you with what you need.

Tom Herbert: Agree with that. Careful on putting requirements. A node can
ignore them based on RFC8200. It is not 100% for something to be
supported in Internet. In public Internet, we need to get a baseline a
minimal set. If you have knowledge on the path, so you can use the
capabilities.

Dave Thaler: 2 related questions: 1) You talked about how primary problem
you wanted to solve was how to build a transport header. Do you consider
IPsec a transport header? Are there problems with hosts have destination
options encrypted inside E2E IPsec?

Tom Herbert: interesting.

Dave: Is the only problem you're trying to solve for routers or do you
also care about end hosts?

Tom: I dont know about the first question. A question to 6man.

Dave: It would be easier to discuss if this said it was only for stuff
that appears before the IPsec header.

Tom: That would be fine. I don't think IPsec is that prevalent on the
Internet. We do want to have some limits even in the host side.

Dave: We should be judicious with anything that impacts node
requirements. 2nd question: It's not encrypted but you can't trust
packets are handled in the regular way.

Tom: This is the discussion we had in v6ops. Not every packet has a
tranport layer that is parsable. In a real world that is an issue.

Dave: Yes, I'm just considering if there is a case where IPsec is
working, you shouldn't break it.

Tom: In this model, that could be an issue in the host.

Haoyu Song: I agree that there should be some limit on header size. We
cannot foresee what future hardware can actually support. I wonder if
there will be some mechanism to advertise capability to routers so the
host can decide how many headers to use?

Tom：The host could send a packet with a large extension header to
test. The potential trend is that the capability is getting stronger.

Erik Kline: If we do decide to say something sensible about HBH
processing should this also say something about limits? Does it make
sense to have one doc without the other or do they need to go together?

Tom: I think they are related. One is the subset of the other.

Bob: We don't specify sizes in the HBH Processing draft. There are some
relationship between this two drafts.

Tom: I think primary difference is that at least one HBH must be
processed.

Toerless: I think if we can better provide guidance, it will be useful.

Tom: That is the biggest thing that is missing for the hardware
developper. Hard to make experiments without guidance.

Ole: the next step will be to continue the discussions in the mailing
list.

Universal Configuration Information Option

Slides

Jen Linkova: Not sure whether we have discussed before about the
configuration error.

Ole: This is a point Suresh also brought up last time we presented. We
had added text to the draft for that. We didn't mind saying that's a
config error. The same thing applies to DHCP. We left that up to the
implementation to deal with.

Fred Templin: Is the intention for having a universal option so all
future protocols would use this or can other protocols use their own
option?

Ole: it is not meant to stop. My intention was not to do it.

Dave Thaler: I agree that it would be a configuration error if you had a
conflict. You should already have created conflict resolution to solve
RDNSS and DNS from DHCP. I would support adoption of this one. To Fred,
it will be useful for this draft to have some text. We need some
guidance. I like the draft answer it.

Ole: We will add it for sure.

Erik Kline: There are some things I mentioned on the list. Maybe this cn
be a way to head off redundancy. There is value in sometimes not having
things standardized. This could force networks to support certain
options. There might be a Pandora's Box aspect.

Ole: Indeed this would let us out of the bag.

Ted Lemon: It's probably not a good idea to abandon this. It's a bad idea
to have 2 ways to do things. Please take doing RAs out of this, so there
aren't 2 ways to do what's already there. If you open it wide up you will
have a train wreck and not get interoperability. I would prefer to see this not
happen.

Ole: A very good point. Thinking about the same thing. It may be a
argument on whether it should be experimental.

Bob: over time.

Erik Kline: Encoding in IETF is sort of problem.

Ted Lemon: That would make me happier, but I'd still be a little
concern. If open up the door and close it later wont help much. You could
consider the experimental. The problem is the process not the spec.

Toerless: There is no reason why we must have just one way to encode
things. You already have that a lot. This is a perfect experiment. I'd
encourage this as experimental.

Bob: I think there is enough interest to do an adoption call on the
mailing list. If you
object to adoption, you can say it then.

Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers

Slides

Stuart Cheshire: I wanted to reiterate what Brian is saying. I cannot
find any browser that lets me connect to a device I have that puts a zone
ID in with its IP address.

Brian: Do you want to be a contributor to this project?

Stuart: Yes.

Brian continues with slides.

Stuart: For everybody else, not to do any escaping. No need to escape
it. One down side, you cannot copy and repaste to the web. It comes to a
lot of pain. Interesting to see how many other people would like to use
it.

Brian: It has been pointed out that...

Dave Thaler: A lot of URI in the world. Prevent cut and paste. I can

Brian: Edge...

Dave Thaler: Edge has switched to using Chromium as a base.

Brian: We really want to get some feedback.

Toerless: Any character. It is going to be long time.

Brian: The problem is RFC was written a long time ago.

Toerless: You dont have to always replace it.

Brian: It is hard to get something changed in URI.

Bob: Chair hat on. Out of time. There appears to be interest in doing
this, it needs additional discussion and socializations in other
groups. We should continue in the mailing list.

ND Prefix Robustness Improvements

Slides

Bob: Thank you, please bring this to the mailing list.

Carrying VTN Identifier in IPv6 Extension Header

Slides

Bob: Thank you, please discuss this to the mailing list.

Meeting Adjourned

Bob: Very constructive session. Thank you all!