6MAN Working Group - Singapore IETF Meeting -------------------------------------------- 13:30 - 15:30, 21 November 2019, Thursday Afternoon Session I, Sophia 17:40 - 18:40, 21 November 2019, Thursday Afternoon Session III, Sophia Chairs: Bob Hinden, Ole Trøan Minute taker: Barbara Stark Jabber Scribe: Peng Shuping Jabber Room: 6man@jabber.ietf.org Meetecho: https://www.meetecho.com/ietf106/6man Agenda - 13:30 - 15:30, 21 November 2019, Thursday Afternoon Session I, Sophia ------------------------------------------------------------------------------ Introduction, Agenda Bashing, Document Status, Chairs, 10 min. Working Group Drafts Next Steps in RFC8200 Fragmentation Errata, RFC8200 Errata , Bob Hinden / Ole Trøan, 15 min. Path MTU Hop-by-Hop Option Update, draft-ietf-6man-mtu-option , Gorry Fairhurst / Bob Hinden, 15 min. Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6), draft-ietf-6man-spring-srv6-oam, Zafar Ali, 15 min. Active Individual Drafts Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers, draft-linkova-6man-grand , Jen Linkova, 15 min. IPv6 Extension Header for the Alternate Marking Method, draft-fz-6man-ipv6-alt-mark , Giuseppe Fioccala, 15 min. IPv6 Formal Anycast Addresses and Functional Anycast Addresses, draft-smith-6man-form-func-anycast-addresses , Mark Smith, 20 min. New Individual Drafts (as time allows) Asymmetric IPv6 for IoT Networks, draft-jiang-asymmetric-ipv6 , Guangpeng Li, 10 min. Support Postcard-Based Telemetry for SRv6 OAM draft-song-6man-srv6-pbt , Haoyu Song, 10 min. Agenda - 17:40 - 18:40, 21 November 2019, Thursday Afternoon Session III, Sophia -------------------------------------------------------------------------------- Introduction, Agenda Bashing, Chairs, 5 min. Working Group Drafts None. Active Individual Drafts In-Flight IPv6 Extension Header Insertion Considered Harmful, draft-smith-6man-in-flight-eh-insertion-harmful , Mark Smith, 20 min. SRH insertion within an SR Domain, draft-voyer-6man-extension-header-insertion , Darren Dukes, 20 min. Working Group Discussion on Header Insertion, , Chairs, Mark Smith, Darren Dukes, 15 minutes. New Individual Drafts (as time allows) None. Agenda Requests Received, Not Scheduled Problem Statement and Use Cases of Application-aware IPv6 Networking, draft-li-apn6-problem-statement-usecases , Shuping Peng. Unified Identifier usecase in IPv6 Segment Routing Networks, draft-wmsaxw-6man-usid-id-use , Weiqiang Cheng. SRm6, (various drafts), Ron Bonica. SRv6 OAM, draft-ali-spring-ioam-srv6 , Zafar Ali. ==================== Session 1 ==================== Introduction, Agenda Bashing, Document Status Chairs presented chair slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-introduction-agenda-bashing-document-status -------------------------------------------------------------------------------- Chairs reviewed status of 6MAN working group documents. Next Steps in RFC8200 Fragmentation Errata Bob Hinden presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-next-steps-in-rfc8200-fragmentation-errata -------------------------------------------------------------------------------- Ole Trøan: I'd like people to review and see if this is right. Éric Vyncke: On one of the slides you showed the reassembled packet [slide 17]. Is this really the right way? Bob: We considered various ways. Figures are helpful, but it's important to read the text. This is also consistent with the style in RFC2460. Suresh Krishnan: Should we put a timer on it and verify by end of year? Bob: OK. When should I file the new errata? Suresh: Let's do it by end of year. Ole: Thank you. No objections to proceeding with the plan in the room. ACTION: Chairs will do a last call on the list and then proceed with the plan shown in the presentation. IPv6 Minimum Path MTU Hop-by-Hop Option Update Bob Hinden and Gorry Fairhurst presented slides in tandem: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-operations-administration-and-maintenance-oam-in-segment-routing-networks-with-ipv6-data-plane-srv6 --------------------------------------------------------------------- Erik Kline: Do you have collaborators for running different sorts of tests. Gorry: Our measurements were set up to measure from different vantage points. We'd love to work with you. Cheng Li: is it a mechanism to be used for OAM packets or data packets? Bob: Not intended to be maximum packet. Please read the draft, it specified in the draft. Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6) Zafar Ali presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-operations-administration-and-maintenance-oam-in-segment-routing-networks-with-ipv6-data-plane-srv6 --------------------------------------------------------------------------- Ole: I found that unless you are quite versed in SR and SPRING you might find this hard to read. How many have read? Quite a few. We need to consider overlap with other WGs and get review from them. Suresh: I think SPRING is important, but others can be handled after WGLC. Ole: This document has to do with network programming? Zafar: No, I think these are independent. Suresh: You understand that there are problems with unpublished normative references. Zafar: Yes. My understanding is the reference is going through WGLC. Pablo: Suresh: They're going to go with early allocation. ACTION: Chairs will start a w.g. last call for this draft on the list. ------------------- Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers Jen Linkova presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-gratuitous-neighbor-discovery-creating-neighbor-cache-entries-on-first-hop-routers Erik Kline: Jen: If ... we don't update the cache Erik Nordmark: This doesn't specify whether you have overrides. Oh wait, it's in the draft. We need to read the draft. Dave Thaler: For router behavior, I think any router that does this is ok. [slide on Proposed Changes] Bottom have I can't comment on. Top half is ok. Jen: There was a suggestion made on the list that this was a protocol change. Dave: I looked carefully at RFCs and think this is ok. You're adding a 2nd condition which the RFC doesn't address. Erik Nordmark: Ole: NA will be sent to all hosts? Jen: It needs to be sent to all routers, but ok to send to all hosts. Don't want to add to noise. Dave: For the part you show in proposal it makes sense. But for other? Do we want all these documented? Might it encourage people to pursue these? Jen: It shows history. Bob: Recommendation is to remove non-pursued options from draft. Suresh: It's not clear in draft about whether... Ole: We want to get consensus of the WG. Hum *against* objection. Does anyone think this is a bad idea? Éric V: I like this. I'm not against it. But it needs a precise solution. Jen: Some will not be done. I can put in text they were considered and discarded. Ole: We'll pick one solution. Fred Baker: Are you saying Jen should let draft in v6ops expire? Bob: It will go away, and there will be replacement draft with one solution. Dave: So -00 version will always be available with older stuff but -01 and beyond will only have one option. Ole: I don't think we need hum to confirm adoption? But will confirm all this on the list. Chairs did Hum for non-adoption. No objections ACTION: Chairs will confirm adoption of this draft on the mailing list. IPv6 Application of the Alternate Marking Method (draft-fz-6man-ipv6-alt-mark-01) Giuseppe Fioccala presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-ipv6-application-of-the-alternate-marking-method-draft-fz-6man-ipv6-alt-mark-01 ------------------------------ Ole: What is relationship between work in IPPM and this? Giuseppe: In IPPM the drafts are only for measurement. They can't make the protocol change. Ole: So 6man defines TLV format and IPPM does what? Giuseppe: The protocol-specific applications are made in 6man but methodology in IPPM. Ole: How many people have read? We'll figure this out on the mailing list. IPv6 Formal Anycast Addresses and Functional Anycast Addresses Mark Smith presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-ipv6-formal-anycast-addresses-and-functional-anycast-addresses ------------------------------------ Bob: We'd like comments. Rajiv Asati: We could keep boundaries with way existing allocations are done. I'm not sure about this. Erik Kline: Operationally, what's the difference in using one of these and using a regular GUA. Mark: I think it would be useful to me to know its an anycast address. Not having it be globally reachable would also be an advantage. Erik Kline: Michael Richardson: I like it. One of your use cases doesn't work if the address isn't announce-able to the rest of the world. So maybe there are 2 allocated spaces. We have a need for anycast address in homenet space, too. We want a special magic address that you don't have to hardcode. Mark: I'm working on including more use cases in the draft. Jen: The biggest problem with anycast is load balancing. Mark: I think idea of using multicast protocols is interesting. Jen: Jordi Palet: One of the advantages I see with current anycast is that it isn't differentiated. Mark: Right, so you don't have to do anything to implement. Just treat like unicast. Jordi: But I think that's a real advantage of current unicast anycast. Ole: Continue discussion on the mailing list. Asymmetric IPv6 for IoT Networks Guangpeng Li presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-asymmetric-ipv6-for-iot-networks ----------------------------------- Ole: Whatdoes the packet look like for the application? Is it compressed on the IoT side, or a regular IPv6 packet? Brian Carpenter: You mean below or above the API? Ole: Brian: That's a good question. My preference would be to use a standard packet header. Ole: It has info that you can actually compress the header. Fred Baker: This takes us back to a discussion from before IPv6 was standardized. My first question is how the host knows where the edge of the network is. I'm not sure a host has that visibility. Brian: It knows the address is in the domain. Which is which is signaled in the packet. Fred: How does a host know what to send. Brian: It doesn't need to. It can use short addresses over long addresses. Bob: I looked at the draft and in the beginning it referenced "User Plane Protocol and Architectural Analysis on 3GPP 5G System" to jusify the approach taken in the draft. However, this document didn't describe problems the problems this draft is addressing. So I don't know what use case is. Is this a problem that needs to be solved? Brian: That's why we took this to 6lo, too. The draft needs more context. People who aren't in the 6lo world don't understand. Suresh: I think the draft isn't clear, and it's not just not understanding 6lo. I think this needs to happen somewhere else and not 6man. But I don't know if there's room for yet another format. It's not clear the overhead is that big. Guangpeng: Maybe because we're used to the RA and ... Suresh: Use case isn't clear. Eric V: May we assume the node needs a short address? Brian: Good question. Need to make sure ... Rajiv: If we could verify how low MTU needs to be and resources required that would help. Also how high does n go? Could it be as low as 2 bytes or as high as 128? Guangpeng: We'll introduce local names into it for 2nd one. And to network it will still be small. Bob: Please continue on mailing list. Support Postcard-Based Telemetry for SRv6 OAM Haoyu Song presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-support-postcard-based-telemetry-for-srv6-oam ------------------------------------------------------------------------ Suresh: Not as AD. I think the idea of having a marking in the protocol isn't going to work. It needs to be outside the payload. Doesn't work. Haoyu: Why? Suresh: Let's say you have packet flowing into system and you want to collect telemetry. Where is the signal? Haoyu: This is a general method that can be applied to any protocol. This is a proposal for how to apply to SRH. Suresh: If you don't have SRH how do you do this? Haoyu: If you don't have SRH you just... Darren: I don't know about IPPM part but I don't know or understand what the special something is that needs to happen. Zhenbin Li: I think this is useful in many ways. I think it can also be used with IPCP. Haoyu: I agree with the use case. I think it's the same requirement from the data center and a common solution can be found. : Is this related to the data center server? We need to figure out whether ?? as a use case is something we want to solve. You need to describe use cases. Suresh: I understand why you want to do this for forced telemetry but not for other protocols. I don't think this is a scalable approach. Haoyu: Not saying it applies to every protocol. : This is very specific. Why restrict to this specific use case? Why not do this in the IPv6 main header? Haoyu: If you look at draft, it describes how it can be applied to other protocols. In here, we want to describe how to apply to OAM in SRv6. If you want to apply to other networks you do need to find place for mark. : But why not in IPv6 header? Haoyu: Don't have good idea of how to do that -- where to put the mark. Brian: Not sure ... Haoyu: Overhead issue if we introduce new header. Brian: Your solution is overly general in space where everything is encapsulated. Ole: Discuss more in the list. We have one more session. ==================== Session 2 ========================== Chairs requested that except for clarifying question, all all other questions and comments to be asked after the two presentations. In-Flight IPv6 Extension Header Insertion Considered Harmful Mark Smith presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessb-in-flight-ipv6-extension-header-insertion-considered-harmful --------------------------------------------------------------------------- Clarifying questions allowed. Darren: Did you read draft-? Mark: Yes. Darren: How is this solution related to that draft? Darren: So what you were talking about with inserted headers sent across the Internet aren't really relevant? Darren: what part of the presentation was related to the insertion versus having EH on the path? Chairs: Darren, please present your presentation. Deployments With Insertion of IPv6 Segment Routing Headers Darren Dukes presented slides: https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessb-deployments-with-insertion-of-ipv6-segment-routing-headers --------------------------------------------------------------------------- Bob: Can you please explain what the dots and such mean in your diagrams (on IP header of traffic traversing the SR domain)? The two presentations are using different ways of representing traversal of packets. Darren: '*' are for delimiting the domain, the [] delimit a router with the router ID inside. Andrew Alston: you refer often to SR domain. Can you specify what is a SR-domain? Darren: Please read the drafts. Greg Mirksy: [about TILFA] is it switchover for one tunnel or for multiple tunnels ? Darren: That's more of a feature thing. In the products I'm aware of, any traffic in a node that fails, the path is recomputed at the point of failure. Greg: But your next segment can be several nodes away, so how do you know it has failed? Darren: I don't care. It's tunneled, so that will get me around any link failures.For purpose of this presentation we need to take it as fact. Greg: No. I don't know where your numbers come from. Darren: Is your problem with how SRH is inserted? It's feature specific thing -- how the numbers are created. Ole Troan: are you stating that node 3 will not insert SRH? Darren: In the L3 DPM example there is no need for SRH header. If there were traffic engineering also applied you would need SR header. Darren: Bernie Volz: are there other EH removed ? Darren: it is up to the inserting node to specify the SID identifying which router will remove the header. Shuping (channeling jabber - Srihari Ramachandra): When SRH is inserted at PLR will the SA be changed to PLR node ?if its not changed and if there is a problem along the backup path that requires ICMPv6 packet generation, where this ICMPv6 packet reach. Since SA is not changed, will it reach the PLR or original Source node ? Darren: No. Andrew Sullivan: in large SRH domain with 1000's of links, what happens if there are multiple failure, then how many SRH will be stacked up ? Which will be the final MTU ? Darren: Read the draft and see how the path is computed. I can send you link to the draft. Mark Smith: in the VPN service slide, I will make node 3 and 4 the tunnel endpoints. Darren: Yeah, let's hold onto that and not forget you suggested that. Cheng Li: is the SRH inserted and removed with the SR domain. I think this is a good idea. Joel Halpern: it is not because you are violating a RFC is not a good reason to ask 6MAN to change a RFC. Darren: You have options to do encapsulation. You can make sure extension doesn't escape the domain. Ole: we move away from clarification to a debate Suresh as AD: to respond to Joel, it is now informational, then it is no more changing a RFC. And this change from PS to informal, changed my mind. Darren: Since we're in the debate portion of the event... Shuping (channeling jabber - Srihari Ramachandra): followup question to SA is not updated at PLR, if there is an issue with MTU, what is expected by the node 3 when it tries to send the packet again ? Darren: version 8 fixes this Shuping (channeling jabber - Zhenqiang Li ): Clarification question: I just want to make sure that the operaters you mentioned deployed SRH insertion not purely SRH? if so, could you please add the SRH insertion scenarios in the deployment draft. Erik Kline: ask a question about performance about encaps vs EH insert Darren: The TLVs can be changeable in the header. We didn't go that way but I understand your point. Erik Nordmark: in term protection, you talk about inject prefix, did you also protect from packet leaving the packet with a specific DA ? Darren: Brian had a similar comment. How do you make sure at the egress edge how I make sure I'm not sending a packet that doesn't belong there. Robin (Zhenbin) Li: SR domain and Internet are different and have different requirements. Mark: Some of this comes from claiming to follow RFC8200 but then not following it. This isn't really IPv6. Darren: RFCs are often open to be amended. And there may be exception within one domain. Mark: I'm not surprised you put MPLS up there. In MPLS, imagine 2 LSRs with Ethernet between them ... that's sort of like having IPv6 routers between the IPv6 hosts. Darren: So you're saying build tunnels between every node. Mark: Yes. Darren: I don't like that. Jen Linkova: I remember having the same discussion when preparing RFC 8200. Mark's I-D says "SRH insertion is harmful" while the slides are about "SRH removal". And they also applies if the SRH was inserted by the SOURCE of the packet (so not insertion). Mark: Bumping the spec, I wouldn't consider to be SRH insertion. Jen: But all the problems caused are the same for both of you. The problem is about not removing. Darren: Jen is right. Mark: Sure. Jen: I think your (Mark) document is confusing. Mark: it is all about finding the consequences of it. Robin Li: follow RFC is nice but we should listen to the requirements. Darren: This is within an SR domain. Robin: we have running code with operators deploying. Mark: The thing to keep in mind is this is a broader 6man issue. Darren: your slides do not consider SRH inserted in a SR-domain and what you describe is SRH over the Internet. There is little relevance to the sRH insert draft. Mark: In your SR domain are you talking about ... Bob: I have conclusions. Thank you. This was, quite good. Bob: As someone said earlier, this is the default case and you're not allowed to do insertion. But if someone writes a draft saying how to do it, we could consider it. Thank you Mark for creating a draft that starts writing down the issues. Now we can consider rationally. But we're not done yet. I think both of these things can exist at the same time. There is room for both to be considered. Suresh: Bob, you called what I wanted to say. Problems in the Internet (dixit Mark) are relevant for the Internet. The ask is not to change RFC 8200 with version -08. Changing RFC 8200 is probably more difficult as it must work on the Internet. Bob: And the -08 came out recently and I haven't had a chance to read it. Suresh: I'm kind of ok with the direction that Darren's draft is now taking. Erik Nordmark: did not realize that de-encapsulation will occur whether it is due to insertion. Suresh: That was one of the things that was removed from the SRH draft. Erik Kline: Q for Suresh: is it possible to publish both documents ? Bob: That was the point I was making. We can take on and publish both documents. Suresh: yes as there is no real disagreement between the two. The 2 documents can be published along each other. Erik: I don't disagree. Bob: This was a constructive session. We're not done with this topic. Both documents can progress, both need more work. ------------------------------------------------------------------------ Meeting Adjourned ------------------------------------------------------------------------