6MAN Working Group - IETF 109

Chairs: Bob Hinden, Ole Trøan

Minute taker: Barbara Stark, Shuping Peng

Agenda - Tuesday, 17 November 2020, 05:00-07:00 (UTC)

Friday, 20 November 2020, 09:00:11:00 (UTC)

Notes

Chair Introduction

Slides

Ole and Bob presented slides. There was no discussion, comments, nor agenda bashing.

draft-templin-6man-omni-option, Fred Templin

Slides

Comments on slide “OMNI Interface Attributes (Type 1)”
Erik Kline: Do you need to say DSCP in doc? Do you need to say RA?
Fred: The two-bit field corresponds to the value in IP header packet.

At end of slides…
Dave Thaler: It looks like main use of this option is for OMNI interfaces. I was trying to look for that in draft. Clarifying question: Where is OMNI interfaces draft? I understand you say it can also solve other problems. But WG doc should also state what problem to solve. 2nd question is I recall ND option assignment is spec required. So even if 6man says no, it doesn’t mean you can’t get the option.
Fred Templin: There is draft called OMNI draft. The purpose of this is to create the RFC that is needed as spec for option.
Dave Thaler: Yes, but 6man WG draft is not only way to create a specification. Independent Stream would also be ok. So this needs to solve more than just OMNI.
Fred Templin: Valid point. I should discuss with chairs and AD, what is the right way to go. To chairs: What is the right way to go?
Bob Hinden：Please show hands if you read the draft
Ole Trøan: Seven shown out of 93, we will continue discussions in the mailing list

The Universal IPv6 Configuration Option

draft-troan-6man-universal-ra-option, Ole Trøan
Slides

Dave Thaler: I’m in favor of this approach. But the way it’s being done – the choice of JSON vs CBOR is something I’d like to discuss. In CBOR these options would be much shorter than JSON. So JSON limits applicability. Prefer to delete all the JSON and just use CBOR
Ole Trøan: I talked to Carston. I think your app could easily do a CBOR implementation independent of how it’s specified here.
Dave Thaler: Similar approach to what was done in other WG, both CBOR and JSON. Lets just delete JSON. You need registry in IANA either way. JSON doesn’t buy you anything. Just use integers to the left of the colon.
Ole Trøan: OK, I can see that you’re right.
Brian Carpenter:+1 to Dave. Only CBOR.
Ole Trøan: Thank you for support. We should clear that up.
Andrew Alston: I definitely prefer CBOR than JSON. I’m not a fan of processing bloated JSON.
Ole Trøan: OK.

Lorenzo Colitti: OK, I don’t see that this gives you semantics. It doesn’t say what to do if you receive one of these. It does not define what are the options. If there is integer time, what are the units? I think you need doc anyway, so I’m not sure common format is what’s important. I don’t think it’s true you need it lke this to get it past the kernel. I don’t have a CBOR parser and would prefer to parse TLVs.
Ole Trøan:How many parser do you have?
Lorenzo Colitti: We have one parser, an SDN one, maybe does not count.
Ole Trøan: We want to avoid taking many years before there are implementations.
Lorenzo Colitti: Take it from RADIUS or something.
Ole Trøan: This allows you to subscribe to messages. You can take out things from the underlying message structure.
Jen Linkova: We’re not just talking about option format. I’m surprised to hear there is no IETF document required. However, I like idea of being able to use random option on my router. So I like the way it’s done but think more specification is needed.
Ole Trøan: Yes, we’re trying to design ourselves out of a job. But I hear what you’re saying.
Fernando Gont: Main goal is to reduce the overhead, right? ead is in semantics?
Ole Trøan: Yes
Fernando Gont:If the overhead is about the semantics, if people specify syntax quickly and we don’t get a doc then what gets implemented? It won’t help.
Ole Trøan: I hear you and share your pain. This came out of IPv6 only debate and what does a flag mean. Maybe it would have been better to specify syntax and let implementations evolve. Yes, we don’t fully know cosequences.
Fernando Gont: If there is not going to be a doc, they still need to refer to somewhere.
Ole Trøan: It depends. And I don’t think there shouldn’t be a doc. There does need to be a stable reference. I share your concern.
Dave Thaler:: I have comments and a suggestion. I think the SUIT WG convinced me that CBOR parsers are really small. And if you have a simple enough structure that you’re encoding, you can parse it. Other WGs decided that wasn’t a problem. Other comment – main overhead I see in IETF is people arguing whether something belongs as RA or DHCP option. So this will cut the work in half. But it doesn’t mean there’s no need for draft. A requirement for expert review is that spec is needed. You can even have a private spec. But once you convert to CBOR and use numbers, smaller numbers are more efficient. Expert review for anything larger than 2 bytes. IETF consensus for 1 byte numbers.
Ole Trøan: Useful, thanks!
Bob Hinden：Please show hands if you read the draft
Michael Richardson: +1 to what Dave said. I think big problem in figuring out semantics is getting people to implement running code. I think this lets people do experiments easily. It lets people who have host and client implementations get expert review. If we can get experimentation down to months instead of years, this will be very useful.
Bob Hinden：16 had read out of 93. Very interesting work, but not mature enough to adopt it here.

IPv6 Neighbor Discovery (RFC 4861) Man-in-the-middle Protection

draft-vasilenko-6man-ND-MITM-protection, Eduard Vasilenko
Slides

Bob Hinden：Start hand raising if you have read the draft. (Bob announced this early during Eduard’s presentation)

At end…
Jen Linkova: If you have duplicate addresses… what you suggest changes current state machine. You say if you detect attack, break everything. I don’t think it’s worth solving this.

Eduard Vasilenko: Not exactly this way.
Jen Linkova: I totally disagree. Look at ISPs doing DAD. You can have duplicated MAC addresses, etc. This is real life. You cannot assume you will never see duplication.
Eduard Vasilenko: Duplication could happen. This mechanism will not be activated just sby duplication. It gets activated when someone does something not according to the standard.
Igor Lubashev:In DC it will be worried about the duplication.
Igor Gashinsky: I agree with Jen, but only kind of. 's a problem that needs to be solved, but maybe not right approach. I think nodes other than h older of address should perform validation. But I think flushing table is harmful because you can DDoS the node.
Eduard Vasilenko: I hear what Jen says. But in my home I’d like to detect. I can see having different choice in different environment, of availability vs. security.
Fernando Gont: Should ask what threat model is for ND. ND requires trusting the link. If you want to mitigate all threats, you need to rely on something like this.
Bob Hinden：Agree with Fernando. We should move to the list.

Least-Common Scope Communications

draft-mudric-6man-lcs, Dusan Mudric
Slides

Bob Hinden：I guess this means devices don’t need GUA. But they need GUA to comunicate outside local environment so I don’t know how useful this is.
Dusan Mudric: Enterprises can keep traffic inside with just LL.
Bob Hinden: But enterprises already have ways to firewall this.
Ted Lemon: Whether you decide to use this depends on how you got LL in
the first place. Your use case is a giant flat network, which we don’t tend to recommend. Is there a real problem to solve? Or is there a better way to solve the problem?
Gyan Mishra: For this use case, it does seem like a lot to do to mitigate a problem with reachability by leveraging LL address. But I wonder if there are other ways. There are other routing protocols similar to LL that work on L2. So maybe using LL like this is unwarranted.
Fernando Gont: I’m trying to understand what is being proposed. The author is suggestig LL be used when nodes on the same link. Normally, you map service to address. So it could be the case to select address of choice – and we have a spec for that. OTOH, if app should only work on local link, I think it should use ULA and not LL or GUA.
Alexandre Petrescu: What is RFC that says what source adress to use? If site deployment has considered and deployed ULAs, then it could be an idea to use ULA instead of LL. Primary use case is SIP phones. One of the slides that shows the topology shows a real network that is flat. This is a real network. (See Problem Statement slide) You’ll see SIP services deployed on left and right sides. Need to talk across Internet with GUA. But using GUA opens self to attacks.
Fernando Gont: What attacks are you tring to mitigate? Attacks against server or client?
Alexandre Petrescu: Mainly against client.
Fernando Gont: As long as the client has a global address, it is subject to attack. So just using LL when you have a GUA doesn’t prevent these attacks.
Ted Lemon: Comment to use ULA makes sense.
Jen Linkova：Use security mechanism by setting requiring hop limit to be 255. As result you can use GUA and it only works on-link.

Carrying VTN Identifier in IPv6 Extension Header

draft-dong-6man-enhanced-vpn-vtn-id, Jie Dong
Slides

Bob Hinden：There is a poll going for who has read the draft. (Bob started this early during Jie’s presentation)

Ron Bonica: 2-part question. First: Does VTN make next hop determination or just which queue you go in? Used for determination of queue or logical interface.
Ron Bonica: So it could make it go to different next hop than if this had not been there?
Jie Dong: No. This (logical interfaces) is an approach to separate resources for same interface.
Ron Bonica: I’m confused. Do all logical interfaces on the same node terminate on same neighbor?
Jie Dong: First you use dest address to determine neighbor. Then this VTN mechanism to determine next queue.
Ron Bonica: OK. If next queue, ok. But as long as not determining next hop by VPN ID, the that’s ok.
Jie: Forwarding based on two step.
Ron Bonica: As long as only identify the next queue it is fine. If next hop, it may cause loop.
Robin Li: It identifies the resouce. It could be queue or interface.
Joel Halpern: It seems some other traffic engineering technique has to be used with this, in which case that other mechanism can do all this and adding extra ID to packt is counter-productive.
Jie Dong: Flexalgo or other mechanisms could be used. But that is on the conrol plane. In the data plane, you need VTN id.
Joel Halpern: But you said this ID isn’t used for flexalgo. If this ID is being used for next hop then we have problems.
Jie Dong:The ID associated with Flexalgo can be used for the next hop. Even after the next hop selection, you need more fine-granularity selection of the interfaces or queues.
Ron Bonica: I’m more confused. I think this VTN ID is moral equivalent of duplicate DSCP bit?
Jie Dong: It will not be used for the next hop.
Ron Bonica: Not clear from draft.
Jie Dong: Will add more text in the draft.

IPv6 Solution for 5G Edge Computing Sticky Service

draft-dunbar-6man-5g-edge-compute-sticky-service, Linda Dunbar
Slides

Ran out of time. Moved to Friday session.

Friday, 20 November 2020, 09:00:11:00 (UTC)

Introduction, Chairs

Slides

Ole Trøan: Attribution Option for Extension Header Insertion (draft-herbert-6man-eh-attrib) from Tom Herbert has been Canceled.

IPv6 Solution for 5G Edge Computing Sticky Service

draft-dunbar-6man-5g-edge-compute-sticky-service, Linda Dunbar
Slides

Ron Bonica: The destination header is the right option for that. Routing header would only be right if you wanted to steer the packet.
Linda Dunbar: That is right. Thank you!
Erik Kline: Agree with Ron. If use DOH, it will be still delivered to the destination.
Linda Dunbar: Thank you. Moving on to next page (Achieve Sticky Service without dependence on UE behavior).
Bob Hinden: We are over time. Any comments?- No. Otherwise, we take it to the list.

SR Compression Design Team Status, Weiqiang Cheng

Slides

Bob Hinden: Clarification question, the last milestone is a year from now? (slide on Progress of Design Team)

Weiqiang Cheng: Should be 2020, my fault.
Bob Hinden: Let’s not repeat the discussions in SPRING WG.
Ron Bonica: Thank you for doing a lot of work. Document is incomplete. There are requirements still in open state. Don’t get nervous if things look incomplete.
Open call adoption for CRH back in May and is still waiting for the completion of the work in the DT.
Bob Hinden: No good answer to you now.

Erik Kline: Important to know that the DT is slower than expected. Maybe you just need a routing header?
Ron Bonica: Good place to start.start
Erik Kline: I will check with other ADs and ask for routing header. Personally is ok.
Ron Bonica: Sounds good.
Bob Hinden: Will also have a close look at the DT team progress.
Weiqiang Cheng: From the DT side, the scope is clear, output the requirement doc and do some analysis on the proposals which have been submitted. We should keep study on the different proposals. If CRH is adopted by 6man, I dont think there is a direct relationship. All the drafts output from the DT are individual not the WG draft. They should not be used as justification.

Darren Dukes: The design team is just focused on building requirements and analyzing solutions.

Cheng Li: The progress of the DT team is going well. Going to finish the dicussions as soon as possible. It is not right to adopt any solution for now.

Andrew Alston: Looking at CRH “thing”, we’re in situation where this has been around a while. Code is shipping today and there are people like me who need it. It’s critical for dealing with geopolitical issues. That’s what I’m using it for. All we’re doing is moving protocol development outside IETF. That is not in the inteerest of anyone. We have massive demand for this and need a working solution to deal with authoritarian states who want to mess with traffic. This has nothing to do with SRH. Let’s treat it as such and get it done.
Let’s stop delay. CRH is a building block.

Ole Trøan: Cannot hear Wim… (Wim Hendrickx was in the queue)

Zhenbin Li: Appreciate the DT’s work. The relationship between the aoption of the CRH and the requirements have been discussed already between the INT and RTG ADs. I think this needs to be coordinated with spring WG. The first adoption process of CRH – even without Design Team, there are issues. I want to know how the ID being identified, and how to support VPN with CRH. Also dataplane needs to be understood.

Bob Hinden: Interesting discussion. We will discuss with our ADs.

IPv6 Minimum Path MTU Hop-by-Hop Option

draft-ietf-6man-mtu-option, Ana Custura, Gorry Fairhurst
Slides

Bob Hinden: (on slide 7) I found from the probe at my house that the MTU is pretty limited.
Gorry Fairhurst: And also limited in other ways.
Bob Hinden: (at random point for count of how many have read the draft during the presentation).
Ole Trøan: Do you want to see implementations parallel to doc being advanced, while experiments are ongoing?
Gorry Fairhurst: If people want to implement it right now, I would love to talk to them. The more experience we get, the better it will be. Maybe then we could push from experimental track to PS.
Bob Hinden: I agree with that.
Ole Trøan: Make sense. Everybody want to discuss about the experiment, Gorry and Anna could be talked with. Also talk to them if you want to have a probe.
Bob Hinden: It woud be good to get probes into places with larger MTUs.
Andrew Alston: Virtual probe?
Gorry Fairhurst: Please email us. Better to talk with Anna about the details.
Bob Hinden: You can also sent that info to the list, unless there’s some reason not to.
Gorry Fairhurst: We would love to get more measurements.

IPv6 Application of the Alternate Marking Method

draft-ietf-6man-ipv6-alt-mark, Giuseppe Fioccola
Slides

Bob started the poll on how many have read the draft (when it is at slide 8)

Ole Trøan: Have you made requests to IANA?
Giuseppe Fioccola: Not yet
Bob Hinden: You should ask first.
Ole Trøan: send you the form: and you can fill out
Bob Hinden: this is WG draft. When do you think it will be ready to advance?
Giuseppe Fioccola: Content is quite stable.
Bob Hinden: Not quite ready but soon? It would be good to see this progress.
Poll shows
raise your hand
20
do not raise your hand
8
participants
74

Closing

Ole Trøan: We will virtually see you in Prague.
Gorry Fairhurrst: I wondered whether people were reading the draft but not able to use the tool?
Ole Trøan: We could have tried hand-waiving and been quiet while people respond.
Ole Trøan: We will now do poll on who has read Alternate Marking. (second poll)
Bob Hinden: we can try it as an experiment

SECOND TEST IF PEOPLE HAVE READ ALT MARKING DRAFT
raise your hand
21
do not raise your hand
16
participants
71

Bob Hinden: Now started Path MTU poll. We’re seeing much higher numbers.

Ole Trøan: You may want to post the contact details of Anna for the Probe volunteers.

Bob Hinden: It ssems that it is better to have the poll after the presentation.
Have you read the Path MTU HBH Option Draft?
raise your hand
13
do not raise your hand
15
participants
71

Meeting adjourned. Thank you all!