>
>
CCAMP Agenda For IETF
97
>
>Session I - Joint YANG session with MPLS, PCE and TEAS
>
Monday, November 14, 2016
(KST)
>
15:50-17:50 - Monday Afternoon session
II
>
Room: Park Ballrom
2
> Presentation Start
Time Duration
Information
> 0
15:50 10
Title: Administrivia - WG Status - Reporting on WG
drafts not being presented
>
Draft:
>
Presenter:
Chairs
Slides: https://datatracker.ietf.org/meeting/97/session/ccamp
Joint session with PCE/MPLS/CCAMP/TEAS on YANG topics
> 1
16:00 10
Title: A YANG Data Model for Path Computation Element
Communications Protocol (PCEP)
> Draft: http://tools.ietf.org/html/draft-ietf-pce-pcep-yang-01
>
Presenter: Dhruv
Dhody
Lou Berger: Good general question, when to stop adding features to YANG
models. It's hard to come up with a consistent answer. We should figure out how
to do this more generally. In TEAS we had a suggestion to pull out what
is stable and publish that in one document, maintaining a living YANG tree with
newer (less stable) features in a separate document.
Xufeng Liu: Suggest to use YANG push and notification subscription model.
Stephane Litkowski: Wait for the stateful PCE draft to end its last call so
we are stable in terms of behaviours and features.
> 2
16:10 15
Title: TE topology
models
>Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
>Draft: https://datatracker.ietf.org/doc/draft-liu-teas-yang-l3-te-topo/
>Draft: https://datatracker.ietf.org/doc/draft-liu-teas-yang-sr-te-topo/
>
Presenter: Xufeng
Liu
>Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
Jason Sterne: You removed a notification - instead you will rely on
subscription methods to subscribe to various state nodes in the model?
(Yes) Is that more generally applicable to other models, rather than
gratuitously generating notifications? (Yes)
Daniele Ceccarelli: What are the implications of this choice?
Xufeng Liu: More powerful and flexible and cleaner model.
Lou Berger: I want to push back on removal of performance metrics. Perhaps there
is a middle ground between something that doesn’t show up in all technologies
but does show up in more than one. You’ve taken grouping out and this is
something that might cause problems in the future, like for example we’re going
to need it in DETNET.
Xufeng Liu: There are different opinions, but this is more from the OTN and
optical side. Personally no strong opinion.
Lou Berger: What do we do with things that apply to multiple technologies
but may not apply to all? I don’t think cloning the information is the right
answer.
Xufeng Liu: We could make it optional for the technologies that don’t
support it.
Lou Berger: Good proposal. We should discuss it across the working groups.
Dieter Beller: We should take out tech specific
metric attributes from this draft as things like active path, delay variation
etc. are not applicable to transport technologies. This is why we should have
them in technology specific augmentations.
Lou Berger: It depends on which transport technology you are talking about,
there is more than optical out there.
Fatai Zhang: It is convenient to
use integer, but you miss some info for OTN switching. How is it possible to
encode ODUcn? You indicate e.g. slot 0, but which
kind of slot? E.g. fixed grid vs flexi grid.
Xufeng Liu: How do you encode it?
Fatai Zhang: You just need to add a
piece of information.
George Swallow: I don’t think it is a good idea to have a list of numbers
with different meanings. A sintax of e.g. 0:1, would
be better.
>Draft: https://datatracker.ietf.org/doc/draft-liu-teas-yang-l3-te-topo/
>Draft: https://datatracker.ietf.org/doc/draft-liu-teas-yang-sr-te-topo/
No comments
> 3
16:25 15
Title: TE/RSVP models
>Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-rsvp/
>Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te/
>
Presenter: Rakhesh Ghandi
Fatai Zhang: For compute only
paths, the result is statefull correct? (yes).
Consensus has not been reached. We should update the document only when
the WG has consensus on the change.
Rakesh Gandhi: Authors will update draft based when consensus reached.
Dhruv Dhody:
What decided here will impact PCE architecture, this kind of computation is not
available in PCE, we only have stateless and statefull
but not statefull compute. If we want this in YANG
this should be applied also to PCEP. We are not sure we want this in the PCEP
protocol yet - we shall discuss.
Young Lee: When you do compute only tunnels and there is no commitment
from the user and you keep them in the YANG store, would it be a valuable
thing? I don’t see value in that. There is a debate ongoing on the lists.
Sergio Belotti: Xian and I have supplied comments
to Tarek, but they have not all been addressed. Tarek has also clarified
that the model is predisposed to support classic RPC but the decision has not
yet been taken.
> 4
16:40 10
Title: YANG data model for MPLS LDP and mLDP
> Draft: http://tools.ietf.org/html/draft-ietf-mpls-ldp-mldp-yang-00
>
Presenter: Xufeng
Liu
Xufeng Liu: The authors planned to split draft-ietf-mpls-ldp-mldp-yang-00
into two documents: draft-ietf-mpls-ldp-yang and draft-ietf-mpls-mldp-yang, as presented
during the session
Pavan Beeram: Would the base model have any features at all?
Xufeng Liu: No.
Acee Lindem:
Interesting convention to keep base model with no features and put them all
into a separate module augmenting that model. Should we do that on a
wider basis?
Jeff Tantsura: It takes time and discipline to do it this way but it ends
up better. It simplifies the model.
Acee Lindem:
In the extended model, are there still features? (yes)
> 5
16:50 10
Title: YANG Models for the Northbound Interface of a
Transport Network Controller: Requirements and Gap Analysis
>Draft:https://tools.ietf.org/html/draft-zhang-ccamp-transport-yang-gap-analysis-01
>
Presenter: Sergio
Belotti
Pavan Beeram: In other section there are a couple of examples in which you
are using richer models like TE tunnel or TE topology as a service and you
carve what is not needed for transport NBI. Do we need to use new models or are
there ways to use existing models?è
Sergio Belotti: other models exis,
not sure if other models can be extended.
Pavan: Currently you are using the tunnel model as service model?
Sergio Belotti: NO because there is also the
transport service model proposed.
Daniele Ceccarelli: Do you want a new different model for the services instead
of using a simpler version of existing ones?
Pavan Beeram: It seems a new model is used using a carved version of an
existing much richer model. Is this what we want to do? The CCAMP design
team will look at this, we can probably provide inputs.
Lou Berger: I want to hear from ccamp chair what the scope of the work that
the design team is going to do.
Daniele Ceccarelli: Think this is more in scope for TEAS as it has a
generic part - in CCAMP we will look at the technology specific part.
Lou Berger: I thought the design team is covering gap analysis and come up
what is generic
Daniele Ceccarelli: We need a TE service model for the generic part and
then work on technology specific models
Young Lee: What is the transport NBI? (Northbouund Interface) We are
trying to avoid that terminology. Some service model does not belong to NBI
Haomian Zheng: Is it agreed that
different interfaces will have different YANG model? I mean northbound
interface vs interface to the devices.
Daniele Ceccarelli: I think they have to be different.
Lou Berger: There is a difference between a service and device model. In
the context of L2VPN and L3VPN services you want to talk about the colection of
pieces that make up the service. You may not want to specify everything but
sometimes you do. So you may end up with a protocol model inside your
service model. Now we have schema mount to take a model from a device
into a service. Perhaps that's a good way to go. As the design team is
looking for gaps, please focus on what is missing versus how to solve the missing
pieces.
> 6
17:00 8 Title: A YANG Data Model for
Optical Transport Network
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-l1-topo-yang-05
>
Presenter: Italo
Busi
Daniele Ceccarelli: Xufeng said technology specific parts are out of the TE
draft. Is there a plan to add them here? (Yes)
Lou Berger: Couple of things easy to fix. Slide 1 says layer 1 =
OTN. Not true - layer 1 is more than just OTN! I think you just mean
OTN. Please make sure you drop layer 1 and change to OTN.
Daniele Ceccarelli: To be more correct please use ODU as OTN us more than
ODU.
Lou Berger: The draft mentions MPLS-TP. Why?
Italo Busi: It was to clarify where OTN fits in the overall transport.
Lou Berger: It is confusing, please remove.
> 7
17:08 7 Title: A YANG model to
manage the optical interface parameters for an external transponder in a WDM network.
>Draft: http://tools.ietf.org/html/draft-dharini-ccamp-dwdm-if-param-yang-00
>
Presenter: Gabriele
Galimberti
Dieter Beller: The draft defines application codes,
out power and other parameters that are defined by the ITU-T which is fine, but
you are saying that you are going beyond that, but I still don’t see it in the
draft.
Gabriele Galimberti: An help from your side to
clean up the document would be appreciated.
> 8
17:15 8
Title: Microwave Radio Link YANG Data Model
>Draft: http://tools.ietf.org/html/draft-mwdt-ccamp-mw-YANG-00
>
Presenter: Amy
Ye
No comments or questions.
> 9
17:23 10
Title: Path Computation API
>Draft: https://tools.ietf.org/html/draft-busibel-teas-yang-path-computation-00
>
Draft: Italo Busi/Sergio
Belotti
No time for comments. Please send them to the list.
Pavan: Please could you confine discussion of this draft to the TEAS
mailing list?
> 10
17:33 7
Title: OTN Service YANG Model
> Draft: https://tools.ietf.org/html/draft-sharma-ccamp-otn-service-model-00
>
Presenter: Anurag
Sharma
Draft not presented.
> 11
17:40 5 Title: A YANG Model for
IP Link and Transport Service Mapping
>Draft:https://datatracker.ietf.org/doc/draft-fu-pce-ip-link-transport-service-mapping/
>
Presenter: Jianzhong
Fu
Sergio Belotti: Your doc provides a mapping between
the client IP link and the server transport tunnel.
Pavan Beeram: Please send the question to the list - we are out of time
> 12
17:45 5
Title: A YANG Model for VNT (IP Link) Protection
Group
>Draft: https://datatracker.ietf.org/doc/draft-fu-pce-vnt-protection-group/
>
Presenter: Jianzhong
Fu
Daniele & Jon: Better discuss this work in the TEAS working group.
> Adjourn
17:50
>
>
Session
II
>
Thursday, November 17, 2016
(KST)
>
13:30-15:00 - Thursday Afternoon session
I
>
Room: Studio
2
> Presentation Start
Time Duration
Information
> 0
13:30 10
Title: Administrivia - WG Status - Reporting on WG
drafts not being presented
>
Draft:
>
Presenter: Chairs
Gabriele Galimberti: for draft-ietf-ccamp-wson-iv-info, it was
just refreshed, no technical updates.
Young Lee: for draft-ietf-ccamp-wson-yang, no updates at
this moment, just waiting for the TE generic Yang, kind of close to be stable.
Italo Busi reports the update DT of Transport NBI.
Now we have just started talking with the chairs to understand the
expected output of the DT. We are planning to start collecting use-cases
and progressing gap analysis starting from two or three of them.
Also considering when and how to organize the team and trying to
understand what is done in other SDOs.
Daniele Ceccarelli: There is some discussion in IESG about
"supporting documents" like requirements, use cases, etc. The
supporting documents should not stop the solution documents. Not all the output
documents from the DT may end up to be published as RFCs, but they would be
progressed as WG documents so they could be available, searched and referenced.
> 13 13:40
10 Title: A framework for
Management and Control of DWDM optical interface
parameters
>Draft: https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-03
>
Presenter: Ruediger
Kunze
Fatai Zhang: There
were a couple of comments about the requirements, especially requirements on
LMP from the last meeting and those comments should be addressed. Actually, LMP
is an optional for GMPLS, but this draft says that LMP MUST or SHOULD be
supported. In addition, I recall a comment from Julien, which is about LMP
cannot be used for connection setup. I hope the authors can modify the drafts
to address these comments.
Ruediger Kunze: OK. We have to update the draft to address the comments.
Daniele Ceccarelli: Yes, I remember the comment was actually about the
difference between auto negotiation and configuration. Probably, we need some
work on this draft.
> 14 13:55
10 Title: Problem description
when describing and modelling Coherent DWDM Interfaces in optical
networks.
>Draft: https://tools.ietf.org/html/draft-many-coherent-DWDM-if-control-00
>
Presenter: Gert Grammel
Dieter Beller: Regarding the abstract or
introduction of this draft, it stated that the control plane aspects
pre-standard coherent optical DWDM applications needs to be preceded
independently of the data plane standards. I do have some concerns and
resistance on this. I am not sure whether CCAMP should step ahead what is going
on in the data plane standardization, and I had many comments in the previous
meeting related to that. I think it is
inappropriate to progress this work in this WG.
Gert Grammel: As feedback, we are here focusing on non-standard
interface. I don’t understand Why the standard work, any kind of influence
here?
Dieter Beller: I think we always develop the
control plane standards for the data plane that was already standardized as far
as the transport technologies concerning in ITU-T. Why we should have different
way for the WDM technology? Secondly, I have difficulty to understand, is this
a collection of proprietary stuff how different vendors have already
implemented this technology? I am not sure if this is useful proposal.
Gert Grammel: There are a few things. It is not always the case
that CCAMP starts working on things that are not yet standardized. For example,
WSON work started in parallel that was not standardized in ITU-T. That is
number one. Number two is, I don’t suggest here to do any kind of standard
work. The aim here is to have for everybody to use a coherent interface, to
have common set of Yang model that can be used for the control plane, so there
is nothing particular important with that. I think it is simply Yang model for
the pre-standardized interface.
Daniele Ceccarelli: We need to keep the scope clear. From one side,
there is possibility to define to try to make non-standard transponders
speaking with each other, as I understood, this is not the scope. The other one
is to define a common way of controlling different transponders provided that
there is some interoperate. Your intention is the second one, not the first one?
[Gert: correct].We are not
defining the standard for the data plane. The authors say that if provided two
transponders from different vendors interoperate, we would like to have a
common way to control them. This is my understanding. Please correct me if I am
wrong.
Gert Grammel: Yes, I would like to extend it. Provided you have
in your network a set of, maybe even pairs of transponder from single vendor,
you would like to control that set with single abstract model, so, again we are
not in the data plane work. We would like to have a simple way to provision the
coherent optical interfaces which are pre-standardized.
Deborah A Brungard: Speak as AD. Of course,
CCAMP does not define data plane. For other type of work could be informational
or experimental. Authors can take this trough CCAMP and you can all discuss it,
they can also never come to CCAMP and just done it as independent stream, so
then you will never see it. Since they brought it here, CCMAP can help guide
them and CCAMP can either decide if it can be informational WG draft or kick it
out of here and we don’t want to do anything here, and then they can go for
independent stream draft. I think at least they get guidance here and
expertise, if when this becomes standard, you have something looks rational to
be based; The danger is they just go for independent stream, you have no input
to this.
Haomian Zheng: How it
can co-work with other data plane work? It is not clear how to move forward
this work.
Lou Berger: When you get to the actual model, perhaps experimental makes
a lot sense because experimental tend to have a specific life time and can give
time the data plane standards to catch up and also allow us to get better idea,
what makes sense and what does not. It seems it is appropriate.
> 15
13:50 5
Title: A YANG model to manage the optical interface
parameters for an external transponder in a WDM network.
>Draft: https://tools.ietf.org/html/draft-dharini-ccamp-dwdm-if-param-yang-00
>
Presenter: Gabriele
Galimberti
Daniele Ceccarelli: Survey by Chair, how many thinks we should reject
this work? - 2;
How many thinks we should do this work as experimental? - 3 (authors)
Lou Berger: I am OK to work on it, but I am not going to build it.
Deborah A Brungard: authors can always do
this, and kick it out later and say the WG does not have interest to publish
it, and then go for independent stream.
> 16
14:05 10
Title: Microwave Radio Link
Framework
>Draft: https://tools.ietf.org/html/draft-mwdt-ccamp-fmwk-01
>
Presenter: Jonas
Ahlberg
Lou Berger: There is alarm model, it is doing control of alarm. There
should be some technology specific part of that. What WG should do it? From Netmod chair point of view, I might say this should belong
to some other place. From Teas chair point of view, I think maybe Teas should
cover the generic part and CCAMP focus on technology specific. But you can also
say that this is not TE, and CCAMP can also do the generic part. I don’t have a
strong opinion but I’d prefer the work not to be done in Netmod
WG. (Lack of technology specific knowledge). But I am open to do generic in
TEAS or both (generic and technology specific) here. I am speaking as one of
TEAS chairs, let’s see my co-chair’s position.
Vishnu Pavan Beeram: I think alarm information could be used for TE
application, so I don't mind taking to teas.
Deborah A Brungard: the most important is to
make the work done; looking at this draft, I see more CCAMP because most of the
things are close to CCAMP and lots of transport alarm expertise is here.
Daniele Ceccarelli: who is in favor of this work? Quite a lot. Who is
against? No one.
> 17
14:15 10
Title: Microwave Radio Link YANG Data
Model
>Draft:https://tools.ietf.org/html/draft-mwdt-ccamp-mw-YANG-00
>
Presenter: Amy
Ye
Daniele Ceccarelli: in case someone wants to join you, when are you
meeting?
Amy Ye: Right after this session and open to everyone.
> 18
14:25 10
Title: GMPLS Routing and Signaling Framework for ODUCn (FlexE)
>Draft:https://tools.ietf.org/html/draft-wang-ccamp-oducn-fwk-00
>
Presenter: Qilei Wang
Gert Grammel: ODUC is a kind of signal type with n is the
multiplier; ODUC1 is different from ODU4? (yes) does it mean we have two
different ways for 100G?
Fatai Zhang: ODU4 is
different from ODUC1 in signal types.
Dieter Beller: Data plane is done in ITU and it's time to start this work in CCAMP, support.
Daniele Ceccarelli: some code already exists; (will try to reuse),
suggest to have a single draft on signaling solution, don't go to
requirement/framework;
Gert Grammel: would need to spell out the difference and
consider Stitching is not available, may need to deal with.
> 19
14:35 10
Title: GMPLS Routing and Signaling Framework for
Flexible Ethernet (FlexE)
>Draft: https://tools.ietf.org/html/draft-izh-ccamp-flexe-fwk-00
>
Presenter: Iftekhar Hussain
Dieter Beller: Resizing is not in OIF EIA. Back
to back use case is also not a part of OIF FlexE.
Iftekhar Hussain: already decided to remove resizing, will update
if there is still any. The B2B has been discussed and currently the authors
prefer to keep it.
> 20
14:45 10
Title: YANG Models for the Northbound Interface of a
Transport Network Controller: Requirements and Gap
Analysis
>Draft: https://tools.ietf.org/html/draft-zhang-ccamp-transport-yang-gap-analysis-01
>
Presenter: Sergio Belotti
Gert Grammel: How to interpret the physical link, e.g.
like Ethernet over ODUCn? Need to address
this for update.
> 21 14:55
5 Title: RSVP-TE Extension for
Beyond 100G Signal Types in G.709 Optical Transport
Networks(OTNs)
>
Draft: https://tools.ietf.org/html/draft-ali-ccamp-oducn-signal-type-00
>
Presenter: Fatai Zhang
Gert Grammel: again, ODUC1 to ODU4, are both
100G but incompatible; would see the need to clarify and should
document somewhere.
Fatai Zhang: Will
have double check with G.709 Editor and document it if needed.
Qilei Wang: I am not
sure if fwk/requirements are needed or not.
Fatai Zhang: we can
work on that, but the requirements are very clear for this draft;
Qilei Wang: ODUCn should be more than 9;
Fatai Zhang: It can
be extended as needed. Currently, a maximum of 6 should be sufficient at this
moment.
Loa Anderson: any information if we found for fwk/use
case, you can integrate into this document.
Daniel Ceccarelli: Is Requirements enough?
Fatai Zhang: need to
investigate if additional requirements are needed when it is beyond 100G.
Routing extensions should be addressed in another separate draft.
> Adjourn
15:00
Note takers
Yuji(remote)
Haomian
Italo