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

Intarea Status Pages

Internet Area Working Group (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2010-Mar-23 —  
Chairs
 
 


IETF-103 intarea minutes

Session 2018-11-07 1540-1710: Chitlada 3 - Audio stream - intarea chatroom

Minutes

minutes-103-intarea-00 minutes



          IntArea WG Agenda
          IETF 103 - Bangkok
          15:40-17:10        Wednesday November 7th, Afternoon Session II, Chitlada
          3
          
          Chairs:
          Juan Carlos Zuniga (SIGFOX) (JCZ)
          Wassim Haddad (Ericsson) (WH) - not present
          
          Minutes: Ian Farrer
          Jabber: Mikael Abrahmsson
          
          1. Agenda Bashing, WG & Document Status Updates (Chairs)
             10 minutes
          
          2. Discovering Provisioning Domain Names and Data, Eric Vyncke (EV)
             draft-ietf-intarea-provisioning-domains-03
          
          Ian Farrer (IF): You can change the rfc3633 ref to 3315bis as this is
          going to be published soon.
          
          
          3. IP Fragmentation Considered Harmful, Ron Bonica (RB)
             draft-ietf-intarea-frag-fragile-02
          
          David Black (DB): In Transport Area WG were working on UDP options. It
          could be used for fragmenting UDP at the UDP level.
          In discussion this morning, we were uncertian about the vaule. I sound
          like this is a reommendation to stop using fragmentation.
          RB: UDP fragmentation solves my problem
          DB: I believe it does
          Mikael Abramahson (MA): I think it does. The problem is not fragmention
          itself it's that there is not information in every packet.
          RB: A recommendation to middle box devs to handle this
          MA: I was looking for a MUST to get middlebox devs, but were not the
          protocol police. I think this is a reasonable compromise.
          
          Fred Baker (FB): I'm not sure UDP frag solves your problmem. You've got
          TCP fragmentation. It only helps if know what the path MTU is.
          
          Suresh Krishnan (SK): We need a way to expose the path mtu to the upper
          layers. That needs to be specified somewhere.
          Erik Kline (EK): There's a sentance about it
          SK: I don't know how that's going to happen. We need to see how this is
          going to be implemented. You need to handle changes across the paths. I'm
          happier with the
          second recommendation than the first one.
          It's a decision for the Transport Domain if they want to do it. That's
          what I think.
          
          JCZ: You have to care about the application and the developer.
          RB: It's a variant of Postel's Law - conservative send, liberal receive.
          
          EK: 7.4 says be standards compliant. Is it worth saying that operators
          should set the right MTU on their links?
          MA: There are ways of seeing this at the moment. It's good for devs to
          include this.
          
          RB: It would be good to have a one liner saying that this interface
          should exist and define it elsewehere.
          
          Corry Fairhurst (CF): -missed-
          RB: What area should that live in?
          SK: I think the answer until today has been 'not in the IETF'. We've
          pushed it POSIX or wherever. I think that DT would say we can write an
          abstraction for this.
          Dave Thaler (DT): Where does the discussion belong? TAPS
          Does the IETF do abstract or concrete? TAPs for abstract. POSIX etc. for
          concrete. I'm the liason for this. All they are talking about is the
          boost(?) style APIs at the moment.
          If there are things we want the community to do then I can post that.
          
          CF: There's 2 different sizes of MTU. We need to be careful that network
          isn't making 1 dicision and transport another and app another. We need
          an API.
          RB: We're just saying that we need a solution, not what the solution
          should be.
          CF: Be careful what you put in the socket layer. Maybe the application
          can do this?
          DB: This just says it happens at a higher layer.
          
          RB: I think the action is a recommendation for a new interface, and a
          sentance from EK.
          
          DB: I agree with CF about not refencing UDP fragmentation in the draft
          
          
          4. GUE update, Tom Herbert (REMOTE) (TH)
             draft-ietf-intarea-gue-06
             draft-ietf-intarea-gue-extensions-05
             draft-herbert-intarea-gue-ctrl-messages-00
             draft-herbert-tsvwg-gte-00
          
          ** TH's video link dropped shortly into the presentation and wasn't
          completed or able to respond to the comments **
          
          CF: As TSVWG chair I didn't get why it was being proposed. TSVWG is in
          the title and this is what TSVWG does. Please talk to us about it.
          SK: I think we did is say this was a 1 off document. Now there's 4. If
          it becomes a protocol suite, it doesn't below here. If TSVWG wants to
          take it....
          CF: I wanted to comment on it!
          Whether we need another encap protocol. We need a BOF etc.
          SK: If there's a significant amount of work, we need a BOF. this is not
          the right place for it
          We can talk off line.
          
          
          5. Limited Domains and Internet Protocols, Brian Carpenter
          Presented by Bing Lui (BL)
             draft-carpenter-limited-domains-04
          
          EV: Maybe I missed the concept of domain, but when I see 'join domain',
          it could just be my old laptop talking to my new laptop. Or did I miss
          the meaning of domain?
          BL: It may be geographic, it may be logical. Thres' two models. In your
          case it's the network
          EK: If you have domains next to each other it may be overkill.
          BL: We need to make the definition more comprehensive.
          
          DB: We wrote RFC8085 which defines a 'controlled environment'.
          It sounds like you're saying when I get away from geographical alignment,
          you've got an overlay network.
          For controlled environment, we used common mangemanet & admin, like an
          AS number as the definition
          BL: I belive that there is an overlay here. I don't know the controlled
          environment. Maybe we need an explicit defintion as options or metadata
          in the protocol. Currently, it's
          always out of band.
          DB: I think I agree you need to sort out the overlap between limited
          domain and controlled environment. I offer to help.
          
          EK: This looks like a way to get execptions for things you otherwise
          wouldn't be allowed to do. Sometimes things jump domains. I don't think
          I agree philiosophically that this is
          a good idea.
          BL: -missed-
          EK: Not really
          
          DB: It doens't have to be both. Exapmles are MPLS over UDP which has to
          be run separatedly and GRE over UDP. We needed controlled environment
          to get those done.
          EK: That sounds like administrate domains
          DB: Yes, it relies on network admins to know what to do and when things
          are going wrong.
          EK: This is a superset of -missed-
          DB: I agree there's a relastionship. I defer on if it's a superset or
          subset
          
          SK: I think we need more eyeballs on this. It affects a lot of
          areas. Maybe a BOF? It needs to be looked at.
          BL: I think that's a good idea.
          
          Ruediger Volk (RV): All examples were at low network layers. These can
          also happen at higher layers. This is a wide field and I don't know it
          can be controlled.
          BL: This is based on some fact in the Internet and we need to consider
          it.
          RV: Are you giving any examples of what you're concerned about?
          BL: There are example, but they might not show that there is a trend. I
          cannot prove that the trend is happening.
          RV: The hints that I'm hearing are that if you have well structured
          systems there are infinite ways to break the structure. If one allows
          people in the wild to
          do whatever they want, you get trends like this. It's not a trend you
          want to support.
          BL: I understand.
          
          6. IPv6-based discovery and association of Virtualization Infrastructure
          Manager (VIM) and Network Function  Virtualization Orchestrator (NFVO),
          Carlos Jesus Bernardos Cano
             draft-bernardos-intarea-vim-discovery-00
          
          Not presented
          
          
          7. User-Plane Protocols for MultipleAccess Management Services (MAMS),
          Jing Zhu (REMOTE) (JZ)
             draft-zhu-intarea-mams-user-protocol-06
          
          SK: I'm trying to understand your end goal. The framework doc. has been
          submitted independently for publication. Where is this is this going?
          ZK: We want to bring this one into the communiy to define with the
          convergence layer.
          DK: My issues is that there is a lot of work to do. This isn't the home
          for this. Come to me or another AD for a BOF. The scope of this is huge
          from the framework. Let's
          talk about the future.
          ZK: Yes. I want to mention that the convergence layer isn't limited to
          MAMS. We introduce a new convergence protocol. We want to know how to
          owrk together with IETF on this.
          
          
          8. Overlayed Path Segment Forwarding (OPSF) Problem Statement, Yizhou Li
          (YL)
             draft-li-tsvwg-overlayed-path-segment-fwding-ps-00
          
          EK: If you name this with an acronym so close to OSPF, it's confusing.
          YL: We noticed that.
          
          9. SOCKS Protocol Version 6, Vladimir Olteanu (VO)
             discuss draft-olteanu-intarea-socks-6-05
          
          SK: How do you want to progess it? Here or AD sponsoered?
          YL  I'd like to standardise it.
          SK: Talk to me.
          
          



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