6MAN Working Group - Virtual 6MAN Meeting 15:00 - 16:59 PDT, 5 May 2020 / 22:00 - 23:59 UTC, 5 May 2020 Chairs: Bob Hinden, Ole Trøan Minute taker: Barbara Stark Jabber Scribe: None Jabber Room: 6man@jabber.ietf.org Notes: https://etherpad.ietf.org:9009/p/notes-ietf-interim-2020-6man-02 Webex: https://ietf.webex.com/ietf/j.php?MTID=mfb47282545035a32e6894000fc1fe9ae Meeting number (access code): 614 075 168 Meeting password: 7yTjrtbnT72 ================================================================================== Agenda - 15:00 - 17:00 PDT, 5 May 202 Introduction, Agenda Bashing, Chairs, 5 min. The IPv6 Compressed Routing Header (CRH), draft-bonica-6man-comp-rtg-hdr , Ron Bonica, 15 min. Generalized SRv6 Network Programming, draft-cl-spring-generalized-srv6-np , Weiqiang Cheng and Robin Li, 15 min. Generalized Segment Routing Header, draft-lc-6man-generalized-srh , Weiqiang Cheng and Robin Li, 15 min. Inserting, Processing And Deleting IPv6 Extension Headers, draft-bonica-6man-ext-hdr-update , Ron Bonica, 15 min. The IPv6 Tunnel Payload Forwarding (TPF) Option, draft-bonica-6man-vpn-dest-opt , Ron Bonica, 15 min. ==================================================================================== Introduction, Agenda Bashing, Chairs, 5 min. Chair slides from prior interim: https://datatracker.ietf.org/meeting/interim-2020-6man-01/materials/slides-interim-2020-6man-01-sessa-introduction-agenda-bashing-document-status Ole asked if there was any comments to the agenda. Question from Sander about whether there would be a call for adoption of Fernando's draft. Confirmed there would be. -------------------------- The IPv6 Compressed Routing Header (CRH), draft-bonica-6man-comp-rtg-hdr , Ron Bonica, 15 min. https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-the-ipv6-compressed-routing-header-crh Darren Dukes: You talk a lot about routing header type zero. Do you intend for this to be a replacement? Ron: Darren: These are kind of like an address translator to use as an opaque identifier to convert to IPv6 addresses. And these identifiers need to be configured and distributed around the network. Ron: Darren: It's going to need Ron: It will have information and that info will have an IPv6 address. Darren: So that will be someone else's IPv6 address? And the node will need that identifier. Ron: You can use a routing protocol, or PFCP. Darren: So distribution could be through a routing protocol like OSPF. Has anyone shown that to work. Ron: Darren: So could these be like IPv4 address identifiers? Ron: With 16 bits you could only go to 65k. But that's not what I had in mind. Darren: If 6man adopts, would you also expect 6man to adopt other work that goes with this? Ron: No Bob: 6man doesn't do that. Darren: Is this being used on the global Internet? Ron: You don't want this on the global Internet. Darren: Where is the domain for this defined? What are the constraints? Ron: Let's say some operator is operating this node. That operator would have the domain. Darren: Will there be documentation describing how the domains work? Z ?: It has been mentioned that there are differences between your solution and other architectures. I think there is a need for an architecture document explaining how everything is put together. There were also scale and complexity issues mentioned that you have not addressed. Ron: It is false that ? was required. Many customers are comfortable with proprietary MIBs. Customer doesn't really care about some of these things. Customers are asking for this. Z: Why not do MPLS? Ron: I have datacenter customers who don't want to use MPLS. Bob: We have a long queue and need to get to other questions. Eric Vyncke: On one slide you mentioned issue with OAM. Can you say what this is about? It isn't in the draft. Ron: I don't need a special OAM doc. OAM works exactly like it has in the past with PING and TRACEROUTE. Eric: Section on ICMPv6 isn't needed and suggestion to remove. It's also unclear whether ... Zhenbin (Robin) Li: I think this has a lot of relation to SR work. I think this is a new header. Second comment is there is relationship with LSR and routing protocols. I think more explanation is needed so we can understand why certain things are needed. Ron: Are you saying you think we need an architecture document? Zhenbin/Robin: I think just the parts that are 6man work need to be included. Cheng Li: Is there any other use case than compression? Ron: I have customer who cannot afford additional routing header. Cheng: We have multiple compression solutions here, and I think those should be worked before adoption. Jen Linkova: I read and liked the draft. ?: Andrew Alston: As operator actively looking at CRH, I don't want complexity of some of what's in SRV6 stuff and will never run it. I like the simplicity of this. Jim Guichard: Question on index mapping on the FIB. You said it mapped to IPv6 address. How do you deal with case where multiple routers use the same index on IPv6 address. Ron: There is a 52 on it. A different IPv6 address is used. Jim: How do I know which next hop to send to? If I have different routers assigning the same index, how do I do the lookup? Ron: 52 on that node will be unique. A FIB has no local treatment. Srihari Sangli: I think 6man is the right place for this work and I like it for its simplicity. Bob: Thank you Ron. I think it's too early for adoption call. Ron: What is needed to get to adoption call. Bob: I can't answer right now. Ron: Can I ask on list? Bob: OK. Ole: Related to what's going on in spring. ----------------------------------------------------------------------------------- Generalized SRv6 Network Programming, draft-cl-spring-generalized-srv6-np , Weiqiang Cheng and Robin Li, 15 min. https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-generalized-srv6 Eric Vyncke: How do we know if it's IPv6 address info or MPLS info? Robin: It's IPv6 information. Eric: It's my understanding you were packing a lot of info in 128 bits. How does a router know what is in those 128 bits. Robin: Please got to slide "G-SID : SRv6 SID ..." Here is what can be contained. This is a generalized SID. Eric: Please make it clear in the draft. Thank you for the explanation. Andrew Alston: I see a lot of complexity here. How do you know which SID is SID has complexity. There is so much info packed together that I wonder about complexity for operator to actually use this. Robin: From our point of view we recommend SRv6. But to support various requirements we need all of these options. I think the complexity is due to requirements and cannot be avoided. Gyan Mishra: This looks like a softwire framework? It seems like softwire techniques can accomplish the same goal with less complexity. Robin: Gyan: If you have SRv6 with MPLS then you can do that in a core, but this also gives you other options if you use a binding SID, etc. Bob: We're out of time and moving on to next. Sander? Sander Steffann: How do you handle the "segments left" value with compression ? Will you cover this in your next presentation? Robin: Yes, for the other cases please read the corresponding drafts Sander: Thx. ----------------------------------------------------------------------------------- Generalized Segment Routing Header, draft-lc-6man-generalized-srh , Weiqiang Cheng and Robin Li, 15 min. https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-generalized-srh Joel Halpern: Even with SRv6 you have to be careful. With this mod of SRH, if you make a mistake, the type won't help. They don't understand bits they are required to ignore if they don't understand. Robin: But I think you don't need that to understand this header. Gyan: With this feature... Could you use this in the core in places where SRv6 had issues? Like when you have a long chain with extended path? Robin: I think ... Gyan: But if in core instead of on edge, where you're tunneling over a core, is this an option instead of SRv6? Or not made for core? Robin: I think this is not for core. Andrew Alston: You've referred multiple times to this being a stepping stone to full SRv6. Do you see this as being something that will live a long time? Robin: I thing this will last a long time. ----------------------------------------------------------------------------------- The IPv6 Tunnel Payload Forwarding (TPF) Option, draft-bonica-6man-vpn-dest-opt , Ron Bonica, 15 min. https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-the-ipv6-tunnel-payload-forwarding-tpf-option Sander: I like the building blocks of this. Protocols using these building blocks will need architecture documents, but for 6man defining the building blocks is the scope. Darren Dukes: Can you explain where the domain lives on the Internet? Ron: Dan Voyer: On slide 6, what are these special procedures you're talking about? Ron: Those are TBD. The only 2 parties that need to know are tunnel ingress and egress. Between them, they could define up to 2 dozen behaviors. In the future. No need to be specified here. Z Zhang: I like generality of this approach. It's simple and generic. That's important. Zafar Ali: I agree with Sander that there is a need for an architecture. If you look at 6man charter, it's not chartered to do major changes to IPv6. You are referencing Sander disagreed on this quote in the chat, this reference to architecture is not what he said Ron: No, RFC 2473 is architecture. Zafar Ali: No, that's not true. Ron: There is an architecture and tis is independent of the CRH. Yes the other proposal uses both of these, but it is not the only thing that uses this. The 6man working group should not be prevented from defining another destination option or segment header without spring permission. Shuping Peng: Routing requirements should come from Routing area. Ron: I'll circulate this in Routing area. Ole: We haven't figured out how to ask for adoption on this platform (WebEx). We'll take that offline. ----------------------------------------------------------- Inserting, Processing And Deleting IPv6 Extension Headers, draft-bonica-6man-ext-hdr-update , Ron Bonica, 15 min. https://datatracker.ietf.org/meeting/interim-2020-6man-02/materials/slides-interim-2020-6man-02-sessa-inserting-processing-and-deleting-ipv6-extension-headers Ron: I'm good with starting discussion on the list. Bob: Go back to slide with original 8200 text. I think you're just trying to clarify what is meant by Destination Address? Ron: Yes. Bob: I think if WG wants to do this, simpler text could be used. Ron: Yes. Whatever works. Jen Linkova: I would be against explicitly blocking certain scenarios and would prefer to define how to do them safely. Ron: OK. Sander: On slide with 8200 text. I have always found parts of this confusing. I think along delivery packet header needs everything in the delivery path. I think if we just declare that any node in path includes all routing headers and then do what Jen said, that would be good. I think we need to confirm what this says about the delivery path. Ron: I do think this is ambiguous and it's understandable why spring WG interpreted that way. Ole: I do think it's important to clarify. Darren: I don't read it that way. ippm WG is doing something similar in a domain in one of their drafts. I think we need to explain how to do it safely. Ron: We did mention to them there was a security consideration. But I think this is different. Inside your domain you can do whatever you want. Darren: No we don't just do whatever we want. We need to explain risks of doing things certain way. Ron: I don't think that's a good idea. Eric Vyncke: We do like innovation. You raise concerns, but I suggest not making doc about forbidding things forever, you write what needs to happen in certain cases in order not to break network. Ron: I'm sure you're aware there are things that can be changed along path. There is room there for intermediate node to do things. Eric: I'm more thinking about form of doc. Don't try to prevent forever. Note the things that must be kept working and avoid to break things. Dan Voyer: Can you be specific about what you see from spring and elsewhere that violates this? Ron: I can see a hop-by-hop option. You can design a routing header with immutable fields in it. Zafar: I agree with Jen and Eric. There should be room for innovation. Suresh Krishnan: If you look at header format, it doesn't have to be Destination Address. I would do like Jen suggests. See what breaks. That's what we need to guard against. Look at proposals on their own merits. Fernando Gont: I think it's clear based on comments that intent should be clarified. I think it should be possible with erratum. But just clarify. In response to Darren, I don't think there is "IPv6 for data centers". Just IPv6. And I don't think this will prevent innovation. Write draft and change current behavior. Andrew Alston: I want to understand what Darren said that it's up to drafts to explain why they need this. But I don't think it's ok for someone in other WGs to write whatever they want. 6man can't abdicate it's responsibilities. I agree with Jen that we need to explain what rules are to prevent certain things from happening. But until there is consensus to change, status quo remains. We cannot leave this as free-for-all -- that would be abdication. We must clarify it. Bob: This topic will go on, on the list. Thank you everyone for attending. Especially those in time zones where it's past midnight. We may schedule other interim meeting. ======================================================================== Meeting Adjourned ========================================================================