Minutes IETF104: teas
minutes-104-teas-00

INSTRUCTIONS:
Please find the related presentation slot below and add/correct notes there.
Please DO NOT add notes at the end or beginning.

NOTE TAKERS ADD YOUR NAMES HERE (not required):

Daniel King
Haomian

> TEAS Agenda For IETF 104
> Version: Mar 13, 2019
> Session 1: Tuesday, March 26th 2019
> 11:20 - 12:20 Tuesday Morning Session II
> Location:       Congress Hall 2
> Slides: https://datatracker.ietf.org/meeting/104/session/teas
> Etherpad:      
http://etherpad.tools.ietf.org/p/notes-ietf-104-teas?useMonospaceFont=true >
Meetecho:       http://www.meetecho.com/ietf104/teas/ > Audio stream:  
http://mp3.conf.meetecho.com/ietf/ietf1044.m3u > Jabber:
xmpp:teas@jabber.ietf.org?join > Available post session: > Recording:     
https://www.ietf.org/audio/ietf104/ > YouTube:       
https://www.youtube.com/user/ietf/playlists

> Num Start Duration Information
> 1  11:20   10      Title:  Administrivia & WG Status
> Draft:
> Presenter:      Chairs

> 2  11:30   10      Title:  WG Draft updates
> Draft:  Many
> Presenter:      Chairs

Pavan: Authors have asked for LC of native-ip-scenarios
        •       - how many have read: more than expected
        •       - Since this is experimental, expect to LC soon

Pavan: WRT TE metric recording
        •       - There has been too little attention to this document, if not
        clos

> 3  11:40   15      Title:  A YANG Data Model for Traffic Engineering Tunnels
and Interfaces > A YANG Data Model for MPLS Traffic Engineering Tunnels > A
YANG Data Model for Resource Reservation Protocol (RSVP) > A YANG Data Model
for RSVP-TE Protocol > Draft: 
https://tools.ietf.org/html/draft-ietf-teas-yang-te >
https://tools.ietf.org/html/draft-ietf-teas-yang-te-mpls >
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp >
https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te > Presenter:     
Tarek Saad

Dhruv: It would be useful to add source information for ephemeral tunnels (who
initiated the setup?) Igor: Reasonable ask.

- There were no objections or reservations to this change
Lou: Unless objections/comments are raised in Last Call (completing on Friday)
the document will be resubmitted to the IETF next week
        •

> 5  12:05   15      Title:  Yang model for requesting Path Computation
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation
> Presenter:      Italo Busi/Sergio Belotti
(Continue discussion in the afternoon session)
Igor: we had a discussion during lunch with Italo and he reminded about the
discussions we had before. The problem is, if you configure a tunnel in a
pre-computation mode, even if you specify the time-out for how long you keep
the state. The server can remove the state after the time-out; but the
configuration will still suppose to be in the configuration datastore and need
to be explicitly removed. If you do it via RPC, the datastore won't be a
problem. The authors think this is important difference, I have no objection to
that. Dhruv: the RPC should not be restricted to be used only between
controller hierarches. Whoever wants should be capable to use the RPC. From the
model points of view, I think the RPC should also be allowed for peer-to-peer
fashion. Would this small change (from hierarchy to peer-to-peer) request a big
change in your model? Why are you mandating? Sergio: It's not mandatory
assumption, in fact this is the point for discussion. So the question for the
WG is we suppose we can use that, the RPC usage should be application
independent. The question is  if the WG thinks we need to modify the YANG, to
cope with other aspect or not, if it is needed to have a description of the use
cases or just say ... make a request independent of the factor of sequential,
flat shape of architecture, etc. These are the question we would like to leave
to the WG. Dhruv: again this model should not be binding with ACTN. If there is
someone else want to use this model, he should be able to use it freely.
Sergio: there is some discussion on distributed or hierarchical, we are not
sure that this is needed and can discuss this further. Our position would be
the RPC should be used independent of the architecture. The feature in the
slide before is to deal with the representation on hierarchies and described
how we can map between MDSC and PNC, typically in the ACTN context. Lou: it's
supposed you are supporting both hierarchical and non-hierarchical. The only
question now is whether you need a flag, and it's not convinced that with the
current shape you can do both.

(Regarding option 1 and option 2)
Lou: before we discussion do you have any recommendation to the WG, or you
split? (Sergio: Split. ) Ok, that's useful information. Lou: how about the one
issue we discussed in the last meeting? We did not see any discussion on the
list, about the policy. Have you solved those issues? Sergio: Yes, we have
discussed in the mailing list, all the attributes are used when requesting the
tunnel model. It's not mandatory during the path computation. Lou: I was asking
about the discussion, is there any different opinion? Sergio: we have solved
the issue with an explicit grouping. Lou: So it sounds like the resolution of
the discussion from Bangkok is that you think there is an agreement in the
document on providing a partial of the attributes instead of all of them. Igor:
This open issue we have discussed and made several changes. I personally do not
like the idea for separate requesting working and protection, mainly because
not only we need to link them, but also basically describe the relationships,
how these path computation results should be related, e.g., what kind of
disjointness is required, and what will happen if the requested disjointness is
not available. Another problem is that (requesting separately) will duplicate
some of the parameters. There are common source/destinations, bandwidth
requirement, common affinities, etc. If you just provide a single request,
these would be all taken care of. And finally there would be a lot of
algorithms that compute the paths simultaneously. (For the separate path
computation) you can solve it but it would be awkward, so rather to have a
single request. Sergio: about the attributes that are repeated twice, to have
double request, we already put in the table. Dhruv: A different opinion with
Igor, I tend to remain the two separate path requests. option 2 for two path
request will help retain the computed features. That would also be possible to
fit into different tunnels. If you remove that, you miss a very important
feature. Even two unrelated paths can be diverse from each other and one
feature should still be there. It's better to have a new tunnel request. This
issue would be decided by WG, but please don't take away the thing already have
in the current document, which is two path requests per request. Sergio: Ok.
Himanshu: (ragarding option 1 and 2) is it possible to support both? Both has
their advantage, and it would be flexible if we can support both. Let's start
with unprotected tunnel, and later on when you want to add the protection, the
two path requests give you that. For the same reason as Igor said, the
diversity could be satisfied with single path request. So I think it would be
nice if we can support both. Lou: To indicate what Igor said, the alternative
approach for two separate path computation request is to sent in the same RPC,
so it's possible for the computer to do k paths. The other point that Igor has
was you end up duplicating information, and that's a value point particular
what happen if you get, like some of the information get complex, it makes the
progress harder. I think the scenario that 'add the protection later' drives
you the both. (Himanshu: Yes. ) Julien: it makes sense if we support both. Some
of the reasons are already discussed, and others may be algorithm dependent.
Application can also be either single request or double common request. I
support both ways to be considered. Igor: do protection you have to take care
of not only protection itself, but also working paths, to guarantee such kind
of disjointness. Do the request at once will not diminish either one. I don't
mind that we have separate requests, it would be useful when you compute path
for different tunnels. Different problems will be solved via different
approaches. Other scenarios like share maximal/minimal common cost would better
be done in single request. But I am good if we support both, as long as we have
these approaches for tunnel request. Italo: Supporting both would bring bad
impact for inter-operability. It is possible that there is an option that a
controller don't like to be selected. For example, if one vendor prefer option
A and the other prefer option B then there would be problem for
inter-operability. All the issues raised can be solved by the other options. So
the only issue is one request per tunnel or one request per path. We can find a
solution to make sure that the same semantic and the same feature we have can
be done with option 1 and option 2 as well. Julien: Assuming the standard is
option 1, but how can people be prevented to use option 2? Standard one option
will not stop anyone to use the other option. Igor; option 1 covers everything,
including both unprotected and protected, and disjointness. Lou: a poll would
help?
 How many are in favor of option 1? A few.
 How many thinks option 2 is sufficient ? Slightly more than a few.

> Adjourn         12:20

> Session 2: Tuesday, March 26th 2019
> 13:50 - 15:50 Tuesday Afternoon Session I
> Location:       Grand Ballroom
> Audio stream:   http://mp3.conf.meetecho.com/ietf/ietf1046.m3u
> Available post session:
> Recording:      https://www.ietf.org/audio/ietf104/
> YouTube:        https://www.youtube.com/user/ietf/playlists

> Num Start Duration Information
> 1  13:50   5       Title:  Administrivia
> Draft:
> Presenter:      Chairs

Continued with discussion from #5 above, refer to #5 for the summary.

> 6  13:55   15      Title:  ACTN applicability to YANG models
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-actn-yang
> Presenter:      Haomian Zheng
No discussion.

> 7  14:10   15      Title:  ACTN VN YANG
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang
> Presenter:      Dhruv Dhody
No discussion.

> 8  14:25   15      Title:  Traffic Engineering and Service Mapping Yang Model
> Draft:  https://tools.ietf.org/html/draft-ietf-teas-te-service-mapping-yang
> Presenter:      Young Lee
Lou: the comments from Tom Petch, need to be solved on the list.
Young: will do that.
Pavan: for availability, do you have any reference?
Young: I think we can have some reference, some operators expressed the demand,
I don't know which reference is the best fit, maybe ITU-T, will figure out.
Lou: some previous comments also mentioned this, we need a reference. Young:
Tom Petch is also chasing, we need to solve anyhow.

> 13 15:20   10      Title:  A Framework for Enhanced Virtual Private Networks
(VPN+) > Draft:  https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn >
Presenter:      Jie Dong Lou: There is a draft in LSR WG, is it worth to talk
about that work here today? (later this week. ) It would be headed our way and
I suspect some overlap with this document. Would be good to, if someone is
available, going there to see what is going on and sync up the content. (Jie：
OK. ) It's in the second LSR session. Jie: I learn about the document, which is
specific segment routing. This work is more generic like framework. Lou: they
do have some generic text as well, that's the reason to sync up. Jie: Ok, we
will talk offline.

> 9  14:40   10      Title:  RFC3272bis -- Design Team report
> Draft:
> Presenter:      Adrian Farrel
No discussion.

> 10 14:50   10      Title:  YANG models for ACTN TE Performance Monitoring
Telemetry and Network Autonomics > Draft: 
https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics >
Presenter:      Young Lee

Pavan: Please add a reference for availability
Dieter: there is no direct description on subscription, which means the text
need to be polished. Young: agreed. Already done in the YANG description but
not in the main body. Dieter: people don't like to search and read the YANG
code, need to do it in the text. (Yes. ) Lou: Some comments from last meetings
were not fully solved, be careful on what part is ACTN-specific and what part
is generic, e.g. in introduction section. Please go ahead using the list for
discussion and look for adoption before Montreal. Young: So you mean the draft
need to be updated to avoid the ACTN context. (Yes. ) Pavan: Moreover, just
make sure the reference on scaling in/out is added (Yes, Section 4). Lou: it
would be useful if you can find reference when you have something new. Young:
that's before adoption ? Lou: yes, before adoption. Be aware that Dieter's
comments are valid, the readability should be improved. Daniel King: This
document is almost two years old now, I am wondering how much more polish it
needs before being adopted. Lou: Dieter raised an issue, and there outstanding
issues from the last (IETF 103?) discussion. These need to be addressed before
we can adopt. Daniel King: Ok, we have clear objectives. We will update.

> 11 15:00   10      Title:  Basic YANG Model for Steering Client Services To
Server Tunnels > Draft: 
https://tools.ietf.org/html/draft-bryskin-teas-service-tunnel-steering-model >
Presenter:      Igor Bryskin Pavan: what's the relationship between this model
and other service mapping models? Have you discussed this offline? Igor: The
service mapping model work is constructing the map between explicit service and
tunnels, they basically need to specify the tunnel names. This draft bring the
possibility to have the capability of mapping instead of specifying tunnel
name, just a pool-id. Lou; I took what Pavan was saying as not from Chairs but
more general. Igor: I have also answered that as a general question. Dhruv: I
think this work is needed, but we can also start the te-service-mapping to work
on the same problem rather than have independent model. when you have TE
tunnels on one side and the services in the other, and you create another
model. Why not augment the existing models to include all the information
there? But now we are creating a rather new model and introducing the pool id.
Is it a small subset of what we have been done before? Is it possible to have
one model solve both the TE service mapping problem and the steering problem?
That would be better than two disjoint models. Lou: the semantics are quite
different, and they are solving different problems. There may still be value on
bringing these together, and optimize the complete solution, rather than
looking them as pieces. The answer we came up before was a very specific scope,
on 1-for-1 mapping, wasn't a pool concept. Dhruv: even if in this tunnel pool,
the tunnel can be shared across services. From the YANG's perspective it's not
big changes, we have created a new YANG model solving this problem. That what I
was commenting. Lou: if we look into previous SR-TE discussion, we are not
creating a single model, but use the information across multiple models, in
order to have composite and useful information. So there were two models
contributive instead of one. Igor: Expect the proposal here. Lou: Yes but he's
not another document. Igor: No, here we complement the solution and helping on
particular problem. For example what happens if there is subscription, if you
put more services on a tunnel than they can carry. Would you always need to
re-map the services to the tunnels? Dhruv: We did do another abstraction called
VN, our thinking was that the services getting mapped to VN, and tunnels are
like your tunnel pool, i.e., they can come and go and things can change. But
you have a bigger abstraction called VN which remain unchanged in this
scenario. So I think it's the same problem being solved by different way, we
can call it either tunnel pool or VN. Igor: we don't really have your model in
mind. For example there are layer 2/3 VPN services, mapping signals to Ethernet
tunnels can be done via another model (in ccamp). There is just no method to
understand mapping to one or multiple tunnels, so many remapping would happen
afterwards. We are suggesting to make it brief. Even further, you can steer
services to slices, it's much general problem. Dhruv: I just want to remind
there is still overlap. I have to implementing both the TE-service-mapping and
te-pool, I still need to understand when to use which one, to make sure using
the right model. Igor: The pool is between tunnels and your services as a
complementary solution. We make it easier to manage that. Himanshu: Do you
cover the tunnels going to the same destination? (Igor: Yes. ) So in that
scenario is there any discipline to have min/max constraints for distributing
the traffic on the tunnel? Igor: we are indicating what source we are mapping
to a pool, the device can take any tunnel from the pool to their necessary
destination. How you do multi-path is a separate question. In our work you
don't say what tunnel you are gooing to use but you only say use one tunnel
(from the pool) to achieve Himanshu. The constraints on this tunnel selection
is not in the scope of this work. Himanshu: I was thinking more about the
traffic distribution to achieve load balancing. If you are subscribing the
services, and putting the services on the tunnel, which tunnel should you
choose in discipline? Min-fill, max-fill? FIFO or other mechanism? Igor: but
this is a multi-path problem, right? Himanshu: ok, we can take (offline).
Pavan: we still have two documents talking about mapping services to tunnels,
even though they are complementary. It would be valuable to be cover under the
same umbrella. Please the author talk with each other. Igor: I have aware more
other works, so in future we may have a bigger umbrella? Given the previous
experience we think it would be better to have separate work. Lou: Come to the
other authors, and come back with your conclusion and proposal to the WG. Igor:
OK. Lou: in terms of the other question you have. In abstract you may have
additional information which is not traditional TE networks, but do you think
it makes sense to be included in this model? We may probably do augmentation
for those (non-TE) informations. But it may be arguable if we should do it or
not. Make sure our AD is happy with what we are doing here. Igor: so we are
doing enhanced VPNS, for example, right? Lou: yes, we are already doing that.
Igor: if we have a context of enhanced VPN, then we want to keep this VPN
regardless of how it is proceeded. Lou: So the interworking function, the entry
function into the TE network, we don't know where do we define that? For
EVPN/L3VPN services, if we want to map them to TE, we will probably talk about
augmentation to a TE model or an augmentation to BESS model to do it. Based on
the proposal, we can talk about where is the right place to do it. Either way
would need a synchronized group. Igor: we still keep in the tunnel level, but
allowing some abstractions. Lou: Thank you.

> 12 15:10   10      Title:  Interworking of GMPLS Control and Centralized
Controller System > Draft: 
https://tools.ietf.org/html/draft-zheng-teas-gmpls-controller-inter-work >
Presenter:      Haomian Zheng Loa: (regarding to slide 2) why LMP is a
'distributed' not 'centralized'? Haomian: actually it's a part of GMPLS, but no
harm if put as 'centralized' as well. Lou: How many have read this document?
Very many. Lou: How many from Design team read this document ? A few. Lou: Do
you think the scope of this work fold into the Design Team (per RFC3272bis)? We
can have the centralized control, distributed control, and hybrid, this work is
about hybrid. Adrian: 'fold in' may not be the right word. If you look into the
size, we certainly will not take it in the 3272bis. But they are related, so in
RFC3272bis we prefer to give a short description and point to this work. This
work folds in the TEAS scope, and is quite useful. Andrew: I have read the
draft, and this is an useful work especially when describing hybrid systems. I
prefer to see it move ahead. Lou: Another comments (not blocking one), although
in presentation ACTN is used as an example, in the draft there ia a lot of
ACTN. We should not make it ACTN-specific. Haomian: Agree, in the last update
(-03) many terms of ACTN has been removed to be more generalized. Only a few
left as an example. Lou: How many thinks this should be the work that WG should
work on? A reasonable number.
   How many have read this draft? Almost same.
   How many think it's a good start point for WG? More than previous two.
   How many think we should not accept this work and start? No one.
Lou: very useful feedback, will take the poll to the list, make it adopted as
-00 and include the open actions.

> 14 15:30   10      Title:  RSVP-TE P2MP Tunnels on RMR
> Draft:  https://tools.ietf.org/html/draft-zzhang-teas-rmr-rsvp-p2mp
> Presenter:      Jeffrey Zhang

Lou: this document is like the other RMR document? It was sent to us from
another WG. Do you think it belongs to here? Last time the other side believed
that this work belongs to here, and I suspect if same thing happens here. I
need to check whether Loa nod or disagree. (Loa Nod) He is nodding, so yes they
want to publish by teas. It would be put in the normal process here. We do have
other RMR documents as WG documents, and seems like reasonable companion. Loa:
The RMR documents, we have two in MPLS, the base document, under WG LC. There
is no dependency on other documents to accept this document. You can do that.
There is also LLDP document and I think there would be a P2MP document going to
a framework document in MPLS. There is potentially a document in spring for
segment routing. Jeffery: to clarify, for multi-cast and P2MP, there is an
informational document in MPLS WG, generally talking about the ring or topology
with rings how the multi-cast works. This work here is explicitly about RSVP-TE
P2MP tunnel optimizations, including the procedures and the encoding to achieve
that. Lou: How many in the room are focusing on RMR, on the topic? just a few.
   How many has read the document? Maybe a couple more.
   How many think we should adopt this? About same number from different people.
   How many think we should not adopt this work? 1, then why?
Adrian: I am not opposing the work, I just went to MPLS list and see how much
discussion has been there, and could not find any. A little bit nerves on the
future. Lou: Do you know the other RMR document we are having? Adrian: Yes, and
also the MPLS WG. I am not still thinking where it belongs, it's a specific
multi-cast RMR, seems to have discussion. Himanshu: I strongly support this
work, because many of the mobile networks are ring-based. We see the scaling
issues, and we really need this solution. We were willing to revive the RMR
work and happy to see this work coming along. In fact we want to see more
stuff, but take it offline. Lou: Comments on the floor, please use the mailing
list. Did you mention the base document in MPLS? Jeffery: it does not mention
the base document. Currently uni-cast and multi-cast are proceeded in parallel.
Lou: is that a WG adopted work or individual? Jeffery: Individual, I think we
are also requesting WG adoption. Loa: There is one reason why we have not start
the poll, we think it's ready for adoption, but we want to wait until we have
done the WG LC for the other RMR base document. Again there is no reason not to
adopt here because of any MPS work. Lou: is the base one about the data plane
work? I don't think the data plane work need to be done here. Jeffery: No,
forwarding plane is no different. There is no changes even for unicast RMR.
Lou: no need to argue about the adoption order here and in MPLs. Loa: we talked
about the informational document right? The base one is under WG LC and wait
for publication. The other one will be adopted in the near future. Lou: then
teas will adopt this work afterwards. Loa: Ok. WG LC for base -> MPLS adoption
on informational -> TEAS adoption this work. Lou: the first order is under MPLS
WG, the next is our decision. Loa: Do you know the document talk about 'soon'?
Lou: Hopefully before Montreal.

> 15 15:40   10      Title:  YANG Data Models for Multiprotocol Label Switching
- Transport Profile) > Draft: 
https://tools.ietf.org/html/draft-busizheng-teas-mpls-tp-yang > Presenter:     
Italo Busi Lou: unless the MPLS chairs disagree, out position is that TP is a
profile of TE, not its own thing. It would be the best to integrate with TE
models. Italo: I just want to make sure that's the opinion from the WG. Lou: is
there anyone who wants to disagree? No. Lou: that seems the direction to go. I
suggest when you think it's necessary to have a change, send to the list and we
just discuss there. Italo: Of course.

> Adjourn         15:50