The draft minutes for the joint MPLS/PCE/TEAS YANG meeting at IETF 96 are now
available. Please see "session II" at the link below. Thanks to all our
minute takers! Please let me know if you have any comments or corrections.
https://www.ietf.org/proceedings/96/minutes/minutes-96-pce
Best regards
Jon
-------------------------------------------------------------------------------
Session II
Joint YANG session with MPLS & TEAS & PCE
Time:
July 21, 2016, 16:20-18:20 (4:20pm-6:20pm)
Location:
Charlottenburg II/III, Intercontinental Berlin, Germany
-------------------------------------------------------------------------------
Last meeting co-chaired by Ross. Set of pictures of Ross sitting between Pavan
and Jon taken by Lou and George.
1. Introduction
---------------
1.1. Welcome, Administrivia, Agenda Bashing (chairs, 10 min) (16:20-16:30)
2. YANG models discussion
-------------------------
2.1 YANG Data Model for TE Topologies
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
Xufeng Liu, 20 min (16:30-16:50)
Dhruv Dhody: Relationship with SR model?
XL: Types to be shared.
DD: Do we need RW on per-node attributes?
Tarek: There are cases where information is learned via IGP, but other cases
where static may be supported, thus the need for RW
DD: What do we do on conflicts? TBD
Igor Bryskin: one of the clients (users?) wanted to do path computation based
on TE information as well
Pavan: How many have read? Not so many. Please read and send comments to the
list.
2.2 A YANG Data Model for Traffic Engineering Tunnels and Interfaces
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/
Tarek Saad, 20 min (16:50-17:10)
Lou Berger: Send that [option request] to Netmod.
Xian Zhang: No strong preference among options, but, do these options on tunnel
model also apply to TE topology?
TS: I think you are actually asking about somthing that is derrived from
routing config, which is also using option #2 (schema mount).
LB: Routing config is using it, although the another wildcard form. logical
element and network instance in the RTGWG are also using this form. This
would be the 1st use of mounting a specific schema.
Loa Anderson: Issues to be fixed on valid ranges of label values.
TS: Ack
LA: Ambiguous names to be fixed on H-LSP part.
LB: What about Extension Labels (RFC7274)
TA: will need to consider.
DD: Be careful on artifical segmentation around PCC/PCE...
DD: The lsp-key is 5 tuple and it should support extensions towards other
technologies, e.g., SR.
TA: Will have split P2P and P2MP LSPs so will have index within each (sub)
trees
LA: ietf-te-yang inherits from 2 models; do we need to ensure special review
for these cases?
2.3 A YANG Data Model for MPLS Static LSPs
https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/
Tarek Saad, 20 min (17:10-17:30)
Iftekar (Infinera): Who's taking care of switch over?
TS: Static configuration. Pre-programmed backups are possible. Behaviors widely
depend on DP capabilities.
LB: What about OpenConfig's "applied state" discussion?
TS: No IETF consensus about its usage so far.
LB: Indeed, reco is not to jump to fast, too much error-prone.
TS: General consistency matters.
LB: From routing area discussion: use to be limited. View as author?
Pavan: Agreed on consistency, but eithier way is fine.
LB: Simplifying our models might be nice. Maybe we should ask the room.
Kamran Raza (Cisco): Should be consistent with MPLS document, some fallback
already happened.
XL: Not so much work. Structure to be simplified.
LA: Would it work if both simplified and more complicated module were pushed?
LB: Would work, but more implementation load. 2 different ways for every
information element; Having just one way to access the information implies
less code.
LB (chair hat on):
How many care? <A decent number, but "not as many as expected">
How many for simplified? <Almost the same>
How many for OpenConfig approach with augmentation? <A small number>
How many for OpenConfig as is? <One>
2.4 TEAS Transport Service Model
https://datatracker.ietf.org/doc/draft-zhang-teas-transport-service-model/
Xian Zhang, 15 min (17:30-17:45)
Tarek S: I don't understand what's missing from other modules for "step 1".
XZ: SB relies on PCEP, this is a service model.
Daniele Ceccareli: Is technology-specific only on tunnels or also at service
level?
XZ: A couple of attributes are relevant for services.
DC: OK, so both tunnels and service include technology-specific.
Anurag Sharma (Infinera): Commonalty with tunnel: required work?
XZ: Many things from tunnels turn optional/unnecessary.
Himanshu Shah: Would end up creating something covered by other service models.
George Swallow: There seem to be confusion. Service layer may be different from
transport layer (e.g., Ethernet and OTN).
Jon: This document is about transport as a service, not end user service
HS: Need another document to connect all the dots
DC: We can have higher layer services on top of pipe as well as service filling
in pipes. We don't have a common service model, like an umbrella.
XZ: We are looking at it differently, where we can have the ethernet or OTN
service
DC: Any plans in mind to solve non-te services?
XZ: Plans only for transport/TE.
Igor Bryskin: There is no difference between transport or service so lets just
use (existing) tunnel model
XZ: Indeed, difference is not clear.
2.5 PCEP YANG
https://datatracker.ietf.org/doc/draft-pkd-pce-pcep-yang/
Dhruv Dhody, 15 min (17:45-18:00)
Jeff Tantsura: Key-chain is close to LC.
Julien: Who has read document? <Some>
Who thinks it should be a WG document? <more!>
Who thinks it shouldn't be a WG document? <none>
Clear consensus in the room. Decision will be confirmed by a poll on the
PCE list.
2.6 YANG Data Model for MPLS LDP and mLDP
https://datatracker.ietf.org/doc/draft-raza-mpls-ldp-mldp-yang/
Kamran Raza, 15 min (18:00-18:15)
No question
2.7 LSP-PING-YANG
https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-03
Greg Mirsky (remaining time; started at 6:07)
Italo Busi: Are you including MEG, MEP, MIP, etc?
GM: LSP ping doesn't need those. No intention to introduce them there.
Zheng? (Huawei, co-author): Confirmed
<6:12 - Meeting adjourned>
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
