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

Rtgwg Status Pages

Routing Area Working Group (Active WG)
Rtg Area: Alvaro Retana, Martin Vigoureux, John Scudder | 2004-Feb-19 —  
Chairs
 
 


IETF-110 rtgwg minutes

Session 2021-03-11 1700-1900: Room 7 - rtgwg chatroom
Session 2021-03-12 1700-1900: Room 5 - rtgwg chatroom

Minutes

minutes-110-rtgwg-00 minutes



          IETF 110 Routing Area Open Meeting (rtgarea)
          Joint with RTGWG
          
          =====================================================
          
          Routing Area Directors:
               Deborah Brungard (db3546@att.com)
               Alvaro Retana (aretana@futurewei.com)
               John Scudder (jgs@juniper.net)
               Martin Vigoureux (martin.vigoureux@nokia.com)
          Web: https://datatracker.ietf.org/group/rtgarea/about/
          
          
          RTGWG Chairs:
               Chris Bowers
               Jeff Tantsura
          
          WG Page:    http://tools.ietf.org/wg/rtgwg/
          Materials:  https://datatracker.ietf.org/meeting/110/session/rtgwg
          
          
          Date: THURSDAY, March 11, 2021
          Time: 1700-1900 Session III
          
          
          RTG AREA Meeting
          
          1   17:00   15m
          Administrivia:
            - Note Well
            - Blue Sheets
            - Agenda Bashing
            - RTG Area Update     Routing ADs
          2   17:15   35m
          WG updates:
          •   PALS
          •   MPLS
          •   SPRING
          •   DETNET
          •   RAW WG Chairs
          3   17:50   10m
          Open Discussion / Any other business
          
          ******************************************************************
          ******************************************************************
          
          RTGWG Meeting
          
          1   18:00   10m
          Challenges for the Internet Routing Infrastructure Introduced by
          Changes in Address Semantics
          https://datatracker.ietf.org/doc/draft-king-irtf-challenges-in-routing/
          Adrian Farrel
          
          Linda:    semantic address, what is it? is it still IPv4 or IPv6?
          Adrian:   what we see is adding semantics to IPv6 address. we might
                    see new address space run ships in the night, but not sure
                    it's my focus beyond what happens beyond IP routing.
          Linda:    what kind of semantics are you adding?
          Adrian:   we're collecting proposals. we want to research around those
                    rather than pushing individual proposal.
          
          
          2   18:10   30m
          Application Aware Networking (APN)
          https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis
          Shuping Peng
          
          Linda:    one comment, in MEF SDWan project, there's a section on
                    application based segmentation. They have a use case of
                    retail payment system, that payment system can only be mapped
                    into certain topology, virtual topology, versus other
                    application can be mapped to other topologies. I think
                    that'll be very useful to use APN concepts.
          Shuping:  would you please post it to mailing list?
          Uma:      Thank you for the presentation. it's good to know that it
                    starts from edge device, it's not limited to any data plane,
                    correct?
          Shuping:  Yes.
          Uma:      multiple WGs are discussion slicing, are you touching slicing
                    issue? or just general QoE?
          Shuping:  it's a general solution. Network slicing could be integrated
                    with a VPN, so mission critical traffic could be steered into
                    the dedicated network slice. That could be one of the use
                    cases of APN.
          Uma:      if it's to be done in IPv6 data plane, is it going to be
                    SRv6 or other extension header?
          Shuping:  If it's IPv6, we could use hop-by-hop header, destination
                    options head, SRH and SRH TLVs. All those cold be sued to
                    encapsulate this information, not new hop-by-hop header. We
                    want to make the hop-by-hop header really usable for the
                    operator because it carries lots of key features and new
                    services. After presenting in V6OPS, it has been agreed by
                    the community and chairs. So the problem statement has been
                    agreed upon.
          Zhenbin:  People in the security area and APP area are not understanding
                    the uses cases that always used in the routing area. The first
                    question asked is how to map to app group or user group at a
                    network edge? We can use five tuples. Second they don't
                    understand why 5 tuples can be used directly? In transport
                    network, there are SRv6 tunnel, MPLS tunnel, so the five
                    tuples of the original packets is not visible in the network.
                    Last question why not copy the five tuple information?
          Kausik Majumdar: I'm wondering how APN hdr would be integrated with
                    MPLS or IPv4 data plane.
          Shuping:  that's based on solution and we'll figure out later.
          Zhenbin:  Just to add a point, for MPLS, there is extension header
                    here. On Friday, there will be joint meeting to discuss extra
                    information in MPLS data plane, and we might be able to use
                    special purpose label to indicate extension information below
                    the label stack.
          
          
          -----------------------------------------------------------------------
          
          IETF 110 RTGWG Agenda – Session II
          
          Chairs:    Chris Bowers
                     Jeff Tantsura
          Secretary: Yingzhen Qu
          
          WG Page:    http://tools.ietf.org/wg/rtgwg/
          Materials:  https://datatracker.ietf.org/meeting/110/session/rtgwg
          
          Date: Friday, March 12th , 2021
          Time: 17:00 -19:00 UTC + 1
          
          1 17:00 15m
          WG update Chris/Jeff
          
          
          2 17:15 15m
          The Integrated OAM
          https://datatracker.ietf.org/doc/draft-mmm-rtgwg-integrated-oam/
          Greg Mirsky
          
          Rakesh Gandhi: there is a similar draft in BFD, is it related?
          Greg:       this one replaced that draft.
          Rakesh Gandhi: it was not clear combining RFC 6374 and BFD, what
                      requirements are addressed. It was discussed in BFD WG.
          Greg:       First to reduce number of OAM protocols need to be
                      supported. Second is to make it light weight. BFD runs at
                      hight interval rate, but the performance measurement
                      doesn't need high rate. The draft has more details of
                      motivations. Protocol like RIFT, already provides infra
                      supports that continuity. It might be nice feature to
                      complement it with the performance monitoring.
          Rakesh:     there is work in SPRING going on. we need to compare with
                      other work in other WGs.
          Greg:       I know you're referring to SR PM work, it's too heavy for
                      continuity. It was not designed at high rate, like 3.3 ms.
                      We're proposing different approach to this problem. what
                      we're doing is try to solve it differently. There is real
                      need to have integrated OAM work. Let's discuss more on
                      which approach is more realistic.
          Cheng Li:   Do you want to extend BFD?
          Greg:       what we're proposing here won't be on top of BFD, more for
                      a new protocol inheriting the best features of BFD, like
                      negotiation. This is not extended BFD, to remove confusions,
                      we marked this draft as replacement of the extended BFD
                      draft. The resulting protocol will be similar to BFD, but
                      not extension to BFD.
          Cheng Li:   we have another proposal that will be presented later.
          Ville Hallivuori: you have this algorithm of negotiation for security
                      and that's about a decade old. The draft says you don't
                      have authentication.
          Greg:       we appreciate comments and open to suggestions. We can
                      discuss more on the list. Different node can be upgraded
                      at different level is more flexible approach. Your
                      suggestion of mandatory security probably the right way.
                      We need to understand more.
          Jeff Hass:  as BFD chair, It's worth noting that we had long
                      conversations with Greg, about could we put this inside of
                      BFD. his slides makes a good point that what we're doing
                      is we're leveraging BFD like mechanisms, the properties
                      that are sort of liked BFD is being able to carry out
                      information from one system to another in a periodic
                      fashion. We do know that BFD is capable of doing that in
                      terms of its protocol machinery, but we're sort of diluting
                      the core mission of BFD in terms of providing continuity
                      checks at speed. So we did suggest that Greg actually
                      leverage the mechanisms from the BFD for those new
                      mechanism. So, some extent to answer Fan/s question in the
                      queue, we did discuss putting this in the BFD, it's not a
                      great fit. At least in terms of the core protocol. but
                      we're quite happy to see the mechanism that the BFD has
                      popularized carried it to the rest IETF for other purposes.
          Fan Yang:   I see you mention path MTU monitoring here, is it any use
                      case for using OAM to do path MTU discover and monitoring?
          Greg:       normally this is part of OAM functionality. For example,
                      MTU discovery in BIER that uses LSP ping extension. it
                      could be done on demand or periodically. in BFD, there is
                      demand from operator to monitor MTU. I do believe MTU
                      discovery is part of OAM responsibility.
          Fan:        since you mentioned BIER, what data plane do you plan to
                      use this integrated OAM?
          Greg:       appreciate this question. our goal is first to define the
                      protocol, then make it applicable to all data planes. Like
                      BFD supports all sorts of data planes.
          Rakesh Gandhi: One comment is that with automation and controller, and
                      SDN are fairly advanced these days. The we are doing less
                      and less control plane tunneling and extensions to simplify
                      the control plane. So I think the simple SDWAN is a perfect
                      example of how controller can be used for such use cases.
                      So here in this signaling extensions going in a different
                      direction.
          Greg:       I don't believe so. I don't see that there is anything
                      precluding to have Yang data model for integrated OEM
                      protocol, and then use a centralized controller to
                      instantiate test sessions, whether pre active or on demand
                      as operator desire. so I don't see any contradiction. Let's
                      take it to the list.
          Jeff T:     the questions, especially with regards to BFD extensions,
                      please send to the list, and Greg would be addressing them.
          
          From Chat:
          Rakesh Gandhi
          Not sure how this draft:
          https://www.ietf.org/archive/id/draft-mmm-rtgwg-integrated-oam-00.txt
          -> relates to this draft in BFD WG.
          https://tools.ietf.org/html/draft-mirmin-bfd-extended-03
          Fan Yang
          why not extension on BFD, I couldn't get it.
          Jeff Tantsura
          @Fan - please send your q to the list
          Jeffrey Haas
          Jeff T, I'd be speaking to that in my comments if I get mic time.
          Fan Yang
          I suppose we should have enough time in this session, so a little bit
          long q is OK :-)
          Rakesh Gandhi
          Seems like combine BFD and RFC6374 to create a new BFD+ protocol
          Jeff Tantsura
          Thanks Jeff
          Jeffrey Haas
          When protocols become popular, people want to extend them. Sometimes
          the extensions are good fits, sometimes not. But it's good to leverage
          ideas elsewhere even if you don't put it into the same protocol.
          See for example various efforts to put stuff in DNS, BGP, etc.
          Tony Przygienda
          Curse of success ;=)
          John Scudder
          There's always the tension between dump truck protocols vs cut-and-paste
          protocols.
          See also the microservices pendulum.
          Jeffrey Haas
          Indeed. Greg now perhaps inherits the dump truck keys.
          John Scudder
          Complexity will get its pound of flesh no matter what we do.
          Jeffrey Haas
          The question now moves from "what is so important that you want to
          hear every 3.3ms" to "here's interesting stuff in a periodic basis
          that you do want to hear - now how to do we pick our timers for that?"
          Jie Dong
          Comparing to existing BFD + RFC6374, what is the benefit of this?
          Jeff Tantsura
          Jie - please send to the list
          Tony Li
          @jgs No, we fight it. Forever.
          Jie Dong
          ok
          Jeffrey Haas
          Eternal disappointment
          Jeff Tantsura
          life isn't fair...
          John Scudder
          @tli, sorry for the defeatist formulation. There's probably a gif from
          Braveheart that would apply here.
          Russ White
          state, optimization, surfaces ... choose two
          
          
          3 17:30 15m
          Data Discovery Use Cases
          https://datatracker.ietf.org/doc/draft-mcbride-data-discovery-use-cases/
          Mike McBride
          
          Joel Halpern: This is confusing. There's already a proposal for how to
                      do SFC service function discovery if you're using
                      distributed system, but it's aimed at make sure that the
                      classifier know where the SF are. Fundamentally SFC is
                      designed for cases where the application, external for
                      classifier function is not choosing the service function.
                      And there are controllers can discover the service
                      functions. This problem is well attacked, I have trouble
                      with this example.
          Mike:       you can have a controller taking care of it. If there is
                      already solutions, that's great. Is that you're saying this
                      particular application has already been solved.
          Joel Halpern: It doesn't need a whole new tack on the problem.
          Jim Guichard: I'm aware of the service function discovery document.
                      This is just a example what kind of data we're talking
                      about. SFC is obviously one of those, it gives a picture a
                      particular data store and we'd like to be able to
                      dynamically discover it.
          Joel Halpern: I get the general need to discover functions, whether
                      that falls into IETF is a whole different debate. SFC is
                      just a bad example, I'm not objecting the underlying
                      problems that Mike is talking about.
          
          Jeff T:     Speaking as WG chair. This seems to be ocean boiling. do
                      you plan to narrow down your use cases to identify
                      consumer, publishers and how it's relevant to routing in
                      general.
          Mike:       Yes, the next step is to consider the solution part of it,
                      maybe a particular use case.  at the end of this ietf we'll
                      try to satisfy a particular problem that we've identified.
          Jeff T:     You should narrow down your problem statement, and make it
                      routing related.
          Mike:       understood. we're gonna think about what solution might
                      solve one of these problems and that will help us narrow
                      down the scope. So yes, we'll narrow it down.
          Jeff Hass:  this is boiling very large ocean. but the two general
                      notions that I think are the interesting ones. you're
                      looking at a general directory/Discovery Service to figure
                      out what are the interesting things I want to get. And over
                      your use cases you're getting the once I've decided that
                      I'm interested in something, how do I actually get it in
                      an efficient fashion that makes sense with the data. Is it
                      something that needs to be reliable? Is it something that
                      I'm willing to get periodic unreliable telemetry stream for,
                      and certainly the second piece of things is for IETF has
                      no good technologies for that sort of thing. We don't
                      really have the sort of dump truck subscription directory.
                      A thing from past history that I have exposure to is corba,
                      where you have basically objects of the system that you
                      may want to get state for and a directory mechanism was
                      created to get to the stuff and published have such things.
                      So I think that directory stuff may or may not itself be
                      within the context of IETF. The other items you have to
                      decide what the properties are you want and decide if you
                      actually have good distribution mechanisms that are fits
                      for technologies we already have.
          
          
          4 17:45 15m
          Associated Channel over IPv6
          https://tools.ietf.org/html/draft-yang-rtgwg-ipv6-associated-channel-00
          Fan Yang
          
          Greg:       it looks like a combination of two processes. one is error
                      detection end to end, second is protection switchover
                      coordination using remote defect indicator, this is not a
                      new problem. This has been solved using combination BFD
                      and protection control automation protocol. Another
                      question, UDP is becoming predominant transport, why not
                      use UDP? why IP?
          Fan:        If it's only signal degradation, BFD can't detect it 100%.
          Greg:       it's great you mention this scenario. You can look at
                      drafts in IPPM that address your scenario, how network
                      failure, packet loss and delay can be combined together.
          Fan:        let's take it to the list and discuss more.
          
          
          From Chat:
          Tony Li
          And now... we recreate FTP!
          Cheng Li
          Hi Tony, can you explain more? why this is similar to FTP?
          Tony Li
          FTP has a separate control connection.
          It's a huge security problem.
          Cheng Li
          oh?
          any link?
          Tony Li
          Specifically for firewalls....
          Cheng Li
          really good input, many thanks
          Tony Li
          https://tools.ietf.org/html/rfc959
          Cheng Li
          thanks, will go to know what is the security issues and other issues
          of FTP
          Joel Halpern
          @ChengLi the short version is that in order to get FTP through a
          firewall (or any security appliance really) the firewall has to examine
          the FTP control protocol payload to be able to recognize the data
          payload and allow it.
          Jeffrey Haas
          Similar issues exist in VOIP land.
          Tony Li
          Out of band control and management is a fine idea, but how do you
          securely associate the control/management connection with the data flow?
          Jeffrey Haas
          Especially if you need the data and control channels to share
          forwarding fate
          Cheng Li
          cool. It seems like this is a common issue.
          It may be worthy to address
          Fan Yang
          would it be better if the control message is carried with the data?
          ACH is in the IPv6 header, user data is in the payload ?
          Tony Li
          That addresses the association issue, but adds a huge cost in overhead
          per packet.
          That does nothing for other forwarding planes, also.
          Tony Przygienda
          There is no such thing as packet tax anymore dr li. That was atm ,=)
          Tony Li
          There are vendors who seem to be telling their customers that. It's a
          strategy to waste bandwidth and sell more line cards.
          
          
          5 18:00 15m
          IPv6-based Cloud-Oriented Networking (CON)
          https://datatracker.ietf.org/doc/draft-li-rtgwg-ipv6-based-con/
          Cheng Li
          
          Linda:      couple of comments. This draft covers lots of things. I
                      feel it's too big, maybe break into several drafts. For
                      example. public clouds have longer distance, and technology
                      needed for that is different from edge computing which is
                      local small domain.
          Cheng:      excellent suggestion, we'll follow up with you.
          Ron Bonica: what's the ultimate goal of this draft? are you building a
                      network architecture so network operators could implement.
                      or are you suggesting the development of some new routing
                      mechanism. if the former, is RTGWG the right forum? maybe
                      ops area.
          Cheng:      this is architecture draft. We're looking for gaps, we
                      need more inputs, and get new mechanism to address these
                      issues.
          Ron:        question to chair or AD, is it like OPS thing?
          Chris B:    we use RTGWG as open discussion platform. It has a low
                      threshold for presentations, but a significantly higher
                      threshold for adopting particular draft.
          Ron:        Fair enough.
          Chris:      we're not really in the context of adopting it yet.
          Jeff:       try to narrow down the scope and not boil the ocean.
          
          From Chat:
          Tom Hill
          Didn't flannel already implement this with VXLAN? :)
          Tom Hill
          'quick connect' VPNs over the Internet, between clouds
          Sorry the slides moved on
          I'm dual-wielding two WGs
          Flannel is quite commonly used already today, AFAIK
          Jeff Tantsura
          flannel (or any other VXLAN overlay) just provides an overlay encap,
          nothing more
          Tom Hill
          Indeed, but do you need any more? Flannel went out of its way to make
          that work, without the IETF porting a protocol to 'General'/cross-Internet
          usage.
          Fan Yang
          @Tom will look into flannel later. But flannel can only work for VXLAN,
          there are other more IP protocols, ACH can be used for any protocols
          on IP and native IP itself.
          Tom Hill
          I don't see the same effort to go further than the basic VXLAN
          featureset.
          Jeff Tantsura
          @tom VXLAN is a L2oL3 encap and perhaps the worse choice of all the
          encaps (generic ones)
          Jeffrey Haas
          RFC 2549 encapsulation is perhaps worse
          Cheng Li
          Hi @Tom,many thanks for your input. Do you have any link of Flannel?
          Interested in it :)
          Flannel is a simple and easy way to configure a layer 3 network fabric
          designed for Kubernetes.
          https://machinezone.github.io/resea…etworking-solutions-for-kubernetes/
          get some info from google, really helpful, will dive into it later
          Tom Hill
          No problem
          It may not be perfect, but it is definitely in use :)
          Cheng Li
          https://msazure.club/flannel-networking-demystify/
          
          
          6 18:15 10m
          SRv6 Midpoint Protection
          https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/
          Xuesong Geng
          
          Bruno:      Speaking as spring WG chair. The scope and goal is very
                      spring specific and the mechanism is a bit heavy on SRv6.
                      In spring, we have a document with the same scope for SR
                      MPLS, so I think this draft is better to be in SPRING. I
                      didn't see any email in the mailing list at spring.
          Xuesong:    we're confused where to put this draft. It's been presented
                      several times, to this stage we prefer to stay in RTGWG,
                      but we're willing to present in SPRING if necessary.
                      Considering TI-LFA is here, this document is informational
                      about the forwarding behavior. we'd like to hear chair's
                      opinion.
          Jeff T:     we had intentions to meet and discuss about six or seven
                      different about protections discussed between SPRING and
                      RTGWG. Let's postpone your question till we reach some
                      agreements.
          Chris B:    Your work so far is still useful since most people
                      attending this meeting attending SPRING as well. It's
                      positive to have SPRING chair say that he thinks it should
                      be over in spring because at least he thinks it's
                      important work. So I wouldn't be discouraged.
          Xuesong:    Happy to know that.
          
          From Chat:
          Bruno Decraene
          https://tools.ietf.org/html/draft-i…g-segment-protection-sr-te-paths-00
          Seem to have the same scope with the SR-MPLS data plane.
          
          



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