Minutes for TEAS at IETF-93

Meeting Minutes Traffic Engineering Architecture and Signaling (teas) WG
Title Minutes for TEAS at IETF-93
State Active
Other versions plain text
Last updated 2015-09-22

Meeting Minutes

   TEAS 93rd IETF

TEAS Agenda For IETF 93
Jul 16, 2015Wednesday July 22nd, 20151300 - 1530 -
Wednesday Afternoon Session I
Room: Congress Hall 1

Chairs: Lou Berger and Vishnu Pavan Beeram

> Presentation                 Start Time         Duration        
Information > 0         13:00         7         Title:         Administrivia
& WG Status >                         Draft: >                       
 Presenter:         Chairs Administrivia & WG Status - TEAS RFCs! - See
slides for update

> 1         13:07         8         Title:         Draft updates
>                         Draft:         Many
>                         Presenter:         Chairs
Re: interconnected-te-info I-D

Adrian Farrel: Apologies. We are reviewing I-D and have substantive reductions
in text soon. This will mean the document needs a careful review.

Pavan Beeram: draft-ietf-teas-p2mp-loose-path-reopt could do with more people
reading it. Not many have so far.

Extensions to RSVP-TE for LSP Ingress Local Protection
Pavan Beeram: The authors of several WG drafts believe their drafts are ready
for LC (see slides).  Please review and comment on the list.


> 2         13:15         5         Title:         Extensions to RSVP-TE for
LSP Ingress Local Protection >                         Draft:        
http://tools.ietf.org/html/draft-ietf-teas-rsvp-ingress-protection >        
                Presenter:         Huaimo Chen Presentation:

Lou Berger: [Slide 5] Have you made any progress on selecting which method
(Proxy-Ingress or Relay-Message)? Raveendra Torvi: We will be meeting later
today Huaimo: Yes, the authors plan to meet, discuss and decide. Lou Berger:
Please announce meeting on list so others may join in discussion

> 3         13:20         20         Title:         YANG Data Model for TE
Topologies >                         Draft:        
http://tools.ietf.org/html/draft-ietf-teas-yang-te-topo >                   
     Presenter:         Xufeng Liu / Igor Bryskin

Presentation: https://www.ietf.org/proceedings/93/slides/slides-93-teas-3.pdf
Lou Berger: It would be good to follow through on your plan to remove
scheduling sooner rather than later Xufeng Liu: Yes, within the next two weeks

Adrian Farrel: Overlay & underlay relationship [slide 16]: I like that you
can look down to the underlay; is it possible to reverse the view, can I (as
the underlay) see what is above, i.e. what overly topology traverses me? Xufeng
Liu: yes, but it may be inconvenient. We don't want to have 2-way links. Adrian
Farrel: is there a quicker way that searching the whole TED? Lou Berger: Can
you clarify if the model has the capability to do this? Or an implementation is
required to support it. Xufeng Liu: The model allows it Adrian Farrel: So there
is no back pointer in the model itself. Igor Bryskin: The model makes it easy
to go from overlay to underlay - that relationship is usually 1:1, from
underlay to overlay it could be 1:n so it is more difficult.

> 4         13:40         25         Title:         RSVP/TE Yang Models
>                         Draft:        
http://tools.ietf.org/html/draft-saad-teas-yang-te >                        
http://tools.ietf.org/html/draft-saad-teas-yang-rsvp >                      
  Presenter:         Tarek Saad >        Slides:

Lou Berger: Same question as IETF 92 - What do you mean when you say "Generic",
does it include GMPLS? Tarek Saad: Generic includes generic features, e.g.,
bidirection, technology specifics are separate. Today just PSC is included.
Igor Bryskin: Question for WG, a number of items missing from generic model. If
we need to configure a transport service, then some elements may need to be
configured that are not end-to-end. Tarek Saad: We wanted to defined a generic
model, if what you state is applicable to multiple technology types it can be
included in the generic model, but if its a single technology then no and it
will need to be modeled and augment. Lou Berger: There is an example of this
mentioned earlier (bidirectional) and the authors have a proposed approach.
Once this is a WG document, the group can discuss and decide if this is best.

Paul Doolan: Are the switching capabilities aligned with the generic model, and
where are they derived from? Tarek Saad: Yes. Check they should be referenced
[in I-D?] Paul Doolan: Ok, I just wanted to state the need to align.

Lou Berger: Have you thought about merging with the OpenConfig draft?
Tarek Saad: had some meetings with them, including one yesterday. We're
aligning with their work. They'll import some of our groupings for now. I'll
let Ina talk about long-term plans Ina Minei: We want to converge, if possible,
and the authors will continue to talk. We want models that are easy to
implement. It is too early to state that the authors plan to merge I-Ds. We
want to avoid duplicating effort.

Jeff Haas: approached the mic but was requested to send his comment/question to

Lou Berger: [To Ina] We need to decide how to proceed as we have an I-D that we
could adopt and work on. However, we do not want to move ahead and diverge from
your work item as it has merit. Ina Minei: I understand your perspective but we
are keeping our work separate for now and working on implementations using the
models. Optimally we'd have our model which is made up of a collection of
standard elements.

Chair Poll (on presented drafts)
- How many have read these I-Ds? 
- How many feel the I-Ds are a good place to start?  

Lou Berger: so we have a foundation, but we don't want to fork the work and we
want to reconcile things. Normally we'd say "please merge the drafts", but we
can't really ask this yet... Ina Minei: I can't speak for OpenConfig
co-authors, but I'll take that feedback back to the OpenConfig folks and
discuss with them. Lou Berger: we can define groupings that are used by
multiple models. Ina Minei: that's the direction we're driving in. Ultimately
we care about implementations and we don't' want to make people write code
twice Lou Berger: Openconfig objective of a concise draft for their use, which
may be different from the WG which may care more about covering the entire

- (asked later) How many feel is good starting point for WG: 

> 5         14:05         10         Title:         MPLS / TE Model for
Service Provider Networks >                         Draft:        
https://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-01 >   
                     Presenter:         Ina Minei >        Slides:

Loa Anderson: Meta question, the document is split 50/50 RSVP-TE and LDP. I am
not clear if TEAS will be performing LDP work. Lou Berger: LDP details belong
in MPLS. We need a common structure, this might be a meta/framework document or
this document. This overall model could be managed here or in MPLS.  For now,
I'd say keep it here but we can revisit. Loa Anderson: As longs as the document
states which containers are used its ok, if you start modifying the details
within the container then its a problem. A suggestion, work on the document and
present the RSVP-TE in TEAS WG and update MPLS WG for your LDP developments.
Ina Minei: Okay. George Swallow: Are you importing containers from other
models? Ina Minei: No, not currently. But that is the plan. ???: Has there been
any work on coordination with other documents? Lou Berger: some, but all the
documents need more coordination.

> 6         14:15         10         Title:         Usage of IM for network
topology to support TE Topology YANG Module Development >                   
http://tools.ietf.org/html/draft-lam-teas-usage-info-model-net-topology >   
                     Presenter:         Scott Mansfield >        Slides:

Lou Berger: Please verify that our YANG models satisfy the IM and work with
authors on any identified short commings.

> 7         14:25         10         Title:         Topology requirements
>                         Draft:        
http://tools.ietf.org/html/draft-doolan-teas-te-topo-ml >                   
     Presenter:         Paul Doolan >        Slides:

Cyril: The abstracted topology seems to already supports some of the
requirements/elements described in [slide n - virtual optical switch], or could
be augmented for transport specific use cases.

Lou Berger: I suspect much of what you are interested is covered by existing
drafts or plans.  Please talk with the authors directly to see if yours needs
are met, or how they could be met. Also, keep in mind that technology specific
definitions are still TBD and will be done in CCAMP.  Once this is done, the
draft can still be valuable by documenting your use case. Paul Doolan: Others
have suggested a similar approach. Julien Meuric: Can you clarify the switching
capability reference you made? Paul Doolan: IANA

> 8         14:35         10         Title:         Implementation
Recommendations to Improve the scalability of RSVP-TE Deployments >         
http://tools.ietf.org/html/draft-beeram-teas-rsvp-te-scaling-rec >          
              Presenter:         Vishnu Pavan Beeram >        Slides:

- How many think this is a topic we should be working on? [a good number]
- How many think this a good document to start with? [~ the same number]
- Does anyone have any comments or reservations about pursuing this work? [none]

> 9         14:45         10         Title:         Extensions to MPLS for
Temporal LSP >                         Draft:        
http://tools.ietf.org/html/draft-chen-teas-rsvp-tts >                       
 Presenter:         Huaimo Chen >        Slides:

Lou Berger: Due to time constraints we will have move the comments to the list.

> 10         14:55         10         Title:         ACTN : Use case for
Multi Tenant VNO >                         Draft:        
http://tools.ietf.org/html/draft-kumaki-teas-actn-multitenant-vno >         
               Presenter:         Takuya Miyasaka >        Slides:

Lou Berger: You mentioned transport to start, and then mentioned L2VPN and
L3VPN as your user service. Takuya Miyasaka: Yes, we are interested in L2VPN
and L3VPN services Lou Berger: [Slide 4] Can you clarify QoS and SLA? Takuya
Miyasaka: Bandwidth, latency, jitter, Lou Berger: Are these MEF definitions,
how do you describe the parameters? Takuya Miyasaka: No, simply the same
parameters for the end-to-end network mentioned before Lou Berger: Looking at
an earlier slide, you show a customer provisioning interface is that something
like a web based interface, is this correct? Takuya Miyasaka: Yes. Lou Berger:
You show PCEP and RSVP for provisioning services within the network, do you use
one or both? Takuya Miyasaka: Both

> 11         15:05         10         Title:         Requirements for
Abstraction and Control of Transport Networks >                        
Draft:         http://tools.ietf.org/html/draft-lee-teas-actn-requirements >
                        Presenter:         Young Lee >        Slides:

Lou Berger: A good start on requirements, and notable section on impact on YANG
but this section needs further development. I would also like to see more
discussion on future requirements and work that needs to be done. For adoption,
I think we need to polish the aforementioned sections.

- Who has read the document? 
- Who thinks this is a good document to serve as a foundation?  

Lou: We can talk offline if comments are not clear, right after this

> 12         15:15         10         Title:         Framework for
Abstraction and Control of Transport Networks >                        
Draft:         http://tools.ietf.org/html/draft-ceccarelli-actn-framework > 
                       Presenter:         Daniele Ceccarelli >       
Slides: https://www.ietf.org/proceedings/93/slides/slides-93-teas-12.pdf
Daniele: this work was previously polled and had good support Lou Berger: Poll
was on the discussion not on a specific draft, and lead to the discussion here
Daniele: (closes by summarizing ACTN overall status) Lou Berger: Understanding
what the protocol extension requirements are would be very helpful. The
interconnected-te document went through a similar process, but more for the
case of end to end signaling control. This document may follow a similar
evolution, but more from the perspective of "logically centralized" control.
Daniele: Correct, that is the main difference Lou Berger: Please look to focus
your document in the context of technologies that we have available, and its ok
to say "this piece is missing". Daniele: Is it ok to keep that discussion (gap
analysis) in this document? Lou Berger: If terminology is changed to cover the
family of TE solutions, it's a great foundation for that. And hopefully we can
get there faster than the we did with the interconnected document Young Lee:
The document is an architecture framework document that should be viewed within
the scope of TEAS with a more  "logically centralized" approach without talking
about protocol yet. Is it ok? Lou Berger: Yes agreed. This is rounds out and
compliments the interconnected-te document and provides a missing part. Please
authors, consider the comment and see if you can update the document from this
perspective, the concepts are the same but will require authors. Young Lee: Do
you have detailed suggestions. Lou Berger: We can talk offline and discuss.

> 13           15:25         5         Title:         Requirements of
Abstract Alarm Report in ACTN architecture >                         Draft: 
>                         Presenter:         Xu Yunbin >        Slides:

Pavan Beeram: Please merge this with the earlier requirement draft

> Adjourn                   15:30

Minute Taker: Dan King

     Matt Hartley has reviewed audio
     ACTN notes updated by Lou Berger from audio