Minutes IETF100: opsawg
minutes-100-opsawg-00

[ Warren Kumari Note: Thanks to Elliot Lear (and others) for taking minutes ]
Agenda bashing/Note Well
We bashed the agenda - no change.

draft-mm-wg-effect-encrypt

Kathleen's presentation

Goal- document issues that are introduced by encryption at different layers. 
Goal is not to try to address all of the issues raised.  Each section could be
a draft on its own.  We just try to document the current state. She discussed
motivations for encryption.  They vary based on type of network because...
Impact varies depending on the type of network. This draft is meant to be an
initial step toward balance with regard to network management/monitoring.
Briefly reviewed opportunistic encryption. TLS 1.3 and potential issues.
Kathleen's view: absent having this discussion "head on" we won't see the
adoption of encryption that we like Ad Injection.  An example where providers
found a way to prevent encryption. Load balancers and DPI could use a bit more
attention. Content filters and load balancing proxies could use a little more
attention. Tried to get diverse input.  Got it for DDOS- not so much elsewhere.
ALPN needs some work because it's a moving target. Mobility needs some
updating. Sometimes sharing more on operational practices may help make
encryption more acceptable.

Discussion:

{Couldn't get name} from Huawei}: one could be talking about the impact of
network management on the security of the network. Warren: Read the document! 
Tone has changed substantially! Lee Howard:  I've skimmed, but great balance on
tone.  I will review it as much as I can.  Please others review. Mike Ackerman:
why is it different when things are in a cloud-hosted environment? Kathleen:
motivations are different. Mike: things get a little darker when in the cloud.
Ignas Bagdonas: Different language used between here and operational community.
  Maybe we need to translate this document to get more info from the
operational community.  Better examples, for instance, around IGP snooping. 
(Russian speaking) ENOG, EuroIX, RIPE meeting, smaller country operator groups.
Benoit: can you quantify? Ignas: 500-600 for E-NOG 100 - RIPE sometimes
mid-digit 10s. Quite a lot of security aspects depend on network design.  Some
assumptions of what goes where (like in our out of the data center) may not
always reflect actual deployments.  Each deployments are unique, although there
are some common denominators that may not align to what is in the document.
Does this mean that encryption is evil and we should do less of it? Kathleen:
really no.  It's all about how to get encryption deployed. Benoit: we should be
documenting what we may be losing with encryption. Kathleen: we need to
document difference between 5-tuple and 2-tuple in terms of impact. Darin
Pettis: I'm an operator. There are some very real needs here.  Definitely
looking for the balance you discuss.  There is a lot of finger pointing between
cloud and enterprise *is* an issue. Joel Jaeggli:  We have over time revisited
technologies and decided to abandon them.  Some mechanisms change out of
necessity.  We may need to address the most problematic tools that are well
deployed. Kathleen: goal of the document is to highlight what is changing. Lars
Eggert: not speaking as chair, we have a challenging problem with QUIC.  One
option in QUIC is to expose hidden information to authorized parties.  But just
because information is going to move into the clear doesn't mean you can trust
it because the protocol machinery may not act on it.  It would be awfully nice
to {know?} {whether operators would accept untrustworthy information}

Supervised Heterogeneous Network Slicing
Liang Gang
Outgrowth from BoF at IETF-99:
Should we still do network slicing still in the IETF?  YES.
We don't have a consensus on what a network slice is.
A network slice is a dedicated network and a group of components, and
generalized (physical or virtual) service functions that can be exposed to
tenants. It has to be supervision, otherwise there is no service guarantee. See
ASCII art in presentation for the architecture. There are numerous domains
within the network.  Legacy, OT, Access. Components for network slicing: Common
Operation and Management for Network Slice == COMS Slide discusses flow. A
common information model is key. Also, life cycle management, monitoring, etc. 
From those come derived models. Southbound interface might need to be
standardized.  Neeed east-west interface.

Nurit:
5G does network slicing, please consider using a different term or one of the
existing definitions within the industry. Network slicing is end to end.  How
to get access, code, etc, put in place.  This must all work together. Concerned
that at the end of the day this solution may not be compatible with 3GPP. Liang:
   { Lots of internal discussion about the relationship between SA2 and SA5 and
   the IETF}
Plenty of end to end use cases just internal to IETF
Juerg Mayer:
3GPP does not have any official requirements towards the IETF.  What we said
last time: if the IETF sees a need to work on slicing, you should go ahead. 
Transport network is left out of our focus. This work is going on in parallel. 
We will for sure create some confusion, which is inescapable.  Look at it from
the IETF perspective for now, and then we will see what we can incorporate what
is appropriate for 5G. Nurit:
    We do need SOME coordination, and something that delivers a valid end to
    end solution.
Jari Arkko:
There are all sorts of technologies that we need to build on, like
orchestration software.  What is the specific work that we should do here at
the IETF?  Much of this is IETF technology.  It's our job to make sure that
this technology is up to speed for 5G use cases (for example). There will a
presentation in routing area working group on some of this (Jari and Jeff
Cantor). Data models is an area we need to work on.  How does it relate to
other data models? Mehmet I have an issue with the term "common information
model".  Give a more precise title. NFV has existed for many years, and there
are different SDOs working on information models tied to that. Some are useful,
others can be harmonized. Will you use an existing information model or create
it from scratch? Terms need to be harmonize with existing information models
and not do it from scratch. Liang: A common information model is
technology-non-specific.  Stil prefer this term Network configuration model is
the mapping to specific technology. Use cases: Customization, resource
utilization, and new technologies

Benoit:
    They are looking for a BOF at the next IETF.

Alex ?:
I don't think this group will create a common information model across all
SDOs.  This is just for network slicing {for what you are building}, but
because you use a lot of technology, you will need to coordinate. Need both
bottom up (from technology) and top down views and good linkage between the two.

Jari:
Success can also be we gain an understanding of what we need to do and place
that work into multiple different working groups. Let's first figure out what
we need.

Onward to the OPSAWG part of the meeting

Administrativia
Agenda
Working group status
Shepherd needed for draft-ietf-opsawg-ipfix-bgp-community-03
TACACS doc needs some additional review.

YANG data model for NAT
Draft has been around.
four revisions since last IETF.
Got some external review.
A number of reviewers contributed (Lee, Jordi, Fred, Tore Anderson, Rajiv
Asati). Updates on CLAT, NPTv6, NAT64, EAM. Support CGN Got YANG doctors review
Removed logging based on feedback. Had to clarify relationship with NAT-MIB

Eliot:
 how many revisions did you go through between the last [missed (last ietf?)]
 and this one.  You should go through WGLC to produce a yang model with some
 lacrity

MUD update
Changes coming up from WGLC and IETF LC
Tied to JSON compatability
If you have an objection speak up soon
model number
element that specifies name for signature will be needed
Going back to UTF-8
Propose to ADs: pause for a little while and wait for apple model and then
create a new draft for IESG review next steps: extensions to the model will
come in London

Joe C:
    Have you asked operators?
"yeah, ok..." and don't care much

Network Data Use Case for Wavelength Service
Chen Li

This was a presentation that went into OAM with Wavelength service.

Eliot:
need 2119 language
What do you want to do with this work?
It's accademic
I'm not sure we have the right reviewers [here]