IDR meeting at IETF 100 (version 1) 13:30-15:30 pm, 11/13/2017 Room: Canning Sue Hares: Starting in 2 minutes. Looking for note takers. Chair's administrivia [13:30-13:45] 0) Agenda bashing and Chair's slides (5) Sue: Starting the IDR meeting. We are meeting once this time. We do not have a really packed agenda this time. There is a Note Well. You may have read this before, please read it again. Note Well applies to anything that is said at the mike is covered by it. RFC 5378 and RFC8179 has the details of what is covered and how. We had a hiccup in our WG process a while ago - it was a late IPR disclosure. Sue: Agenda bashing. John is not here this week. Jie Dong is IDR secretary helping me to run the meeting. Ignas is kindly providing scribing. First part of chair¡¯s slides: get all the drafts that were asked for be sent forward, please check if we missed anything. Then we will go through the IPR because we had a late disclosure. Then we will go through the existing drafts and the new works. Sue: Comments on the agenda? 1) Chair¡¯s comments on IPR (10) Sue: Going through the basic IPR rules and problem case. WG chairs tend to trust the WG participants, and we would like to continue to trust. RFC8179 describes IPR disclosure rules. There may be sanctions for improper IPR disclosure, including removing the authors from the document and/or taking document off the standards track. ORR document had late IPR disclosure. We asked on the mailing list whether this is a problem, and there were no responses. If you think this is a problem come up to us and talk about it. IDR WG does IPR poll in parallel to LC poll. We would like to continue with this practice as it saves time. Does anyone have any concerns with this draft? No response in room. Updates on existing drafts [13:45-14:15] 2) Signaling ERLD using BGP-LS [Gunter Van de Velde] (10) https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld/ Gunter presenting. [presentation] When create this draft, the assumption is the main use case is for entropy label. Over time there may be other use cases of RLD. Would like to know whether should put ELC and RLD together or separate in BGP signaling. [discussion] Jeff Tantsura : Initial use case was entropy labels. There are other ones that would require multiple labels pushed and swapped on the transport, it is important to know how deep the stack can go. It is not only related to PCE. Jeff Tantsura : To confirm - you have a preference to confirm how many labels can be used, not necessary specifying whether it is for entropy of something else? Jeff Tantsura : It is for the operator to decide. It is essential to have this information but not the detailed usage. There are limited capabilities in microcode, it is up to operator to decode how to use it. Gunter: You can actually signal the readable space but at the same time you signal the capability of the router to do something with it, to actually use for entropy, for passive marking, or for something which maybe not being documented yet. Jeff Tantsura: In most cases it is agnostic. What it does is less important than maximum depth. Stephane Litkowski: Speaking as coauthor of SPRING draft. Based on discussion in Chicago we concluded that the RLD notion is not enough, we did not have the knowledge on the ability of the router to read the entropy labels. There needs to be a capability to read the amount of labels. In the MPLS document we do not need any additional capability as it is included in ERLD definition. In my opinion IGP draft should be consistent with this approach too. Gunter: This is to be added in future. Stephane: In the future we may see other uses of entropy labels. Jon Mitchell: In SPRING context, intelligent TE does not require the use of entropy labels but would have a use for RLD depth on a platform for a controller to make decisions. Gunter: Do you mean separate or single? Jon Mitchell: Separate. Gunter: I have just heard two completely opposite opinions. Jeff Tantsura: I forgot the question. :-) Gunter: Interesting, I have heard two different positions here and not certain how to progress, asking chairs for guidance. Jeff Tantsura: You should be following the IGP, not invent your own. Stephane Litkowski: I agree, we need this consistency between IGP and BGP, and this needs to be defined in MPLS document. This needs to be addressed by MPLS WG. Chris Bowers: I agree to let IGPs to address this. The logic should be the same as in IGPs. Sue: My personal preference would be follow what IGP did, and double check on the mailing list. Ketan Talaulikar/Cisco: Label depth of MSD subtypes instead of separate type? There is MSD draft. Do we use the same as a subtype? Gunter: No, we decided to keep them separate. Chris Bowers: Can you repeat the conclusion what you decided to do? Sue: My personal opinion is BGP should follow the IGPs. How to get input - float this on the mailing list. Chris Bowers: You are asking about adoption? Sue: Gunter was asking about WG LC. Chris Bowers: Therefore I believe the conclusion is wrong. It should sit and wait until MPLS and IGPs figure out what to do. Gunter: This is not the only draft following this recommendation. There are BGP-LS documents that are used to export IGP attributes. Chris Bowers: You asked for opinion. Stephane said it is in the state of flux. My opinion the document should wait until it is solidified in MPLS and IGPs. Sue: Do you know how long is the wait? Chris Bowers: No Jeff Tantsura: The relevant IGP authors are in the room. Jeff Tantsura: Talking as MSD author, we created separate IANA registry. Rather than use a separate registry, it could be a separate subtype. Stephane: MPLS document was in WGLC that failed. We fixed all the issues, I expect new WGLC to be sent. Maybe it is a good timing to ensure that there is a WG consensus on IGP document. Sue: Is there anyone in the room from OSPF or ISIS WG? Sue: Thank you for the input, it was very useful. 3) Carry Congestion Status in BGP Community [Zhenqiang Li] (10) https://tools.ietf.org/html/draft-li-idr-congestion-status-extended-community/ Zhenqiang presenting. [presentation] [discussion] Robert Raszuk/Bloomberg: How do you plan to deal with the case on n links between a pair of ASBRs, and the utilization on the links is different because the hashing is not good. L3 links, not LAG. Zhenqiang: I think you are describing the case of loopback peering, the sessions could be separated per link (paraphrase of response). Jie Dong: This solution works for traffic steering among different BGP peers, for the case of multiple links belonging to the same BGP session, currently it is not covered. Ruediger Volk/DT: The description of the semantics of this are sufficient. The idea of having indication of load and congestion on several paths to be an important input for routing decisions is clear, but when one defines a specific coding scheme to signal that, the idea of how to derive the actual signal (that is partially done in the draft) and what to do when you see the signaling - that needs to be defined. The considerations on oscillation are in that territory. But it doesn't look like the draft has anything that can prove that oscillation can be avoided, rather let's see and observe and then fix implementation and configuration aspects. In the complex interworking of BGP systems that does not look like a convincing approach, although I have to admit it has been taken in a past. Sue: Can you post those examples to the list to get more feedback? To hear what people are saying about the examples? 4) BGP Extensions for PCE Discovery [Dhruv Dhody/Jie Dong] (10) https://tools.ietf.org/html/draft-dong-pce-discovery-proto-bgp Dhruv presenting. [presentation] Draft was presented in PCE in the past, also want input from IDR. [discussion] Ketan Talaulikar/Cisco: For the encodings you use ISIS style TLVs, but for OSPF they are different. BGP-LS follows two byte OSPF style TLV encodings. Dhruv: Will be checked. Ketan Talaulikar/Cisco: Another comment - would be good to describe the use cases and scenarios. Dhruv: One of the reasons is that there is a PCE document with requirements for discovery. We need to reference that document and may add something from BGP-LS point of view to this document. Ketan Talaulikar/Cisco: IGP based discovery covers IGP domain wide, now we have scenarios that are inter-AS. Sue: Are you concerned about specific scenarios? Ketan Talaulikar/Cisco: Yes, there are scenarios of redistribution IGP-BGP-IGP. Sue: You should describe those scenarios on IDR mailing list. New Work [14:20-15:30] 5) BGP Revised Data Store model [Susan Hares] (10) https://tools.ietf.org/html/draft-mks-idr-bgp-yang-model/ Sue presenting. [presentation & discussion] This is a revised datastore version of the model based on OpenConfig. The OC model is not going to be adopted in NETMOD. Two different models and two different decisions, this is not good for deployment. We require two interoperable implementations, it is not the case here, fundamental differences in where operational state is stored in the tree. Sue/chair hat on: proposed solution differences. There are different formats but the same equivalent information. After discussions including routing ADs, the solution is to publish OC model, it will not go STD track but informational. This draft does exactly that. Lou mentioned that versioning precludes publishing of both modules at the same time. We may use different names for different modules. Chair hat on - it seemed right thing to give an opportunity for OC people to reuse their work. I do not know how ADs will handle updates to OC modules. This is an encouragement for putting modules on the Github. Rob Wilton/Cisco: Namespace issue - it does not matter what namespace you use for OC drafts. They are implemented in OC namespace, there is no version issue here. Sue: Repeating - the OC module and NMDA module has to have different names. Rob Wilton: That is not what people will be implementing, they will be using OC namespace. The IETF name in the OC informational draft doesn't matter as no one will actually implement that. A particular version in that particular OC name space. Mahesh: The question is - you are referring to the original IETF draft for BGP and the IETF namespace. That was written with IETF namespace. No-one implemented that. If you want to publish it, we have to give the namespace. That namespace will be IETF namespace. Rob Wilton: You can call it ietf-bgp-opencoinfig :-) Sue: That was my suggestion. Lou: If they have different names you have no versioning problem, they are not related. They are different modules. The other question - the point was made that no-one should implement OC version. If no-one is going to implement that, why are we publishing? Jeff Tantsura: There are 7 implementations. Sue: It is current the IDR BGP model we are switching off. . Lou: If you expect people to implement then publish. Lou: It means that Rob Wilton¡¯s comment was not accurate. Rob Wilton: Have people implemented OC module with OC namespace, or have implemented IETF draft? Lou: The reason it does not compile within IETF context. If you bring other OC modules it complies. Keyur Patel/Arrcus: To answer Rob Wilton¡¯s and Lou's questions, there are implementations that are pure OC based. They compile, no issues. Sue: The reason why I would like it be published - BGP selections inside that module are wise. The choices made for BGP are wise. I want to ensure that we have a copy for IPR purposes of those wise choices. Rob Wilton: In that case it would be better to publish references to particular version of OC module that should be implemented. That would be better than creating a third module in different namespace. Jon Mitchell: I do not understand why not referencing the OC module directly in the information draft, we should not publish something in IETF name space. Sue: It seemed reasonable because people had contributions. I will take this to the list. Lou: One modification to Rob Wilton¡¯s proposal - publish the work as just data structures but not the modules. Publish that as informational but not as a compliable module. That would avoid all reference problems. You will not end up with a compliable module that no one is going to use. Keyur Patel: It is important that we publish this, there are shipping implementations that can be referred. Lou: Is that IETF namespace or OC namespace? Keyur: OC namespace. Sue: We need to talk offline. Ruediger Volk: I am getting confused. What I wonder - publishing stuff is fine, publishing stuff on stuff that has been implemented is even better. Recently I have learned that vendors have their own models and they are doing mapping and transformation of the modules. I wonder whether the stuff that you are going to publish will cover the naming and transformation. It would be good that the audience does not get confused even more of that modules are available in the space. Sue: We will issue adoption call. We need to move to revised datastore architecture. Does anyone have problems with this approach? Himanshu Shah/Ciena: I have sent email on some missing attributes (address families). That was one of the drafts that had those attributes and after the merge it all got lost. Sue: I know what you are talking about, I will address this. Sue: Any other concerns about adopting? Sue: Once we settle on the revised datastore model, we will take other modules depending on it. Once we adopt this, we will adopt the extensions. 6) BGP Link State extensions for IPv6 Segment Routing(SRv6) [Gaurav Dawra] (5) https://tools.ietf.org/html/draft-dawra-idr-bgpls-srv6-ext/ Gaurav presenting. [presentation] [discussion] Keyur Patel: It is a great draft, I have not read it. :-) You are carrying SRv6 information. What happens if my tunnel SAFI has IPv4 and IPv6 encapsulation capabilities? Gourav: That is not specific to this Keyur: This is specific to BGP. You may want to clarify this in the draft. Gourav: We can verify that. Jeff Tantsura: The number of TLVs is defined in a similar way as MSD capabilities. Ahmed Bashandy: It is better to put one piece than in separate small pieces. Jeff Tantsura: You are signaling redundant information. Ahmed: Not really. Jeff Tantsura: If you build both software and hardware I would agree. In disaggregated world you will start confusing everybody. Gourav: It may end up being more confusing that having one interface. Ahmed: We encode it as a single element, while you are suggesting to have in different TLV fragments. Mach Chen: There is another draft that defines similar extensions that has different implementation details. We can discuss offline how to approach. Ketan Talaulikar/Cisco: Jeff, you mentioned that information is redundant, I didn't quite catch that Jeff Tantsura: It is not redundant, it is defined in multiple places. 7) Segment Routing based Service Chaining [Gaurav Dawra] (10) https://tools.ietf.org/html/draft-dawra-idr-bgp-sr-service-chaining/ https://tools.ietf.org/html/draft-clad-spring-segment-routing-service-chaining/ Gourav presenting. [presentation] [discussion] Keyur: I have a question for chairs. There was a draft presented that was intended for service chaining. I have a recollection that at that time service chaining was not in charter for this WG. Sue: Let me talk to Alvaro. He is not here until Tuesday. I will send a note to the list on the outcome of the discussion. Gourav: We are defining BGP-LS extensions in this draft, not the service chaining itself. Sue: Keyur, can you send a pointer to the draft you mentioned? Keyur: Will do. Sue: This falls into the coordination between IDR and SFC. --- Sue: I have 1 WG adoption and 1 codepoint allocation. If you miss your allocation and miss LC , do not be shy for sending us another message. Sue: End of meeting.