Minutes IETF103: teas
minutes-103-teas-01

Meeting Minutes Traffic Engineering Architecture and Signaling (teas) WG
Title Minutes IETF103: teas
State Active
Other versions plain text
Last updated 2018-12-24

Meeting Minutes
minutes-103-teas

   >                         Monday, November5th 2018
>                         11:20 - 12:20 - Monday MorningSession II
>                     Location:    Meeting 2
>
>                     Slides:   
https://datatracker.ietf.org/meeting/103/session/teas >                    
Etherpad:   
https://etherpad.tools.ietf.org/p/notes-ietf-103-teas?useMonospaceFont=true
>                     Meetecho:    http://www.meetecho.com/ietf103/teas >
                    Audio stream:   
http://ietf103streaming.dnsalias.net/ietf/ietf1038.m3u >                    
Jabber:    xmpp:teas@jabber.ietf.org?join > >                        
Available post session: >                     Recording:   
https://www.ietf.org/audio/ietf103/ >                     YouTube:   
https://www.youtube.com/user/ietf/playlists > Youtube session 1:
https://www.youtube.com/watch?v=7as2GwZGpIw

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

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

Zafar Ali: WRT TE Metric recording - will have issue addressed before IETF 104
Pavan Beeram: could you use some help with this?
Zafar Ali: yes, that would be appreciated
Lou Berger: How many people are interested in this document? (a few)
   Any volunteers to help edit? (none)
Lou Berger: we're at the point where the authors need to either get this moving
again by the next IETF, or we'll declare it dead and move on. Igor Bryskin: WRT
tutorial draft, looking for input on packet network example; need volunteers to
work on this Tarek Saad: RSVP-TE yang split - should be done shortly, then
ready for YANG DR review and LC

00:18:30
> 3    11:40    15   Title:    A YANG Data Model for Traffic Engineering
Tunnels and Interfaces >                    Draft:   
https://tools.ietf.org/html/draft-ietf-teas-yang-te-17 >                   
Presenter:    Tarek Saad

Igor Bryskin: The comment from the YANG DR is very valid.  We don't cover
defaults, but do want to cover active choice. We should take the comment
seriously. Lou Berger: Authors are following approach of only defining defaults
based on specifications, I think this is a good choice Igor Bryskin: my point
was that it is better to choose some reasomable option Tarek Saad: the risk is
that people may differ on what's a reasonable choice so we need to be careful
here. Could maybe have a separate document with defaults? Lou Berger: I thought
I heard that the authors' approach was only to have a default when it's
specified somewhere in the protocol. Speaking as a contributor, I think that's
a wise choice Igor Bryskin: if you do not go to default you need to have
multiple choice and create confusion Aihua Guo: In my experience some defaults
are necessary, but not all. If a default has interoperability implications
should specify something Tarek Saad: yes, I think if there's a default that you
feel is important to set then we should discuss on the list Igor Bryskin: A
default doesn't preclude a user setting something else if they want Pavan
Beeram: Please send a message to the list outlining the changes needed to
te-types document to resolve the exising document MISSRef RFC editor state.
(Including changes to align te-topology with final definition of te-types.) Lou
Berger: where it's necessary to align the topology document with this one, I
think it's sufficient to put out a proposal for that and give it to the RFC
Editor. I know there were some substantive issues that were discussed off-list
and those should be brought to the list and closed

00:35:15
> 4    11:55    10   Title:    SF Aware TE Topology YANG Model
>                    Draft:   
https://tools.ietf.org/html/draft-ietf-teas-sf-aware-topo-model-02 >        
           Presenter:    Young Lee

Lou Berger: There was an issue from the last meeting on identifiers, that is
addressed with new -id. Did we talk to SFC about how they handle this? Young: I
did, yes. They refer to work in TEAS and NFV.

00:40:15
> 5    12:05    15   Title:    Yang model for requesting Path Computation
>                    Draft:   
https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-03 >      
             Presenter:    Sergio Belotti

Lou Berger: do you want to discuss the open issues now, or on the list?
Sergio Belotti: on the list might be better
Lou Berger: it would be good to say how you think you should do it now. We have
time Igor Bryskin: To ensure the returned path is same as used for the tunnel
when it's provisioned, we need to provide all tunnel configuration parameters.
The discussion on the list, not much harm to provide everything. Tarek Saad: I
agree with Igor. I don't think the fact tht policy isn't there should block
progress. The attributes can be passed and the computation server can ignore
them if it likes. Provides foundation for future policy module. Sergio Belotti:
The problem is that if we need complete alignment on attributes, we'll need
some modifications Tarek Saad: I'm proposing that you use the full set and the
server can treat them as optional. Pavan Beeram: aren't we just using a
grouping for the full set of constraints? Sergio Belotti: we don't have
justification for a list of attributes when we don't know what they are Lou
Berger: the justification is that a full set of attributes gives maximum
flexibility Igor Bryskin: we want to avoid the situation where you ask for a
path calculation and get a path, but then provision the tunnel with the same
parameters and it takes a different path Italo Busi: that situation is
difficult to avoid. If the client provides all attributes you can still get the
same problem if the client doesn't provide an attribute that the server is
nevertheless using. We're adding a path-verification phase in the next version
of the document to try and address these issues. And if you have a policy, you
have to explain exactly how it works for it to be useful. It can't be hidden.
Sergio Belotti: No, we don't want hidden policies our position is that if the
policy is there it has to be explicit. Igor Bryskin: I disagree with Italo. All
we're requiring is that if you specify the same parameters for two tunnels, you
get identical paths. Secondly, policies don't need to be known externally; they
could be proprietary to the server. Lou Berger: there's clearly a difference of
opinion here, but I saw there was some new text about path verification in the
latest version and I don't think it has really been discussed on the list. It
would be good to have the conversation

WRT slide 5:
Tarek Saad: To clarify the TE tunnel approach: setting multiple constraints is
optional. When there are multiple constraints, it's not clear which the server
should drop if need be. What does a server prioritize? We went with optimizing
the inclusions/exclusions and make it clear that this is best-effort. Igor
Bryskin: We need to define what it means to relax a constraint. If you can't
satisfy a contstraint you could drop it entirely, or you could treat it more
gently. Dhruv Dhody: WRT alignment with PCE, what is the cost of alignment, if
cost too high, not worthwhile.  We need a smarter way of modeling it. Igor
Bryskin: please look at the model, it already has a mechanism that may be
sufficient Dhruv Dhody: I like the way PCEP has specified this. I'm confused by
what Tarek said about hops - it's like loose vs strict hops. We need to discuss
further. Jon Hardwick: Not sure how important this is. The user wants to set
their constraints, just need to express same level of richness. To take the
example here we're looking at two more-or-less equivalent ways of doing the
same thing; PCE can do the same thing - the PCE can return a set of candidate
paths to the PCC and allow the PCC to choose the one it likes best. Sergio
Belotti: The example is chosen on purpose: not trivial to deduce for
implementation in yang the same functionality while for PCEP it is just a
Boolean variable to use per constraint Lou Berger: we're over time but I'd like
to continue the discussion tomorrow when we resume.

> Adjourn    12:20
>
>

>                         Tuesday, November 6th 2018
>                         16:10 - 18:10 - Tuesday Afternoon Session II
>                     Location:    Chitlada 3
>
>                     Slides:   
https://datatracker.ietf.org/meeting/103/session/teas >                    
Etherpad:   
http://etherpad.tools.ietf.org:9000/p/notes-ietf-103-teas?useMonospaceFont=true
>                     Meetecho:    http://www.meetecho.com/ietf103/teas >
                    Audio stream:   
http://ietf103streaming.dnsalias.net/ietf/ietf1036.m3u >                    
Jabber:    xmpp:teas@jabber.ietf.org?join > >                        
Available post session: >                     Recording:   
https://www.ietf.org/audio/ietf103/ >                     YouTube:   
https://www.youtube.com/user/ietf/playlists > Session 2:
https://www.youtube.com/watch?v=A7MJ8NY7kTk

> Slot Start     Duration    Information
> 1    16:10    10   Title:    Administrivia
>                    Draft:
>                    Presenter:    Chairs

00:03:00
> 6    16:20    10   Title:    ACTN applicability to YANG models
>                    Draft:   
https://tools.ietf.org/html/draft-ietf-teas-actn-yang-02 >                  
 Presenter:    Haomian Zheng

Pavan Beeram: this references a bunch of YANG models which are under
development so I do not see any need to rush to WG LC, we need the basic models
cited in this draft to be mature. Haomian Zheng: Agree on not rushing, but we
expect some clarification what is the basic models and how mature we need to
wait. Daniele Ceccarelli: here we are defining a huge number of documents,
maybe we should define which one can be the showstoppers for the draft without
waiting for the all the other drafts. I'd propose TE topology, TE tunnel and
Ppath Computation as the three we need. Lou Berger: when this document is
published as RFC, which documents we would like to be referenced as RFCs and
which one as drafts? Since this is informational it will be published quickly,
and all the references that are still drafts will be referenced as drafts.
Daniele Ceccarelli: I would like to see those three referenced as RFCs and the
rest can be draft.

00:10:20
> 7    16:30    10   Title:    ACTN VN YANG
>                    Draft:   
https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-02 >               
    Presenter:    Dhruv Dhody

Adrian Farrel: there was original argument from the chairs on 'whether we need
a separate model than TE', want to confirm whether this issue is addressed or
not. I think the presentation explained this quite well - are the Chairs happy?
Lou Berger: I think the question is whether the WG is happy.
     Poll: how many has read this draft (a reasonable number)?
     How many think the proposed approach is the right way? (same as above)
     How many thinks this is the wrong way ?(none)
Lou Berger: the WG gives the answer.
Adrian Farrel: the Chairs expressed that they had a lack of clarity. Have we
cleared that up or is more work needed? Lou Berger: The working group has
provided the answer -- yes Pavan Beeram: I think the document has gone a long
way and thanks for the work and making things clear thank you. Lou Berger: Is
the model and the notion of VN something that is ACTN specific or something
applicable to any VN node/link control? Isn't it generic and applicable to any
TE controller approach? Dhruv Dhody: I think we can use, VN is a general thing,
but defined in the context of ACTN.   It can be a base, and augment it to
achieve other features such as network slicing, but what is the issue with
calling it ACTN? Lou Berger: The issue is that the next the model does not read
as being generally applicable and that an implementer of VNs who is not using
the ACTN model won't think that can use this work.  If ACTN term is removed
from the model, then they can use it. Dhruv Dhody: if it's just the name space,
then yes. Daniele Ceccarelli: ACTN is a structure that you don't necessarily
implement everything, you can only implement a piece (like VN), or you can also
implement all the pieces and put together, which is ACTN. Lou Berger: we'd like
this work to be generally useful whenever we're modeling VN information Igor
Bryskin: I agree with Lou, when we're talking about ACTN we're talking about
all the building blocks we're building in this group. Anyone can use what they
need. So you can use just the topology model if you want.

00:26:00
> 8    16:40    10   Title:    Traffic Engineering and Service Mapping Yang
Model >                    Draft:   
https://tools.ietf.org/html/draft-lee-teas-te-service-mapping-yang-12 >     
              Presenter:    Young Lee

Lou Berger: it would be great to have a non-ACTN example in the document.
    How many think it is a topic we should work on? a reasonable number
    How many have read the document? more than those who think it is a topic we
    should work on How many think it is a reasonable starting point? a very
    reasonable number
Let's take this to the list. It would be nice if the solution we adopt could be
used for more than ACTN.

00:32:15
> 9    16: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-08 >
                   Presenter:    Young Lee

Dieter Beller: we noticed in the model, there are parameters such as delay,
delay-variation, packet-loss, etc: are they tech-specific or general? Young
Lee: delay is not technology-specific Dieter Beller: delay-variation is
packet-only. Should it be defined in a technology-specific augmentation? Young
Lee: I agree with packet loss but not with delay Dieter Beller: I was talking
about dealy variation Young Lee: what do we have other than packet routers and
otn switches, what do we have? Lou Berger: our approach thus far has been to
have a base model and then augmentations. That means people implementing only
one technology don't have to flag deviations from the base model because they
didn't implement all of it. It doesn't make any difference to how the topology
works. Gert Grammel: in the last ITU-T meeting there was a presentation about
delay variation in OTN caused by asynchronous mapping Young Lee: will this give
us trouble with TE types? We just imported that model - do we need to make that
more generic? Daniele Ceccarelli: if the issue is to separate packet-specific
attributes, we can develop a new module but it is not worth having a separated
draft. Let's avoid having a document for only one value Tarek Saad: as the
author of ietf-te-types, we need to make sure that our model covers generic
performance parameters, and leave the tech-specific parameters augmented to
generic TE models. Lou Berger: the comment is about the packet loss attribute
being technology-specific, and that's in TE-types We have a YANG Doctor comment
about it that needs to be addressed and I think this is worth looking at. Pavan
Beeram: I'd to see like some discussion on scaling intent and how that's
addressed. Young Lee: you can define this as what happens when you're above or
below a certain utilization Pavan Beeram: we should discuss on the list.
    How many have read the document? A reasonable number
    How many think it is ready for WG adoption (assuming the comments discussed
    here are addressed)? A bit less
Lou Berger: do the update to the comment (on generic/tech-specific), and then
we take it to the list. Young Lee: So what do we do about TE types? Lou Berger:
we'll sort that out so it becomes generic. Tarek Saad: the grouping we defined
in TE types is generic but maybe doesn't apply to optical. So we could take
these out if they're packet-specific Lou Berger: the packet loss is a useful
attribute. It does not need to be removed from the te-types document but just
been removed from the grouping Pavan Beeram: the TE-types issue isn't the only
caveat - also need to make it ACTN-agnostic

Lou Berger: We'll swap the next two presentations, first the enhanced VPN
framework, then will do ACTN for network slicing. 00:46:40 > 11    17:10   
10  Title:    A Framework for Enhanced Virtual Private Networks (VPN+) >    
               Draft:   
https://tools.ietf.org/html/draft-dong-teas-enhanced-vpn-02 >               
    Presenter:    Jie Dong

Ketan Talulikar: Seems this draft defines an architecture. The changes needed
are defined in other drafts in SRING, LSR and other areas. What to standardize
here? Lou Berger: From process standpoint, this is the right working group for
the architecture draft. Stewart Bryant: It is an informational draft, shows how
to bring things together to solve a problem. Lou Berger: could you clarify the
question? Ketan Talulikar: I'm not asking if this is the WG. My question is:
what are we standardizing here? Lou Berger: it's an informational document, so
by definition, nothing. Ketan Talulikar: This document generates requirements
for standardization in other WGs. Lou Berger: This document informs how
different standard mechanisms can be used in a particular way to solve a
particular problem. We have many documents that do that. Stewart Bryant: This
is absolutely normal. There are many similar documents, e.g. for MPLS-TP and
Pseudowires. Lou Berger: It depends on WG's opinion whether there is value to
move forward. Zafar Ali: There is a draft in SPRING which has addresses the
same space as this draft. Maybe we should bring that draft here as well?
Stewart Bryant: My recollection is that this draft is a superset of the draft
you mentioned, it is not restricted to SPRING based solution. Zafar Ali: My
question is - do you need a superset? This draft looks like marketing, and I
think it would be fair to have both drafts discussed. This draft proposes
specific ways of doing things that are not needed. We also need SPRING to look
at this. Adrian Farrel: I would agree with Zafar if this document were
proposing any changes to a technology, but I don't think it does. This document
does not define specific extensions to segment routing. It is just one
candidate technology, SR and MPLS-TE may both be used. Zafar Ali: I have no
objection to the TE side, but for SR, specific SIT types are defined here. Jie
Dong: The SR specific extensions are defined in another draft, which will be
discussed in SPRING tomorrow morning. Lou Berger: We are happy to have
architecture discussion happen in TEAS. Wim Hendricks: One question is about
the scale, SPRING was a stateless architecture, we are going to introduce more
state. The scale is an important factor and we should clarify this in the
document and say which technologies are/are not in scope for a given scale Lou
Berger: I've talked to one of the SRPING chairs about this, and we do have some
marketing going on. The term SRTE is very confusing, can mean different things
to different people. Some people think with TE you do introduce state into
devices for resource allocation. Some others think SRTE is purely path steering
or "PE" (path-engineering). We really need good definition of SRTE or PE. Zafar
Ali: SPRING has an architecture document for SR policies or SRTE. Lou Berger:
That's SR policy. There is no definition of SRTE anywhere. We hope we will get
one. Zafar Ali: Agree with what Wim said on the scaling analysis, e.g. on the
implications of using and adjacency-SID. Lou Berger: We need a definition of
SR-TE first. Otherwise it could have different state implications. Daniele
Ceccarelli: How about TEAS gives the definition of TE, then if SPRING agrees
with it, we can call it SRTE, or they can call it SRPE. Lou Berger: Would be
reasonable to have one informational document on what TE is. Can be based on
the TE presentation on Sunday given by Adrian and Haomian. Maybe they could
turn that into a draft. Robin Li: The framework document is not SR specific
thus belong to TEAS. The discussion about SR or SRTE for VPN+ or network
slicing could happen in SPRING.

01:08:45
> 10    17:00    10  Title:    Applicability of Abstraction and Control of
Traffic Engineered Networks (ACTN) to Network Slicing >                   
Draft:   
https://tools.ietf.org/html/draft-king-teas-applicability-actn-slicing-04 > 
                  Presenter:    Dan King

Dan King: Our thought is to move portion of this document into the previous
document as a subsection. Then will have a document which we could do liaison
to other standards organizations looking at network slicing. Do we need to wait
for the composite document be adopted before having formal liaison to other
SDOs? Lou Berger: We don't usually do liaison on individual documents (look to
Deborah). I don't know if there's a hard and fast rule on this. Deborah
Brungard: We could do some liaisons as 3GPP already did liaisons to us showing
interest in an area of work. And ITU-T SG-15 have started 5G work, so we could
liaison with them to show our work on 5G or network slicing, and ask about the
work they are doing now. Lou Berger: If there is value it is certainly
something we could do, whether we do it or until we have something adopted?
Deborah Brungard: I would do it now. SG-15 is moving fast. The only concern is
the data plane technology was FlexE, and that's not the only data plane
technology. It would better to make things more general as individual
technologies belong to the OIF or ITU. Lou Berger: Maybe we should set up a
liaison. Propose some text and we'll work on it. Adrian Farrel: I'm working
with the co-authors to do the merge of the three drafts. ACTN will be one of
the candidate technologies. There will also clarifications about the terms - we
have four terms that are almost the same (VPN, VPN+, Virtual Network and
Network Slice), and they seem to be names for the same things depending on
where you view it from. The data plane technologies will also be extended from
packet focused to other TE technologies. Lou Berger: I want to confirm whether
the authors want to do the merge (of this and the previous documents). Jie
Dong: As coauthor of VPN+ framework, in support of the merge. Daniele
Ceccarelli: VPN+ is something we should work on, but need to be careful about
saying VPN+ is network slicing. If we merge everything we lose the distinction.
Network slicing is a much bigger problem. Lou Berger: What I heard is VPN+
solves part of the problem of network slicing. Stewart Bryant: It was
originally intended to solve the data plane and lower layers. Network Slicing
is a much bigger problem. We didn't use the term network slicing in beginning
because we want this to be universally useful, and applicable to some aspects
of network slicing - and also because Netowrk Slicing was a very controversial
term when we started the work. Young Lee: As coauthor of the 2 ACTN drafts,
support the merge as long as we clarify what VPN+/network slicing mean. Could
clarify our scope is transport or TE network slicing. Lou Berger: We are
running over time so we need to wrap the discussion. The plan is to merge the
documents. And that's gonna be pretty quick.
    Who is interested in working on this topic in this working group? Very
    healthy number.
Lou Berger: We'll need to see the merged document, but given the level of
interest and discussion we'd like to not wait for the next meeting to do a
poll. Zafar Ali: There is another draft, WG also need to see it. Lou Berger:
After adoption there is opportunity to bring your content into this document,
and the ownership moves from the authors to the WG. Zafar Ali: Would like to
work with the authors of the draft, even before the WG adoption poll. Dan King:
we'd be happy to work with you.

01:24:20
> 12    17:20    10  Title:    Interworking of GMPLS Control and Centralized
Controller System >                    Draft:   
https://tools.ietf.org/html/draft-zheng-teas-gmpls-controller-inter-work-01
>                    Presenter:    Sergio Belotti

Sergio Belotti: The draft was presented in CCAMP last time but was considered
technology-agnostic so it is now presented in TEAS. Lou Berger: is it proposed
as an Informational document or as a Standard Track document? Sergio Belotti:
it is Informational Lou Berger: How many have read the document: an ok number
    How many think we should work on this: the same
    How many think it is ready for adoption: a bit less
    How many think we need to wait for the changes? none
There is support but not overwhelming. We will discuss offline the next steps

01:32:40
> 13    17:30    10  Title:    Hierarchy of IP Controllers (HIC)
>                    Draft:   
https://tools.ietf.org/html/draft-li-teas-hierarchy-ip-controllers-01 >     
              Presenter:    Dhruv Dhody

Pavan Beeram: Is the scope of this limited to ACTN, or are we going beyond
packet networks? Dhruv Dhody: this work include the BGP which is not a part of
ACTN; Adrian Farrel: Is it possible to generalize this as a controller-driven
document? i.e. something that covers the material in the previous draft? Dhruv
Dhody: open to discussion. Lou Berger: How many are interested to this topic
(even if they have not read the document)? A reasonable number Lou Berger: it
would be good to follow up on Adrian's suggestion

01:38:40
> 14    17:40    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-00
>                    Presenter:    Igor Bryskin

Daniele Ceccarelli: I like the idea of pools but I would like to see pools made
by a single tunnel, i.e. specify that a particular tunnel is to be used Igor
Bryskin: you have the option to reference a tunnel or a pool Italo Busi: I
agree with Igor. It's better to reference the tunnel or the pool, rather than
have to create a pool with one tunnel Daniele Ceccarelli: that's ok, I just
need to have the possibility to specify a specific tunnel Lou Berger: we have
to cut the discussion here. I think the conversation demonstrates that there's
interest in this.

01:45:20
> 15    17:50    10  Title:    Applicability of ACTN to VPN with POI
>                    Draft:   
https://tools.ietf.org/html/draft-lee-teas-actn-vpn-poi-00 >                
   Presenter:    Daniele Ceccarelli

Lou Berger: How many thnk this is useful work? (a few)
  How many think we shouldn't be talking about this in the WG? (none)
  Please discuss more on the list

1:53:20
> 16    18:00    10  Title:    GMPLS Signaling Extensions for Shared Mesh
Protection >                    Draft:   
https://tools.ietf.org/html/draft-he-teas-gmpls-signaling-smp-00 >          
         Presenter:    Italo Busi

Pavan Beeram: There are three protection C-types. Need to clarify which we're
changing. Italo Busi: second one Pavan Beeram: We currently don't have any IANA
registry for the flags. We may want to consider one. Dieter Beller: the draft
mentions shared-mesh protection, which is similar to shared-msh restoration.
But protection is done by the data plane, whereas restoration is done in the
control plane. How do the two coexist? Both use shared resources in the
network. Italo Busi: I would not expect that SMP and SMR would be in the same
network, but if they were I would expect them to share resources. Igor Bryskin:
What's the environment for this? Do you envision a multi-vendor GMPLS network?
Italo Busi: the requirement is to set up a working LSP and a protecting LSP.
The transit nodes need to know that the protecting LSP belongs to an SMP schema
rather than SMR or linear protection. Igor Bryskin: But is it a single- or
multi-vendor environment? Italo Busi: at the moment I don't expect multi-vendor
as there is no common APS signaling. Igor Bryskin: So why are we discussing
this? Lou Berger: How many are interested in this? A small number
   How many have read the document? More
   Chairs will discuss.

See you all at the next meeting.

> Adjourn    18:10
>

Notes by:
Italo Busi
Haomian Zheng
Matt Hartley