CCAMP Working Group Meeting @ IETF 93

Monday, November 2nd, 2015

1520-1650 – Monday Afternoon Session II

Room: 411/412

>0 15:20 10 Title: Administrivia- WG Status

> Presenter: Chairs

We have a new errata, since last meeting, filledby Dhruv and Jon. It was accepted, identifying the wrong padding in RFC 4920. No new RFCs since last IETF, four at the RFC Ed. Queue (two about flexi-grid and two about WSON), one at the IESG process. About to issue WG LC for otn-signal-subregistry (IPR poll at the moment).

>WGs not presented

draft-ietf-ccamp-wson-iv-info:

Giovanni: Preparing a liaison text to send to the list and then double check with ITU-T on the list of parameters in relevant recommendations. Question from Xian: can we ask questions about I-Ds, which are not WG drafts?

Daniele: Yes; it is possible.

Giovanni: About the latest version, we did refresh but only clarification regarding Section 3, which is mainly targeting ITU-T people.

>Liaison:

<1> Achieving packet optical optimization using DWDM interface from BBF

Dave: BBF/IETF liaison coordinator. If it is at all possible, suggest to get the reply to this back by the middle of next week for their meeting the week after the next. They are trying to wrap up that document.

Daniele: Draft liaison already sent to the list; please review. I am doing some revision, will send my comments as well later. We can try to send out by middle of next week.

Dave: The document is essentially in their LC, better also take into account CCAMP comments.

<2> From ITU-T

Scott: ITU-T/IETF liaison coordinator. I wrote it and it is from SG15. ITU-T Study Group 15 focuses on ETHERNET, MPLS-TP, OTN kinds of transport, so Layer 2-ish. Historically, it likes to work on the protocol-neutral informational model using UML, not MIBs or YANG. This liaison points out that ITU-T is looking at creating protocol-specific models based on their UMLmodels. So, the way that is done is described in a couple of Internet drafts gone to the TEAS and NETMOD WGs, providing description of how UML written in the ITU is converted into YANG. We are trying to align the YANG being created and that are already in development. So there is a lot of discussions going on with lots of different people. We want to make everybody aware of this and not to be surprised since these has been going on for a while. There is not much detail in that particular liaison. It is just that there is all these work going on and we are also looking at some development of protocol-specific models, meaning NETCONF/YANG specific models. The other part of that one is more directed towards the IEEE, coz it is about modeling for Ethernet ring protection. So, there is work going in ITU-T Q9 on Ethernet ring protection. IEEE is working with ITU-T to ensure their work on bridge modeling is compatible with the models that have been done in the information modeling in G.8032. If you have any questions, drop me an email. I can address your questions.

Fatai: One comment: you just mentioned the Ethernet ring protection model, any other protection specific ones?

Scott: Good question. The Liaison is broken into two parts: (1)About ONF and ITU-T work on generic information modeling(G.7711), abstracted out of the technology-specific models; also a open model profile providing guidance on how to create such an information model; You will see that there is a model for MPLS,-TP, for OTN and for Ethernet. (2)About the new work IEEE is talking about, i.e., Ethernet ring protection;

Gert: Quick question. Let’s assume you have created this model and we can up with additional requirements for discovery or something. How would you assume those to be matched? Do they need to be matched or if our model is a super-set of your model is ok? What are the models between the models developed here and your models?

Scott: That is the reason why we are talking about this, coz if there seems to be overlap or things not aligning, let us know right away. If we see the same thing, then we can let you know so that we can create a work relationship. There is a large number of industrial groups that are working on various aspects of YANG data modeling. Some like to use YANG to work up and some like to use UML to work down. So, this is a way to get relationship, so that we do not duplicate the work.

>1 15:30 10 Title: GMPLS OSPF-TE Extensions in support of Flexible Grid

>Draft: https://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-ospf-ext-03

>Presenter: Haomian Zheng

Daniele: I am not going to ask for how many have read the draft since it has been a WG for a while. This document is the next one to go for WG LC after the RSVP-TE one. Before issuing WG LC, I would like to hear from the room, is there anyone still has concerns? [no one commenting] Ok, I see no one.

>2 15:40 7 Title: EthernetTraffic Parameters with Availability Information

>Draft: https://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-bandwidth-availability-03

>Presenter: Amy Ye

>3 15:47 7 Title: OSPFRouting Extension for Links with Variable Discrete Bandwidth

>Draft: https://tools.ietf.org/html/draft-ietf-ccamp-ospf-availability-extension-03

>Presenter: Amy Ye

Daniele: If this new version addresses all the comments from TEAS, I would like to hear from the chairman?

Lou: Apparently, I am supposed to say yes. But in reality I am not sure. Need to check the comment and then to confirm.

Daniele: We said a joint-WG LC. Administrative question: which WG should issue the LC?

Lou: CCAMP should, cc-ing TEAS WG. Fine to discuss in CCAMP or both. It’s your call.

Fatai: Only the routing draft needs joint WG LC, right? The other stays in CCAMP.

Lou: We agreed before and we do not reason to revisit.

>4 15:54 10 Title: Link Management Protocol Extensions for Grid Property Negotiation

>Draft: https://tools.ietf.org/html/draft-ietf-ccamp-grid-property-lmp-02

>Presenter: Qilei Wang

[remote presenting: deferred to the end but dropped due to poor voice quality in the end]

>5 16:04 10 Title: A Yang Data Model for WSON Optical Networks

>Draft: https://tools.ietf.org/html/draft-lee-ccamp-wson-yang-02

>Presenter: Young Lee

Giovanni: Quick question on the model. I have seen the Device type here, you adding in the draft as fixed or dynamic. Is that something this exists in the previous draft where you are taking the model to here? As far as I remember, everything in WSON drafts is reconfigurable. By adding constraint, you can also represent fixed model.

Young:I don’t think we changed the original model, this is based on a WSON RFC.

Giovanni:is it in existing draft?

Young:Yes. In WSON OSPF-TE encoding.

Giovanni:ok; I didn’t realize that and I am not sure.

Young:As you see here, all those node and link attributes we augment from generic model. We only specify what peculiar model is for Layer 0. At the moment, all of them are read and write. We will fix them as some of them are read only. We can then add laser, flexi-grid, even iv model later, if Giovanni develops a iv model. This draft is around for a while. WG adoption?

Daniele: You mentioned the possibility of merging with the contribution from Gabriele. Gabriele, any plan or preference?

Gabriele :No right now. We are open to work together or to cross check the two.

Sergio:When we started WSON work in IETF, the reference was OCh level that was defined at the moment. IN ITU, now the OCh is changing to media layer, signal layer. Do you think the draft made for flexi-grid YANG should be aligned with the new definitions or not?

Young:Yes; need alignment. Could you check the draft to see if it is consistent?

Sergio: Intention to merge?

Young: Not discussed fully, but it is within scope.

Daniele: How many people have read the draft? [Hands up in the room] Quite a lot of people. Of who read the draft, how many are in favor of adopting it as a starting point for a WG draft? [Hands up in the room] more or less the same. Thesupport seems to be reasonable. We will take it to the list.

>6 16:14 12 Title: A framework for Management and Control of DWDMoptical interface parameters

>Draft: https://tools.ietf.org/html/draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-01

>Presenter: Ruediger Kunze

Daniele: This document is pretty much in an early stage but the discussions around this have been non-agreeable and around for a while. Actually, the authors wrote this upon the suggestion of chairs and the AD, so we owe them at least a polling. How many people have read the document? [Hands up in the room] ok. How many think this could be a starting point for this topic, which is an old but anew topic? [Hands up in the room] Ok; more or less the same people. I think we can take this to the list.

Fatai: One comment. BBF is doing similar things and they have two models: separate and integrated. Do you think your draft should also capture both models to make the draft more complete?

Ruediger: Not necessary. We focus on a very narrow use case scenario.

Fatai:SO why BBF defines these (two) models?

Gert: The 2nd model of the BBF is not considering the colored interface which is defined here basically, still uses grey interfaces. BBF has two models, one is integrated one and described here and the other is the separate solution which is the state of the art with transponders in a ROADM. In the 2ndcase, the optical interface is not described because it is part of the ITU model. In the first model, we need to define it because interoperability aspect between a ROADM or a WDM system and a router or a device/transponders. I think it is decoupled. This is just one of them.

Julien: Kind of agree with Gert’s comment. I think if the use case does make sense per se alone, it doesn’t prevent everything from this use case by a solution which could be applicable to other models. But, this is to drive a set of requirements for a use case and a solution may be or may not be more generic. I do not mind to keep that in scope there for my point of view.

Dave: This is dealing with the management requirements for the thing Gert as mentioning as BBF part-A scenario. As Julien said it could be applicable to Part B but we need to see what’s in there. What might be agood idea is that, let them know, given that we are going to generate a response back to them on a similar topic, we let them that this work is possibly taking place, assuming that it gets.

Daniele: we can add this to the liaison.

>7 16:26 8 Title: An SNMP MIB extension to RFC3591 to manage optical interface parameters of "G.698.2 single channel" in DWDM applications

>Draft: https://tools.ietf.org/html/draft-galikunze-ccamp-dwdm-if-snmp-mib-00

>Presenter: Gabriele Galimberti

Julien: The proposal includes SNMP SETs. I guess you are aware that there is an IESG statement against (not prohibiting), but recommending to avoid SNMP MIBs for SETs and move to NETCONF/YANG.

Gabriele:Yes; in NETCONF/YANG, of course we have the SET but we are aware it is not a good policy to use. Maybe, we can add a comment here to say that this parameter can be set but it is not recommended to be used, if you like?

Julien: Partly yes.

Gabriele: We agree on your comment.

Julien: I think there is process that involves OPS area there when there is SNMP SET there. Maybe we can check that later.

Daniele:Actually, it may look a bit strange that inside a RFC, something is included but suggested not to be used. Do you consider also remove the SET from SNMP and move it in NETCONF/YANG for SET, maybe using SNMP as GET?

Gabriele: What we can do is to remove the set of parameters and refer to the YANG model for SET operation.

Daniele: That would be great.

Gert: Just a comment we should make clear that there will then be difference between the YANG model and SNMP model. So far, our goal was to keep them closely aligned. For us, it looks strange that we have two models which are supposed to do thesame but one does not coz of policy reasons. So, we must make it clear why there is the difference then.

>8 16:34 8 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-netmod-dwdm-if-yang-00

>Presenter: Dharini Hiremagalur

[Presenterchanged to Gert]

Yuji:I have read this YANG draft and I am struggling with the wavelength central frequency change and notifications message on the NETCONF. I am not sure where is it coming from? My question is why it is required for this message? Maybe this requirement needs to be clarified in another document.

Gert:For the requirement please look at the framework draft. If you still have doubt, we can discuss.

Yuji:Will go on with offline discussion.

Daniele:I did not understand. Is the requirement already addressed in the framework draft or you are suggesting to add it there?

Gert:if there is a requirement, we should put it in the framework.

Daniele:If there is requirement missing, please let us know in the mailing list and we can try to fix that.

Yuji:I am simply saying that I do not find any kind of requirement for frequency exchange and why notification should be defined. This is the major concern and maybe, it should be aligned with G.874.1.

>9 16:42 8 Title: Extension to the LMP for DWDM OLS to manage the application code of optical interface parameters in DWDM application

>Draft: draft-dharinigert-ccamp-DWDM-if-lmp-00

>Presenter: Gert Grammel

Xian:Because the last four presentations are related, my question might be related to the framework Ruediger presented. So my understanding of the framework draft that the requirements are that it needs collecting information as well as configuration some parameters. SO this draft is talking about using LMP for collecting information, so how is the configuration done?

Gert:One of use cases: ROADM is fixed and router has a tunable transponder. If they connect with a piece of fiber, which wavelength does the router need to be tuned because it sits on certain wavelength? So they can exchange the LMP information where the optical node basically can tell the router that the only wavelength it can tune is X. The other can tell the optical device that it is able to tune to whatever wavelength he wants. It also works the other way around. So if you have a ROADM with tunable spectrum but a router has a fixed transponder, they need to exchange to understand the only wavelength they can use is this one (X).But be careful, there is no configuration happening. But it is information thatwhatever you need to configure has certain limit, which is not constraints ofitself but given by the other end.

Xian:I understand. The requirement draft talks about two requirements. This solutionis addressing only the exchange of capability, which has nothing to do withconfiguration, right? It is not clear in the framework draft since it says that there are parallel solutions for the specified requirements which includes configuration. But you are now saying it is not.

Gert:They are addressing similar use cases. This is more kind of discovery and alignment draft, if you want coz it exchanges the set of parameters you can work with. Now, if you have a controller on top with YANG and everything, you can get everything via your YANG model. The controller then can figure out what is useful and what is not. In a sense, this is a distributed solution for the same problem as if you had done it centralized. It looks at the same problem at different angle.

Xian:Do you mean the two needs to be combined to form a complete solution?

Gert:No. They are independent, but they use the same information.

Xian:I mean do you need something else for the configuration?

Gert:Right, let’s say…(interrupted)

Xian:ok; I have more questions, but I will raise them in the mailing list.

Daniele:Actually we have some more time.

Gabriele:Just more clarification for Xian. Actually, there is some configuration. When we have applied the use case of to close loop to the ROADM and the client to set and adjust the power. This is using LMP. If you look at one of the use cases in the framework draft, there is a possibility from the ROADM to adjust the power into the transmitter and vice versa and share this information.

Xian:Now I am confused.

Loa:Me too. But Gert’s point is that you can use LMP to get the information but you cannot use LMP to configure.

Gert:There is one point which is about power. So, it is not configured anywhere in WSON and also in the ITU model for the colored link. So, the question is that it is a configuration or say a parameter that needs to be negotiated? Let’s say thereis a WDM system and the receiver measure powers, and tries to align with the transmitter. This is a kind of autonomous process, which is not related to configuration in a sense you are not really configuring a parameter.

Loa:It sounds like configuration to me. If it is not configuration, then you have a very bad language in the text and you need to go back and revisit that. You need to make that clear and LMP is not made for configuration. If you use LMP to get the parameters and you need to do some configuration, there is something else that is doing the configuration.

Gert:You are hitting on one of the points that also we want to discuss with others whether this is ephemeral or non-emphemeral data.

Lou:To Loa, is port mapping configuration, which is allowed to be negotiated in LMP?

Loa:Clearly, there is a borderline here. However fuzzy the real world is, you have to be clear in the text. It will need to be sorted out one way or another. I would say that the port mapping is in the fuzzy borderline between configuration and information gathering.

Daniele:Called negotiation?

Load:Sure; but doesn’t help. Here actually, we need something to actually tune the wavelength and that is configuration of the box that is actually tunable.

Gert:The LMP is not tuning the wavelength but it collecting restriction on the range of wavelength which somebody else can tune the wavelength. Somebody else fixes the wavelength, RSVP could do it or management. The only thing that the LMP tries to figure out is what’s the limit of wavelength and that should be clear ahead of time. Maybe it is only one. But the actual doing the configuration of the wavelength is out of scope of LMP.

Xian:Another question about the previous (first) solution which is using theNMS-based solution. The requirement is to configure the power as well aswavelength. I am not sure if I am using the right terminology, so it is actuallyEMS task to do this. Are you using an EMS, say a transport EMS, to be in chargeof configuring outside of its own administrative domain? Do you understand myquestion?

Daniele:Different EMS?

Xian:According to the framework draft, it is the same EMS that configures both.

Gert:I think I understand your question. If you look at the picture shown inRuediger’s presentation, we intend move this kind of which EMS is in charge ofwhat out coz for the work here what is of interest is what information northfrom the device, not how many boxes are on the top or which boxes are on thetop to configure the thing, which could be 1 or 10. What is important is the informationthat goes up and down? This is what we tried to keep aligned between the threedrafts and now the framework.

Daniele:We probably need an interface between two EMS?

Xian:Yes; that is what I am thinking about.

Gert:It is a solution but again I don’t think it is CCAMP solution.

Xian:I would suggest to something text to explain that.

Gert:Ok.

Xian:Last problem is the example/use case. I actually preferred to raise them in themailing list coz they are detailed comments. In the example taken from here tothe framework draft, you have to exchange the power information, can it bedirectly monitored?

Gert:The point for monitoring is to look for fiber break or dirty fiber. So, if youhave a sender set at certain power, and you have a receiver that gets somepower, so the receiver is on the other side. But if you want to supervise alink from a router to a ROADM, so you can supervise the power at the ROADMMside to see it matches the power level you had at the transmitter side. If then (you can figure out) there is a problem on that link, or it is a problem all the way down. It is an option. But it basically allows localizing a dirt fiber or the fault of an access link or not.

Xian:You mean it actually is to identify a link failure or transponder failure?

Gert:Yes. People have proprietary methods to monitor power. This is sort of more standard way. If you can get information at necessary points, you can do that kind of correlation and figure out the problems.

Xian:Got it and I am done.

(For remote presenting on LMP for flexi-grid.)

Daniele:We are trying to contact Qilei, but we have connectivity issues. Last IETF, we did polling to see the interest in this draft and the interest seemed going down. This draft has been around for a while, and the authors probably would like go for LC. In order to understand how to progress this draft, we would like to know whether there is implementation or such a willing to implement. Please comment on the mailing list or contact our chairs so that we can decide to whether to proceed it with experimental or standard track or whatever we think better. Please usethe mailing list or contact our chairs, so that we can decide how to proceed with this draft. Sessions closed.