Minutes for TEAS at IETF-96
minutes-96-teas-4

> [Please add your name to the end if you want to be acknowledged as a note
taker. >  This is not required.  Notes should be added below, after the
slot/draft slide url] > >                     TEAS Agenda For IETF 96 >        
            Version: Jul 15, 2016 > >                     Thursday July 21st
2016 >                     10:00 - 12:30 - Thursday Morning Session I >        
            Room: Charlottenburg II/III > >Etherpad:
http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-teas > Video:
https://www.youtube.com/watch?v=_o_HEhgdL-w > Joint session:
https://www.youtube.com/watch?v=t26WRG36Rkc > Num      Start   Duration   
Information >          Time > > 0        10:00    10    Title:    Administrivia
& WG Status >          Draft: >          Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-teas-0.pdf >               
  http://www.ietf.org/proceedings/96/slides/slides-96-teas-0.pptx >         
Presenter:    Chairs

Lou Berger: please respond to IPR requests; we can't progress a document until
all authors and contributors have done so.

> 1         10:10  (10:08)  10    Title:    WG Draft updates
>          Draft:    Many
>          Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-teas-1.pdf >               
  http://www.ietf.org/proceedings/96/slides/slides-96-teas-1.pptx >         
Presenter:    Chairs

<draft-ietf-teas-metric-recording>
Pavan Beeram: Open questions from June need discussion on list. Additive vs
non-additive attributes - can non-additive attributes be handled by this draft?
If we open the door to non-additive attributes, should we add others, such as
those discussed in RFC 7471?? Do we need a generic mechanism for the collection
of these attributes? Pavan Beeram: Anyone here want to talk about this now?
<nobody> Pavan Beeram: Please discuss on the list.

<draft-ietf-teas-network-assigned-upstream-label>
Poll: How many have read latest version <some>
                 How many have read any version <a reasonable number>
        How many think ready for last call <not many>
                 Any technical objections <none>
Lou Berger: Expect to see the LC process to start on this document to try and
drive reviews, early reviews are welcome

[draft-ietf-teas-rsvp-egress-protection-04] Status
Pavan Beeram: Authors would like to do an internal review and then move to LC.
Comment outstanding from last IETFs about adding text to make the document more
generic by adding text on segment protection, and also coordination with the
document in MPLS WG on egress protection. Huaimo Chen: We will work on the
comment on making the draft more generic and address it Lou Berger: That'd be
great Huiamo Chen: On the second point: the other draft is a framework which
has been introduced much later than this draft. We may put some more text in
our draft to reference that. Lou Berger: does the draft in MPLS need updating
to align with yours? Huiamo Chen: that draft claims no extension is needed in
RSVP-TE for egress protection. I don't think that's true. I had a hallway
conversation about this at the last IETF and explained why the extension is
valid and necessary. For example: need extension to protect multiple LSPs to
the same egress node. Pavan Beeram: Will you suggest changes in the framework
document Huimo Chen: I haven't yet. Lou Berger: Please suggest text on the
framework on list Huaimo Chen: I can do this and explain why we need an RSVP-TE
extension Yimen Shen: I'm the author of the draft intended for MPLS WG. I've
had an offline discussion with Huaimo. We will work with Huaimo and come up
with text. Pavan Beeram: Thanks for coordinating. We look forward to seeing the
outcome.

> 2         10:20 (10:22)   20    Title:    YANG Data Model for TE Topologies
>          Draft: http://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
>          Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-teas-2.pdf >               
  http://www.ietf.org/proceedings/96/slides/slides-96-teas-2.pptx >         
Presenter:    Xufeng Liu

[re: ID type debate: numbers vs URI]
Michael Scharf: As an implementor, in case of a very constrained node, the
reasons you give for numbers may apply. In the case of case of high end,
scalable implementations none of the reasons that you give for numbers make
sense and it makes no difference to use numbers vs anything else. Lou Berger:
What do you prefer in your implementation? Michael Sharaf: Prefer string or
URI. The string is very flexible - you can do anything with it. Numbers seem
limited. Pavan Beeram: Do you want to do this for every identifier in the
routing domain? Michael Scharf: not for all of them, but for some identifiers
across service models will be helpful. My key concern is service models. Anurag
Sharma: First, I prefer strings. The TE topology augments the I2RS model, which
uses URIs. We need to be consitent across IETF models. Second, in other SDOs
they are also using URIs, and it would be difficult to fit everything they have
into an integer and move that back to a UID. Third, I agree with Michael and it
applies to service model too Igor Bryskin: I don't have a strong preference on
strings vs integers. We do not model internals of DB; we model how DB is seen
from remote. Numbers vs String doesn't matter; I'll still have to convert the
external replresentations to my internal ones. Changes to string will be lot of
work. Anurag Sharma: To answer Igor's point, you can model an integer as a
string, but not the other way round. Oscar Gonzalez de Dios: I prefer URI. The
schema of the URI can be specified so the URI can be fully transparent. We may
need to do some work on the URI schemas. Tarek Saad: I agree with Oscar. This
has wider applicability, and the decision needs to be coordinated across Yang
Models. We need additional data to understand what the URI is. Anurag Sharma: I
also agree with Oscar. You can use URI as a face value too; you aren't forced
to parse it. Pavan Beeram: You are ok with URI and an additional qualifier
Anurag Sharma: Yes. That will put us in sync with other SDOs.

[Re: slide 18]
Lou Berger: what feedback do you want get from the group?
Xufeng Liu: I'd like to see the WG's consensus
Lou Berger: it's definitely a complicated question. Some questions to the WG:
    How many people care which one to use? <Many>
    How many have opinions? <as many as previous>
Now for feedback, not a consensus poll, how many prefer:
    Uint 32 <a few>
    URI <about the same>
    String <about the same as URI>
Lou Berger: good thing this wasn't a consensus poll.
??? Can we have a question on "non-uint32" (ie string or URI)?
Lou Berger: we know that about two thirds prefer non-uint options.
Lou Berger: This is useful information and demonstrates that more disucssion is
needed on this topic. Please use the list, the informal meetings and if needed
the chairs can schedule an interim.

[Re: naming discussion]
Lou Berger: do the authors have a recommendation?
Xufeng: we prefer PSC.
Lou Berger: Is that OK? Does anyone find the use of PSC unacceptable?
Tarek Saad: Objecting, because it trickles down to other models too. There are
other TEAS models that are named with "-MPLS" Adrian Farrel: Better if we use
existing terminology, not just here but in the previous document too. Refer to
RFC4397 which established terminology for a lot of this. Lou Berger: and what
conclusion will that lead us to? Adrian Farrel: nothing, but other documents
will lead us to "packet". Lou Berger: This is likely to affect other models in
other WGs, e.g. MPLS, so we might want to hear from their Chairs. PSC is well
understood in the GMPLS context, but is a bit narrow in context of generic TE.
mpls/packet is well-known terminlogy. George Swallow: PSC is too esoteric. The
rest of IETF understands packet and MPLS Lou Berger: We have some pushback
against "PSC" and towards "packet". Please use packet and see if we recieve any
objections

> 3         10:40 (10:50)  20    Title:    A YANG Data Model for Traffic
Engineering Tunnels and Interfaces >          Draft:
http://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/ >          Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-teas-3.pdf >               
  http://www.ietf.org/proceedings/96/slides/slides-96-teas-3.pptx >         
Presenter:    Tarek Saad

Lou Berger: Have you talked to the YANG doctors?
Tarek Saad: We have mailed them, but didn't get conclusive feedback. We should
discuss F2F Lou Berger: Will arrange a meeting with YANG doctors after this and
get Benoit to help out. Anurag Sharma: In netmod there was a discussion on
mounts, and the authors themselves have some reservations about the mounting
technique, so it would be a good idea to sync up with them. Lou Berger: Any
comments on issues 2 and 3? Dhruv Dhody: For issue #3, clarification question
that the ephemeral auto tunnel would be at the device and not at the PCE, where
it is config. Igor Bryskin: for issue #2, support the separation of P2P and
P2MP. Tarek Saad: Yes Anurag Sharma: RPC is clean, for a clear state; Xufeng
Liu: RPC is not a YANG stuff, should be netconf; RPC should not be used to
create state, notification do that. Igor Bryskin: agree with Xufeng. If I
create a tunnel via RPC then I'll want to see it in telemetry output. There's
no point in creating a tunnel and forgetting about it. Adrian Farrel: I have no
specific opinion, but I'm wary of creating many ways to do the same thing. From
an implemenmtation point of view you then have to track ownership, and who
creates what, and who's allowed to delete it. If you're doing it just because
you can, then I'd advise you not to; if there's a good reason for it then
that's fine.

> 5         11:00 (11:08)   10    Title:    Extensions to RSVP-TE for LSP
Ingress Local Protection >          Draft:
http://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-ingress-protection/ >     
    Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-5.pdf >   
              http://www.ietf.org/proceedings/96/slides/slides-96-teas-5.pptx >
         Presenter:    Huaimo Chen

John Messenger: (re: slide 5): it looks like you're assuming the failure
detection is bidirectional and the underlying transport communicates the
CE1-PE1 failure back to the source. Is that a safe assumption for all transport
types? George Swallow, off-mic: it's just a matter of time John Messenger: So
if you want quick protection, that assumption needs to be met.

Lou Berger: We've talked about various mechanisms. This is only for FRR,
correct? Huaimo Chen: Yes Lou Berger: Change the title "-for FRR". Wrap it up
as soon as you can. We've decided this is experimental, right? So narrowing the
scope (to FRR) is okay. What work is left before publishing? Huaimo Chen: we
need to add more details for a particular corner-case. Lou Berger: it would be
good to wrap this up ASAP so we can begin experiments. Adrian Farrel: How does
this work compare with the pseudowire work in PALS. Dont' need to answer the
question now, but can you add a pointer to the draft and state why it is
different? Huaimo Chen: I think this was asked a long time ago. Lou Berger: Add
the answer in the document.

> 4         11:10     10    Title:    Requirements for Abstraction and Control
of TE Networks >          Draft:
http://datatracker.ietf.org/doc/draft-ietf-teas-actn-requirements/ >         
Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-4.pdf >       
  Presenter:    Young Lee

Adrian Farrel: I'd like to offer to help align the terminology with
inter-domain TE and PCE based central control. Not a change to the content,
just to align terminology. Lou Berger: Thanks Adrian for the offer. We've asked
for this in the past, so please do. Young Lee: Should that be done in this
document, or in the framework? Lou Berger: anything that helps the WG
understand the requirements would be useful, so I think it's a very important
step. Young Lee: Adrian, please could you provide a list of the terminology
that needs clarifying? Lou Berger: Adrian has offered to work with the authors
on this, and he's the WG technical advisor. Adrian Farrel: I'm not looking to
change the meaning of the document or slow it down; in fact, I think this will
speed things up. All I need to do is read through it and suggest substitutions
for some terms. George Swallow: Should be done before last call. Lou Berger:
Agreed.

> 6         11:20 (11:27)   10    Title:    ACTN framework
>          Draft:
http://datatracker.ietf.org/doc/draft-ietf-teas-actn-framework/ >         
Slides: http://www.ietf.org/proceedings/96/slides/slides-96teas-6.pdf >        
         http://www.ietf.org/proceedings/96/slides/slides-96-teas-6.pptx >     
    Presenter:    Daniele Ceccarelli

Igor Bryskin: Do you distinguish between access link and inter-domain link. In
the TE topology model we do not distinguish. PNC doesn't distinguish either.
Daniele Ceccarelli: I think that's an open point that needs to be discussed. I
tend to agree with you that there's no difference. Anurag Sharma: Does this
framework cover policy? Daniele Ceccarelli: It wasn intended to, but it has
been sidelined a bit. Were you asking because you had a proposal? Anurag
Sharma: No. Just asking because there's work going on related to policy and
it's becoming more important. Daniele Ceccarelli: Yes, adding some text here
would be a good idea. George Swallow: if you consider policy in the document,
the draft will be too large to handle. My experience is that it's better
addressed separately. Dan King: Considering the policy, should be consistent
with the requirement document. If there's nothing on it in the requirements
document, you don't need it here. Lou Berger: I'd hope policy would show up
when we discuss inter-domain, since we generally have policy considerations
there.

> 7         11:30 11:36   10    Title:    ACTN Info Model
>          Draft:
http://datatracker.ietf.org/doc/draft-leebelotti-teas-actn-info/ >         
Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-7.pdf >       
          http://www.ietf.org/proceedings/96/slides/slides-96-teas-7.pptx >    
     Presenter:    Sergio Belotti

Lou Berger: How many have read <a reasonable number>
Lou Berger: Will wait for terminology discussion to happen then look for an
update

> 8         11:40 11:45   15    Title:    ACTN VN Yang
>          Draft: http://datatracker.ietf.org/doc/draft-lee-teas-actn-vn-yang/
>          Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-teas-8.pdf >               
  http://www.ietf.org/proceedings/96/slides/slides-96-teas-8.pptx >         
Presenter:    Young Lee

Igor Bryskin: TE-topology is not just for extracting the physical topology from
providers; client can ask for an abstract topology and request that a segment
of the physical topology be represented as an abstract node. This machinery
exists in TE topology. Young Lee: Yes, you can use the TE topology to determine
a view of the topology. Igor: My point is that you also have a way to configure
this. Young Lee: this is aimed at the customer interface. Igor Bryskin: Only
for CMI model, your model works well for MPI Dieter Beller: I have difficulty
in understanding how you can create abstract topology without knowing
underlying topology Haomian Zheng: to respond to Igor, the first motivation for
this model is to be used by CMI to introduce the VN description. It may have
overlap with topology but should not be fully duplicated, will fill the gap if
any. Igor Bryskin: You can always take the native topology and then configure
abstract topology. We can update the TE topology if something is missing. Lou
Berger: We need to find out what is missing from topology model in detail (ie
down to which leaf items are missing). We can then figure out whether we need
to augment the topology model with this draft, or whether something's missing
from the topology model and needs to be added, so this is quite important.
Young Lee: the access point and customer endpoint is new Lou Berger: There are
policy differences, and we should discuss those in other documents. Young Lee:
Yes, we need to clarify this. Igor Bryskin: An important issue is how you
control the customer equipment. We have a concept of Tunnel Termination Point
and TTP can be given to orchestrator and used there. Young Lee: Yes, but the
customer has to give permission for this. Sergio Belotti: The second model of
VN needs to be addressed Igor Bryskin: It is already supported in TE topology
model Xufeng Liu: Regarding policy, we also plan to add in topology draft.

> 9         11:55 12:02   10    Title:    The Use Cases for Using PCE as the
Central Controller(PCECC) of LSPs >          Draft:
http://datatracker.ietf.org/doc/draft-zhao-teas-pcecc-use-cases/ >         
Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-9.pdf >       
          http://www.ietf.org/proceedings/96/slides/slides-96-teas-9.pptx >    
     Presenter:    Artsiom Rachitski

Jeff Tantsura: How do you envision provisioning flows in the LSP?
Artsiom Rachitski: We expect the controller to be provisioning IGPs and well as
LSPs, so traffic with go through L2 segments. The devices have L2 rings and are
the point of attachment for VPLS. VPLS uses the tunnels, and so VPLS traffic
also uses the tunnels. The question is how to load-balance efficiently. Jeff
Tantsura: So you'll just recursively resolve the loopback and have the traffic
follow the LSP closest to the loop? Artsiom Rachitski: yes. Jeff Tantsura: Do
you see a need for more granular provisioning to send traffic across different
LSPs? Artsiom Rachitski: yes, there's a need for that. We're expecting tunnels
to be built in regard to services required. Dieter Beller: Comment on the
draft, the statements that compare signaling-based solutions with distributed
system should be removed. Those are valid solutions for some problems. I
thought we had agreed to do that. Quintin Zhao: I sent an updated version was
sent to Dieter, your response is awaiting. We agree those statement should be
removed. Ina Minei: It seems like you're statically configuring label ranges
and downloading these from the controller. Artsiom Rachitski: no, we're not
statically configuring it. We're calculating the path and uploading the labels
Ina Minei: Why not use segment routing? Artsiom Rachitski: it's like discussing
whether to use one IGP or another. It's just a different solution. Ina Minei:
How are the labels allocated? Artsiom Rachitski: They're allocated by the
central controller. Ina Minei: what's the advantage in that? Artsiom Rachitski:
SR is just a tunnel built from the ingress; here we can control all devices.
Ina Minei: then what difference from previous PCE? Artsiom Rachitski: now we
can control on each node, and maintainance TED and LSPDB. Anurag Sharma: are
you planning to extend this use-case to multi-layer? Right now this seems to a
single-layer Artsiom Rachitski: we may try it. Lou Berger: How many read?
<quite many>
    How many think it is useful to WG? <quite many>
Lou Berger: As there will be an update soon, WG adoption poll will come after
update and discussions on list.

> 11         12:05 (12:14)   10    Title:    Architecture for Scheduled Use of
Resources >          Draft:
http://datatracker.ietf.org/doc/draft-zhuang-teas-scheduled-resources/ >       
  Slides: http://www.ietf.org/proceedings/96/slides/slides-96-teas-11.pdf >    
     Presenter:    Yan Zhuang

Dhruv Dhody: in the solution doc, synchronization between the controllers is
mentioned, and should be also included in the architecture draft as well. Yan
Zhuang: Confirmed. Lou Berger: Dhruv do you think that should be done
before/after WG adoption? Dhruv Dhody: After. Lou Berger: this topic has come
up in the IETF many times. When we were working on the distributed control
plane we said it didn't belong there. Now that we're looking at more
centralized models it seems like a reasonable thing to be looking at.
    How many have read? <Quite a lot>
    How many thinks this function useful? <Quite a lot>
    How many thinks this work good foundation? <Quite a lot>
Lou Berger: Clear that there's support in the room. Will move to WG adoption on
the list

> 10         12:15 (19)    10    Title:    PCE in Native IP Network
>          Draft: http://datatracker.ietf.org/doc/draft-wang-teas-pce-native-ip/
>          Slides:
http://www.ietf.org/proceedings/96/slides/slides-96-teas-10.pdf >              
   http://www.ietf.org/proceedings/96/slides/slides-96-teas-10.pptx >         
Presenter:    Aijun Wang

Lou Berger: do you see the work as constrained to TE, or broader than that?
Aijun Wang: only for TE.
Lou Berger: I didn't really get that from the document.
    How many have read? <a few>
Lou Berger: we have another path-computation use-case document; think about
whether there's common ground there and whether we should have a single
use-case document. Lou Berger: Thanks, all. See you in the joint Yang session
later today.

> Adjourn         12:30
>
> Notes taken by:

Dhruv Dhody
Haomian Zheng
Matt Hartley (from recording)