Idr Status PagesInter-Domain Routing (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 1994-Aug-15 —Chairs:
IETF-104 idr minutes
Session 2019-03-25 1610-1810: Karlin 1/2 - Audio stream - idr chatroom
Session 2019-03-28 1050-1220: Grand Ballroom - Audio stream - idr chatroom
Monday Session Chair start. Sue Hares: need 5575BIS completion to get RFC 5575 updated. Need implementation references. Several Flow Spec drafts are waiting on it. Need feedback on how long to hold this. Question: how long do we wait? how about April 15. Need implementation information Two early Allocations are extended recently. Need implementation so could send them to IESG. General Concerns about BGP message size, error handling of BGP-LS and many small BGP-LS drafts for code points/encoding. Way forward: extended messages is passing WG last call. An update of RFC7752 is on today's agenda to improve error handling. Propose: one document to keep the encoding in both IGP and BGP-LS. asking LSR to handle encoding in their document set John: there are IDR drafts which simply say this is defined in IGP, need to bring it to BGP-LS. Sue: we are stuck on the partial implementation reports. need help. (On bgp-bestpath-selection-criteria) 2 from Cisco, partial from Juniper. Is it enough? if yes, we will go forward. It has been sitting for over 6 years. John: About tunnel encaps draft, if we go back and do it again, maybe we would have a separate framework draft, and separate drafts about different tunneling technologies. The current document has everything in one place, the problem is nobody has a full implementation. In this case the implementation requirement should be the fundamental stuff and at least one tunnel type. Need feedback on this. Sue: we need feedback on these partial implementation reports, need to clear the deck based on the implementation status. 1) BGP-LS Extension for Inter-AS topology Retrivel Aijun presenting.Defined a new NLRI [no questions] 2) BGP extension for SRv6 SIDs allocation https://tools.ietf.org/html/draft-chen-idr-bgp-srv6-sid-allocation/ by Huaimo Chen One is node ID, another is adjacent ID, both Using BGP-LS Introduce 2 TLVs: one for Node ID, another for Locator. For adjacent ID, use the same structure. Ketan (Cisco): BGP-LS has been used for reporting information to the consumer. this draft is major shift of using BGP-LS as provisioning tool. have some concerns. Sue: can you send your concerns to the mailing list? Robin Li (Huawei): there are some scalablility issue of existing method for SRv6. using central control to eliminate scability issue. BGP-LS or other BGP extensions may help to solve the issues in deployment. Acee: We do have these things in the SR-Yang model (mpls and SRV6) for provisioning. I do not want to lock anyone into 1 method. Ketan: SR SIDs and locators are more like provisioning or configuration stuff, BGP SR policies are more dynamic control plane thing, thus think YANG models and other provisioning mechanisms are sufficient. Huiamo: BGP already have SR extensions for SR routing policy additions. That one also need to use resource. This is just another extension for provisioning. Maybe not do it via BGP-LS, but some other extensions to BGP. The BGP option allows more scalable provisioning. John: (As individual contributor) Just because you can do anything, doesn't mean you should. (As WG chair) We have a SPRING working group to do the segment routing architecture. Since most of the discussion involves SR architectural issue, and the architectural part is appropriate for SPRING. I recommend that you talk to the SPRING chairs for architectural advice. If they recommend it, you can present at SPRING to get feedback. 3) BGP Extensions for Routing Policy Distribution (RPD) [Huaimo Chen] (10) https://tools.ietf.org/html/draft-li-idr-flowspec-rpd/ Huaimo presenting. Jeff Tansura: John's comments to the previous draft are applicable here. Where is the feedback loop? How to convey the operational states with BGP? Huaimo: maybe more work needs to be added for that. John: Question for Jeff, how does that work with Flowspec? Jeff T: Same way, using CLI... It's a serious question. Christoph Loibl (Next Layer): Don't think FlowSpec is the right vehicle for this. There are two options, but no similarity to Flowspec. John: Didn't intend to suggest Flowspec is the right mechanism, just to say this isn't the first time that BGP not return feedback loop. Jie Dong: Also want to mention that we do not have feedback loop in many existing BGP cases, such as BGP Flowspec and BGP SR policy. Some mechanism to provide feedback needs to be considered. Acee: With restconf/netconf you have immediate feedback. What is the advantage compared to netconf/restconf? Huaimo: This is a good question. We need rapid changes during rapid traffic engineering. Acee: Today there are products doing this via proprietary CLIs to push BGP stuff to network. Robin: We have seen the challenges of using the CLI for interoperbility issue and netconf/restconf for performance issue. BGP has advantage in both interoperbility and performance. Sue: My understanding from Robin is the improvement is due to the p2mp (single BGP speaker to lots of BGP peers receiving the results). Robin (Huawei): Similar case as SR-policy distribution, there is already a solution. Jakob Heitz (Cisco): Using BGP is due to the ability of BGP to cross domains. Is this what required in this case? Huaimo: We provide details on how to get this data across to other ASes. 4) Subsequent Address Family Indicator for SDWAN Ports [Linda Dunbar] (10) https://tools.ietf.org/html/draft-dunbar-idr-sdwan-port-safi/ Linda presenting. (note taker was presenter - so notes were lost] Ali Sajassi (Cisco): We have another draft in BESS. What kind of features you are proposing that can't be addressed by BESS's SECURE-EVPN draft? Linda: this draft is about WAN ports property registration, about dynamically register WAN port properties to the SDWAN controller. The SECURE-EVPN is about managing clients routes and various ways of mapping clients routs to IPsec. Ali: The common denominator is we need to allow for multiple ports to be flexible to set up different IPsec tunnels among them, and map traffic flows to IPsec tunnels. Sue: Due to time limit, suggest to continue the discussion on mailing list. 5) BGP Diagnostic Path Attribute [Jakob Heitz] (10) https://tools.ietf.org/html/draft-heitz-idr-diagnostic-attr/ Jakob presenting. Jeff Tantsura: The draft lack of motivation, need to explain why would you do it? Jakob: Because of bugs. Two implementation required this information, the checksum would be helpful to solve the bugs. Time stamps can help to find the keys in process, or routing loops. Jeff Haas: There was a time-stamp draft 3 years ago. There was problems of incremental deployment. We stop pursuing this due to the problems. Could you give more information about the checksum? Jakob: You need to turn this diagnoistic on only when you need it. You need to be mindful of the update packing. Jeff H: My question is what is the use case for the checksum? Jakob: We have some bugs in implementation. Jeff: So the case is that the BGP stack is tightly coupled with TCP stack. Robin Li: Why the internal process timestamp information is propagated in network? Another question is why not using BMP to collect the information? Jakob: It may be useful to be propagated one hop. There are multiple tools: stream telemetry, BMP or this draft. Keyur: BGP problems related to Queueing buildups are transient. For this to be useful, you need to provide justification of use cases. And need to explain how this is better than BMP. Jeff: Part of the motivation is where do you do the time-stamping? What you are able to see the information flow (router to router) via data. There is motivation for something beyond BMP. [WG adoption requested] 6) BGP-LS Extensions for Inter-AS TE using EPE based mechanisms [Srihari Sangli] (10) https://tools.ietf.org/html/draft-hegde-idr-bgp-ls-epe-inter-as/ Srihari presenting. Sue: Is this related to the B bit described in draft-ietf-idr-bgpls-segment-routing-epe-17? If so, how was this problem discovered. Alvaro: I'm reviewing the bgp-ls-epe draft and I asked how B set-up backup links. The authors told me it was configured in proprietary manner. Now, we see a signalled manner. It cannot be both unless there is more description. Sue: If this is something discovered in implementation, may provide more substance to that particular section. Maybe worth conversation with the authors of the epe draft. Ketan: Explain the B bit, how the node determines what would be used for backup is implementation specific.B bit says this link is protected by FRR. We don't have the mechanism to tell which one is serving as backup, niether do we have it in IGP today. .... back to slides. Ketan: (About the second problem) Agree there is a gap to address Alvaro: It would be good to have the "B" and "F" descibed in the Spring epe draft. It is past RFC approval, but there is time to add this one small clarification. Please talk to the Spring chairs. [In the slides: Authors request this as an IDR draft]. 7) BGP Link State Extensions for SRv6 [Gaurav Dawra/Ketan Talaulikar] (10) https://tools.ietf.org/html/draft-dawra-idr-bgpls-srv6-ext/ Gaurav presenting. Propose the SRv6 SID NLRI and Locator TLV. Sue: what is the improvement you found from the original version to the deployments? Gauray: what we learned is syn with IGP, so can keep the implementation simple. And to address the comments about size of the BGP-LS attribute, we created a new NLRI. Sue: what helps by creating a new NLRI? Gaurav: lots of information needs to be carried. Alvaro: speaking as an individual, are you defining new MSD type? Gaurav: It is the same concept, we are using it for functions of SRv6. Alvaro: You said that the values are not assigned,are you define the registry and everything else here, or is that coming from the IGP draft? (the slide shows they are defined in IGP draft) Jeff Tantsura: The registry has been created for SR-MPLS draft. Jie: You mentioned that you learned a great deal to align with the IGP SR design.In ISIS SRv6, you have Locator as top TLV, and SIDs are carried as sub-TLVs. Ketan: The IGP we had less SIDs, but BGP-LS had more SIDS. If carries the SIDs in node attributes, it grows the BGP-LS message size. Jie: With this mechanism, individual BGP Update message may be generated for each SRv6 SID, the number of BGP Updates will increase significantly. Gaurav: You can pack multiple SIDs into one Update message. Jie: Only if they have the same attributes. Gaurav: Yes. [WG adoption requested] 8) An Update to BGP-LS Specification (RFC7752bis) [Ketan Talaulikar] (30) https://tools.ietf.org/html/draft-ketant-idr-rfc7752bis/ John Scudder (chair): This presentation is a bit unusual in that we had a draft uploaded only 6 hours ago. We decided to let this presentation go forward due to the topic is interesting enough to the group. Since we have 2 sessions, we can have more discussion on Thursday. Ketan presenting. Keyur: (About message exceed 4K) If you drop it and consider it as attribute discard, the consumer may not have a clear picture of the topology, you may want to signal that. Ketan: One way is BGP extended message, but it will take time to deploy. Another option is to limit the number of TLVs. To answer Keyur's question, when we discard the attribute, the actual link-state NLRI is still propagated to the consumer. The consumer sees a link state NLRI without BGP-LS attribute, it is a hint that it is not a withdrawn, this may be used for debug. Sue: question: do you get into a loop? Where consumer doesn't know John: Need to follow up on the mailing list (Back to the presentation) Keyur: Suggest to move some changes into a different draft, not include them in the base. Existing implementations only need to fix things in the base then still conform to the RFC. Ketan: Need to go through which part makes sense and how to do that. Jeff Tantsura: Checked the diff, the external type 2 for OSPF is removed, is there a reason? Ketan: No intention to remove. Will check. (?) Ciena: We do have implementation of BGP-LS, find two specification bugs in OSPF, one is very simple, another one is more complicated. Will provide details on that. Thursday Session: 0) Agenda bashing (5) We have 30 minutes at the end of the session for additional conversation about BGP-LS update. 1) BGP YANG Model for Service Provider Networks [Mahesh Jethanandani] (10) https://tools.ietf.org/html/draft-ietf-idr-bgp-model/ Mahesh presenting.Go through the updates and the issues. Acee: Routing YANG is getting ready for WGLC. Need wider review. Issues: statistics will be addressed in another draft. Jeff Haas: About issue#1, need clear BGP neighbor, clear routes can be controversial. About statistics, the stuff covered in MIB maybe put the the base module. About Notifications, what it means here for route updates? Mahesh: What it refers to is anytime that is changed to the route of entry in the model, that might result in a notification Sue: You have a neighbor-state change if you go from a particular state to another state. Jeff H: Clearning statistics is contraversial. Clearing routes is also controversial. For the controversial things, let's protect those via feature. Jeff H: Notifications for neighbor state change that makes sense, Notification for route updates can ve very noisy. This should only be able to be enabled by configuring a filter. John: Encourage to continue this discussion after the meeting. Robert Raszuk: Clear BGP in many cases can be based on route refresh, is this supported? Keyur: Yes, route refresh is supported. 2) Updates to BGP Tunnel Encapsulation Attribute [Keyur Patel] (10) https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps/ Keyur presenting. Linda: If a route can traverse through multiple ports, can it be associated with multiple tunnel attributes? should multiple "Remote End-point" SubTLVs can be attached to one UPDATE? the draft doesn't have clear description. The error handling says only one Remote End-point, otherwise, ignore Keyur: The error handling section specifies how multiple same TLVs should be handled. Please send the question again and will answer it. John: (With chair and document shepherd hat on) Another WG last call may be needed due to the revisions. Make sure to get your comments before or as part of WG last call. Linda: the RFC5512 has BGP speaker's endpoint address is specified. This Tunnel-encap removed it. Doesn't it mean that a third entity can send update on behalf of a router? Keyur: The text does not prohibit what you say, but If you see any issue with that, please highlight on mailing list. Linda: It enable additional functionalities, but also introduce more issues. The draft hasn't addressed any of those issues. Keyur: Plan is to publish a new version with all comments received so far, people can review and provide comments if any. John: We may need another WG LC to catch all this comments. Sue: (Chair's hat off) There is a lot in this draft to implement, are you going to segragate a common base? Jeff: Everyone need to double check the changes from SHOULD to MUST. (Keyur go through the changes.) Robert Raszuk: Historically, IPsec was not included in this draft, but now there are use cases for that. Can this draft be updated to add new types to cover that? Keyur: The start of this draft was to replace 5512, which didn't cover IPsec, it was in a separate document. Extensions can be defined in other draft. John: Suggest to finish the WGLC, if anything need to change about the base should be covered, new tunnel type or extension can be in a follow-up draft. Don't want this document open forever. It's designed as a modular and extensible framework. Keyur: As coauthor happy to include incremental changes if WG wants. John: (About implementation of a big draft), it would be good to define skeleton part first then the tunnel types in follow-on ones. Now we have 6 tunnel types in this draft. I guess almost no one will implement all of those in the beginning. Suggest to check the implementation of basic functions and at least one tunnel type. Keyur: As coauthor, we will get feedback and edit the document accordingly, we have no problem splitting the document, but if we do it, better to do it now rather than later. Acee: Support to complete this draft. If there is anything that nobody will implement, just take it out now. Linda: support having a skeleton document explaining really well of the mechanism, such as how routes can be egressed to different WAN ports, how to handle 3rd party sending update on behalf of another node, then have different encapsulations listed in Appendix, except IPsec because there are much more needed for IPsec. Srihari Sangli(Juniper): Respond to John's question, we could wait one month or a few weeks to make a call on whether split it. Keyur: Will publish version 12 and solicit comments. 3) BGP Signaled IPsec Tunnel Configuration [Hu Jun] (15) https://tools.ietf.org/html/draft-hujun-idr-bgp-ipsec/ Jun presenting. Fine with either make it a separate draft or update the previous one. Linda: with I2NSF chair hat on, this mechanism was discussed in, was controversial, Suggest to align with what Security Area discussion Jun: Think the mechanisms are different. Linda: Traffic selection in IPsec is not purely based on destination, can use other parameters,the current mechanism may not provide all this. BGP route update from a node say R1 can't tell R2 the Traffic selection policy. TS is usually specified by the policy. Jun: Not trying to be a SDN solution. This draft is just a extension to the BGP tunnel encapsulation draft to cover IPsec tunnel case. Robert Raszuk: it is useful to specify additional local prefixes, this is also applicable to other types defined in tunnel encaps draft. May consider to add that information to the base document. Jeff: Think this is a useful work. Need to add operational considerations section. Do you consider inter-domain use case? Jun: Not yet. Jeff: There are places this can also be useful. Related to the deployment of TE path attributes. It is difficult because of coordinating IKE across internet. Jun: Would add text to describe that. John: Please see email to the list to continue the discussion. Stephane: (As BESS chair) There are several draft in IDR and BESS about IPsec with tunnel ensaps. Suggest to find one solution to cover all the cases. And which WG is the owner of this work? John: We should talk after the meeting. Sue: (As indiviual) +1 for Stephane's comments. Question to presenter: Have you read the secure EVPN draft in BESS? Suggest to review that draft for multi-domain. Why are the remote address prefix and local address prefix necessary? Jun: With IPsec, user could specify both the source and destination subnets. Sue: The reuse of color may have conflicts with other case. Jun: THe color sub-TLV is put under the IPsec TLV, it is specific to IPsec. Ali Sajassi: Mention the secure EVPN draft, there are overlaps. And there is still mech of IPsec session, you were talking about the scale. Jun: Not trying to address the scale of IPsec session, only to scale the configuration. Ali: RFC 5566 defines similar mechanism, the difference is that was based on RFC5512. Jun: Yes. Ali: Are these prefix sent with the attribute VPN prefixes? Jun: They are the endpoint of the IPsec tunnel. Ali: SECURE-EVPN draft covers both the discovery ans setup IPSec session, and also P2MP signaling instead of mesh of P2P session. In the first part there is overlap with this draft. Keyur: About moving the list of prefix part into the base document, could work on that together. Need to cover how the routes across ASs willingly or unwillingly to be included. 4) BGP BFD Strict-Mode [Mercia Zheng] (15) https://tools.ietf.org/html/draft-merciaz-idr-bgp-bfd-strict-mode/ Mercia presenting. Will revise the backward compatibility section based on 5492, and add a new section to specify the BGP session state transaction. Juliusz: Could you give an example of the problem? Mercia: This is a common problem to control protocol, this is mentioned in section 4 of RFC 5882. Robert: This strict-mode has been proposed for OSPF, etc. But here it talks about link quality. BFD is not used to monitor link quality. There are proposals to enhance BFD, but there is gap. Mercia: The case like BFD dampening. Alxander: Do not understand why need to negotiate the capability. Can be just configured locally. Mercia: To avoid potential dead-lock. Acee: Many venders support strict mode. Signaling can help when you don't want to use it. Keyur: Like the document. Don't think need the capability. Suggest to take it out to make it simple. Himenshu: The use case about RR client is not covered. The connection between clients can be bad, but there is no BGP session. John: This case is addressed by draft-ietf-idr-rs-bfd. Jeff: This is a real problem. The issue is at what point in the BGP state machine to insist BFF either started, up and stable. There are interop problems, and this draft is a good place to standardize the behavior. John: several people stated they don't need the capability Jeff: Think the capability is needed for interoperation. Reudiger: BFD was used to tear down BGP session when something bad happens. Here it is to control the establishment of BGP session. There may be different approach to solve the problem. May not be necessary to delay the BGP session, but delay the advertisement of routes and the use of the received routes. Then the deadlock can be avoided. John: Suggest to continue the discussion on the list. Aocording to the progress of agenda topics, we don't have time for discussion on BGP-LS update today. 5) Route Leak Prevention using Roles in Update and Open messages [Alexander Azimov] (5) https://tools.ietf.org/html/draft-ietf-idr-bgp-open-policy/ Alexander presenting.Ask for WG LC, there are 3 opensource implementations. No questions. John: Will add it to list of WG LC. 6) BGP Flow Specification for SRv6 [Lei Li] (10) https://tools.ietf.org/html/draft-li-idr-flowspec-srv6-00/ Lily presenting. Define two types to match either the whole SRv6 SID or some fields of the SID. Robert: Do we need to consider match of the extension header type? Lily: This draft focuses on the new types for match of SIDs. Extension header may be covered in other drafts. Robin Li: SRv6 SIDs can be used in the IPv6 destination, but meaning can be different. Rafal Jan Szareck (Juniper): Which field in the header to compare with that? Is this against the SRH or the IP header? Lily: It is for the destination address in SR header. Meeting adjourn.