Minutes IETF99: teas: Thu 13:30
minutes-99-teas-201707201330-00

==============================================================================
TEAS Session 2 -- Joint with CCAMP, MPLS, PCE
==============================================================================

>
> Thursday July 20th 2017
> 13:30 - 15:30 - Thursday Afternoon Session I
> Room: Congress Hall I
> Meetecho:  http://www.meetecho.com/ietf99/teas
> Audio stream  http://ietf99streaming.dnsalias.net/ietf/ietf993.m3u
>
> Num Start #Min Information
> 0   13:30  10  Title:  Administrivia
>                Draft:
>                Presenter:  Chairs
> 1   13:40  15  Title:  YANG Data Models - TE Topologies
>                Drafts: 
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/ >               
         https://datatracker.ietf.org/doc/draft-liu-teas-yang-l3-te-topo/ >    
                   
https://datatracker.ietf.org/doc/draft-liu-teas-yang-sr-te-topo/ >             
  Presenter:  Xufeng Liu

Rob Wilton: It looks like you produced the -state models by hand and optimized
the size of them, which is fine, but an easier way to create the -state model
could be to just copy the NMDA model and change the name and namespace
namespace with -state Xufeng Liu: size is a factor, and another motivation is
that we don't want to have duplications as they create maintainability issues.
We're looking for a tool to fully automate this. Rob Wilton: we will check the
tools. Also, the state modules are intended to be temporary; once the NMDA
models are ready the state modules will be deprecated as they'll no longer be
required. Xufeng Liu: Yes. But some protocols may chose to use state models if
they don't want to support multiple datastores. Tarek Saad: I have understood
that the -state holds the applied configuration, do we need a -dynamic model
for the dynamic data? And if future modules wish to augment this one, will they
have to augment the model itself and the -state model, and maybe the -dynamic
model too? Xufeng Liu: Yes Rob Wilton: -state model serves two purposes. One is
to support the applied configuration value, and the other is allows you to
report system created interfaces. There is no intention to have a -dynamic
datastore; the intention is that you require a NMDA-compatible implementation
to work with dynamic datastores. Tarek Saad: There are implementations that
support dynamic creation of objects. How do these work until NMDA comes along?
Rob Wilton: They stay in the -state tree. Tarek Saad: does -state hold applied
but not dynamic config? Igor Bryskin: This is a good gernal discussin, but in
TE topology model we do not consider dynamic datastores. Lou Berger: AD
recommendation is that the -state model contains both applied and
system-created information, so system-created could be dynamic for a particular
model.  If there is some other type of "dynamic" not covered by this then we
should discuss that, but no-one has identified that yet. Sue Hares (I2RS Chair
hat): The benefit of the topology model with NMDA is that it can be loaded in
the dynamic ephemeral datastore without problems. I think you need to be
careful to disambiguate between dynamically-created data and the dynamic
datastore.

Sue Hares: There is a deployed non-NMDA BGP model which is hopefully a basis
for this SR addition.  We are working rapidly on an NMDA model.  Do you
anticipate data coming from a BGP NMDA model plus an augmentation for serviced
routing to be lent to your SR-TE toplogy model? Xufeng Liu: They are working on
SR TE model to make it NMDA. Sue Hares: So as a guiding Chair I must make sure
that all models align wrt NMDA. Pavan Beeram: The model we discuss does not
cover SR-TE policy. Sue Hares: there are two types of policy: BGP policy
relating to SR-TE, and basic SR policy. Which one were you talking about? Pavan
Beeram: right now this is only SR-specific extensions to the TE topology. TE
policy mapping is not covered here, but we can discuss where that needs to be
modeled.

> 2   13:55  15  Title:  YANG Data Models - TE Tunnels and Interfaces, RSVP-TE
>                Draft: 
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ >                    
   https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp-te/ >            
   Presenter:  Tarek Saad

YANG-TE

Sue Hares: you said you had an update for stitching in tunnels. Did you ever
look at points of encapsulation and decapsulation besides labels? Tarek Saad:
our generic TE model is independent of the technology and labels can be packet
or non-packet and there are other modules that are packet-specific. The label
in the model is a generalized-label and doesn't use packet label types.

YANG-RSVP-TE

Rob Wilton: when you have a NMDA model, the operation datastore will contain
the dynamic data. The -state can be thought as a pre-standard implementation of
an operational datastore Tarek Saad: my understanding is that there's two
datastores, applied and operational: will there be a dynamic datastore? Rob
Wilton: potentially, for I2RS only. Tarek Saad: We have lots of dynamic state
in this model Rob Wilton: all models have a lot of dynamic state (e.g. BGP
peers). That isn't an issue. Rob Wilton: let's discuss offline Sue Hares: I2RS
is creating a dynamic datastore, we can help on this. The folks who wrote NMDA
made a datastore template.

> 3   14:10  15  Title:  Yang model for requesting Path Computation
>                Draft: 
https://datatracker.ietf.org/doc/draft-busibel-teas-yang-path-computation/ >   
            Presenter:  Sergio Belotti

Igor Bryskin: There are some important and useful open issues, like the lack of
order of relaxation of constraints, which are easy to address. Some are
misunderstandings like the last one regarding local protection: we are not
assuming the existance of signalling in the TE Tunnel model. Protection is
important not just for provisioning tunnels but also path computation. Sergio
Belotti: we're just missing LSP state. Sue Hares: the base topology model is
going to WG LC. The base question from YANG doctor is whether we are doing just
read/write operations, or RPC as well. Pavan Beeram: given the topic discussed
in the draft, the RPC is what they are looking for Sue Hares: I agree RPC is
what is needed here. Need to discuss if the TE Tunnel model needs to support
all three Pavan Beeram: yes, well allow all three in the base model Sue Hares:
will you allow edit-writes too? Pavan Beeram: we are not preculiding them at
this point Pavan Beeram: we don't normally poll in the joint WG yang session,
but given the overlap with PCE I'll make an exception.
       (poll) How many have read the latest version of this doc? A few.
                  How many think it's ready for WG adoption? more
                  Will take it to the list.
Jeff Tantsura: It may be worth reviewing this with external folks
(YANG-doctors, etc) while it's going through WG adoption. Pavan Beeram: we
don't have a set policy on that, but yes, it makes sense. Jeff Tantsura: it
makes the document quality better Lou Berger (TEAS chair hat): if you do it too
early you're getting feedback on something that's immature, so the yang doctors
should know that. Jeff Tantsura: there are other people who know yang besides
the yang-doctors *volunteers to review the draft* Italo Busi: can we share the
document with PCE, given that there's common ground? Lou Berger: we've had this
before. Agreement with PCE is that TEAS will focus on the architecture side and
PCE on the PCEP side, but this covers both. It's easy to keep both groups
informed while we're running these joint meetings. Sergio Belotti: the authors
sent all open issues to the list, so they can be discussed there.

> 4   14:25  15  Title:  A Yang Data Model for WSON Optical Networks and tunnels
>                Draft: 
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-yang/ >                 
      https://datatracker.ietf.org/doc/draft-lee-ccamp-wson-tunnel-model/ >    
           Presenter:  Young Lee

WSON Topology:

Daniele Ceccarelli: once the TE topology model is approved, what's left to do
on this draft? Young Lee: we do not have impairment validation here, although
that exists in WSON GMPLS. If people feel we need to add here, we can do that
or we can have a separated YANG model augmenting this one.

WSON Tunnel:

Dieter Beller: I have a question about CCAMP WSON YANG drafts defining the
connectivity matrix, why not reusie the connectivity matrix defined in the TE
Topology model? Young Lee: when I have started this one, it was a
technology-specific connectivity matrix so we have sligthly different
implications Dieter Beller: I think is quite the same as the TE Topology model
Young Lee: Actually we augment the connectivity-matrix in TE Topology model,
but we have to specify WSON references for interface types. Dieter Beller: I am
asking why you need this augmentation at all, but we can take the question
offline. Igor Bryskin: Agree with Dieter; in connectivity matrix we have all
parameters that are sufficient for all layers across the technologies we use,
so there is no need to augment this information. Young Lee: Abstract topology
will have generic model, but over time you have included specific encoding.
That is an issue for CCAMP to resolve. Your model was written after this work.
Igor Bryskin: we started with the optical layer and then realized this wasn't
specific to that layer, and applicable to abstract nodes an any layer. Young
Lee: Charter for TEAS is to produce a generic model - you are violating the
multilayer assumptions. Either way is fine but we need to decide as we have
other technologies (e.g. OTN, flex-grid). Igor Bryskin: if flex-grid needed
more imformation they could augment the topology model, but so far nobody sees
the need for this. Lou Berger: this is a classic discussion for CCAMP, where we
start with something technology-specific and once we have a solution we had to
take a step back and see what is generic and should belong to the generic
capabilities. After the specific is done, it is the right time to step back and
look at what aspects can be abstracted to be generic. It's always tough for the
people who have done the work on their technology as they feel like they're
finished and want to ship the draft, and we have to respect that... but if we
don't do it we don't end up with generic and re-usable capabilities. Dieter
Beller: regarding the connectivity matrix, it may indicate limitations such as
switching capabilities, should it be a read-only parameter? Young Lee: yes,
should be read-only for topology, and configurable for tunnel model. Igor
Bryskin: for physical ROADM this is probably true but if you see the node as an
abstract representation of a domain, you can configure the desired connectivity
matrix. e.g. you can add path setups to provide optimization. For this reason
in the base topology model we have made it configurable but for physical ROADM
it is only reporting what is feasible and what is not.

> 5   14:40  15  Title:  OTN Topology YANG model and OTN tunnel model
>                Draft: 
https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/ >             
          https://datatracker.ietf.org/doc/draft-sharma-ccamp-otn-tunnel-model/
>                Presenter:  Zheyu Fan Daniele Ceccarelli: just a correction to
the agenda, the OTN Tunnel model is now a WG document: it became a WG document
right before the start of the meeting

Igor Bryskin: when we have started working on the TE Topology and Tunnel models
we adopted the strategy to produce technology-specific augmentations but more
recently we've found that this works well for TE Tunnel but not well for TE
Topology. One reason for this is that in the topology, links could belong to
different layers, and it is not clear which augmentation to use in case of
multi-layer topology as well as in case of multi-functional links. We came to
the conclusion that it might be better to introduct layer-specific types rather
than layer-specific augmentations. It is a very important question to know how
to go about that Young Lee: That's very useful. Where do you take these types?
In a separated YANG module? Igor Bryskin: yes Young Lee: that makes sense
Haomian Zheng: we are looking for a stable TE generic models from which to
generate layer-specific models Igor Bryskin: it is fine to have layer-specific
augmentation if you have more constructs, but if you have layer-specific
attributes, it is better to define layer-specific types rather than
augmentation. Example: FRR applies to the packet layer but not to others, but
if you want to have layer-specific parameters for link, you need layer-specific
types. This is similar to what we used to do in GMPLS where we defined
layer-specific TLVs. Haomian Zheng: I think almost all the parameters here are
from existing RFCs. We aren't creating anything new.

> 6   14:55  15  Title:  Extending YANG for events, actions, and finite state
machine >                Draft: 
https://datatracker.ietf.org/doc/draft-sambo-opsawg-ccamp-supa-ext-yang-fsm/ > 
              Presenter:  Nicola Sambo (remote)

Daniele Ceccarelli: this draft was linked to CCAMP, OPSAWG and SUPA. To CCAMP
because it started with an optical use case but it could be generalized: CCAMP
can do the technology-specific extensions but the base work should be done in
other places, not clear where. Haomian Zheng: considering the use case, it
seems you are trying to trying to optimize the message flow in order to improve
the performance. Are you introducing additional functions? Nicola Sambo: It is
not to optimize performance; we have some performance parameters to monitor
which have to stay inside an acceptable range. It is enough that it is in the
aceptable range. If outside the range and becoming critical, creating problems
to the service, we then take some action. Our use case is more related to
maintenance of the service. Greg Mirsky: I agree with your statement about
generalization of this work. A couple of pointers: work in LMAP that defined
their framework and data model for a controller that performs performance
measurement and passes the information to a collector which can then monitor
quality of service and uses a new performance-measurement registry. Secondly,
if we talk about packet networks, then there will be more than one metric that
will be monitored, so the mechanism should be extended to combine multiple
metrics and then allws an ability to define when something goes in and out of a
degraded state. Nicola Sambo: Our work started with optics but we tried to make
it generic. We should think about packet networks. It can be a use case; any
discussion on use-cases on the list is welcome. Regarding performance
monitoring, the work you cited can stay parallel to this work because we are
not defining any way of monitoring, but our system will exploit some monitoring
system. Dieter Beller: I have a question about the use case that's used as the
major motivation for this. I have understood that the optical transponder can
autonomously change its mode of operation depending on the signal quality.
Typically when the signal degrades you have to switch to a modulation scheme
that also has an impact on the service datarate, which is typically reduced.
That means that if a transponder that can carry 2x100GigE degrades, it will
only be able to carry 100GigE. This has an impact on the services that have to
be dropped and I have doubts about whether this should occur autonomously. I
would prefer that an SDN controller or NMS subscribes to receive telemetry data
from this transponder and that an alarm be raised, and then the controller can
take action e..g, re-routing some services, or the operator can do something,
rather than letting the transponder autonomously take actions that may impact
traffic. I do not expect these events to happen very often. Nicola Sambo: the
use cases come from the Orchestra project with services that admits the
reduction of the rate under some conditions. Amy: if you wish to speed up the
rate reconfiguration this could be done by the data plane without involving the
control or management plane. Secondly, the work is generic: we have a similar
feature in microwave networks. Nicola Sambo: regarding the first comment, I do
not see another way to re-adapt the transmission parameters without going to a
centralized controller with the current state of the art and this is time
consuming Amy: you can make the decision on the node itself Nicola Sambo: maybe
you can do that in a single-vendor scenario while it not easy in a multi-vendor
case without going through a centralized controller Amy: this is already done
in microwave systems, we can discuss offline Jeff Tantsura: a few comments on
extendability. Splitting your use cases might make it easier for people to
consume, especially as you go to the packet layer. Secondly, your conditions
are binary at the moment, and in the packet layer they won't be. Thirdly,
usually there's a number of conditions on which you'd want to perform logical
operations in order to come to a conclusion. Pavan Beeram: further discussion
on the technology specific use case to continue on the CCAMP mailing list

7     15:10  15  Title:  BBF Yang Update
                 Draft:
                 Presenter:  William Lupton (BBF Liaison Manager)

Lou Berger: Are you aware that ietf-interfaces will be revved?
William Lupton: Yes
Lou Berger: It is good for this group to know that - please see the netmod list
for information. William Lupton: several of the drafts presented today have had
a section on NMDA, and that will impact us too. Lou Berger: I wanted to make
sure BBF was aware of it. William Lupton: We are now :) We will be impacted
both by the updates to the interfaces and entity models. I think our reaction
is likely be in line with the IETF's own WGs. So you will delete the state
tree, rather than deprecate it? Lou Berger: I am just saying that the update is
half-way done.

William Lupton: We are interested in having the alarm management draft updated
in CCAMP. Daniele Ceccarelli: It is an individual draft so we have no power
over it - please contact the authors. William Lupton: I have done so. Hopefully
there will be progress before the next meeting. We haven't decided to what
extent we'd like to augment this draft vs bringing some proposals back to the
IETF. Lou Berger: You can submit an alternate individual draft. William Lupton:
We'd prefer to work with the authors. We do understand that our members have to
bring proposals into the IETF rather than make demands.

Jeff Tantsura: We started a discussion a few IETFs ago about SD1 data models. I
heard BBF are working on that so we would like to cooperate. William Lupton:
Hopefully there will be some projects where non-members can contribute, but we
do recognise the problem of some work being done in a closed environment.

Pavan Beeram: that's all: see you all in Singapore.
> Adjourn 15:25

Minutes by Haomian Zheng, Italo Busi, Matt Hartley