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

Session 2020-07-31 1410-1550: Room 6 - Audio stream - idr chatroom

Minutes

minutes-108-idr-02 minutes



          # IDR meeting at IETF 108
          
          ## Friday,  14:10-15:50 UTC, July 31, 2020
          
          ### Materials:
            https://datatracker.ietf.org/meeting/108/session/idr/
          
          ### Meetecho:
            http://www.meetecho.com/ietf108/idr/
          
          ### Collaborate on Note Takingļ¼š
            https://codimd.ietf.org/notes-ietf-108-idr/  (recommended)
            https://etherpad.ietf.org:9009/p/notes-ietf-108-idr/
          
          
          ### 0. Agenda bashing and Chair's slides (10 mins)
          Requests for WG LC and WG adoptions will be sent
          to the idr list after the meeting.
          Check it.
          
          ### 1. RD based ORF [Wei Wang/Aijun Wang] (10 mins)
            https://tools.ietf.org/html/draft-wang-idr-rd-orf/
          Wei Wang presenting.
          praveen Mada: I have a single domain case I want to ask a question
          regarding.
          
          When PE1 injects a prefix, will it impact other routers which are not
          overflowing the source?
          Wei Wang: The RR will check the IP source address, and it will not send
          to PE2 and PE4.
          Praveen Mada: It would be useful to provide more detail
          on the use cases in the draft.  Do you
          have any implementation experience with this draft?
          
          Wei Wang: I cannot hear the question.
          
          John Scudder: Please take the questions to the list to
          regarding the use case and the implementation experience.
          
          Keyur Patel: The back-pressure to the PE may not be
          required.  The prefix filter level filtering has
          more expense than a higher level filters.
          [Robert Razuk (chat list)]: An RD-ORF
          there was a number of technical problems
          sent to the list. None of these were addressed.
          This is not the right way to filter VPN.
          
          
          ### 2. BGP SR Policy Extensions to Enable IFIT [Giuseppe Fioccola]
          (10 mins)
            https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit/
          Giuseppe presenting.
          
          WG adoption requested.
          [no questions]
          [from chat]: [Ketan Talaulikar]: Having a routing/control plane
          considerations of
          IFIT proposal in some document would help.
          Right now it is being introduced in
          multiple protocols, but I'm not getting
          a proper picture. Please point to any document
          that I am missing.
          Giuseppe: Good point
           @Ketan good point we will give a proper picture in the next revision.
          Ketan Talaulikar
          @ Giuseppe. Thanks. Would really appreciate a sort of routing
          consideration
          section in your base IFIT document that puts out requirements for all
          these
          various routing protocols that you are proposing to add IFIT extensions
          to.
          It would make it easier for review.10:49:04
          Giuseppe Fioccola: @Ketan A new section in the beginning of the draft
          can help to clarify. We will work on that10:59:10
          
          
          Joel: Hmm. I thought the ifit proposal in other WGs was distinct from
          the
          ioam and alternatve marking proposals.10:26:32]
          Giuseppe:   Joel yes in other documents IFIT is also associated with
          the framework
           but in this document we just use IFIT acronym as "In situ Flow
           Information Telemtry"
           to summarize in one word IOAM and Alt Mark methods.
           @Giuseppe - given the different use of the term, I find it confusing
           to use
           it in this draft to mean "these two other things".
           @Giuseppe - depending upon how the draft evolves, the term may well
           become
           irrelevant. In which case it is not needed.
          
           [end chat]
          
          
          
          ### 3. BGP Bitmask Route Target and RT-Constrain Extension [Jeffrey Zhang]
          (15 mins)
            https://tools.ietf.org/html/draft-zzhang-idr-bitmask-route-target/
           https://tools.ietf.org/html/draft-zzhang-idr-bgp-rt-constrains-extension/
          
          Jeffrey Zhang presenting..
          Jie Dong: First comment on the bit mask route target.
          Is it main use matching the group defined in teas.
          Jeffrey: yes, this is the use case.
          Jie Dong: We had another draft describing the
          generalized RTC which was not adopted.
          The draft-ietf-idr-bgp-ipv6-rt-constrain has
          a mechanism to allow for this.
          Jeffrey: The global administrator could be an
          IP address.
          Jie Dong: If the global administrator could be a
          prefix, and that would be a issue.
          
          Haibo: Why not use a (not heard) prefix?
          The receiver which receives the routes.
          
          Jeffrey: I will need follow up online.
          [from chat room]
          Jeff Haas: Please repost the general rtc draft name?
          Jie, Juniper's implementation of rtc-c allows for
          short than host length for rtc filtring.
          Haibo: rt-c RFC4684 is applied to many address families.
          This extension works in similarly address family agnostic fashion.
          Jie: http://tools.ietf.org/html/draft-dong-idr-vpn-route-constrain-02.txt
          
          Jeff: Thank you Jie. I recall reviewing at the time.
          I'll re-review for applicability to our problem.
          Jie: Another question is can the BIT mask RT
          be advertised in RTC as prefix?
          Jeff: Jie, there's still some encoding discussions happening
          with the authors about how a wide community rt-c would look,
          even for a dense case like we have in the proposed draft.
          Jeffrey Haas:  Please expect us to followup the list on that point, Jie.
          
          Haibo Wang: @Jeff, Yes, RFC4684 is applied to many address families,
          but I don't think it's a good idea. If we want to extension the
          RTC, why not we may set AFI to resolve the problem like Jie has shown.
          Jeffrey Haas: Haibo, this discussion point covers a portion of what we
          had with the
          draft Jie had posted moments ago. We don't currently segregate route
          target types to specific vpn technologies.10:47:32
          Haibo Wang: My another comments is that, whether should we to do it
          like RTC or like RFC7543 CP-ORF10:48:05
          
          
          Robert: RFC4684 does not allow to send RT as a prefix.
          NLRI says fixed 8 octets. I proposed to the
          authors addition of RT as a variable length
          prefix as well - but that was not mentioned
          during the presentation.
          Jeff:  Your memory for rfc4684 is incorrect, Robert.
          "The NLRI field in the MP_REACH_NLRI and
          MP_UNREACH_NLRI is a prefix 0 to 96 bits,
          encoded as defined in section 4 of [5]."
          Robert Razuk:  Clearly RTC ... ORF is not transitive.
          RFC7543
          Robert Raszuk: @Jeff - yes I take it back ...
          I was thinking about SAFI 128 not RTC10:52:09
          
          Jeffrey Haas: It's okay, Robert. We keep repeating that point about
          RFC4684, so it's clear that it's in people's heads as being
          fixed length for some reason.10:53:44
          Robert Raszuk: Probably as RFC does not show length field in the figure
          :)10:55:17
          and figure says 8 bytes not 0-8 bytes too10:55:45
          Jeffrey Haas:  That would make sense, Robert. That may be worth an
          errata.10:56:12
          Robert Raszuk: Agree.10:56:29
          
          
          Bill Fenner: @jhaas in fact I had to fix tcpdump for that case
          too10:54:14
          Jeffrey Haas: !Bill, probably because of our implementation. :-)10:54:30
          
          
          
          [end chat room]
          
          ### 4. BGP-LS with Multi-topology for SR based VTN [Cong Li/Jie Dong]
          (10 mins)
            https://tools.ietf.org/html/draft-xie-idr-bgpls-sr-vtn-mt/
          (Cong Li presenting)
          
          [chat room start (not sure if this is the correct link]
          Ketan Talaulikar: I'll post my comment here to save time.
          BGP-LS has been specified as a northbound
          distribution mechanism for topology information from
          network to controllers.  One of these drafts is
          proposing to re-purpose BGP-LS for southbound
          provisioning.  Leaving aside whethr BGP
          is suitable for this, why not consider doing this as a
          separate Conficg SAFI?
          
          Floor questinos:
          Zhaohui Zhang: Can we chat about scalability.
          The Bit mask route target has ways to reduce the flow.
          
          Jie: We have some BGP based mechanisms regarding this
          topic.  We can talk about this more on the list.
          
          
          ### 5.Traffic Steering using BGP Flowspec with SRv6 Policy [Yisong Liu]
          (10 mins)
            https://tools.ietf.org/html/draft-jiang-idr-ts-flowspec-srv6-policy/
          [Jeff]: As an author of the redirect IP draft,
          since you are specifying more than one community
          you need to be careful how this interactions.
          [Kaliraj Vairavakkalai]: How does this work with the
          inter-domain case?
          [Yisong]: We'll consider this information in
          future drafts.
          
          
          ### 6. BGP-LS Extensions for Advertising Path MTU [Yongqing Zhu/Shuping
          Peng] (10 mins)
            https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/
          (Shuping Peng presenting)
          WG Adoption called for by authors.
          
          Ketan: The draft is a trill draft that describes RFC7176.
          [missing the response from shuping so notes get text from Shuping]
          Ketan: Thank you for the clarification
          
          Jeffrey Haas: Shuping, with regard to the link MTU draft, I think it's
          a useful feature.
          However, I would suggest the document provide a warning that this is the
          signaled MTU which may be different in bad cases from the actual MTU.
          this is usually from configuration mismatches in a control plane and
          a data plane component.11:04:57
          
          
          Tom Hill: +1 Jeffrey & Ketan - there are many "MTUs"11:06:25
          It is otherwise not a bad idea11:06:49
          Jeffrey Haas: IMO, having a way for probed MTU to be published
          in bgp-ls is a nice feature.11:06:52
          but since once of the pathological cases is
          LAG with mismatched MTU component links...11:07:18
          
          Takuya Miyasaka: The title of this document is confusing.
          I think it should be [BGP-LS Extensions for Advertising "Link"
          MTU]. 11:08. 11;
          
          Shuping Peng
          @Jeffrey, thank you for the comments. Your concern is acknowledged
          and we plan to add it in the next version.11:12:07
          
          Alvaro Retana: @Ketan: The registry shows that the sub-TLV applies
          to the "normal" TLVs: 22, 23, etc.. It seems to me that we should be
          ok.11:12:10
          
          Ketan Talaulikar: @ Alvaro : yes we should ok
          
          
          ### 7. BGP Classful Transport Planes [Kaliraj Vairavakkalai] (15 mins)
            https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes/
          
            (kaliraj Vairavakkalai presenting)
          
            Robert Razuk: Today transport class can be embedded in the SID.
            Here we are opening it up to explicit signalling ... I understand
            you may want to support RSVP TE but not sure if this
            extra complexity is really needed.
            (read by Sue)
          
            [chat room:
            Jeffrey Haas: Robert, while it can cover such a scenario, this draft
            supplants the problems we were trying to solve in the prior
            labeled-color-unicast draft.11:21:09
             So, a degree of similar flexibility is desired.11:21:19
          
            Robert: @Jeff: I like the new SAFI sepration if we go for that ..
            I recall the BGP 3107 discussions about it too. Just not sure we
            still need it if we are up to SR everywhere paradigm
          
            Kaliraj: Works with other deployed technologies for
            tunnels we have. It is good to have a layer which
            I'm not sure if you are referring to
            Jie Dong: Policy has a color and and nlri.
            Are you transferring color as a SR-TE tunnels?
            [Kaliraj]: The color is the transport color of that
            tunnel.  We will create a transport class with
            a color so that it fits seamless into the SR-TE tunnel.
            [scribed missed a portion of text]
          
            [Jie Dong]: I will take up more on this topic online.
          
          
          ### 8. (If time allows) Controller Based BGP Multicast Signaling [Jeffrey
          Zhang] (5 mins)
            https://tools.ietf.org/html/draft-ietf-bess-bgp-multicast-controller/
             John: By the careful help of the presenters and
              by some miracle we have time for the last presentation.
            (Jeffrey Zhang presenting)
            [request early allocation for the code points ]
            John Scudder: The "any encap" would you be able to
             use a multiple next hop mechanism in BGP.
             The controller want you to replicate across 2 tunnels.
          
             Jeffrey: For one down stream ways to get to a down
               stream node, go through any of the 20 tunnels.
          
             John: If we had a way to represent 20 next hops,
              you would have used it (observation).
              The load balancing tunnel is not limited to multicast.
          
            Jeffrey: The load balancing concept introduced for
             multicast purpose. There seems to be an existing
             tunnel for the load-balancing of unicast.
              [missing a portion of the discussion.
          
          John: The programming incoming packet handling.
             The whole model that tunnel-encaps used is that
             you send information regarding the head of the tunnel.
             Your drafts talk about the tail of the tunnel.
          
          Jeffrey: Can you provide a bit more information on the
           tail end?
          
           John: ingress is head ends, and egress is tail end.
          
           Jeffrey: The route sent to all points.  For the route
            sent to the egress point, it is for the
          
           Kaliraj: This is a reserved layer.
          
           Jeffrey: This gets to beyond the tunnel encapsulation draft.
           We are talking about controller signaling.
           Every router will use the same label.  That
           label will be assigned by a controller.
          
           Kaliraj: Like from a static route configuration.
            To John, we did propose multiple next hops for a bGP route.
          
            Jeffrey: Could we use tunnel encapsulation instead of
            multiple next hops.
          
            Kaliraj: This draft is giving a specific tunnel endpoint.
            Your draft is slightly different.
          
          
          
          
          ### 9. WG adoption calls requested
          
            https://tools.ietf.org/html/draft-qin-idr-sr-policy-ifit/
            https://tools.ietf.org/html/draft-zhu-idr-bgp-ls-path-mtu/
          
          ###
          #### [5 minutes for switching]
          
          



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