* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Idr Status Pages

Inter-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

Minutes

minutes-104-idr-00 minutes



          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.
          
          



Generated from PyHt script /wg/idr/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -