CCAMP Minutes For IETF 92

MONDAY, March 23, 2015

1520-1650 - Monday Afternoon Session II

Room: Oak

Presentation      Start Time           Duration              Information       

0                             15:20                     10                          

Title:      Administrivia - WG Status - New charter and WG scope

Presenter:          Chairs

0                             15:30     5              Title:      Reporting on WG drafts not being presented

- Draft-ietf-ccamp-ospf-availability-extensions-01 and draft-ccamp-rsvp-te-bandwdith-availability-01:

Amy Ye: Drafts adopted in August and just some editorial changes since then. There are discussions ongoing regarding the general applicability of the drafts.

-draft-ietf-ccamp-additional-sygnal-type-g709v3 and draft-ietf-ccamp-otn-signal-type-subregistry

Matt Hartley: Some changes since Honolulu based on the comments from Lou Berger and Adrian. There was the thought of extending the OTN subregistry and do a similar job on all the IANA registries in the scope of CCAMP but it has not been done yet. No outstanding issue on the drafts.

1                             15:35     5             

Title:      Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks

Draft:    draft-ietf-ccamp-flexi-grid-fwk

Presenter:          Oscar Gonzalez de Dios

Daniele Ceccarelli: As said before, there is IPR polling for this draft. Please reply to the IPR polling. Secondly, since both the chairs and Oscar are involved in this draft, Lou Berger will call for WG consensus.(Thanks for that). If you have comments, please don't wait until the LC. Any time is good to say anything.

2                             15:40     10          

Title:      Flexi-grid protocols extensions - update and latest discussion report

Draft:    draft-ietf-ccamp-flexible-grid-ospf-ext, draft-ietf-ccamp-flexible-grid-rsvp-te-ext, draft-ietf-ccamp-flexigrid-lambda-label

Presenter:          Haomian Zheng

Lou Berger: Is there any reason for this extension to be technology specific? Option 1, you are talking about using a generic mechanism to start and seem it is a reasonable discussion, at least many people think it is useful. The reason is we did generic before, why do tech specific here? I don't have strong opinion, but worth asking this question.

Daniele Ceccarelli: the first thing that comes to my mind is the differentiation between bandwidth and portion of spectrum. Thinking of this, I would tend to say it is tech specific.

Lou Berger: This is a valuable point, and I also said that on the list.    We had the same issue with OO switch and we have mems and mems switch a portion of spectrum. We still at that time going to use bit per second as coded by IEEE format, and we had done that before on g.709 drafts. We really did that before in generic way. So, It really does not make sense to do something tech specific when we could do generic and we don't need to worry about next time. So think about it.

Rajan Rao: One of the parameters that impacts the Max LSP bandwidth bit per second conversion is the modulation format, this was discussed on the mailing list. Everybody thinks that it is related to other format, so people prefer to go for technology specific. We can look at redefining Max LSP bandwidth as number of the slots.

Fatai: Everyone agrees to introduce Max LSP Bandwidth but how to encode is not decided.

3                             15:50     5             

Title:      Link Management Protocol Extensions for Grid Property Negotiation

Draft:    draft-ietf-ccamp-grid-property-lmp

Presenter:          Xihua Fu

Daniele Ceccarelli: How many people think that this draft is ready for LC? Not so many. How many think it is not ready and any issues to be fixed? No open issues and take to the list.

Sergio Belotti: I have concerns about the topic defined by the draft. This draft proposes to exchange the capability of flexible and fixed grid. Since I suppose you don't have lots of them, you have one or the other and you could probably configure before and there is no meaning to exchange the information.

Fatai Zhang: So you mean that we could manual configure that, which is easier than the exchange by the protocol?

Sergio Belotti: Yes, I have doubts on the applicability.

Xihua Fu: In GMPLS many things can be manual configured by the management plane and there is no conflict between the manual configuration and LMP communication.

Fatai Zhang: It depends. For the dynamic info, we usually like to use control plane to do that, for the static info, people may prefer to configure that.

4                             15:55     10          

Title:      Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation

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

Presenter:          Giovanni Martinelli

Daniele Ceccarelli: Please start drafting a text for the liaison, send it to the list for review/contribution.

5                             16:05     10           Title:      Information Encoding for WSON with Impairments Validation

Draft:    draft-martinelli-ccamp-wson-iv-encode-05

Presenter:          Giovanni Martinelli

Daniele Ceccarelli: Liaisons does not necessarily need to be tight to a WG draft. If you think it is easier/more convenient to have a single liaison covering both this draft and the wson-iv-info one, please go ahead. Regarding the experimental path I don’t have a strong opinion yet and would like to poll the WG. We had a similar discussion for the WSON impairment free.

Lou Berger: Correct. If people are not sure to ship products based on a draft or there’s just one vendor, experimental is a nice way to go. Unfortunately experimental does not mean what it used to: the IESG decided to put a time limit on experimental drafts and this is moving away from them. My personal opinion is that this is a bad idea. If we had the WSON drafts as experimental they would have been available much earlier.

6                             16:15     10          

Title:      A Yang Data Model for WSON Optical Networks

Draft:    draft-lee-ccamp-wson-yang

Presenter:          Young Lee

Daniele Ceccarelli: I think here there is some work that could be considered technology agnostic and some that is technology specific, e.g. connectivity matrix.

Young Lee: here we are considering technology specific constraints. What defined in the upper layers is not applicable here.

Lou Berger: comment on the description of the first 2 bullets, they point at an old draft. Since then there has been a lot of work on generic TE models (will be presented later this week in TEAS). I think the right way to go is to augment those models.

Young Lee: When you say generic model, what is generic is the label, but here we are speaking about WSON devices and the label concept is contextual and we need to keep the label as a lambda label. When we do info model we can generalize it, but here we are talking about WSON in particular.

Igor Bryskin: What you describe is a generic TE model but it is specific to a WDM layer, this is what we have in mind by augmenting the models we’re developing with link and node attributes. The connectivity matrix you describe applies also to OTN. I recommend you to look into the existing model.

Young Lee: we don’t want to augment more than necessary components. We’ll look for augmentation as much as possible, when possible.

Gabriele Galimberti: This is a good start. Do you plan to define also the amplifiers and so on?

Young Lee: It will be the next step.

Gabriele Galimberti: You said you want to augment existing models, for the interfaces I would suggest to consider G.7223 which is a good starting point for DWDM interfaces.

7                             16:25     9              Title:      Extension to the LMP for DWDM Optical Line Systems to manage the application code of optical interface parameters

Draft:    draft-dharinigert-ccamp-g-698-2-lmp-09

Presenter:          Gert Grammel           

Haomian Zheng: Is the power monitoring related to the frequency or is the same for all frequencies?

Gert Grammel: It’s not related to the wavelength, but since a black link is a wavelength, we could say that the power monitoring is related to such wavelength.

Haomian Zheng: I’m asking because if we make it mandatory it is going to be very expensive, mostly for higher rate interfaces.

Gert Grammel: Agree, that’s why it is not a mandatory feature. In addition to that not all the equipments would be able to monitor the power. Anyway this is about protocols; we don’t specify how the power is monitored but how the info is carried.

Daniele Ceccarelli: When you say that LMP is used nor for signaling or for routing, you mean that you’re not dealing with routed paths, in the sense that they are fixed paths?

Gert Grammel: A link is black when it is lighted up, in the sense that once you’ve lighted it up you have a number of parameters that characterized it, not before.  In addition to that we’re not asking to setup a wavelength, what we do is informing the guy that is setting up a wavelength what are the options; so the answer to your question is yes.

Fatai Zhang: (comment on slide 6): You are saying that you have one end of the link that supports application codes A and the other supporting application codes A, B and C and you’re exchanging this kind of capabilities, right? This is a quite static information, wouldn’t it be enough to configure the transponder to work with application code A?

Gert Grammel: It is not either discovered or configured. This is an additional option.

8                             16:34     8             

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

Draft:    draft-galikunze-ccamp-g-698-2-snmp-mib-09

Presenter:          Ruediger Kunze

Daniele Ceccarelli: Reading the minutes of the last meeting I see that there was the proposal to remove the power as a parameter. I see the power is still there, is there any particular reason not for removing it? Are you planning to put it into the vendor specific parameters or whatever?

Ruediger Kunze: In DT we have different departments for the provisioning in the different layers. In order to give the optical guys the opportunity to configure the optical interfaces in an easy way we decided to allow to set the power here. Now we have a YANG draft for configuration, so no need to keep the power config in SNMP. For DT is ok to remove the power setting from SNMP but not the info getting.

9                             16:42     8              Title:      A YANG model to manage the optical interface parameters of "G.698.2 single channel" in DWDM applications

Draft:    draft-dharini-netmod-g-698-2-yang-02

Presenter:          Gabriele Galimberti Galimberti

Xian Zhang: The 3 drafts are dealing with the same parameters, are they completing each other or competing with each other? At least the MIB and YANG ones seem to be competing.

Gabriele Galimberti: It’s just  a matter of time. At the time being SNMP is the most used protocol. Once YANG will take place, probably the SNMP MIB draft could be “frozen”.

Xian Zhang: Application codes should be standard parameters, only get from the network, not configured.

Gabriele Galimberti: Correct. The application codes are get only. What can be configured are parameters like power and frequency.

Adjourn                              16:50