Tuesday, March 9, 2021 12:00-14:00 (UTC)
Thursday, March 11, 2021 16:00-18: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, https://meetings.conf.meetecho.com/ietf110/?group=6man&short=&item=1
Thursday Session, https://meetings.conf.meetecho.com/ietf110/?group=6man&short=&item=2
==================================================================
draft-dunbar-6man-5g-edge-compute-sticky-service , Linda Dunbar, 15 min.
Slides: IPv6 Solution for 5G Edge Computing Sticky Service
Ole Trøan: Where do you see this work will be better to go? 6man or other WGs?
Linda Dunbar: We have proposed different aspects in different WGs. For 6man we only want to propose next hop destination header. Egress router for ANYCAST can also be carried as well as preference. All these info needs to be propagated to the ingress router. Then ingress router can have enough info to choose optimal path. There are also OSPF extensions.
Fred Baker: They have a draft in v6ops too. And will be asking for WG adoption. But WG will not adopt unless it conforms to v6ops charter.
Ole Trøan: Haven’t seen so far enough discussions. We could use show hand tool.
Bob Hinden: The work that this is related to APN, has that been adopted in another WG?
Linda Dunbar: No.
Bob Hinden: My thinking is that it would be more appropriate to ask 6man to adopt once APN has been adopted in another working group.
Linda Dunbar: That makes sense.
draft-mishra-6man-variable-slaac, Alexandre Petrescu, 15 min.
Slides: SLAAC with prefixes of arbitrary length in PIO (Variable SLAAC)
Jen Linkova: Two questions. Should we go home because devices will do whatever they want so there’s no sense in writing standards. Confused with the draft – longer prefix, but could not find the shorter one. I am still not convinced that this will not open the door. to race to the bottom
Alexandre Petrescu: Maybe “Bug report” should not be used. Agree that if longer prefix is allowed that could cause some problems. There should be some tools to stop . For shorter prefixes, that would be a good idea. If operator provides shorter prefix then user needs method to form their own prefixes. If this is completely stopped and this WG has no desire to even work on this as experimental, then I will be tempted to continue to use /66 in a network.
Ole Trøan: Any more comments? Last slide?
Alexandre continued with the last slide…
Ole Trøan: In homenet it was also discussed to just use DHCP which supports other prefixes just fine.
Alexandre: Yes, there is homenet.
Ole Trøan: Did not suggest homenet. They looked at the same problem. The solution they identified was DHCPv6, which has been there for many years.
Alexandre Petrescu: Maybe homenet protocols standardize use of DHCP.
Ole Trøan: You dont need to across the 3GPP network. If you just use DHCP inside of the network it will not require any changes.
Lorenzo Colitti: Why they do this? Not sure there is any problem to solve. DHCPv6 is already in the 3GPP standards. The fact it isn’t deployed is a deployment problem.
Alexandre Petrescu: WRT why some or most block DHCPv6, means blocking multicast and ports of DHCPv6. We don’t know why they do this. A list of reason why they do. Just to suspect why. DHCP vs. SLAAC. New research may change things, but probably a few years.
Lorenzo Colitti: DHCPv6 is there for operators to use already. Writing another draft won’t change that. They are for operators to use already.
Alexandre Petrescu: Yeah, it is true. More a requirement to 3GPP. Sometimes 3GPP does refer to IETF draft when they write their own.
Bob Hinden: Thank you!
draft-yang-rtgwg-ipv6-associated-channel, Fan Yang, 15 min.
Slides: Associated Channel over IPv6
Bob Hinden: Not see too many questions/discussions.
Fan Yang: I have discussed this in other WG.
Bob Hinden: Any questions?
Erik Kline: Relationship with other iOAM work?
Fan Yang: iOAM is one case that can make use of / be a type of ACH. If you look at encapsulation – they are similar. The design behind these two technologies area different. There are requirements to carry this on the IP layer. ACH is open to any applications. It should be used in the IP layer.
Bob Hinden: How does this relate to other things like APM?
Fan Yang: Don’t have it in my mind. Not related with APN.
Bob Hinden: Just traffic between routers?
Fan Yang: Yes, limited to the network nodes. Don’t want to have it between the hosts.
Bob Hinden: OK. Thank you. Out of time.
draft-geng-6man-redundancy-protection-srh, Fan Yang, 15 min.
Slides: SRH Extension for Redundancy Protection
Bob Hinden: Is that the same flow label as in IPv6 header?
Fan Yang: Yeah, Ipv6 header flow label could be used.
Bob Hinden: Yes or no answer?
Fan Yang: Prefer it here in the SRH optional TLV. Otherwise IPv6 flow label can only be used for this but not ECMP.
Erik Kline: My scan of the document is you want to allocate new TLVs from SRH header? That’s expert review and doesn’t have to be done in 6man. Could be done in Spring or elsewhere. Unless you want to do the IANA allocation.
Fan Yang: If not we could also move it to SPRING. I will leave this to the WG Chairs.
Darren Dukes: Same question as Erik about location of work. But also it will impact the usage of the ECMP.
Fan Yang: Yeah, I agree with you. ECMP should be protected.
Bob Hinden: I would add that if this is just wanting to define TLV for SRH then having that work in Spring would be fine with me. 6man could follow but this is more relevant to work in Spring.
Stewart Bryant: Fit more in Detnet? Reliable streams…
Fan Yang: Yeah, it includes the segment and policy definition. The draft is shifted from Detnet. We can focus on it in the SPRING. This work was proposed two years ago in Detnet.
Stewart Bryant: This is a function that Detnet needs.
Fan Yang: Yes, Detnet needs it, but they also need the extensions in SPRING.
Bob Hinden: 6man is not the best place for this draft.
Ole Troan: We can take further discussion offline as to where to do work.
draft-templin-6man-omni-interface, Fred Templin, 15 min.
Slides: OMNI Adaptation Layer (OAL)
Bob Hinden: Any comments?
// There were no comments.
draft-templin-6man-omni-option, Fred Templin, 15 min.
Slides: OMNI IPv6 ND Message Sizing
Ole Troan: Any comments?
Fred Templin: I made bold claims in first draft, like that IPv4 to IPv6 transition would be easy if everybody adopted OMNI. I’d like discussion of those.
Bob Hinden: Any comments from the WG? Not seeing any significant interest in the WG. Sorry.
Ole: No more people in queue. We’ll see each other again on Thursday. Follow up on mailing list in the meantime.
Alexandre: I see 2 polls in Meetecho but don’t know what the poll questions were.
Ole: forgot to run the poll. Would take it to the mailing list.
Bob: We are done today. See you at the next session.
====================================================================
Ole and Bob briefly walked through chair slides.
Slides: Introduction, Document Status
draft-srcompdt-spring-compression-requirement, Weiqiang Cheng, 15 min.
Slides: SPRINGSR Compression Design Team Report
Andrew Alston: Repeating what I said in spring… What are next steps for CRH? You have vendors actively shipping code in production releases. We’re entering phase where this has been going on for so long that the WG is getting no say in something that is being developed. These delays are leading to IETF contributing to a lack of standardization. This is not good for industry or operators. This has been dragging on for longer than a year and I’m getting frustrated. When will things proceed?
Weiqiang: Why are we coming to IETF? Because we want to standardize the proper solution for operators and vendors. I think the analysis draft lists 4 different solutions. From my point of view, I don’t know. We don’t have the result of which is the proper solution. We don’t want to split the industry.
Ron Bonica: I’d like to support what Weiqiang said – to take our time to get it right is important. But I also support what Andrew said. Squatting on code points is not desirable. I believe early allocation is up to the ADs?
Ole: Yes. Does AD want to give update on that?
Erik Kline: Can anyone speak to deployments that need to interoperate within a single administrative domain?
Andrew: At the moment there is the Juniper implementation. There are 6 things we’re working on that are Linux based. Other things that use other bases. There is much that we’re working on that are being held back. This is especially impacting African continent.
Erik: Not experimental?
Andrew: Not experimental. There are several things I’m intending to take live in the next few weeks.
Erik: Good to know.
Darren Dukes: On Feb 11 I read proposals and came up with analysis. At that time, design team decided it could not meet February date for review. But I think April date is feasible. I’d like to know if CRH draft is stable enough to justify code point allocation?
Erik: Author committed that format was stable and would require no changes going forward.
Cheng Li: I saw there were a lot of modifications in CRH draft. So I’m not sure it’s really stable or mature?
Zhibo Hu: We need more time to review. There have been many changes.
Andrew: I’ve said my piece. We have many requirements. I don’t want to be forced to go outside standards because of so many delays. This has been way too long and it’s really hurting.
Ron: Changes have been due to extensions and don’t impact interoperability. Early allocation will not impact risk. Risk is minimal and it’s unclear why opposition is so strong.
Erik: The reason Spring design team was created was to allow them to do their review. As long as early allocation would not interfere with spring design team work – that would be a consideration.
Weiqiang: We will provide analysis to both WGs soon.
draft-ietf-6man-ipv6-alt-mark, Giuseppe Fioccola, 15 min.
Slides: IPv6 Application of the Alternate Marking Method
Ole: As I mentioned during document status, our plan for next step is to advance to IESG. Comments? If not, we will proceed on that plan.
// There were no comments. Chairs plan to advance after the IETF meeting.
draft-ietf-6man-slaac-renum, Fernando Gont, 20 min.
Slides: Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events
Bob: Comments?
// There were no comments.
Bob: We would like to see more review of this. If you could review, please contact the chairs. There do seem to be some changes proposed to items that are basic to IPv6.
draft-hinden-6man-hbh-processing, Bob Hinden, 20 min.
Slides: IPv6 Hop-by-Hop Options Processing Procedures
Ron Bonica: There are many drafts today that try to repurpose bits in the IPv6 header. Because of this I think this is most important draft in 6man and should go to top of our priority list. 2nd comment is that real HBH routing can’t be implemented really (the HBH header can’t be implemented, basically it is too many options, unlimited, within). So we need to scale it back. We don’t know what the right number of forwarding engines are – that are needed to process. Anyway, we need to get going on this.
Fernando Gont: As much as I would like to see the sitation with extension headers improved, I don’t think that option of limiting number of extension headers or options in a header in this draft will cause much improvement. The length of this extension header is basically unlimited. So what we need is a method to limit the length of the extension header chain length, rather than the number of options in the extensions header itself.
Cheng Li: I think the solution to HBH issue is important. But it seems like solution that has router dropping options would work too. We don’t know what right length is now. But perhaps if operators would deploy new equipment (make requirement that) that supports HBH, that would solve the problem.
Eric Vyncke (without any hat): HBH over the Internet, over multi-domain system won’t work. We know this. So the limitation of a single option in HBH header over the Internet won’t change. But this would limit inovation within a single domain. So I do not support this.
Bob: Shouldn’t routers look at options in HBH? Definitely, Bob said, they should.
Eric: Indeed.
Jie Dong: I agree this is important work. HbH is designed for forwarding routing. Many features require HBH functionality. But I think limiting to one option might limit deployment. Could we allow a few more options but in a limited domain to encourage extensibility and innovation?
Suresh Khrishnan: I think this is something I’ve been wanting to solve for a long time (20 years now). But I think we do need to limit time router spends on processing a packet.
Gyan Mishra: This is an important subject. Many applications want to take advantage of HBH and right now it’s not a viable option. Christmas tree extension headers. Chip manufacturers. Fear of impact of mgmt plane. Difficult operational caveat to make HbH viable. Closed domain, just within your op network, overlay underlay network, the service provider carry core. Internet traffic carried in VPN, not impacted by HbH (MPLS, overlay); but global table different. Reducing the number of? Not punting anything to control plane, that fine tuning, stop cycle of dropping all HbH, it is complex. Need to continue figure out solution for.
Cheng Li: I think this issue is important. We have a lot of innovation based on HbH extension headers. So we do need to discuss. We can work together to figure out how to address this issue.
Igor Gashinsky (with Verizon Media): One of biggest problems with HbH and extension headers is there are data centers that limit to 120 Bytes +. So size of option is bigger issue than number of options.
Bob: But that is a number that will change over time?
Igor: Yes but that number has been around for several years.
Bob: IT would be good to hear from people who deal with this.
Michael Ackermann: Many enterprises aren’t deploying IPv6 because of management issues. I think working out HbH is important.
Ole: Lots of comments. Perhaps not ready for an adoption call.
Gorry Fairhurst: Thanks to Bob for presenting. We want this to work. Please adopt this next time around.
draft-gont-6man-ipv6-ula-scope, Fernando Gont, 15 min.
Slides: Scope of Unique Local IPv6 Unicast Addresses
Tim Chown (on slide 3): What are the conflicts. You say there are 3 in RFCs, but I don’t immediately see what they are.
Fernando: In the next 3 slides.
after presentation…
Jen Linkova: I have a few comments. I think what you’re talking about is the way addresses are used.
I dont think its a real problem. There are not ten thousands networks of ULAs together. No reason to make such a drastic change. But if you change the scope then a problem to the scope address architecture. Router would not forward, scope of the source address; people might use ULA to reach global scope might become possibile so its dangerous.
Fernando: 2 comments. I agree you wouldn’t end up connecting more than 10 ULA networks. What I’m saying is that what the definition says is that if they are global scope (and they are thus globally unique) – global implies the whole Internet. Whether you interconnect or not is different. But it says unique in Internet is global scope. So definition doesn’t synch with what you say – it’s not about just being unique in where you choose to use it.
Fred Templin: point that in addition to LLA, ULA, GUA, also host identity tags HITs; less profitable than GUA. Can we put that in the hierarchy.
Fernando: David Farmer also has suggested other cases. I agree with you that there are other cases that almost certainly follow the same principle.
Bob Hinden: I’m an author of the ULA spec. I don’t agree with Fernando’s proposal. The spec is clear about level of uniqueness and how ULAs are to be used. I dont hear any form of operational issue. It might be what could be called an ‘academic’ problem. The paradox problem? (discarded because of something). I don’t think there is benefit to change anything because it’s not shown what actal problem is being caused. To use among multiple enterprises – there was never an intention that you would route over the Internet, so the chance of collision is practically zero so I don’t know what problem you are trying to solve.
Fernando: in this slide number 3; I agree in this area, if you say in this area? then agreed. But 4007 defines this is the whole Internet. If you say academic? Then yes, but architecture is academic. There are apps: the python lib is not academic.
Michael Ackermann: From enterprise perspective, we’re struggling with deploying IPv6. One of the parts we’re struggling with is replacement for RFC1918 private addresses and we think ULAs might be the solution, or the LL is the solution, not sure. But it’s confusing. If this draft could improve the clarity to that it would be helpful.
Erik: Python library is old. Brian Carpenter’s draft talks about some of this. The IP address library did not take into consideration some issues. The difference between global addresses and global routing is a key issue. The temptation to map ULAs onto RFC1918 addresses is imprecise.
Fernando: Based on slides here and this definition it can’t be claimed that ULAs are global.
Erik: That was the most proximal understanding at the time.
Ole: Thank you. Who knows if we will meet in the summer. We will see you on the mailing list.