Thursday, November 21, 2019 (+08)
10:00-12:00 Thursday Morning session I
Room: Hullet
Presentation
Start Time Duration Information
10:00
Title: Administrivia - WG Status - Reporting on WG drafts not being presented
Presenter:Chairs
Haomian Zheng:(draft-ietf-ccamp-flexigrid-media-channel-yang）depending on the L0 types/TE tunnel. Once those drafts are stable this work can be progressed.
10:10
Title:A Yang Data Model for Optical Impairment-aware Topology
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-optical-impairment-topology-yang-02
Presenter:Dieter Beller
Fatai Zhang: where does the architecture figure (disaggregated ROADM) come from (ITU-T? Openroadm)
Dieter Beller: this is from Openroadm;
Fatai Zhang: from the data plane, usually we follow ITU-T recommendation rather than OpenRoadm.
Gabriele Galimberti: In general this is an example architecture, where you can simply have fiber and lambda switching inside. This is one of the most used in the industry today. This is applied whenever we want to identify the two nodes by different models. We are using this architecture to figure out how to use YANG to describe it. The discussion is still open, on whether port-based or path-based, we will figure out how to model internal the box, which is a black box.
Dieter Beller: The reason why we are looking at this kind of architecture is we have to make sure that the models we are defining cover all potential architectures, including disaggregated architectures. We try to make sure cover all the different architectures.
Daniele Ceccarelli: I agree with that, otherwise we have risk to have something that covers only 10-20% of what is in field. If we want to make something usefull we have to make sure at least good portion can be covered. This is not a fully architecture mandated by the ITU, but I have the same feeling this can be deployed.
Deborah Brungard: this is a document with sufficient material. Please remember to update references and reference as much as you can. Keep to do it now to avoid future problems. Folks may have concern if something is not ITU, but feel free to consider them as well. Liaison may be needed to be sent to ITU-T SG15. Try to get a clear version at beginning of January and liaise to ITU. They have liaised us and clarified the OTSi, and I believe you have already aligned on that?
Dieter Beller: this document is also related to G.807, which is under AAP Last Call. Resolution is in progress.
Deborah Brungard: I think it is important now include those references in the liaison and specify why you choose these parameters to build enhance models, to make sure they can understand. Otherwise they will just feedback some of these are not ITU.
Haomian Zheng: G.807 is just architecture, not data plane. We need to refer both G.807 and ITU-T data plane recommendations.
Fatai Zhang: a reminder to reference to data plane. Regarding Roadm architecture, we should not only reference to G.807, but also G.672, which talks about the architecture of Roadm. The current draft does not reference G.672, please double check.
Dieter Beller: will do that, we need to add more reference to ITU Recommendation.
(3R page)
Daniele Ceccarelli: Please check if 3R is always coupled with ROADM or there can be legacy scenarios in which regenerator is present without ROADM.
Dieter Beller: this may be something beyond our assumption.
Gabriele Galimberti: in general if you just have a regenerator, it is on lambda and you need a Roadm. And then you can select a lambda that you want to regenerate. That is why we combine the regenerator with the Roadm architecture.
Daniele Ceccarelli: just want to make sure that all the legacy architecture can be covered, for example when the regenerator is in the non-Roadm nodes. That is also in field.
Gabriele Galimberti: in this case you don't have it, but in the end you may. Regenerators can be on any channels. We can also cover this stuff.
Daniele Ceccarelli: I don't have the number on the portion of such nodes. May not need to cover it if the percentage is very low.
Gabriele Galimberti: I think this kind of regenerators has been used in SDH/SONET. Now there is much less.
Daniele Ceccarelli: if you finally find the usage is not much, you can leave it out.
(github)
Daniele Ceccarelli: we discussed the possibility to have a CCAMP github, we are happy to have WG account from github. I read the draft on organization github, seems that sooner or later we will have one in datatracker, but not sure about the timing. We may also have github controlled by IETF later, so that would be another migration. We may first create a WG one and then move to IETF.
Dieter Beller: that is exactly what we are suggesting. Let's take it offline.
Fatai Zhang: please go to the list for discussion and comments.
10:25
Title:A YANG Data Model for Layer 1 Types
A YANG Data Model for Optical Transport Network Topology
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-layer1-types-03
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-otn-topo-yang-09
Presenter: Sergio Belotti
Robert Wilton: is this model and the layer-0 types are the models to be reviewed (by YANG doctor)?
Fatai Zhang: layer1-types are already sent to YANG doctors for review.
Robert Wilton: which model is referring to the layer1-types module? OTN topology or layer0-types?
Haomian Zheng: layer1-types is foundamental in OTN and will be referenced in OTN topology module; the progress now is the chairs send the layer1-types and layer0-types to YANG doctor review as they are correspondence in different switching layers. The WSON topology will be referencing to layer0-types.
10:40
Title:A YANG Data Model for Layer 0 Types
A YANG Data Model for WSON (Wavelength Switched Optical Networks)
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-layer0-types-02
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-wson-yang-23
Presenter: Haomian Zheng
Greg Mirsky: where do you prefer to have fractions? here you have uint16. You cannot have fractions in this type.
Haomian Zheng: here (slide 3) is typedef dwdm-n (uint 16). We are proposing fraction on central frequency, which is the numerical value on the spectrum. Central frequency would be 193.1THz, with channel spacing 12.5G.
Greg Mirsky: basically you can have a union, for GHz digit 1 and for THz digit 4.
Daniele Ceccarelli: the m and n are integers, aren't they?
Haomian Zheng: m is for slot width, but measured in GHz, n is for nominal central frequency, measured in THz.
Greg Mirsky: will double check, integer won't need fractions.
Gabriele Galimberti: to clarify, no matter you use n/m or the frequency, you should have 5 digit for THz.
Haomian Zheng: 5 digits? Are you talking about potential 6.25GHz?
Gabriele Galimberti: yes, 6.25GHz will need 5.
Haomian Zheng: so 2 for GHz and 5 for THz.
Italo Busi: to help clarify, we have two different types. If we talk about n/m, they are integers. If we talk about the representation of signals, for example the central frequency, then it is THz/GHz; they are two different types.
Fatai Zhang: it seems we have two types of units, GHz and THz. Can we just use one type of unit? For example GHz only?
Italo Busi: some times it is more readable to have THz, in some other cases it is more readable to have GHz.
Haomian Zheng: If we have to choose one, slightly prefer to GHz.
Italo Busi: then we will have rather long numbers before the comma (as integer part), not easy to read in JSON code.
Dieter Beller: we also have discussion for carrier-frequency regarding TE models for optical impairment. We decided to use certain digit numbers. The question is how can we get alignment with layer0-types across multiple YANG modules which are using these type definitions.
Robert Wilton: (as YANG doctor) going back to the point 'more readable to choose', generally it is better to choose one. In JSON you can get it and change to easier numbers. In terms of trying to get commonality, we need to review those modules together to make sure on their consistency. I do not know how to make it as it is hard to judge. If they are used in different positions we usually try to keep a consistent format. Moreover, given the channel spacing is becoming smaller and smaller, we may need more digits.
Greg Mirsky: confirmed that decimal types allow fraction digits. The comment is to use single units, either GHz or THz to make the system simpler.
Haomian Zheng: we agreed on only using the unit of GHz.
Greg Mirsky: then you can have decimal32 or 64, to have 5 digits.
Haomian Zheng: for GHz we don't need as much as 5, (Greg: then 2.)
Gabriele Galimberti: please make sure to be future-proof, 6.25 is becoming 3.125.
Dieter Beller: Regarding impairment discussion, is this work going to WG LC and be frozen? The progressing impairment work may impact the types by introducing additional types.
Fatai Zhang: Agree on this.
10:50
Title:A YANG Data Model for Transport Network Client Signals
Title:A YANG Data Model for Ethernet TE Topology
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-client-signal-yang-01
Draft:https://tools.ietf.org/html/draft-zheng-ccamp-client-topo-yang-07
Presenter:Italo Busi
(draft-zheng-ccamp-client-topo-yang-07)
Fatai Zhang: How many has read? Many.
How many support the WG to adopt? As many as 1st.
How many does not support? None.
Fatai Zhang：will take this to the list.
11:00
Title:Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application
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-ietf-ccamp-dwdm-if-lmp-01
Draft:https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-param-yang-02
Presenter:Gabriele Galimberti
(first document)
Haomian Zheng: why maintenance section added for LMP?
Gabriele Galimberti: useful in case you have client and server relationship and maintenance is between neighbor not e2e.
Dieter Beller: this yang model also use layer0-types?
Gabriele Galimberti: need to understand whether to layer0-types or ietf-if, and how to use them. We may need to add some types into layer0-types and/or ietf-if types.
Dieter Beller: I believe you may also need to use layer0-types.
Gabriele Galimberti: is layer0-types also using ietf-if types? (No.)
Italo Busi: maybe both would be needed. Defining groupings in layer0-types, then they can be used in impairment to augment topology, and used in your model to augment the interface.
Gabriele Galimberti: ok, will do that when we understand and decide.
Dieter Beller: then we can get much more alignment among different YANG models.
Fatai Zhang: Regarding LMP new use cases are taken from FWK document, do you imply to delete them in future editing?
Gabriele Galimberti: FWK is stuck, we have not decided. Let's discuss among the WG.
Fatai Zhang: according to the suggestions from AD, we need to focus on the solution draft.
Gabriele Galimberti: then it's fine to have the fwk dropped.
11:10
Title:Problem Statements of FlexE Interface Management
Draft:https://tools.ietf.org/html/draft-jiang-ccamp-flexe-ifmps-00
Presenter:Fan Yang
Qilei Wang: regarding the negotiation protocol, we need to be careful as there is no need to invent a new technology for FlexE (data plane). In this protocol I cannot find any definition on FlexE data plane standard, so it does not make sense to have a protocol on that.
Fan Yang: Agree on the element from the data plane should not belong to here.
Yuanlong Jiang: we don't introduce any new protocol here, just reuse data plane protocol defined in OIF.
Fan Yang: maybe misunderstanding from the negotiation protocol, no protocol there.
Robert Wilton: RPC should not be used for PS5. The usage of RPC is usually for configuration, but not for management.
Fan Yang: it's not yet quite mature to have RPC here, it's not in the draft so far. Open to comments offline with more details.
Dieter Beller: OIF IA for flexE is currently as informative document, should it be a normative?
Fan Yang: not quite sure, will check offline.
Fatai Zhang: please continue after next two presentations.
11:20
Title:YANG Data Model for FlexE Interface Management
Draft:https://tools.ietf.org/html/draft-jiang-ccamp-flexe-yang-02
Presenter:Yuanlong Jiang
Fatai Zhang: what is the conclusion/findings after you compare the two models? Do they have much in common or huge difference?
Yuanlong Jiang: The target for these draft is to manage the FlexE group, the problem is the same but methodology is different.
Daniele Ceccarelli: We are looking for consensus, 'this is much better than that' is not helping to make progress. We need some synergy to move on rather than discuss the difference. We see comments raised on the list right before the session. Please use the list to do the discussion. we have difficulties on choosing one of the document to be adopted. Make progress between two meetings on the list.
Yuanlong Jiang: the authors from two drafts are having different opinions, we would like to put the difference on the table.
Daniele Ceccarelli: but the wrong table, please use the list.
Yuanlong Jiang: Good suggestions, we will do that.
Danele Ceccarelli： let us know if you need periodical meetings.
Greg Mirsky: what's the scope of the switching? Switching E2E or within a link.
Yuanlong Jiang: we focus on the link between two FlexE nodes. It is just a link, but also sham to sham.
Greg Mirsky: You mean the switching from one link to another?
Yuanlong Jiang: No, just switching from one calendar configuration to another calendar configuration.
Greg Mirsky: then that's not switching, it is reconfiguration.
Yuanlong Jiang: Then it may be a new concept.
Greg Mirsky: No there is switching, and configuration. We are understanding that, switching you do in TDM is on the box, between different links. ITU-T told us in their liaison, not to do switching. If you talk about configuration, then it is reconfiguration. According to your presentation, you mention channel switching so we understood as you are doing switching.
Yuanlong Jiang: Switching is the concept of OIF...
Greg Mirsky: no. You should be aware of ITU liaison on 'not switching' .
Fatai Zhang: We get the point, please have more discussion on the list.
11:30
Title:Analysis for FlexE control & A YANG Data Model for Flex Ethernet(FlexE)
Draft:https://tools.ietf.org/html/draft-wang-ccamp-flexe-control-analysis
Draft:https://tools.ietf.org/html/draft-xiaobn-ccamp-flexe-yang-mod
Presenter:Qilei Wang
Italo Busi: ITU-T G.8023 defines the interface between the atomic function and the EMF. The YANG model is the interface on top of the EMF. Q14 also clarifies that not all the details need to be exposed in the YANG model. We are also working in Q14 to build the attributes of the YANG model and to avoid to expose every bit on the wire. We assume to have only what is needed to be configured as part of the YANG model.
Qilei Wang: Ok. Let's do an analysis based on use cases (agreed by Italo)
Yuanlong Jiang: (regarding the comments pages). A is always the active calendar, and B is never used. How do we represent B? Why do we need to configure it?
Qilei Wang: Just to not preclude any possibility. You mentioned this is a typical configuration, but there can be other variations. We should avoid to restrict to any specific implementation.
Yuanlong Jiang: Ok, but it looks you are also having private implementation which are not the OIF behavior. Is your coding function specified in OIF? You are also talking about some other use cases.
Qilei Wang: No I don't think so.
Yuanlong Jiang: Maybe we can bring it out, look and see if the problem is really there.
Qilei WAng: This has been already explained, twice.
Fan Yang: I have different thought here, regarding calendar configuration. If we are going to define these attributes, when you assign the parameters to the device, the running calendar of the FlexE on the device should be disrupt becuase you are running the new parameters there. Then there is an interupt of the FlexE service. Did you consider other possiblility to configure the calendar? The calendar configuation on A and B are specified in OIF, the main target of this tool on the two calendars won't make sense if one of them is always active and the other is not used. Two calendars may also be useful when you have to make hitless switch-over such as resizing. Do you plan to consider any better or other way to deal with such scenarios?
Qilei Wang: this part has not been covered in the slides. We have plan on this and probably discuss offline.
Robert Wilton: two competing flexE models. I see Cisco name on one of the draft. To get consensus, we suggest to use YANG features if something is optional. How to manage the FlexE node would be a separate question, that cannot be solved by using such features. The suggestion (from YANG doctor) is to try to look at the shapes of the two models and try to get alignment and generate a common shape. My understanding is with FleE, the issue is about when you create the interface and try to set it up, if you put multiple interface you get large cache with issues. So maybe sometimes having things outside would fit better. I am trying to get the agreement of those external things.
Daniele Ceccarelli: the suggestion from YANG doctor is a common sense. Please go ahead start building something together. The calendaring is an issue but not the biggest one. The switching part, the configuration, are the issues the authors should start with.
David Sinicrope: When we talk about something should be or should not be on the interface, we need paper-based proposal, and ask for OIF feedback.
Fatai Zhang: please the authors talk with each other, understanding and seek for convergence.
11:40
Title:A YANG Data Model for Client Signal Performance Monitoring
Draft:https://tools.ietf.org/html/draft-zheng-ccamp-client-pm-yang-00
Presenter:Haomian Zheng
No discussion & Comments.
11:50
Title:RSVP-TE Extensions in Support of Proactive Protection
Draft:https://tools.ietf.org/html/draft-lin-ccamp-gmpls-proactive-protection-00
Presenter:Yi Lin
Greg Mirsky: you do this end-to-end, not segment/link protection. I don't think there is any need for extension. With the QoS degradation, you can have the existing method to deal with the problem. All the mechanisms are already in RSVP-TE. No more than informational.
Yi Lin: Prediction is different from SF/SD. SOP can be one example.
Lou Berger: we said it belongs to teas. Please discuss on the teas list.
Adjourn12:00