intarea working group
IETF 87
Friday, August 2,2013
1120-1330 Friday Afternoon Session I & II
Minute takers (Thanks!!!): Scott Brim and Jaqueline Queiroz 

== WG and Document Status ==

Suresh presented the wg document status and there were no changes to
the agenda.

== Implementation Status Experiment ==
RFC6982
Presenter:  Brian Haberman

Main goal of this RFC is to raise awareness of existing
implementations (by adding an implementation status section in
Internet-drafts). The authors encourage people who work on protocol
specifications to document implementations developments. Brian
highlights that this section will be removed before RFC is
published. Brian encourages people to read the document and use it as
much as they can.

No questions or comments from the room.

== A Fragmentation Strategy for Generic Routing Encapsulation (GRE)==
draft-bonica-intarea-gre-mtu-02
Presenter: Carlos Pignataro

Goal is to, first, share with implementors fragmentation strategy for
GRE and second goal is to provide users/operators with information
about how it works. It does not update RFC2784, and it concerns
point-to-point GRE only. It starts with different options for
fragmentation strategies. Authors want more reviews, inputs and
comments on this document.

Lars: are you following guidelines like handling ECN with fragments?
There are rules to deal with ECN when you fragment. There are generic
text and if it works for you should only point it. (RFC3168 & RFC6040)
Carlos: will take a look.

Suresh: No sense of the room taken, as not many people read the
document. Request volunteers to review the document. (Scott Brim, Dave
Thaler, and David Black volunteered).

== A Framework for Signaling Flow Characteristics ==
draft-eckert-intarea-flow-metadata-framework-01
Presenter: Toerless Eckert

First, a demonstration of how to reboot a Mac.

Many related drafts exist - see cover slide of presentation.


David Black: How planning to use RSVP? Are you anticipating that every
router will speak RSVP or just smart/service nodes?

Toerless: is a open question- some routers must speak RSVP. If other
routers don't speak RSVP we need a way to speak to them.

David Black: wants Toerless to think about whether RSVP is
appropriate.

Toerless: no problem deploying RSVP on all routers in enterprise, but
not in broadband access.

David Black: Has concerns about the use of RSVP. He does not want to
use it to signal DSCPs. RFC4594 describes configuration guidelines for
service classes.  Go back and look at service classes, think about SIP
service classes, try to get to one service class model.

David Black: if you really get to the point of needing to signal
something lower level (might not need to), don't signal DSCPs unless
you have a low level protocol like RSVP that you know is going
hop-by-hop and will be picked up by everyone who might remark the
packets.  Don't signal DSCPs over the top.  Maybe start with rfc 3140.
But start with service classes.

Toerless: Welcomes the terminology beating. and agrees that DSCP is a
bad thing to signal, and thinks service classes are even too specific
for applications.  Wants advice on what apps should send. Maybe a
"service label" (??).

David Black: If start by thinking you need to signal bandwidth, you
will eventually arrive at RSVP Tspec.  Apps don't want to signal
Tspecs.

Toerless: start with first step, just look at capacity
planning/management.  Don't get down to buffer management.

David Black: OK but start with Tspec, it reflects what routers need.

Lars Eggert: This presenation made my head ache.  It contains many bad
ideas.  Where is the "internet" in this?  Why did this get agenda
time?  Thank god NSIS is gone.  No technical comments, his head
exploded.

David Black: Lars is disagreeing with your assumptions and assertions
of the nature of the problem and how it behaves on the network. I see
lots of handwaving.  But I'll wait and see how holes are filled in.

Toerless: We have running code that solves customers' problems. Want
to know how to leverage protocols. Want to leverage network services
through simple policies.

Suresh: Is this an intarea topic?  No.  It is more like a tsvarea
topic. The draft was discussed on the mailing list and this was a
chance for the draft authors to present the relevance to intarea.

David Black: this was brought to us, we took one look and decided it
was not appropriate or ready.  Couldn't give specific answers yet. You
need to decide What do you want to do and how before bringing it back
to tsvarea?

Linda Dunbar: congestion conflict scenario - why not just use
priority?

Toerless: at which point in time do you know which has the higher
service requirement?  Sometimes there are different instances of an
app that have different priorities.  And have policy decisions made
once and embodied in network in the future.  This app, from this
device, from this user.

Linda: That doesn't require metadata, could just signal (put it in
control plane). Don't need to carry anything in the data packet.

Toerless: metadata is not carried in every packet, want to send
attributes relevant to the applications with a protocol (our
implementation use RSVP).

Suresh: I still don't see what's the relevance to intarea? If none,
where should it go?

Michael Ramalho: Nobody uses RSVP.  Toerless is presenting a real
problem, real users have that problem.  We don't care how we do it but
we need this communication.

Wes George: Suffers from SDN disease. We have the problems but not a
good sense on how to solve it yet. The reality in order to better use
the network or improve customer experience is that there is a missing
link which is the link between the application and the network. Think
its the right place for that because of the interaction with the
network side.

David Black: still a lot of handwaving going on, and "bandwidth" is
one of those.  Start with t-spec, services at the top, figure out what
to do in the middle.  Learn from history.

Toerless: why IntArea?  The most compatible thing we have is naming
objects, and that's DNS.  Might come up with right data model and
interfaces.

Lars Eggert: Every ten years there is an effort to improve Internet,
if we could specify the needs of the flows and signal it. Tried
several times and it doesn't work. It may work for some specific
applications but doesn't seem to scale. We've tried again and again
and nothing stuck. Compare with NSIS.

Toerless: we've learned things, making it more lightweight and make it
work for limited control networks.

Lars: in NSIS every flow needed to signal and stick to what it said.

Toerless: but there are a lot of easier options.

Henning Schulzrinne: long term participant in NSIS and FCC.  The
problem is users already routinely don't understand why the network
doesn't work, don't trust providers.  The protocol is not the problem,
it's the human business aspects e.g. how much do I pay for what?

Amin Choukir, co-author: clarification: signaling services from apps
are important but must have a controlled environment.  They are not
proposing uncontrolled signaling, but the characteristics of the
traffic, and the policy is left to the network.

Mike Ramalho: this is the right place, it's solving a real problem
with real user.  Don't punt to research group, right now we're doing
things in a much less secure much less trusting environment to meet
needs.  If it's not here where is it in non-research?

Suresh: Nobody is saying it's not a problem, but the question is
whether it is an intarea problem?

Charles Eckel, co-author: provides better visibility.  Everyone might
be able to learn something.  We have an early version of running code.
Visibility itself is valuable.  QoS is one example of something you
_might_ be able to do.

Wes George: just because we've seen this before doesn't mean we
haven't learned and can't do a better job this time.

Scott Brim: (1) You could do this purely in the management plane. (2)
it's not ready for TSV, it's not appropriate here but you want a home,
try ICCRG.

Suresh: intarea can't do anything for you except to offer a place to
discuss it.  The only INT area thing in the proposal is "PCP".
Explain why it should be here?

Ted Lemon: First, what Suresh said.  It's a question of who can work
on it.  Not here.  Please go away, answer all those questions, and
that will clarify where it should be worked on.

David Black: for TSVWG: when this all works out they are interested in
being the downstream recipient for specifics in protocols they
actually work on.  It should go where there is expertise in
information modeling.  He wants a model of what to signal, and why
it's coherent.  That's not TSV, it's not INT.

Toerless: yes lots of questions around bandwidth that TSV is expert
on.  They presented in IPFIX.

David Black: wants a big picture, top down, how it fits together.

Suresh: why not in TSVAREA?  

David Black: because we're not information modelers.  Toerless is
starting from applications and working through interactions of a
number of other elements.

Toerless: management might be a good start but need the specifics.

David Black: first attack the big modeling problems, and we are
downstream, don't start with our nuts and bolts.

Bob Hinden: Leave it here, if you can convince this group the rest is
easy.

Ted Lemon: in previous attempts the source of the information was a
big problem.  You have ideas of how to source the information, stress
that as a good step.

Suresh: Take the discussion to the list and see where it goes.

==  Stateless user-plane architecture for virtualized EPC ==
draft-matsushima-stateless-uplane-vepc-01
Presenter: Ryuji Wakikawa

Hui Deng: <Please fill in your comment here>

Linda Dunbar: use I2RS? Change routes in routers for special
applications?

Ryuji: yes close to I2RS but now we have BGP.  If had I2RS it's okay.  

Suresh: Linda please send email to the list so they can respond.

Dapeng Liu: normally they put internet peering point at VEPC and data
traffic goes there anyway, no need for this.

Ryuji: peering point is elsewhere.  

Suresh: Different mobile operators have different kind of
deployments. Perhaps worth tightening up the applicability. Please
discuss this offline.

Lorenzo: Are you proposing this for IPv6 or IPv4?

Ryuji Wakikawa: IPv6 (we have some sections IPv4)

Lorenzo: Could you virtualize EPC and use this same scheme for IPv4?

Ryuji Wakikawa: we tried to run IPv6 and run IPv4 on top of it

Satoshi: independent of hardware, operators can choose from many
different equipment without picking dedicated hardware. It should be
discussed in the IETF.

Alex Petrescu: Support. In past there was effort doing mobility
protocols, some problems with what's out there.  Using a routing
protocol takes care of some drawbacks. As presented seems focused on
cellular operator. Could it be used in other contexts?

Ryuji: yes, 3GPP is the reference scenario. Could use with wifi for
example.

Peter McCann: Likes it. Thinks there should be a BCP for using iBGP
for mobility in an access network.  Need a generic link layer
interface.  Need a mobile identifier, a set of prefixes assigned to
that mobile node -> generalized document.

Suresh: Please discuss it further in the list.

6. Issues with IP links in spontaneous wireless networks
draft-baccelli-manet-multihop-communication-02
Presenter: Charles Perkins

Suresh: Why is this work not being done in MANET? Should the Internet
adapt to wireless links or should the wireless links adapt to the
Internet.

Alex Petrescu: interesting. good slide about problem statement. But
have a feeling is link to routing protocols developments or is it
something like ip-over-foo kind of work?

Charlie: Not exclusive to either. This draft is relevant about the
characteristics of wireless communication that may nor may not work
well for links.

Emmanuel: why not done in manet? various debates around what describes
the draft was done in roll, manet. These issues just keep popping up
in various WGs that works on spontaneous wireless networks.  It
doesn't only have to do with manet.

Carsten Bormann: we solved this in 6lowpan.  Does the node adapt, does
the internet adapt?  The answer is both.  Can't rely on multicast
being available. Need to hack ND. e.g. 6lo wants to work on Mesh Link
Discovery Protocol. 

Suresh: Carsten will you provide a review? (Carsten said yes.)

Erik Nordmark: intarea is reasobnable place to be and propose to review.  

Suresh: Erik will you provide a review? (Erik said yes.)

Scott Brim: This draft addresses some fundamental questions, so it is fine
to bring here if other WGs don't want it.

7. Scaling ARP for large data centers
draft-nachum-sarp-06
Presenter: Linda Dunbar

Suresh: Not clear what to do with this draft. It has been presented
multiple times, and each time it has been updated to meet
comments. How many people have read this draft?

Suresh: Only 5 persons have read the draft. Not really useful to seek
the sense of the room. We will start the adoption call in the list and
see what happens.

END OF MEETING