Minutes IETF103: intarea
minutes-103-intarea-00

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.