Minutes IETF111: apn
minutes-111-apn-00

# Application-aware Networking (APN) BoF IETF-111
Chairs:    Bob Hinden
           Daniel Voyer
           Adrian Farrel
AD:        Martin Vigoureux
Minutes:   Linda Dunbar
           Carsten Bormann
           Daniel King
           Shuping Peng

## Session Information
Friday, July 30, 2021
12:00 - 14:00 (PST) Session I (UTC-7)
Time Zone Converter:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=IETF+111+APN+BoF&iso=20210730T12&p1=224&ah=2
Room 5

## Useful Meeting Links
Materials:      https://datatracker.ietf.org/meeting/111/session/apn
Note taking:    https://codimd.ietf.org/notes-ietf-111-apn
Meetecho:      
https://meetings.conf.meetecho.com/ietf111/?group=apn&short=&item=1 Audio
stream:   http://mp3.conf.meetecho.com/ietf111/apn/1.m3u Jabber:        
xmpp:apn@jabber.ietf.org?join Jabber log:     http://jabber.ietf.org/logs/apn
Session ICS:    https://datatracker.ietf.org/meeting/111/session/28976.ics

## Useful Background Links
Related documents:   
https://datatracker.ietf.org/doc/search?name=apn&rfcs=on&activedrafts=on&olddrafts=on
Past materials:       https://github.com/APN-Community BoF Wiki description:
https://trac.tools.ietf.org/bof/trac/

## Agenda & Minutes

0. Administrivia
   Chairs
   5 mins (5/120)

Note that this is a working group forming BoF.
The intention is to collect material to assist the AD in his decision, to allow
the proponents to explain what they want to achieve, and to let the community
ask questions and give their opinions.

1. Aims and intentions of the BoF (Martin)
   AD
   5 mins (10/120)

Looking at:
(1) standardization work to do? in the IETF?
Do those use cases need IETF to standardize?
(2) what is the best way to achieve it? Is a WG the best way or not?
is there critical mass?
is there sufficient diversity of interest -- that is needed to make standards
robust

Proponents have done a lot of work and although the initial discussions may
have started in one direction, the proponents have made good progress.

2. What's in a name? Clarification of "APN"
   Chairs
   3 mins (13/120)

Long history behind the name. The function has evolved considerably since the
fist mention of the name. The name no longer fits the function. Please listen
to the proponents and make your judgement based on what you hear, not based on
what the name might imply.

3. Questions to have in your mind during the BoF
   Chairs
   2 mins (15/120)
   https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-chairs-slides-04

a. What are the key work items/deliverables?
b. What are the key things to exclude?
c. Do you think APN would be harmful in any way?
d. Is the benefit of APN worth the cost of development and deployment?
e. Would it be IETF work?
f. Does it merit a new working group or distribution across existing WGs?

(Slide 8)

4. Introduction to APN
   Robin (Zhenbin) Li
   10 mins + 5 mins questions for clarification (30/120)
   https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-introduction-to-apn-01

Ingress classifier (5-tuple, QinQ, ...)
encapsulate
process/forward
decapsulate on egress
Privacy!  No user sleuthing.

APN domain: packets are encapsulated at the Ingress node, the APN attribute is
removed along with the encapsulation header by egress nodes. It could be
multiple domains owned by the same operator.

APN attribute stores more fine-grained info derived by classifier

Kireeti: Can you give examples of policies that you described in the slides?
Robin: Actually, the next slides will talk about policy enforcement, the
concept is to match the traffic.

Greg Mirsky: The function is similar to IPv6 flow label
Robin: flow label is used for ECMP, cannot use that here

Tom Hill: A lot of lookups, for a large number of attributes?
Robin: Not sure I get your point
Tom Hill: Large lookup table?
Robin: Yes.

(Dan flushes queue)

**Selected comments in MeetEcho Chat during this presentation.**

Lars Eggert: to help me check if i have the right mental model of this: could
an instantiation of this architecture use a packet classifier that then
tunneled a given packet, and apply a diffserv mark to the outside of the
tunneled packet? Adrian Farrel: @Lars, that is how I understand the separation
of function at the edge into APN edge and APN head. kaduk@jabber.org/barnowl:
What Lars describes seems consistent with the understanding I am gaining from
the presentation so far. Stewart Bryant: Assuming that diff serve is a
sufficiently sophisticated QoS indicator Jana Iyengar: I'm wondering what more
this does. Cedric Westphal: Is the APN node a router or a server? Shuping Peng:
@Cedric, the APN node is a router within the APN network domain14

Antoine Fressancourt: Isn't Diffserv manipualted inconsistently in routers so
using it is not reliable now?14:19:52 Toerless Eckert @Antoine: there is no
mandatory IETFrequirement to configure DiffServ inconsistently ;-)14:20:37
Shuping Peng: @Lars, yes, that is the case.14:20:44 Stewart Bryant: I think we
need a more sophisticated ingress marker to specify the required
behaviour14:20:57 Tarek Saad: there's a lot of similarity in what a network
needs to do to support network slices and what seems required from it to do to
support APN14:21:01 mcr: @Antoine, but 90% of networks are consistent, and in
any case, all of this APN would be occuring within a (set of) cooperating
operators.14:21:43 Toerless Eckert: @Aontoine: Kidding aside, there are a lot
more network features easily inconsistent if configured manually.14:21:49
Shuping Peng: @Jana, with this added attribute, policy can be enforced at the
policy enforcement points within the APN domain, such as traffic steering or
IOAM14:22:13 Ted Hardie: How large is the space of APN attributes? If the data
on the previous slide were enough to identify and individual (e.g. by physical
port), could the attribute carry a user identifier?14:22:17 Jen Linkova: 5
tuple vs thing to inspect - oh, it's called MPLS ;)14:22:23 Stewart Bryant: Why
do we need to restrict ourselves to deducing the required behaviour rather than
introducing a method for the application to specify what it needs14:22:31
Shuping Peng: @Cedric, the APN node is a router within the APN network
domain14:22:35 Erik Kline: @linkova: I was thinking the same thing14:22:42 mcr:
@Ted, it's a good question. @Jen, they claim that a single MPLS label isn't
enough. But, haven't gotten a reply to why a stack of MPLS labels couldn't be
used.14:22:53 Jari Arkko: @Jana: You asked what more is done. I'd observe that
if all ports are 443 and all packets are destined to Amazon & friends, and all
connections are fully encrypted, I don't think there's other things the network
even could do. But maybe there's another question of whether we need a new
mechanism to handle 5-tuple mappings.14:23:08 Antoine Fressancourt: @Toerless,
sure, my point was mor ethat using Diffserv in the current situation would be
placing faith in the fact diffserv is not manipulated in a way nobody knows
exactly14:23:13 Watson Ladd: A structured general tag seems incompatible with
fast hardware handling to me. Also can't apply all preferences hop by hop iirc:
this is not my strongest area.14:23:16 Ole Trøan: The "application" (or user)
has no way to express "want" here right?14:23:28 mcr: @Ole, @Jari, despite the
name, many proponents don't intend to connect to the application, or create an
API. (I think they should do exactly that, and this belongs in ART)14:24:14
David Black: This has some structural similarities to Geneve (nvo3 network
virtualization) - TLV header structure would accommodate APN

Stewart Bryant: @Antoine - depends on the trust between the host/application
and the network14:24:46 Roland Bless: Currently, I don't see any difference to
SFC or SR14:25:09 Eduard V: DSCP has just 6bits. Here could be a much bigger
granularity.14:25:27 Watson Ladd: @David: i think the goal of this work is to
make the contents of that per tunnel header? not terribly clear on this14:25:29
Toerless Eckert: @Antoine: even as much as 5 years back, i have seen SDN
controllers configuring per-5-tupl flow ACLs to give required service level
objetives to individual users telephony 5-tuple flows.14:25:40 Tony Przygienda:
@roland yep

Daniel Bernier: there are a myriad of mechanisms to achieve this, some better
than others ... however how to express such "policies" so that a developper
does not hardcode DSCP bits with a Excel spreadsheet on it's desk to know what
mapping means what14:27:22

Antoine Fressancourt: @Toerless, the problem with QoS, being that everybody
believes his packets are special, I am not that astonished.14:29:16 Toerless
Eckert: @Toerless: sure, and if they would pay the nework operator more money
for that traffic, the operator would be happy to make them special. Right now
thats just very difficult to buy at the granularity of VPNs.14:30:11 oops,
@antoine.. not meaning to talk to myelf ;-) Gorry Fairhurst: @Eduard - but a
DSCP is associated with a treatment by the network (likely few), not a category
of traffic (there could be many) - Many people think of a limited set of
treatments, albeit with a complex classifcation at the edge - but do you need
to carry the classification info in the packet, only the required
treatment?14:31:36 David Black: @Watson: Will be interesting to see what is
emphasized in gap analysis.14:31:47 Shuping Peng: @Tom, the states at the edge
are always there for flow identification and classification. The good thing
with APN is that at the APN edge an APN attribute is added and with attribute
at the network intermediate nodes the table for policy enforcement is
significantly reduced. Please pay attention to the use cases being presented.

5. Use cases
   Luis Contreras
   15 mins + 5 mins questions for clarification (50/120)
   https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-apn-use-cases-01

* Performance measurement
    * IOAM flows according to 5-tuple -- but that is already encapsulated
* traffic steering
    * can't disclose all policy information to intermediate domain
    * encapsulate that in the APN tag instead

Greg Mirsky: slide 5, three domains, single tunnel?
Luis: Yes. This would be the same operator with three areas.
Greg: This scenario is a unique case where the tunnel crosses both the local
and IP Backbone areas. Luis: Not from my experience. Greg: I think you need to
make it clear that this use case is single operator, multi-domain use case. It
changes the mechanisms and applicability of APN, if we consider iOAM, then iOAM
has to be removed from the edge of the domain, in a multi-operator enviroment.
Luis: Ok, thats clear.

**Selected comments in MeetEcho Chat during this presentation.**

Jari Arkko: @watson @david I think what is being presented is largely usual
policy application, the main question in my mind is whether we need a new
mechanism for that. Earlier versions of APN went way beyond the usual policy
application btw and had issues there, that does not seem to be a problem any
more.14:34:07 Dan Voyer: @Jari, good question14:34:35 Shuping Peng: @Tarek,
network slicing is just one network services that can be better supported by
APN but APN is not bound to network slicing. There does not have to be network
sicing within an APN domain.14:34:58 Lou Berger: why not mpls or SR without
apn?14:36:24 David Black: Wondering about what APN attribute will grow to -
suspect that "structured attribute" is more accurate than "tag" and wonder how
resulting resolution complexity will compare with 5-tuples being used as bogey
in current preso.14:36:52 Shuping Peng: @Ted, the APN attribute will be
introduced in more details in the following presentation. The proper design of
the APN attribute is one of the work that we will need to work on. Your
suggestions are always welcome.14:37:09 Tom Hill: Ironically, I suspect that an
SRv6 SID could completely replace APN. Anything here that isn't covered by
that?14:37:15 Boris Khasanov: Might be that SPL in MPLS could be an APN
attribute too14:37:26 Gorry Fairhurst: @Eduard: e.g. Classify IP fields ->
Class (traffic category) -> Per Hop Treatment (indicated by DSCP)-> Schedular,
traffic policing and other configured policy14:37:55 Toerless Eckert: @Lou: if
i wanted to get special treatment for my packets across my access SP to e.g.:
the third-party edge-cloud content provider i am streaming from, which existing
SR/MPLS policy signaling mechanism could i use ?14:37:58 Ted Hardie: @Shuping.
Thanks. David's question has similar implications, so hopefully both aspects
are addressed.14:38:03 Charles Eckel: I thought the first presentation said APN
attributes were applicable within a single domain only, whereas this one
focuses on its use across multiple domains. The requirements are very different
for these two cases.14:38:24 Russ White: I assume there will need to be some
mechanism for the provider to be paid differently based on the kind of service
the application is asking for ... and the control plane will need to be
modified to support these various kinds of paths ... I wonder what the
additional complexity will be to go beyond "mark the packets and do fancy QoS"
that seems to be implied here ... Toerless Eckert: @Lou: maybe this could be a
good policy signaling mechanism to faster proliferate DetNet services into SPs
;-))14:39:03 dhruvdhody: @Tom - I see APN trying to be agnostic and support
multiple tunnel encapsulation include SRv6/IPv614:39:18

Lou Berger: @toreless well that's another question, what does APN bring that
isn't already being done within detnet14:39:48 Jana Iyengar: What Charles
said.14:39:52 Ted Hardie: @Greg I have optical service and wireless service
from the same operator, and this would not be unusual for that operator, from
what I can tell.14:40:11 Tom Hill: @Dhruv, that's a fair point - though a whole
new protocol? hmm.

Ted Hardie: @Greg But I agree with your characterization of "single operator,
multi domain".14:40:31 kaduk@jabber.org/barnowl: For what it's worth, I did
perceive "only a single operator" from the first presentation.14:40:37 Tarek
Saad: @Shuping Peng: what I meant the tools introduced to support network
slicing are reusable to a big extent here in APN14:40:40 Jana Iyengar: I
understand the request to not over-pivot on the name, but I'm struggling to
understand how any of this is "application-aware" in the slightest.14:40:41
John Scudder: @Charles I believe the use of "domain" is very imprecise. The
first speaker said it was applicable when multiple "domains" are owned by a
single entity.14:40:48

Watson Ladd: Why doesn't the head know how to encapsulate with the treatment
that will be applied?14:41:01 Eduard V: I do not agree with Greg. It is very
often that a big Carrier has separate ASs (IGP, BGP) for the backbone and all
metros.14:41:05 Lou Berger: very true14:41:20 frodek: @charles, they used the
term "APN domain", not "network domain" David Black: Expecting diffserv
domain/region model and notion of cooperating operators to be applicable
scopes.14:41:35 Uma Chunduri: @Greg Mirsky, I agree with Luis on this. Crossing
operator boundaries when packet crossing metro is an exception. Lot of backhaul
networks have multiple subdomains all maintained by same operators.

Watson Ladd: Different AS's exchanging non IP traffic? didn't know that
worked!14:41:54 Ted Hardie: I am now convinced that 25 minutes is not going to
be enough....14:41:57 Can we speed through any of the other aspects?14:42:11
Toerless Eckert: videos of speakers are nice!14:42:20 Shuping Peng: @Greg, the
APN domain owned by a single operator is always clearly stated in the APN
Introduction slides.

6. Why are existing mechanisms not enough?
   Gyan Mishra
   5 mins + 10 mins questions for clarification (65/120)
   https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-existing-mechanisms-01

DSCP not big enough.  Want more fine-grained.
Entropy labels (IPv6 flow, mpls, pw) used mainly for entropy (ECMP).
SFC SID: meant to used between service function nodes.
IOAM Flow ID:  Meant for IOAM.
BSIDs: SR only
FlowSpec label (RFC 5575):
Group Policy ID (VXLAN-GPE):
they all have a specific function -- could be used, more coarse
-> specific functions, specific data plane
APN would be generic to that, data plane agnostic

Tarek: You missed: Aggregate ID for network slicing; lot of resemblance -- look
at that

Alissa: Identifier space not big enough -- what's the size?
Gyan: later, I believe 32 or was it 16

**Selected comments in MeetEcho Chat during this presentation.**

Bib Hinden: The flow label could be used for anything given that a tunnel is
created Roland Bless :@Bob: true14:44:33 Shuping Peng: @Greg, I would not say
that this is a rare case, and I thought you would be very farmiliar with this
case since it is a very normal deployment case in China's network setup. :p
Generally the network in a country like China for example is always very large.
It will go through multiple domains belonging to different department of the
same operator.14:44:46 Jen Linkova: 5 tuples are also used for load balancing,
it doesn't prevent them being used for other things..14:45:26 Zhenbin Li: @Jen
I explained that in the introduction, the APN domain is a logic concept. In the
physical environment, it can be network domains controlled by one
operators.14:45:26 Martin Duke: I don't understand how the bullets for #2
answer the question14:45:33 Shuping Peng: @Jen, it doesnot have to be MPLS, it
could be any payload protocol.14:45:34 Martin Duke: likewise #714:46:07 Adrian
Farrel: @Jana (wrt the name) I understand your point. Possibly it "delivers
network performance appropriate for the network", but also possibly it really
has just evolved and not changed its name as it went14:46:20 mcr: @martin, the
gap analysis document is also lacking conclusions, a comment I made months
ago.14:46:25 Gorry Fairhurst: I thought the previous speaker said the APN
domains were all under the conrol of one oeprator, so doesn't that match the
scope of the IOAM header?14:46:40 Watson Ladd: Not sure why if you're going to
update all your equipement to do this you don't make them all use the same
tunneling solution14:46:56 kaduk@jabber.org/barnowl Gorry: I think the scope
matches, yes14:47:07 Justin Iurman: +1 Gorry14:47:15 Jana Iyengar: @Adrian --
That happens. But by the time it's a BoF, it's worth revisiting that,
especially if everyone has to go out of their way to say "please don't pay
attention to the name"14:47:17 Watson Ladd: also China network very unique
history and structure.14:47:18 Jen Linkova: @Bob: +1. I'm not sure why the
outer header flow label is not enough.14:47:24 Watson Ladd: name changes are
hard, but better sooner than later14:47:33 Dirk Hugo: BTW SFC service Id draft
is meanwhile rfc8979 ??14:47:35 Jari Arkko: @martinduke I also don't see a
conclusion for items except the DSCP one. They are used in specific situations.
Wouldn't a new APN thing be also used in the specific APN networks?14:47:38
Shuping Peng: @Jari, with APN the 5-tuple mapping only happens at the APN edge.
Within the APN domain, there is no need to that anymore. You can only use the
APN attribute in the single field to do the policy enforcement and no need to
do the further resolving of the 5 tuples.14:47:42 Jari Arkko: Or am I missing
something?

Daniel Bernier: comparison should include SRv6 independent from BSID, use of
TLVs (srh, nsh, geneve, ...)14:48:20 Martin Duke: wait, aren't flow labels
generic?14:48:27 Zhenbin Li: @Gorry the IOAM is the policy enforcement in the
backbone domain according to the APN attributes. The IOAM is only used in the
backbone daomain.14:48:45 Jari Arkko: @Shuping: understood. The question is if
that clear benefit is enough though. Not saying it isn't but that's a question
we need to ask. One could do the 5-tuple lookup every time, if one wanted
to.14:48:47 Kireeti Kompella: @martin duke they are indeed, simply flow labels
-- they can be used for all sorts of things14:49:50 Jen Linkova: "20 bits ought
to be enough for anybody" ;))14:50:46 Tom Hill: Ah, 4B permutations. OK. I got
loads of FIB in my edge devices for that.

7. What is contained in an Identifier and why?
   Chongfeng Xie
   10 mins +  5 mins questions for clarification (80/120)
   https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-7-the-apn-attribute-00

APN Attribute = APN ID + APN parameters
can be used as an opaque value to map to policy
ID can include:
* Application Group ID
* User Group ID

APN parameters: can provide performance requirements (BW, latency, loss, jitter)
is open, other parameters can be introduced.

Zhaohui Zhang: opaque, has a structure which is not supposed to see--
contradictory APN \[parameters]: should a router look at this?

Lou Berger: vs. DETNET -- we already have a 6-tuple
Chongfeng: sorry, don't know
Shuping: DETNET can be used

David Black: opaque lookup? which parameters to use? what exactly are you
looking? ShuPing: Operator doesn't need to know identifity. Some identifier can
be used for

Greg: APN parameters, do they explicitly express bandwidth requirement,
schedule policy? Chong Feng Xie: currently we think the bandwidth can be
carried by APN parameters.

Greg: what if transit nodes can't satisfy? should transit nodes drop?
Shuping: we don't think transit nodes need to use the information.
Greg: what is the use to carry the information in the APN headers if transit
nodes don't handle the information?

**Selected comments in MeetEcho Chat during this presentation.**

Lars Eggert: @jari one difference between "a 5-tuple lookup at each hop" and
adding a packet field at the edge is that you could use a bunch of ML at the
edge that analyzes a flow's history, and then encode that in the field so you
don't need to ML at each hop. in other words, you can afford to do much more at
the edge. there are upsides and downsides to this, as always14:52:46 Shuping
Peng: @Ole, @mcr, yes, the APN work only focuses on what we can do within the
network.14:52:48 Bob Hinden: We are 15 minutes ahead at the moment14:52:58
Roland Bless: So either flow labels are sufficient or SFC: also classify once
and then use the NSH that should be expressive enough. Then you need to map
your policies to SFPs and that's it? #3 wasn't showing any gap to the use case
or I didn't understand.14:53:02 Watson Ladd: this seems way to generic to
actually work across devices of very different capabilities14:53:09 Rick
Taylor: I keep thinking abusing LISP may yield the same results... if the APN
becomes encoded in your Identifier at the edges...14:54:19 Jari Arkko: @lars
good point!14:54:24 Ted Hardie: @Lars There appears to be a fundamental
assumption in this that the edge operator takes all available information
(including the five tuple) and assigns an APN structured ID. This means that
the ID carries a piece of information that is potentially semantically *richer*
than the five tuple and making that available to path elements that would not
otherwise have that data. The size of the ID is high enough that the policy
could identify emitters or characteristics that would not be available in the
current Internet. As you note, there are major downsides of that, and I am
struggling to see how this could work within the advice of 8558. That's an IAB
doc, not IETF consensus, but these path signals don't match the limitations it
advises.14:54:24 kaduk@jabber.org/barnowl: I'm not sure how a "user group ID"
would be extracted from 5-tuple/etc at the edge node. Unless we're equating src
IP with user...14:54:25 Lars Eggert: what happens to a flow if a hop can't meet
the apn requirements?14:54:32 dhruvdhody: @roland - from what i understand is
that re-purposing NSH for non-SFC usecase would be a bit of a mess14:54:53 Ted
Hardie: @kaduk the edge has access to physical port as well.14:54:56 Takuya
Miyasaka: I'm not sure how edge routers can estimate APN ID and parameters (
latency, bandwidth, etc.) just from 5-tuple. Is there any interface or API
between application and APN domain controller?14:55:15 Sergey Fomin: Feels like
a false dichotomy: this APN id is presented as something that works with any
data plane.. but in reality it is the new dataplane14:55:17 Watson Ladd: @Ted:
but a rich identifier is hard to switch on, which seems to go against some of
the envisioned applications14:55:19 Adrian Farrel: @Ted. In fact even virtual
port id. Various APN implications14:55:45 kaduk@jabber.org/barnowl: "can be
treated as opaque", not "is opaque"14:56:01 Ted Hardie: @Watson I have no doubt
that you could build those with this rich an identifier. But it also looks like
a privacy footgun in the making.14:56:08 Watson Ladd: can build yes. Can build
faster than 5 tuple extraction or MPLS label popping? dubious14:56:42 David
Black: If treated as opaque, how does attribute richness interact with opaque
lookup? Is that just opaque lookup based on ID (would make more sense)?14:57:00
kaduk@jabber.org/barnowl: I'm interpreting "can be treated as opaque" as
indicating that a given device might only need to process a handful of APN
values. Those specific values do have internal structure that could be
interpreted, but for this particular device it just uses a lookup table for
those fixed values.14:57:49 Gorry Fairhurst: It seems that there is edge policy
that sets up a set if IDs in each packet; then each node is configured with
policies that match an extensible set of IDs (in some combination) and make a
decision about how to map/lookup the packet to decide on scheduling, policing,
etc. This is gloriously flexible and amazingly complex to coordinate between
nodes ...14:57:52 Adrian Farrel: @David I *think* (but unsure) that you can
apply bit masks to the opaque identifier if (and only if) everyone sets the
identifier in the same way.14:58:09 kaduk@jabber.org/barnowl: So, such a "treat
as opaque" case could not actually use the full richness of attributes14

Rick Taylor: @lou - +1 on similarities to DetNet15:01:03
Jana Iyengar: @Ted -- exactly. It seems to me that we're staring at a giant
privacy issue in the making here. An arbitrary generic structured field that
can be shared across operator domains enables significant sharing of metadata
across operators. That concerns me.15:01:53 Gorry Fairhurst: @Adrian.. yes -
that's where I am, until someone explains this differently15:02:22 dhruvdhody:
@jana - the claim is that the APN information is stripped along with tunnel
encapsulation when it leaves the one operator domain (something like
IOAM)15:03:42 Alexander Clemm: is "treat as opaque" the same here as "treat as
optional"?15:04:27 David Black: @kaduk Sounds like opaque was used solely wrt
privacy of info from which APN ID is derived.15:04:44 kaduk@jabber.org/barnowl:
David Black: would you mind typing up your understanding of the answer you got?
I think I missed part of it, unfortunately15:04:50 dhruvdhody: @alex - maybe
part of how the policy is enforced15:05:27 Jingrong Xie: so opaque means
something like "RBAC(Role-Based Access Control)" instead of some known the
specific user. some kind of "indirect"15:05:30 Jana Iyengar: @dhruv: my
understanding is that the entire value of these APN tunnels is to communicate
information across domains.15:05:31 David Black: @kaduk What I understood is
that "opaque" refers solely to hiding of information used to construct/derive
APN ID, thereby affording privacy properties, but APN ID is completely
non-opaque to network elements.15:05:39 Ted Hardie: @Dhruvdhody The current
privacy and security doc makes that claim, but it is an operational practice,
not a characteristic of the protocol. For the one operator, multiple domain
case, you can't really put it into the protocol mechanics.15:05:51 dhruvdhody:
@jana - but within a single operator15:05:52 Watson Ladd: so what's between the
domains15:05:56 Jie Dong: @Gorry, in your "then each node is configured with
policies...", to my understanding APN does not require each transit node to
have that policy configured, only the nodes which need to perform APN specific
manipulation15:05:59 kaduk@jabber.org/barnowl: David: thanks!15:06:16 Daniel
Bernier: is it expected that the APN ID and parameters be "normalized'
(standardized) or be defined domain specific15:06:25 Alexander Clemm: @dhruv -
not sure policy is sufficient here. If optional, other questions come up like
how to know whether or not it is being acted upon by intermediate nodes15:06:29
David Black: suspect that Greg and Shuping do not have a common understanding
of "transit node" term ...15:06:37 Rick Taylor: ... and Greg just underlines
why this is just DetNet15:06:38 Jingrong Xie: @David Black, I have similar
understanding with yours after explaination by Shuping.15:06:39 Jari Arkko:
@dhruvdhody @jana We can look at this in different ways. Can information, if it
exists, be used for a bad policy? Yes. Can it be shared with others? Yes.
However, modern operator networks don't really have much metadata to share,
given progress in encryption. At least in most parts of the world. If we are
concerned about metadata, we should be concerned about CDN, Google, etc. user
tracking and how that data is shared eg with advertisers. This does not mean
that I'm in favour of APN, because I happen to believe we have the plumbing
tools for this already available, so no new tech needed.15:06:47 Ted Hardie:
@Jari the structure of this enable the sharing of information that is not
normally available by on-path inspection, because of the priviledged place the
marking occurs. I think that's different from the "not much metadata to share"
case.

Alissa Cooper: What is the mechanism that forces this attribute to be stripped
at the network operator's boundary?15:08:23 Jeffrey Haas: The meta data is a
wonderful place to carry a Google FLoC. Zhenbin Li: @Greg How to process the bw
req para is about the solutions. It is open now. There is the possible way to
configure the local policy for best effort if there is enough bw for the bw req
para. There can be other policies to process your mentioned cases.15:08:53 Bob
Hinden: I think it stripped when the packet is deencapsulated15:08:58 Jen
Linkova: why am I thinking about lawful intercept..15:09:11 Jeffrey Haas:
s/lawful//15:09:22 Jana Iyengar: @Jari -- I strongly disagree. Making that
information flow richer (arbitrarily so), allowing arbitrary aggregates of
users, and making it possible for this information can be shared across
operators IS a pretty big difference from existing mechanisms such as
DiffServ.15:09:34 Ted Hardie: @Bob Unless decap and re-encap are guaranteed to
be in different boxes, then you still have practice, not protocol
mechanism.15:09:47 Watson Ladd: I think many people would disagree with the
idea we have a clear program15:09:48 Jen Linkova: @Jeff: sorry, should have
used double-quotes15:09:53 Jingrong Xie: "APN domain" boundary to ensure this
attribute to be stripped I guess @Alissa15:09:58 Sergey Fomin: @Jana - i don't
think they propose to share between operators, though15:10:07 it can be, but
shouldn't15:10:18 Zhenbin Li: @Alissa The apn attribute is carried along with
the tunnel. When the tunnel is removed, the APN attribute will be removed at
the same time.15:10:20 Jana Iyengar: @Sergey -- see @Ted's point above. That's
an operational point, not something the protocol can enforce.15:10:32 Erik
Kline: similar to SRH mechanics then?15:10:34 Watson Ladd: so the tunnel goes
across the domains? Why doesn't that allow all the mechanisms we already have
like detnet, etc. to work?

Jeffrey Haas: I think the idea that they can remove the privacy implications of
these mechanisms by charter is ludicrous.15:11:08 Lou Berger: for those who may
be interested - DetNet session is 30 minutes after this session ends - see
https://datatracker.ietf.org/wg/detnet/about/ and
https://datatracker.ietf.org/meeting/111/session/detnet15:11:10 Rick Taylor:
@Watson: this is just DetNet - but the "attribute" is "policy-compliance"
rather than latency or reliability. kaduk@jabber.org/barnowl: There is the
question of who decides whether there is violation of the user's
privacy/security, yes. I can imagine some people whose decisions would
essentially not let anything be published15:11:47 Alissa Cooper: I guess I was
wondering about the case when the interconnecting network says, "hey, I'll pay
you to leave that attribute there after decap"15:11:52 Toerless Eckert: @Lou:
so if a user wants to get DetNet service for a flow, the user and network need
to le to know network know 5 tuple flow. Is that a violation of user privacy ?

8. Work items to be covered
   Shuping Peng
   5 mins + 5 mins questions for clarification (90/120)
   https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-8-apn-work-items-00

Greg: why IPv6 tunnel not sufficient?
shuping: some tunnels are not IPv6 based,
Grep: what encapsution do you have in mind?

**Selected comments in MeetEcho Chat during this presentation.**

Boris Khasanov: What's the point for using GTP-U there?15:12:58
Zhenbin Li: @Watson the detnet is the network service to be policy-enforced. It
can be done according to the APN atttribute carried in the tunnel.15:12:59 Lou
Berger: @toreless the stated scope was single provider, so they already have
the info15:13:00 Watson Ladd: why can't detnet carry the info?15:13:09 Rick
Taylor: It can15:13:19 Watson Ladd: why do we need an abstract container for
service info across all tunneling mechanisms?15:13:29 Justin Iurman: ... why
can't IOAM carry the info?15:13:32 kaduk@jabber.org/barnowl: Does DetNet-IP
have ways to convey information other than 6-tuple?15:13:37 Lou Berger:
@watson, was about to say that's an option too15:13:38 Sergey Fomin: @Watson
that's a great question15:13:47 Lou Berger: we have an mpls service label
already and have a proposal for a service IP label15:14:02
kaduk@jabber.org/barnowl: I think I remember DetNet-MPLS having more
flexibility than DetNet-IP15:14:03 David Black: "will not publish anything that
violates user's privacy and security" seems to be both untestable and miss the
point - "that can be used to violate ..." is where the problems reside ... and
looks like I'm not the only person thinking along these lines - +1 @Jeff &
@kaduk15:14:09 Sergey Fomin: Don't see a need to define a new dataplane to
carry this info, while you could use existing mechanisms15:14:10 Watson Ladd:
when open mic starts i;ll ask it15:14:12 Dan Voyer: @watson that's what coming
next15:14:44 Dino Farinacci: the question is not being answered, what is the
OUTER HEADER?15:15:39 Tom Hill: @david We're all quite well aware of the power
(danger) of metadata.15:15:40 No different here tbh15:15:48 Toerless Eckert:
@lou: thanks15:15:50 kaduk@jabber.org/barnowl: Lou: do you have a link to the
service IP label draft handy?15:16:26 Tom Hill: Basically taking a bunch of
factors and giving every user an identification number in the core.15:16:42

Shuping Peng: @Tarek, that is true. APN and network slicing do not conflict
each other.15:17:28 kaduk@jabber.org/barnowl: Thanks Lou!15:17:34 Lou Berger:
NP - they are both individual so still working this part out15:17:53 David
Black: @Tom - if that's done, "opaque" != "private"15:17:53 Dino Farinacci: my
big concern is an "APN setter" can DoS the network15:18:07 Jim Guichard: i dont
think they mean opaque in this sense15:18:49 Jari Arkko: @Ted we may agree
actually on the conclusion on what we should be doing in the IETF on this. So
I'm not sure I want to argue too much with you. But I am not sure the point
about privileged place. In many networks -- mobile networks in particular --
you already carry a lot of information about ingress "ports" for instance, as
there is a technical reason for tunneling and that involves some identification
of the connection. Lars' point is valid that one could set up an AI thing, but
that sees more about the need to have enough resources at a stable node to do
that if one really needs to. That could be somewhere else than in the edge. In
fact in mobile placing it in edge might be a bad idea. But Lars is right that
if one does that, then attributes would be a way to distribute the information
further. Although maybe not in order that the APN diagrams show it. You'd have.
to deliver it in reverse order, if the analysis point was in centralized cloud
facility, for instance.15:18:50 Lou Berger: @dino its really the same issue as
interdomain mpls15:18:56 Jingrong Xie: OUTER HEADER is the header prepended to
the original packet during encapsulation I guess @Dino15:18:56 Dino Farinacci:
agree @lou, but since mistakes of the past are repeated, that's the definition
of insanity15:19:31 Rick Taylor: I'm still not sure what the problem domain
is... What is the problem APN is trying to solve?15:20:22 Ted Hardie: put a
link to the slide here instead of reading it aloud?15:20:37 Dino Farinacci: the
problem statement is simply this "what can an app do to get better service for
it, from the network"15:20:56 Shuping Peng: @frodek, APN domain is
Application-ware Network domain :)15:21:06 Dino Farinacci: and of course all
apps want the best service, so what gives?15:21:06 Sergey Fomin: @Dino an app
does not participate in this, per my understanding15:21:21 Rick Taylor: Aaah..
"How can an app get a determinsitic service from the network" ?15:21:27 Lou
Berger: @chairs how does this listing of slicing related to APN???15:21:33 Dino
Farinacci: what would Sally Floyd say about this?15:21:36 Jana Iyengar: About
privacy -- an arbitrary structure that can be (i) defined by an operator at
runtime, and (ii) shared arbitrarily makes this particularly problematic. This
is literally a mechanism for creating and sharing arbitrary metadata about
arbitrary aggregates across arbitrary boundaries. That solves many problems,
sure, but it creates as much or more room for trouble. If there are specific
problems that we want to solve, let's consider them individually and try to
solve them. If general themes arise, let's see if we can generalize to cover
the use cases. Arguing for a completely general mechanism based on two use
cases is an academic exercise, not an engineering one.15:21:39
kaduk@jabber.org/barnowl: An optimist might say that different apps care about
"best" on different axes (bandwidth, latency)15:21:43 Watson Ladd: i don't
think that's the problem. much simpler solutions. And some apps deliberately
deprivilege flows: bittorent choking and scavenger tcp controllers15:21:47 Dino
Farinacci: @kaduk, then we have a multi-dimensiona "what gives"15:22:28 Jim
Guichard: this is not network slicing15:22:39 Antoine Fressancourt: @Jana,
Funny how you describe Flow label15:22:56 dhruvdhody: Creating a network slice
for the APN usecase for policy enforcement seems extreme15:23:01 Jie Dong: in
my understanding APN and network slice are concept at different
layers/granularity15:24:15 John Scudder: @Jim it's too bad Jeffrey's slide
didn't project, because it would be interesting to hear your specific rebuttal
of his specific points.15:24:19 kaduk@jabber.org/barnowl: Hopefully Jeffrey
could still put a link to his slide in the chat?

9. Return to the Questions and open discussion
   Chairs
   25 mins (115/120)
   https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-chairs-slides-04

Zhaohui Zhang: the entire scope of the work are well covered by existing IETF
work. Zhaohui Zhang: if you have to look at the individual field to forward,
then it is no longer opaque.

Tarek: among all teh work Shuping identfied, there is no gap analysis on why
the exisitng ones can't do the job.

Peng Liu: We have the usecase that the APN is used for the edge computing. The
APN can work in the network domain controlled by one operator. It will be not
harmful to others. Fine granularity network service provided by APN is good for
the application and users, operator can also provide differentiated network
services based on APN and may benefit from it. I think this work is different
from the traditional routing work. So to set up a WG to have all possible work
together may be better.

Ted Hardie: Thanks for the security mentioning. problem around the identifier
which can carry more information than the 5 tuples, which can be problemic
across multiple domains. for having metadata across different encapsulations,
it is very costly. having generic metadata is not the right approach.

Watson Ladd: Can you pick a tunneling layer, like MPLS that already has a
policy that you want. Its not clear what the use case is that cannot be solved
with existing mechanisms, including Detnet. Have to deploy this new mechanism
across all devices in the domain, why not standardize on one tunnel with that
effort?

Jana Lyengar: Repeating Ted and Watson, the metadata needs to be carefully
managed (??). If the problem was more specific, then the solution could be
narrower. APN could be harmful in the way it is currently described.

Feng Yang: If we have end-to-end tunnels, then its clear APN works currently.
APN looks ok for single operator. If we have multiple domains, with different
tunnel types, then how would APN work? It seems APN is good for fine
granularity packet classification. So support to set up a WG.

Daniel Bernier: I agree there is a need to work on application internetworking,
we discussed this in PANRG as to how an application expresses requirements to a
network layer, I dont think this abstraction needs to be another protocol or
part of the application itself.

Greg: Looki 6437 IPv6 flow label and DetNet, they already solve this problem, I
dont think need another mechanism. If a problem does exist it does not have to
be solve in the data plane, it could be the management plane.

Ron Bonica: The use cases presented do not justify the broad APN charter, they
lack detail to know if exsiting mechanisms might be used instead. APN would
also span many technology areas, so we need a clearler problem defintion to
perform a succint gap analysis.

Shuai: we have the Use case of implementing APN to realize game acceleration.
Based on the implementation of APN, the apn attribute is only used in our
network domain and will not be harmful to other work. I think the
implementation process is according to the contract with the game service
provider. we can also exploer better business models to achieve win-win
cooperation through APN. I think this work makes a lot of sense. I will
contribute to the work. Maybe more application attribute need to be defined, so
a new working group is a better way to do these work.

Jari: A suggestion what you should be doing: write a document that assumes this
model (lookup, encode a small field, process) and shows how to do this with
existing IETF tech

Jingrong Xie (Huawei): Comments, multicast useful; APN can combine with
multicast

Y. Richard Yang: I like this work. Lots of header (label, code point, etc.)
information, APN might be good for introducing a generic type system. I see a
lot of use cases, for instance application to network signaling but I see the
lookup issue and have less state and be careful with semantic identifiers.

Erik Kline: If using 5-tuple classification how useful is that when we have so
much encyption, where that information would be in the presence of MASQUE and
OHTTP proxies?

Dirk v. Hugo: good job to point to the need for better classification, but just
introducing another items then claiming that this can provide infinite
granularity

Jim Guichard: APN ? network slciing: NS allocates resources to flows; APN
identifies that can be used to enforce policy. Who = is wife, kids, device,
location. I then map that to an identifier which is mapped to a path in the
network. I get that more detailed use cases may be required.

Dhruv Dhody: Comment on gap analysis, we need to add - why do we need an
agnostic mechanisms instead of just hacking into  existing mechanism
individually. This adds to why having a single WG to focus on a technology
agnostic mechanism would be useful before various dataplane encapsulations are
developed seperately.

Toerless Eckert: Comment on privacy, there are implications for M2M ... (???)

Shuping: These use cases could be considered "lite", for multple meetings we
have presented general and detailed use cases. One example, CLoud Lease Line,
the enterprise will purchase this service and they must communcaite the
provider what type of traffic and uses (marketing or finance), which allows the
provider to differentiate traffic, so privacy and securities exist already.

**Selected comments in MeetEcho Chat during this part of the meeting.**

Jim Guichard: @John Scudder i guess it will go on the mailing list but the main
point is that APN *could* be used to forward a traffic into a specific network
slice but i would doubt having a slice per APN given that the permutations
could be very large15:25:44 John Scudder: I took his point broadly speaking to
be that if one focuses on the definition of network slicing and ignores the
marketing name, the definition matches. Which if true, is a good thing, that's
what you want out of a well thought-out architecture. "If the shoe fits, wear
it."15:25:58 Joel Halpern: @Jim Guichard - I hope this is not network slicing.
However, it is hard to distinguish the two apparently different meanings of
assigning behavior to subsets of traffic. The IETF network slicing work has
been focusing on making sure that the result is aggregatable and scalable. So
it seems to be tackling the harder problems. Beyond that, we have plenty of
tools.15:26:15 Dirk Hugo: is the gap that existing approaches only provide
limited granularity but APN an unlimited one?15:27:17 Zhaohui Zhang: Here are
the text from the slide that I tried to share:15:27:32
kaduk@jabber.org/barnowl: Right, we have no protocol mechanism to enforce
what's in the APN marking and when it's removed, which I think relates to a
question Joey had asked near the start of the session.15:29:16 Dino Farinacci:
I really agree with Ted15:29:27 Zhaohui Zhang: Ongoing IETF Network Slicing
work already addresses the problem domain and solution - An IETF Network Slice
provides the required connectivity between different entities in RAN and CN
segments of an end-to-end network slice, with a specific performance
commitment. - It is intended that IETF Network Slices can be created to meet
specific requirements, typically expressed as bandwidth, latency, latency
variation, and other desired or required characteristics. - An IETF Network
Slice combines the connectivity resource requirements and associated network
behaviors such as bandwidth, latency, jitter, and network functions with other
resource behaviors such as compute and storage availability. - Term "Slice"
refers to a set of characteristics and behaviors that separate one type of
user-traffic from another. IETF Network Slice assumes that an underlying
network is capable of ... fulfilling all or some of SLOs to all of the traffic
in the slice or to specific flows - Many approaches are currently being worked
on to support IETF Network Slices in IP and MPLS networks with or without the
use of Segment Routing. Most of these approaches utilize a way of marking
packets so that network nodes can apply specific routing and forwarding
behaviors to packets that belong to different IETF Network Slices. Different
mechanisms for marking packets have been proposed (including using MPLS labels
and Segment Rouing segment IDs) - The realization can be achieved in a form of
either physical or logical connectivity using VPNs, virtual networks (VNs), or
a variety of tunneling technologies such as Segment Routing, MPLS, etc. - Slice
Aggregate concept (similar to DiffServ Behavior Aggregate) in draft-bestbar is
about identifying some or all traffic in a slice using opaque numbers and
providing corresponding forwarding treatment15:29:29 Shuping Peng: @Jen, that
is because the 5 tuples of the original packet have encapsulated within the
tunnel. If people want to do the policy enforcement again within the network
domain, they will have to resolve the 5 tuples.15:29:51 Zhaohui Zhang: The
bullets are quotes from the IETF Network Slice framework15:29:57 Watson Ladd:
so it's just pulling the 5 tuple to the front?15:30:09 Lou Berger: @zhaohui --
thanks for clarifying, it wasn't clear to me why you were reading this
definition15:30:51 Dino Farinacci: right, and leave some packet bits for the
app ;-)15:31:49 Rüdiger Volk: is slicing more general because addressing MULTI
operator scenarios?15:31:55 Jari Arkko: +1 on Watson's argument about picking
an existing tunneling layer15:32:15 Shuping Peng: @Waston, we are not creating
new tunnels, we are using the exisitng tunnel to carry the APN attribute, to
that, we would need some extensions and new specifications.15:33:16 Watson
Ladd: but why not extend existing tunnel across your entire network?15:33:34
Dino Farinacci: putting the solution in the overlay alone doesn't solve the
problem, the underlay needs to support it too15:33:59 Watson Ladd: from the
first slide you've got one entity controlling different incompatible pieces
with different tunneling mechanisms. just pick one: you've got to change
everything anyway15:34:22 Antoine Fressancourt: With properly anonymized
packets, APN could in teh end represent less metadata than want an encapsulated
packet sent on a mobiel network would leak15:34:25 Dino Farinacci: tell me why
copying outer TOS to inner TOS and using existing equipment is not
enough?15:34:38 I mean inner to outer on encap15:34:52 Sergey Fomin: @Shuping
is that just an attribute, though? or a new encapsulation which should be
processed in fastpath on each hop?15:35:28 feels like the latter.15:35:33
Roland Bless: I didn't find the gap analysis convincing. IMHO there are plenty
of solutions available to do this.15:36:44 Lou Berger: +115:36:57 Watson Ladd:
+115:37:06 Sergey Fomin: Agree with Roland.15:37:08 Tarek Saad: @ Roland
+115:37:20 Joel Halpern: @roland +115:37:53 Tarek Saad: though Gyan started on
it (thanks) - but was not exhaustive15:37:57 David Black: @Shuping - suggest
starting by picking one encapsulation to carry APN, focus on that and ensure
that APN solves a problem that the existing encapsulation does not. The
assertion that the APN must be encapsulation-independent is poorly supported by
what I've seen.15:38:13 Kireeti Kompella: @roland +1 @tarek +115:38:29 Nicolas
Kuhn: I think inter-domain relies on protocols inter-operability that is dealt
with a protocol-per-protocol basis ; not sure a specific WG is necessary to do
so. this needs to be discussed in specific and existing WG15:38:32 Luis
Contreras: I see some contradiction between the positions that "this can be
done with other existing capabilities" with the argument of "this is potntially
problematic". If the first argument apply, then the second does not (or at
least the risk is already there).15:38:35 Srihari Sangli: @roland + 115:38:57
Roland Bless: The other thing I find a bit odd: 5 tuple is considered to be
complex, but processing the attribute parameters on bandwidth, delay, jitter
requirements etc. not? I mean I understood, that the latter is probably only
required for some attributes, but nevertheless...15:39:00 Antoine Fressancourt:
@Luis +115:39:07 Watson Ladd: @Luis: it's "the claimed application can be done
with existing technology" and "the generality is dangerous"15:39:11
@Roland+115:39:24 Dan Voyer: @Dino, how about you come to the mic with your
views ? :)15:39:25 Kazuaki Ueda: @Roland+115:39:29 Uma Chunduri: @Luis
+115:39:43 John Scudder: @Roland thanks for saying that15:39:54 Antoine
Fressancourt: @Watson if privacy is a concern, I encourage you to look at the
academic litterature on AI uses for Traffic classification15:40:01 Jim
Guichard: @chairs maybe let folks talk that have not already been to the mic
multiple times?15:40:21 Dan Voyer: yes15:40:37 Alissa Cooper: @Luis, as Jana
said, the threat model for a generic attribute is different than for a narrowly
scoped attribute specific to a particular tunneling mechanism15:40:38 Kireeti
Kompella: @dan bernier: change APN to API?15:40:38 Uma Chunduri: @proponents -
Slicing solutions and it's overlap should be addressed in the gaps15:40:53
Daniel Bernier: @kireeti did not want to go to "intent". but API oh yes15:41:27
Jen Linkova: Luis: (re your "existing mechanism vs risk arguments) - we might
have mechanisms to solve the proposed use cases. New mechanism might have
*additional* security/privacy implications which existing mechanisms don't (or
have but not to that degree).15:41:34 Uma Chunduri: @proponents is the
structure for APN-ID (if there) has to be defined and standardized case by
case? or it's generic 16/32/8 bit metdata15:42:12 Watson Ladd: +1 Ron: avoid
making desert wax and floor topping15:42:29 Kireeti Kompella: @dan API =
application intent?15:42:56 Daniel Bernier: yup !15:43:14 a network domain
might decide to convey it by any means available15:44:29 or not if the intent
is ludicrous15:44:41 Shuping Peng: @Jari, thank you for your
suggestions!15:44:44 @Uma, thank you. That is up to the working group to decide
the proper design.15:4

10. Wrap-up
    Chairs/AD
    5 mins (120/120)

Adrian:

Lots of questions still pending in queue, sorry to those waiting.
Here is a summary of what the chairs think they heard:
- Points raised around all the existing mechanisms and how they would be use in
APN, or why APN is needed instead. Particular reference to DetNet and Network
Slicing which did not form part of Gyan's presentation. - Privacy issue was
raised, how this affects APN also needs to be dicussed in more detail. In
particular, Ted's point about accidental breach of privacy and subversion of
decapsulation. - Use cases need to explain more about what is needed from the
APN attribute and what policies are applied in the network. We need more
detailed "killer" use case examples. - The APN atribute should not become a way
of carrying arbitrary metadata. It is not clear at this stage what information
needs to be in the APN attribute versus what information Could be in the APN
attribute. - We also need more undersanding of how APN is relevant in encypted
enviroments. - The point was raised about whether APN should be applied to
multiple trasnport/underlay protocols or whether it would be better to pick
just one and use it in all APN-enabled networks.

Martin:

Overall, a success to bring people together to discuss this topic. However,
there are gaps that need to be addressed between the proponents and the
community together, and bring more diversity to the APN proposal. Using Jari's
comment, write an I-D with one specific use case and data plane technology, and
see if are able to understand how APN would work in this scenario.

**Selected Notes from MeetEcho during this part of the Meeting.**

Daniel Bernier: the trick is how an app developper can know what capabilities
are available from a given network (sdk ?)15:47:29 Shuping Peng: @Ron, the use
cases presented here are intended to be kept simple, clear and strightforward
so people could get the point immediately within the 10mintues presentation.
But since ietf108 we have presented so many times on the use cases and usage
scenarios and no need to repeat here and we already drafts15:47:48 Dino
Farinacci: that's why we only have TOS bits to play with Erik15:48:25 and TOS
has an advanage, you only have 8 bits of combinations, a feaure, less profiles
better15:48:59 Boris Khasanov: @Daniel - very important question! Agree that
APN should think about it too.15:49:25 Shuping Peng: @Dirk, we are not creating
new domains. We are building upon the existing networks.15:49:37 Dino
Farinacci: who you are? That can't be good15:50:05 Shuping Peng: @Daniel
Bernier, APN is only about the network15:50:43 @Dino: Many people confuse "who
am I" with "what are my attributes"15:51:04 Dino Farinacci: no its not, IMO,
its about the packets anyone or anything could send15:51:06 Kireeti Kompella:if
you weren't scared before, jim's made a case for really being scared15:51:07
That is even our definition of identity15:51:15 Watson Ladd: APN is about the
network doing what? feel like we've had the same conversation after 11015:51:18
Jim Guichard: @kireeti i am scary, terribly so ;-)15:51:44 Watson Ladd: if
there isn't a succinct usecase that doesn't fit existing work, the case for
doing it sounds week to me?15:52:00 Dino Farinacci: right, @cabo15:52:00 32
bits is not enough to tell who you are, need 1 or 2 more bits15:52:03 Dino
Farinacci: well a hash(jimG) could fit in 32-bits15:52:24 but just don't do
it15:52:29 Zhenbin Li: @Ted regarding your issues, though the entry/exit points
is flexible, the APN attribute must be carried along with tunnel in the domain.
Then the APN attribute will be removed along with the tunnel.15:52:52 Jim
Guichard: @kireeti maybe identify is a better way to put it so identity to
attribute mapping to be used to identify which policy to enforce15:52:57 But it
is nearly irrelevant for a router, no? What the application *is* (not wants) is
of interest — API (intent) indeed15:53:12 Zongpeng Du: IMO, APN is a kind of
network programming mechanism,and it increases the network intelligence
capability. It should be helpful to the operator, and hope it to be
flexible.15:53:20 Kireeti Kompella: @jim, post mapping, sure. but identity
itself? and location, what they are doing, ...? that gets truly scary15:53:58
Dirk Hugo: @Toerless: DIUYC that machines need no privacy? They are very often
strongly related to humans IMO15:54:39 Ted Hardie: @Toerless the fact it came
from a device and not a human does not eliminate privacy concerns, it changes
them. Consider the privacy characteristics of a set of CO2 sensors--within the
application they demonstrate which rooms are occupied and can tell you whether
a specific dwelling has people home or not. That still has privacy
implications, even though not emitted by a human. That's a very simple example,
but hopefully you can extrapolate to other applications from there.15:54:49
kaduk@jabber.org/barnowl: What different treatment will the network give my
traffic if I'm in finance vs. marketing?15:55:10 Jim Guichard: @kireeti sure
but locality is interesting and perhaps what you are doing in terms of which
application (not what your doing in the application)15:55:23 Dino Farinacci:
but how do you scale for "granular treatment" for 1000 flows on the other side
of that leased line?15:55:31 Lou Berger:@ted+115:55:34 Tony Przygienda:
Classify on the edge map on whatever tunnel flavor rocks your boat all done
last 2nr seemed like grappling for some nebulous usecase and since it’s not
apparently visible it seems general solution for the unknown case is summoned
??15:58:00 Dan Voyer: @kaduk@jabber.org/barnowl your question seems to also be
a question for slicing15:58:23 Shuping Peng: APN does not conflict with the
existing solutions on the fine granular network services such as network
slicing and detnet. APN is a way to express the services for the operators to
better perform service provisioning, which is for sure based on customer's
consent.15:58:33 Watson Ladd: why does the operator need that?15:58:44 they
already deploy slicing to deliver the service15:58:53 or MPLS to deliver the
service15:59:01 Toerless Eckert: @ted; i didn't say all m2m has no privacy
concerns, bit significant and important cases do not15:59:03 Kireeti Kompella:
the gap is in understanding what's there today15:59:27 Shuping Peng: this use
cases presentation has shown some benefits15:59:33 Kireeti Kompella: benefits
that are delivered by network slicing15:59:52 Zongpeng Du: we do not think it
is conflicted between Network slicing and APN16:00:12 Kireeti Kompella: great!
that's a good place to start16:00:28 Toerless Eckert: @ted: btw: still
interested to better understand your iabopen comment ;-)16:00:51 Lou Berger:
what does the apn architecture add that isn't in existing IETF architectures
and solutions16:00:59 kaduk@jabber.org/barnowl: Huge thanks to the chairs for
organizing/running the session and providing the summary at the end!16:01:25
Joey Salazar: +1 Martin, a draft is needed to clarify the points we've been
going in circles for a while