Minutes IETF100: teas
minutes-100-teas-00

                        TEAS Agenda -- IETF 100
                         Version: Oct 31, 2017
        Tuesday November 14th 2017
        09:30 - 12:00 - Tuesday Morning Session I
        Room: Canning

        Slides: https://datatracker.ietf.org/meeting/100/materials#teas
        Etherpad:      
        http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-teas?useMonospaceFont=true
        Meetecho:       http://www.meetecho.com/ietf100/teas Audio stream:
        Jabber: xmpp:teas@jabber.ietf.org?join

        Available post session:
        Recording:     
        https://www.ietf.org/audio/ietf100/ietf100-canning-20171114-0930.mp3
        YouTube:        https://www.youtube.com/watch?v=CeQdMtuWpPk

#  Start Time Information
0  9:30  10    Title:  Administrivia & WG Status
               Draft:
               Presenter:      Chairs

Lou Berger: please use the list for discussions. If draft authors discuss
changes amongst themselves and publish a new version then it still needs to be
discussed on the list. However, if discussion on the list results in changes,
then that can be considered WG consensus.

1  9:40  5     Title:  WG Draft updates
               Draft:  Many
               Presenter:      Chairs

Pavan Beeram: We didn't receive an update from the pcecc-use-case draft. Would
be useful if the authors can get an update sent to the list. Authors of the
te-metric-recording draft still need to address/discuss the comments sent out
mid-last-year.

2  9:45  5     Title:  Post pub request update: 
draft-ietf-teas-network-assigned-upstream-label
               Draft: 
               https://tools.ietf.org/html/draft-ietf-teas-network-assigned-upstream-label
               Presenter:      Vishnu Pavan Beeram

Lou Berger: there were no technical changes since the last revision, right?
Pavan Beeram: No
Lou Berger: generally we do not do an additional LC if there are no technical
changes post-LC so we can proceed without a second LC

3  9:50  5     Title:  Post pub request update:
draft-ietf-teas-rsvp-te-scaling-rec
               Draft: 
               https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec
               Presenter:      Vishnu Pavan Beeram
<no comments>

4  9:55  10    Title:  Post pub request update: draft-ietf-teas-lsp-diversity
               Draft:  https://tools.ietf.org/html/draft-ietf-teas-lsp-diversity
               Presenter:      Dieter Beller
<no comments>

5  10:05 10    Title:  LC Update: draft-ietf-teas-yang-te-topo
9:46           Draft: 
https://tools.ietf.org/html/html/draft-ietf-teas-yang-te-topo
               Presenter:      Xufeng Liu

Lou Berger: Poll: how many have read the latest version?
 - A good number
How many are planning to augment this model (e.g. in CCAMP)?
 - Also a good number
If you're working on an augmentation please rlease review the guidelines on
augmentation guidance in the latest version and send feedback to the list in
the next two weeks.  Would like feedback before submitting for publication in
~2 weeks. Positive feedback is also very useful.

6  10:15 15    Title:  RSVP/TE YANG Models Update
               Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp
               https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te
               https://tools.ietf.org/html/draft-ietf-teas-yang-te
               Presenter:      Rakesh Gandhi

Lou Berger: I sent a message to the list commenting on the need for referencing
RFCs that define the feature being configured, can you comment on this? Rakesh
Gandhi: We have references in some places, but not all.  We agree to go and add
missing references to the docuement. Lou Berger: it's really good to have
references to where the original features were defined so that everyone
understands what is intended. Lou Berger: there are three pieces to the yang-te
draft, general, RSVP-TE and MPLS-TE, does it make sense to split in three
different documents? Generally we try not to put separate technologies into the
same document. I'm talking about splitting the document into three WG documents
and moving quickly to WGLC, not restarting the entire process. Rakesh Gandhi:
we did that for RSVP we had two and now we have three, we can split as needed.
Lou Berger: it would be good to hear from the WG. Poll: How many think it is
better to split generic and technology-specific part?
 -  A reasonable number.
How many want to keep it as it is?
 - None.
Sounds like we shoudl split the documents and submit the new ones as WG drafts
Rakesh Gandhi: OK
Xufeng Liu: what about te-types?
Lou Berger: it's generic. Is there any reason why we shouldn't keep it in the
generic documents? Xufeng Liu: The te-types will be shared by topology and
tunnel models. Ok to keep the te-types in the same document

7  10:30 10    Title:  ACTN Info model
               Draft: 
               https://tools.ietf.org/html/draft-ietf-teas-actn-info-model
               Presenter:      Sergio Belotti

Lou Berger: we are going to check that all the IPR declarations are there and
then we can issue a WG LC on this draft together with the requirements and
framework draft

8  10:40 5     Title:  ACTN YANG applicability
   10:13       Draft:  https://tools.ietf.org/html/draft-ietf-teas-actn-yang
               Presenter:      Haomian Zheng

Michael Scharf: On slide 3, there is some confusion between the L1CSM and the
VN Member. The draft doesn't well define how they relate to each other and
whether they overlap. Haomian Zheng: VN model provide a high-level description
on how the virtual network is described. While L1CSM is used to support the
L1VPN service. Michael Scharf: We need a clear defintion of the differences so
that a CMI user can understand how to establish different service types.
Especially for layer 1 we need a precise definition of what the difference is
and why we need two different things, and how the customer would use this, e.g.
how to set up a VN member, how to set up a L1 member, etc. The document doesn't
explain these concepts well. Haomian Zheng: OK - well discuss more offline and
update the docment. Lou Berger: How does the service model in this draft
related with the transport-service model that presented a few meetings ago?
Haomian Zheng: That model (transport service) is to describe the client-server
relationship in multi-layer network, which applies on MPI. The current service
model is used on CMI, which is different. Jeff Tantsura: Don't be fixated with
a specific transport protocol (NETCONF/RESTCONF), gRPC is another option; focus
only on the YANG models. LouBerger: the draft should only mention the YANG
model and say nothing about how they are transported.

9  10:45 10    Title:  ACTN VN YANG
               Draft:  https://tools.ietf.org/html/draft-lee-teas-actn-vn-yang
               Presenter:      Dhruv Dhody

Igor Bryskin: what you describe is exactly what TE Topology can do it right
now. The customer can configure and view an abstract topology that has nothing
to do with the native topology. Dhruv Dhody: TE Topology and Tunnel model are
required to provide the attributes that network element and SDN controller
needs, but not to show to the customer. In the IETF we've found it helpful in
the past to have separate models for the customer view and the provider
network. In theory it is possible to use TE Topology but using VN allows
specifying the policies and let the MDSC to further translate rather than
having the customer to configure all the detailed attributes. So, for example.
you can set up a policy to optimize links for for delay and all the details of
how that's actually done are hidden from the customer. The customer view comes
from the CMI and is the job of the MDSC to translate that into the real
provider network. So we need to decide whether we want to do everything with
the same model or whether we want a customer-facing model that only deals with
the things that customers care about. Igor Bryskin: So what can't be done with
the topology? In our view, it is different layer of abstractions but it is the
same topology. Dhruv Dhody: The example I gave for link optimization is one. We
reuse the abtract topology model where we can, but having a VN model as an
entity towards the customer helps. We also want to ask if having the same model
at all layers meeting requirements for device, network as well as service and
exposing all these details towards the customer is a good idea? Lou Berger:
generally in this group we try to re-use the solutions that we already have and
to define things in a generic way so they can be used in multiple layers. We
are trying to use the same models. There may be some missing attributes. We
need to understand what it is missing before deciding whether we wish to define
new models or augmenting the existing models. This was one of the changes I
requested in the Framework document Micheal Scharf: I want to back what has
already been said regarding applicablility of TE topology and tunnel models.
It's not clear to me why a new model is needed. Bear in mind also that the
relationship between the MDSC and the PNC could be a business relationship or
it could be an internal interface within the same organization, and the
attributes you expose between layers could be different in each case. I think
you'll need a lot of the attributes in the TEAS models in the VN models too.
Applying a policy to a set of tunnels is also something we don't need to solve
here. Dhruv: I agree, but we are considering the case where a business
relationship exists Michael Scharf: But that's just one case. The Framework
document has a clear use case where the relationship is not external. Dhruv
Dhody: I agree. Since this model refers to the topology mmodel it abstracts
things, and if you want more details the reference is there so you can go to
the topology or tunnel model and find those details. But we don't think the
fact that abstraction isn't always required means it shouldn't be available.
Young Lee: the VN concept is needed to  express customer's demand, but we don't
want to reinvent the wheel so we re-use many things from the tunnel and
topology models Lou Berger: there is no disagreement that the VN concept is
useful, but the disagreement is on how to realize the VN concept Young Lee: To
answer Michael's question, customers don't care about diversity becasue they
have SLAs. They may have requirements on delay, etc but they don't need that at
the VN level. Micheal Scharf: I disagree on that. In a use case I have,
diversity is needed so we need to add diversity to the CMI. If we can't have
that, why are we doing traffic engineering? Young Lee: we aren't doing traffic
engineering for the customer - the SLA takes care of that. Lou Berger: I think
this highlights the range of requirements customers may have. In my experience
in transport networks being able to tell the customer that you're using a
diverse path is important and if we presented an interface that didn't include
that they'd never use it. But that's just one use case, and in others the
customer may not want that. Young Lee: our main case is where CMI is the
demarcation between the network and the customer Lou Berger: I'm thinking of an
external customer. I think it would be worthwhile the authors to take the TE
Topology model and see how it can be augmented and what leaf in the TE Topology
is not needed and can be marked as optional. YANG provides the ability to not
use everything that is in the model. Dhruv Dhody: one thing we found is that a
simple TE topology is pretty straightforward, but what we do in type 2 VNs with
full-mesh, hub-and-spoke, etc is very messy in the TE topology. Who talk to
whom and what are the properties of objects. It's easy to ask for bandwidth on
a link; it's not possible to ask to optimize the whole network for delay.
That's why we felt it was better to start a new model, but we can go through
the TE model and see what's needed. Pavan Beeram: that would be very useful. I
don't think anything mentioned so far is hard to do with the topology model,
but working out where the topology model is lacking would be useful. Daniele
Ceccarelli: the problem is not what is missing but what is too much. The
customers who just provide connectivity between endpoints do not want to know
anything about tunnels and topology but just being able to request connectivity
between two points without caring about multiple domains or multiple
technologies. The VN is intended to cover this simple case. Lou Berger: There
are different cases and we wish a solution that can cover a range of use cases
and we have to figure out the right way to do that. Daniele Ceccarelli: in many
cases, if you tell a customer to deal with a topology they won't want to. Lou
Berger: you could use the topology model but only supply endpoints; I think
that's the solution Pavan suggested earlier Igor Bryskin: optimizing an
abstract topology can often be a single attribute as you're only optimizing for
one thing. A single-node or mesh topology is also very simple. When people say
it's too messy to do with the TE topology, I'd like to see what exactly is
messy. Dhruv Dhody: I think this an exercise for the authors - we'll take it
offline. Lou Berger: You also need to address Daniele's point - is there too
much that's always required and could be optional or a feature-set. Pay really
close attention to nodes that are mandatory and those that aren't. Jeff
Tantsura: for customers, what matters is the ability to express constraints.
Physical diversity is a business requirement and when I was a customer I would
ask for cable layouts. So you absolutely must have the ability to express this,
but it doesn't have to be mandatory. Most people will work at the level of SLAs
but the details need to be there for those who need them. Dhruv Dhody: it's
there, but not at the per-tunnel level. What we do is say that all members must
be diverse for the whole VN so we have redundancy. We can do this via the TE
topology model, but is it too complicated? e.g. if I have a full mesh and make
a change, I have no way to say I'm making a change to the VN as a whole; it has
to be on each tunnel. Jeff Tantsura: it's about the ability to express what you
need. Dieter Beller: for VN Type 2, I do not understand why the TE Topology
model cannot be used because these use cases were considered when developing
the TE Topology model. We were specifically looking at this when we developed
the TE topology model. Dhruv Dhody: yes, we used the TE topology and referenced
it. We are maintaining per-VN data like policies in this model. We also include
operational data as well as configuration, so I can use this model to see how
the VN as a whole is functioning without looking at each tunnel, link, etc
individually. Lou Berger: so there's some homework for the authors before we
discuss WG adoption.

10 10:55 10    Title:  ACTN telemetry
   10:59       Draft: 
   https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics
               Presenter:      Young Lee

Michael Scharf: Two questions. First, this model contains technology-specific
attributes (e.g., packet loss). Need to think about how to deal with different
technologies and how to model it, e.g., defining different augmentations and it
isn't clear how you do that. Second, scaling policies can be complex and
include e.g. also business logic. Do we really want to encode this in such a
YANG model? And what about policies beyond scaling? Young Lee:  We thought
packet loss was generic, but TDM may think about BER. It could be augmented in
CCAMP. On scaling, I agree that isn't really telemetry. We could take it out
and put it in a separate model if people think it's useful. Lou Berger: where
you're augmenting the TE topology with things that are truly generic then it
would be good to get them in the TE model before we close it. Could you send
them to the list soon so they can be discussed and we can work out whether we
should bring it in? Pavan Beeram: some of the attributes you are augmenting
from the TE Tunnel are already there in the base model. Young Lee: I think the
TE model has more link statistics than tunnel statistics Pavan Beeram: there's
per-link statistics in the topology model, and then some statistics for the
tunnel as a whole. Young Lee: the tunnel is per-domain? We're talking about
C-to-C tunnel Lou Berger: we're running short of time, so we should take this
to the list Jeff Tantsura: usability: you can want to compare your operational
state with your intended state, and we recently published a draft with a
compare operation for this based on filters. That would be useful here.

11 11:05 10    Title:  ACTN TE Service Mapping
   11:11       Draft: 
   https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang
               Presenter:      Daniele Ceccarelli

Michael Scharf: these examples are too simple and unrealistic, please add more
realistic use cases in order to explain what you want to map to (e.g., when
talking about L3VPN, an actual topology with PE, P, and ASBR routers, tunnels,
etc.). An optical network may be an underlay of the IP network. And there's
contradictions between this and the framework document. Daniele Ceccarelli:
these are not the latest slides, the latest version should make you happier
Michael Scharf: same comment applies to the latest slides in datatracker. Lou
Berger: are your comments to the slides or to the draft? Michael Scharf: Both.
The draft has less than the slides. We could do with an example L3VPN over two
ASs. Lou Berger: we're running short of time but it would be great if you could
get together this week to discuss what's missing.

12 11:15 10    Title:  TE Topology and Tunnel Modeling for Transport Networks
   11:20       Draft: 
   https://tools.ietf.org/html/draft-bryskin-teas-te-topo-and-tunnel-modeling
               Presenter:      Igor Bryskin

Lou Berger: (Poll) How many think it is a useful work for the WG? A good number
        How many have read the document? Also a good number
        How many think this is a good foundation? Also a good number

We'll take this to the list

13 11:25 15    Title:  Consideration for applying PCE in native IP network
               Draft:  https://tools.ietf.org/html/draft-wang-teas-ccdr
               https://tools.ietf.org/html/draft-wang-teas-pce-native-ip
               https://tools.ietf.org/html/draft-wang-pce-pcep-extension-native-ip
               Presenter:      Aijun Wang

Adrian Farrel: Can you confirm that you are not doing anything special in the
forwarding plane that isn't already achieved today using CLI to install static
routes. In other words, your proposal is about introducing a central controller
and standardardised southbound protocol, and not any change to how the network
works. Aijun Wang: Yes. We don't want to change the network. Lou Berger: Poll:
How many are interested TEAS WG to work on TE for IP network, independently of
this or another solution? A few people, more than I expected If we say to do
this an experimental work and provide a home to foster this, how many would be
interested? (asking for those who have raised the hands before, not to raise
again): Jeff Tantsura: if there's interest, we should give it a change Lou
Berger: we'll take this to the list towards an adoption call as experimental.
That covers the first document, and the last is definitely PCE. I'd like to
hear from the PCE Chair on where they think the second document should be. Jon
Hardwick (as PCE chair): This was discussed in PCE a couple of meetings ago. I
wanted this to come to TEAS because I wanted some guidance on whether this is a
problem we all want to be working on, and an adoption poll in TEAS would answer
this. I don't think we're ready to adopt solution work in PCE yet.

14 11:40 10    Title:  Use Cases for SF Aware Topology Models
               Draft: 
               https://tools.ietf.org/html/draft-bryskin-teas-use-cases-sf-aware-topo-model
               Presenter:      Igor Bryskin

Dhruv Dhody: Is this model useful with VxLAN? Is this model only for when the
underlay is a TE tunnel? igor Bryskin: we don't want to narrow down to TE
tunnels - it could be any other tunnel. The point is that it doesn't matter
where the service functions are in the topology. Dhruv Dhody: if I have a
choice between the same service function being available in multiple places, I
can make a good decision on which service functions I should choose. Igor
Bryskin: I agree

15 11:50 10    Title:  SF Aware TE Topology YANG Model
               Draft: 
               https://tools.ietf.org/html/draft-bryskin-teas-sf-aware-topo-model
               Presenter:      Igor Bryskin

Lou Berger: Interesting work - we'd definitely like feedback on the list.

Lou Berger: something I forgot earlier: there's no joint yang session this
time. I'd like to get feedback from the WG on whether that's a good or bad
thing and we'd love to hear from you. Himanshu Shah: we asked for LC on our
associated co-routed FRR draft and it hasn't been mentioned. What's the status?
Pavan Beeram: it was updated yesterday, so we'd like to see it discussed on the
list.

Adjourn         12:00