* 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-102 idr minutes

Session 2018-07-19 1810-1910: Viger - Audio stream - idr chatroom
Session 2018-07-20 1150-1320: Place du Canada - Audio stream - idr chatroom

Minutes

minutes-102-idr-00 minute



          IDR meeting at IETF 102 (version 3)
          
          Session I:  Thursday,  18:10-19:10,  7/19/2018
          
          Room: Viger
          
          0) Agenda bashing (5)
          Keyur: Presentation #4 is not adopted according email list message,
          so why is on the agenda?
          John: There is quite some discussion going around on requirements and
          neighbor and liveliness dicussions. Many proposals emerged, and chairs
          didn't expect that this particluar topic would be on the agenda right
          now. Randy was asked to redeliver the talk from LSVR on requirements at
          at IDR WG
          Keyur: If solutions that are not adopted, we should removed it from
          speaking about on the agenda
          John: No, request noted, but it remains on the agenda
          
          Jeff Tantsura: The BGP model depends on the policy in the rtgwg model
          (draft-ietf-rtgwg-policy-model-03), and it is not done.
          Sue Hares: How quickly can you get it done.
          Jeff Tantsura: It is only 60% done.
          Sue Hares: Perhaps you should put it on high priority to get it done.
          
          1) Update on merger of RLP and eOTC drafts for route leaks solution
          [Kotikalapudi Sriram] (8)
           https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation
           (solution)/
           https://tools.ietf.org/html/draft-sriram-idr-route-leak-solution-discussion-00
           (design discussion)
          Sriram presents the draft to WG
          Jacob H: Abouta year ago i put in a draft on another solution for this. So
          that neighbor can check this type of aspects. Did you see that?
          Sriram: Maybe Alexander can comment
          Sue: The chairs want a specific answer to Sriram questions and we need
          to focus on that and be specific if you discuss around something else
          Alexander: I would like to understand why we go from attribute to
          community. Attribute is better, but will take years and years. We know
          the limites of the communities, there  may be issues, so please comment
          Randy Bush: Locally community communities are very strongly authenticated
          and integrity verified
          John Scudder: So that was a joke, go ahead please.
          Job Snijders: It's no difference for attributes like this. This doesn't
          need to propagate very far, so in the limited radius there is already
          benefits.
          John Scudder:
          
          2) BGP Model for Service Provider Networks [Keyur Patel] (8)
           https://tools.ietf.org/html/draft-ietf-idr-bgp-model/
          Keyur presents on YANG model updates
          Acee Lindem: We talked about this offline. You are going to change it
          to augment IETF routing protocol model instead of being at the top.
          Keyur:The model compiles, we'll make the change suggested. Would like
          to take it to WG LC.
          Dhanendra (Cisco): Do you plan to define BGP RIB structure in the base
          one?
          Keyur: Yes.
          Dhanendra (Cisco): And need to add support for clear RPC.
          Keyur: The clear should be taken on a separate track.
          Dhanendra (Cisco): The policy extensions, if policy extensions are
          required, then it looks like extensions for policy may need to be thought
          about also in the model
          Keyur: this model has only base extensions, and would like to reference
          these features to the extensions draft track
          Sue: What needs to change in the base model?
          Keyur: RIB
          Himanhsu: What extension will be needed for the BGP EVPN and L2VPN?
          Keyur: The AFI/SAFI support and the related BGP parameters.
          Himanhsu: Will it overlap with the BESS EVPN L2VPN model?
          Keyur: It should not overlap with the BESS EVPN L2VPN model
          
          3) BGP Extra Extended Community [Jakob Heitz] (8)
          https://tools.ietf.org/html/draft-heitz-idr-extra-extended-community/
          Jakob Heitz Cisco presents the draft
          Keyur: What if the WG thinks we need 30 byte communities 6 months
          later. Will we define a new AFI/SAFI for another RTC?
          Jakob: Yes.
          Keyur: I suggest based on that I suggest we stay with the wide
          community.
          Jeff Haas: We already did refactoring. Let's do the transitivity.  Yeah!
          Let's do that. I do not like the 6 bytes.  It may work for your code,
          but it does not work for mine. If put the field in the beginning we can
          have variable-size and do parsing based on the type.
          Jakob: (comment regarding length of time to be deployed) ---
          John: Both "unreasonable positions" have been noted - go on.
          Sue: +1.
          Jorge Rabadan: I am confused about your slide. The new RT are to be
          used in addition, and not as replacement. I assume that all your EVPN
          PEs need to support this community. That needs migration.
          Jakob: There will be no conversion between old and new. It could be done,
          but I would not do that
          Jorge: If you send both to all the leafs, then there is no gain as you
          still have to configure the other RT.
          Job Snijder: I want to comment on the transitivity aspect. Jeff
          Hass and keyur created some drafts on this. Maybe using common
          headers/container. From a marketing perspective saying that it is just
          like large communities, but then bigger, but transitivity should be
          the considered. How we solve this as WG it should be considered. Per
          attribute, per community or per color etc. may not be ideal. We need to
          think how to push to market
          Jakob: We need to look into scoping the solution.
           Chairs:
          
          4) BGP Neighbor Autodiscovery [Ketan Talaulikar] (8)
           https://tools.ietf.org/html/draft-xu-idr-neighbor-autodiscovery/
          Ketan presents the draft
          Chairs: we are 10 minutes in overtime, it would be appreciated if time
          can be respected
          Chairs: Due to the current status of the draft, lets not dig into further
          details at this time for the interest of time
          
          5) Requirements for BGP Neighbor Autodiscovery (15)
          LSVR Hello Neighbor Requirements [Randy Bush] (8)
            Discussion (7)
          Randy Bush: Presents requirements summary
          Sue: The only thing I mentioned in the LSVR was the ES-IS protocol.
          John: Probes WG to understand if this a topic of interest to the WG:
          Mostly HUMS say yes
          John: Probes if we understand the requirements for IDR: Mostly hum that
          we don't know exactly the requirement
          
          Jeff Haas: LSVR has the liveness requirement, we don't, that may bias
          the solution. The solutions offered have significant overlap. I do not
          think we are far from the actual requirements.
          Keyur: +1 to Jeff Haas. We should think about this work to apply to IDR,
          LSVR, and to other points.
          John: The AD has asked us to work with the LSVR to have a unified solution
          instead of 2 proposals.
          Rajiv: Most of the MDSC are going to be IPv6.  We should leverage IPv6
          neighbor discovery or at least add it to analysis.
          Acee: The requirements have a lot more then that as the capability of
          IPv6 neighbor discovery
          Rajiv:I would like to ask if this list is expanded with IPv6 ND.
          John: Lets take the requirements as they are
          Acee: Lets make clear that the liveness requirement is not BGP liveness,
          but Ether liveliness
          Randy: I would like IDR to not take this up. LSVR has a constrained
          problem. IDR can expand to known universe.
          Ali Sajasi:With respect to the LLDP option, I would consider if Jumbo
          frame can be considered.
          John: Let's take of time have this address with the people that know
          more about LLDP
          Keyur: Jumbo frames is good to have, but not necessary.  You do not want
          to go beyond one hop.
          John: Almost certain we will schedule an interim to talk about this.
          
          [Total 52 minutes]
          
          Session II:  Friday,  11:50-13:20,  7/20/2018
          
          Room: Place du Canada
          
          0) Agenda bashing and Chair's slides (10)
          Sue and John Go over the Chair slides
          - Chairs ask for volunteers to be shepherds.
          - Chairs ask to know about implementations
          
          1) LOCAL_PREF Overloaded = Overwritten [Alexander Azimov] (5)
          Alexander presents the slides
          Ruediger Volk: I do not like the idea that the router is setting
          attributes outside of the policy configuration. It is unlikely that there
          is any use-case related that should need such a solution. I prefer locally
          controlled policies as that is under operator control, with maybe vendor
          support for simple well known standard policies to insert if needed
          Alex: DT is fully capable, and so is NTT and so are the other 50k
          ISPs. In FRR (Open source router) and in there the local policy is
          already overwritten.
          John Scudder (as contributor): If you have a complicated set of criteria
          of policies, then you still have to come to conclusion. What about BGP
          custom decision, a WG document that is potentially applicable. I wonder
          if this is a problem that really needs to be solved, but it has been
          there for 2 decades
          Alvaro: Echo what John said. The custom decision draft addresses some
          of this.
          Alexander: The default policies that overwrite route-maps give me
          uncomfortable feeling.
          Ruediger: the concept of providing a library of standard policies would
          be a good thing.
          Alexander: People may copy it without understanding what they are
          doing. Templates going in the wild not really working.
          Jeff Haas: We are running into two things. Number space is
          gigantic. Another location of consideration that is messy is the tie
          breaking process, and the influence of extensions that have impact upon
          these preference tie breaking concepts. It may be worthwhile to have a
          draft to discuss these aspects
          
          2) Updates to BGP Signaled SR Policies [Dhanendra Jain] (8)
           https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy/
          Dhanendhra provides draft update
          Andrew Stone (Nokia): No a comment on this draft, wider scope. Consider
          advertise the range of Binding SID?
          Dhanendhra: we have plan to add deriving the binding SID from SRLB.
          Jeff Tantsura: Would be interesting to describe how the feedback mechanism
          works as the machinery is spread over different drafts
          Sue(Chair): Please put in a security section before WG LC.
          Ehsan Rezaaifar (Nokia): Signaling policy using BGP is OK, What about
          feedback mechanisms. If controller is peering with a RR, then there is
          no way for a controller to know if this is something that router can
          support this?
          Chair: this discussion go to deep, let have the discussion after the WG
          meeting
          Ehsan Rezaaifar(Nokia); The problem is router should advertise the
          capability using the same mechanisms (AFI/SAFI).
          Ketan: Fact that router support the capability and is peering with RR,
          whether that's sufficient indication of the capability.
          Keyur: I would like to see sections added to describe the RR in forwarding
          path, vs. the RR off forwarding path.
          
          3) YANG data model for BGP Segment Routing Extensions [Dhanendra Jain]
          (8)
           https://tools.ietf.org/html/draft-dhjain-spring-bgp-sr-yang/
          Dhanendra presenting draft
          John:  let's keep the comments brief.
          Sue Hares (contributer hat): Work with RTGWG on policy. Please look at
          Keyur extension draft and harmonize/restructure the work. Is this based
          upon any other traffic studies outside of SPRING use-cases?
          Dhanendra: Yes, ther eare SR extensions in BGP. The approach is take the
          minto BGP and augmenting the structure. I will look at the BGPextension
          model, especially the BRIB model. Yes, it is in the context of SPRING
          and this related to it.
          Jeff Tantsura: We are trying to align all policies in single
          document. Naming of the document is policy , but is not doing BGP policy
          is unfortunate naming.
          Dhanendra: ack
          Jeff: there are some comon types in routing and they should be used in
          this document also
          
          4) BGP-LS Extend for Inter-AS Topology Retrieval [Aijun Wang] (10)
           https://tools.ietf.org/html/draft-wang-idr-bgpls-inter-as-topology-ext/
          Aijun presents draft
          John (Chair): Adoption discussion on list
          Ketan: It would be good to describe the new TLVs in the document
          Jeff Tantsura: The address space used on the interconnection address
          space is uncommon to be imported into the IGP. The adres space frm other
          operator does not belong in your IGP address space.
          
          5) Distribution of Traffic Engineering (TE) Policies and State using
          BGP-LS [Ketan Talaulikar] (10)
           https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution/
          Ketan presenting draft
          Jeff Tantsura: Anytime you signal something then you should be telling
          also how it is retrieved as this is distribution of operationalstate
          
          6) Flexible Algorithm Definition Advertisement with BGP Link-State
          [Ketan Talaulikar] (5)
           https://tools.ietf.org/html/draft-ketant-idr-bgp-ls-flex-algo/
          Ketan deliver presentation
          
            BGP Link-State Extensions for Seamless BFD [Ketan Talaulikar]
           https://tools.ietf.org/html/draft-li-idr-bgp-ls-sbfd-extensions/
          Ketan deliver presentation
          John (Chair):We have little time. WG adoption request noted and request
          will be taken to the list
          
          7) Applying BGP flowspec rules on a specific interface set [Jeff Haas]
          (5)
           https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset/
          Jeff presents draft
          No comments or questions
          
          8) Segment Routing Policies for Path Segment and Bi-directional Path
          [Cheng Li] (15)
           https://tools.ietf.org/html/draft-li-idr-sr-policy-path-segment-distribution/
          
          
            SR Policies for Path Segment and Bi-directional Path in BGP-LS [Cheng
            Li]
           https://tools.ietf.org/html/draft-li-idr-bgp-ls-sr-policy-path-segment/
          Cheng Li presents drafts
          No comments and questions
          
          9) BGP-LS Extensions for Advertising Path MTU [Fenghua Zhao/Zhibo Hu]
          (10)
           https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/
          Fenghua presents draft
          Jeff Tansura : There are multiple MTU's in play. Which one do you want
          to advertise?
          Fenghua: Let me come back
          Victor: Is there operator input that this likely a problem or something
          that will happen in real live?
          Fenghua: I will get back through email list
          
          [Total 86 minutes]
          
          



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