> 83rd IETF -- CCAMP Agenda

> CCAMP Agenda

>††† for the

> 83rd IETF Meeting


> First Session

> Monday, March 26, 2012.

> 1300 - 1500 Afternoon Session I

> Room Name: Maillot


> Presentation†††† Start Time†††† Duration†††† Information

> 0†††††††††† 13:00†††10

> Title:††††† Administrivia & WG Status

> Draft:

> Presenter:†††† Chairs

> Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-0.pdf


Lou Berger: Status of WG drafts not on agenda?

OAM configuration documents (Attila Takacs): some update on SDH and OTN OAM configuration documents to add delay measurement support. MPLS-TP doc updated based on comments on the list, documents are stable and ready for last call.

Lou Berger: Have you closed the loop with the ones that made the comments?

Attila Takacs: Yes.

draft-ietf-ccamp-gmpls-general-constraints-ospf-te (Fatai Zhang):waiting for updates on related documents (WSON information model and encoding drafts). Continue monitoring them.

draft-ietf-ccamp-lmp-behavior-negotiation (Dan Li): Updated half year ago. We are waiting for comments and feedbacks on implementations. No issues raised so far.

Lou: is anyone willing to comment on their own implementation. [no one raised issues] If no one wants to speak publicly please write to the chairs or our AD. Please comment, if no implementations then perhaps no reason to progress it.


Deborah: Liaisons. We have sent one over to Q6 on flexible grid and we have a reply. Hopefully after this meeting we can send them back a response. We have an update on the OTNT standardization plan, they asked us to review and we should respond on that, so please review these.


> 1†††††††††† 13:10†††† 10

> Title:††††† Framework and Information model for GMPLS and PCE Control

of G.709 Optical Transport Networks

> Draft:


> Draft:


> Presenter:†††† Sergio Belotti

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-3.pdf


Lou Berger: Last IETF we discussed support for payload types other than 20/21. Do you think we need to include anything in these documents for non-payload type 20/21 clients?

Sergio Belotti: You need to take into account Type/TSG

Lou Berger: Do you think the Info and fwk document has sufficient info (payload type)?

Sergio Belotti: We think the document has sufficient information for 20/21

Lou Berger: What about other PT values from G.709?

Sergio Belotti: We think the info in these two docs is sufficient for multiplexing.


> 2†††††††††† 13:20†††† 10

> Title:††††† Traffic Engineering Extensions to OSPF for Generalized

MPLS (GMPLS) Control of Evolving G.709 OTN Networks

> Draft:


> Presenter:†††† Daniele Ceccarelli

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-4.pdf


Deborah Brungard: Do you have a resolution for the outstanding one? Do you want to include FAs?

Daniele Ceccarelli: We do not think we need additional extensions.

Deborah Brungard: What about type-2 type-3?

Daniele Ceccarelli: I think thereís agreement on moving from three to two TLVs, there are examples on how to advertise them and I think the issue is solved.

Deborah Brungard: We think we have a solution.

Lou Berger: Two questions: Do we need to advertise payload type for adaptation? Itís going to be vendor dependent, some of them are going to support multiple of them, some others are not. Do we need to address the client adaptation at the routing layer?

Daniele Ceccarelli For intra-OTN we have a solution, the combination of Payload Type and TSG is enough. For inter-switching capability multiplexing the adaptation advertisement is needed and we should address it in another document.

Lou Berger: Are you volunteering to author another document?

Daniele Ceccarelli: Yes

Deborah Brungard: Why not keeping things together?

Daniele Ceccarelli: This document is OTN specific and no more info is needed for intra switching capability advertisements. If you want to address also inter switching capability issues in MLN/MRN more extensions are needed but to the IACD rather than to the ISCD.

Lou Berger (Chair hat off): For using switching caps, issue is closed assuming we have consensus from the WG on handling of swcaps going forward. I have an individual draft on this that will be presented later, but is an individual draft at this point and may not represent WG consensus.


> 3†††††††††† 13:30†††† 10

> Title:††††† Generalized Multi-Protocol Label Switching (GMPLS)

Signaling Extensions for the evolving G.709 Optical Transport Networks Control

> Draft:


> Presenter:†††† Fatai Zhang

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-5.pdf


Lou Berger: Same question (payload type and adaptation object). This document is quite different because you have an adaptation object defined.

Fatai Zhang: this is only for intra-OTN hierarchy not client adaptation, client adaptation uses G-PID.

Lou Berger: if you have a generic field in which you can carry the information all the time (G-PID), why introduce an adaptation object in one case and using the generic field in the other? It doesnít seem to be consistent.

Fatai Zhang: it is consistent

Lou Berger: It seems there is a contradiction but maybe Iím just confused. Discussion will continue off-line and be summarized on the list. Also, in order to be ready for last call please make sure you have conformance language in sections where procedures are defined. Notably section 8. (Rest of document shows good improvement on usage of conformance language.)


> 4†††††††††† 13:40†††† 10

> Title:††††† RSVP-TE Extensions for Associated Bidirectional LSPs

> Draft:


> Presenter:†††† Fei Zhang

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-6.pdf


Kam Lam: You assume this is triggered by the NMS? What happens if the two ends belong to different domains and different NMSs are used?

Fei Zhang: Just an example, it could be triggered by CLI.


> 5†††††††††† 13:50†††† 5

> Title:††††† RSVP-TE Extensions for Associated Bidirectional LSPs and

Exchange of MPLS-TP LSP Identifiers

> Draft:


> Presenter:††† Fei Zhang

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-7.pdf


Lou Berger: (Slide 3) We heard in the prior talk about associated bidirectional LSP that have two association types, if you had the need to carry this ID why do you need both mechanisms?

Fei Zhang:This is different from the previous (bidirectional) solution as association object may carry different information.The prior types required identical.

Lou Berger: How many read this document? [two hands] This draft is derived from MPLS-TP discussions, and has requirements.

Lou Berger: How many think this TP requirement needs to be satisfied?

[More hands]

Lou Berger: We need to understand if people think this solution satisfies the requirement(s), will poll on the list to give people time to review the document.


> 6†††††††††† 13:55†††† 10

> Title:††††† RSVP-TE Extensions for Lock Instruct and Loopback in MPLS-TP

> Draft:


> Presenter:†††† Jie Dong

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-8.pdf



Lou Berger: As mentioned, these are also TP related functions. The functionality looks similar to the lockout function provided by RFC4872, have you checked to see if those mechanisms satisfy the requirements?

Jie Dong: I see protection lockout as different than lock instruct as it includes ability to send test traffic.

Lou Berger: I think that RFC4872 would provide a solution, together with the existing Admin status bits would be suitable. Consider reviewing existing solutions and highlight why they are not suitable.

Lou Berger: A second point, you also introduce a new way of providing information to an intermediate node (using notify) rather than use/extend an existing mechanism (ERO or SERO).

Jie Dong: We are reusing the call mechanisms.

Lou Berger: This is an end-to-end usage, please consider reuse and justify why shouldn't leverage one of the existing mechanisms.

Julien Meuric: What I would like to see is the motivation for this work, see RFC6435 already.

Lou Berger: Well, TP is a motivator but we try to avoid a technology specific solution and have something we can apply to other technologies, and this is applicable to other technologies, e.g. Lambda.

> 7†††††††††† 14:05†††† 10

> Title:††††† GMPLS-UNI BCP

> Draft:†††† http://tools.ietf.org/html/draft-beeram-ccamp-gmpls-uni-bcp-01

> Presenter:†††† Igor Bryskin/John Drake

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-9.pdf


Lyndon Ong: We received a number of questions internally regarding this document. It was not clear why this was GMPLS UNI, this was more multi-layer than GMPLS UNI

Igor Bryskin: This is not multi-layer, UNI and E-NNI is peering at the same layer, a question might be why is this UNI and not ENNI. The same companies that implement this UNI with routing have additional implementations that use just routing as described in this draft but not signaling. Why then is ENNI, UNI + routing.

Deborah Brungard: We have established there is a gray area of what is UNI, ENNI and peer-to-peer and various shades of gray. This document gathers a lot of information from the multi layer documents; if you really want to have a BCP then you need to refine the document and the aspects (multilayer, virtual TE link, et al.) you need to focus. Scope the document, if Lyndon and others cam help refine for GMPLS UNI.

Malcolm Betts: I share the concern of what is the intention of the document, especially as it is a BCP. I also have a lot of detailed comments on the draft.

Lou Berger: OK great, a few comments. Document status should be in the document status and not ID title. Also the term UNI does not include routing, it sounds like you're defining more of an ENNI and by using the ENNI term, you help fulfill a requirement that is on the WGs plate (from MPLS-TP).

Igor Bryskin: Question for Adrian, can we define new control plane entities? E.g. ENNI including UNI and E-NNI with routing and signaling and you can use either of them or both?

Lou Berger: May I answer as a chair, we will discuss any draft put forward and progress documents that have support of the WG, without it, we won't.

Deborah: We can define whatever we want, but as long as you mention e.g. G.8080 we must get alignment.

Eve Varma: A few comments, one issue the draft mixes concepts, if you scoping GMPLS UNI RFC4208, PCE is not in scope, routing info not in scope. You need to cite what are the commercial available instantiations of GMPLS UNI if you want to draft a BCP. The other thing I noted is that the addressing options provided at the edge nodes in 4208, were there were two options that may or may not come from the same addressing space while you are saying that they must come from the same one. Again if there are some modifications there needs to be a justification for them. Also there are new areas on SRLGs, again any modifications proposed must be discussed in context of (existing) drafts.

Igor Bryskin: In L1VPN, we recommend to use the same address space.

Eve Varma: Section 6 of your doc refers to RFC4208 indicating that the same address space is to be used.

Igor Bryskin: Please re-read the draft, we say there are two options and recommend to use one of them.

Eve Varma: Thatís exactly what I say, but agreeing that it is a best practice is another story.

Deborah: Scope the application.

Adrian: This is a good document that collects information and ideas. If you want to take this forward as an RFC, you must break it out into different things that you want to cover (new concepts, definitions, interoperability, BCP, et al.). If you reference normatively (e.g. G.8080) then this constrains you, if you want to define something new, you need to provide clarity and context. You must be clear whether your work impacts prior work or it is a new idea.


> 8†††††††††† 14:15†††† 10

> Title:††††† RSVP-TE Extensions for Collecting SRLG Information

> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-srlg-fa-configuration-05

> Presenter:†††† Oscar Gonzalez de Dios

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-11.pdf


Lou Berger: if you would like to move forward as a proposed standard, please make sure you use conformance language appropriately. Please look at Section 4.1 (Signaling Procedures) especially and refer back to RFC2119.

Lou Berger: How many read the draft? [a reasonable number], how many would like to move forward with the document - [a few more]. Will discuss on the list.


> 9†††††††††† 14:25†††† 10

> Title:††††† Revised Definition of The GMPLS Switching Capability and

Type Fields

> Draft:†††† http://tools.ietf.org/html/draft-berger-ccamp-swcaps-update-00

> Presenter:†††† Lou Berger

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-12.pdf


George Swallow: I support the main proposal and deprecating PSC-2-4 in particular, I thought it was a bad idea when it was introduced.

Lyndon Ong: I also support this idea, removing the ambiguity is a good idea.

Xian Zhang: Question on new Ethernet switch caps, why there are two of them instead of using the L2SC switch cap?

Lou Berger: These are really past decisions by the WG and examples where different values are used for different versions of switching of the same type. The reason was insuring no ambiguity between old and new implementations.

Xian Zhang: With respect to ILH, are you proposing modifying the OTN documents?

Lou Berger: There was an example discussed on the list, as I said on the list I'm not proposing any change to the G.709 docs as they are more mature, but just using OTN as an example. In that example I said copy the value from the stage 0 of the SCSI, and no modification to the SCSI. The draft doesn't specify specific mapping of ILH values for specific technologies, just says will be different for each sublayer/multiplexing level.

Xian Zhang: Does the ILH define a specific hierarchy for each technology?

Lou Berger: It indicates a different level of multiplexing but what that level is, is a technology specific answer.

Deborah: There are two parts to this draft.It looks like there's good support for the first part. We will need to look carefully if we need to separate out the second part. I suggest that you read the documents and comment on the list.


> 10†††††††††† 14:35†††† 10

> Title:††††† Requirements for Combined Protection and Restoration and

Revertive Recovery Requirements

> Draft:


>†††† http://tools.ietf.org/html/draft-roch-ccamp-full-reroute-reversion-00

> Presenter:†††† Lyndon Ong

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-13.pdf


Slide 2: 4873 should be 4872.

Gert Grammel: Anything (document-wise) that needs to be referenced from ITU?

Lyndon Ong: We will check.

Igor Bryskin: Good news, the functionality described is available. It is good to standardize. One good example is reversion done in a hitless manner, is good.

Lou Berger: General observations, anything not references in an RFC is allowed. Use case would be informational, an update to an existing document (RFC) would be an Errata.

Lyndon Ong: I expect that it is the latter


> 11†††††††††† 14:45†††† 10

> Title:††††† RSVP-TE extension for Routing Diversity using Exclude

Routes, recording TE Metric of LSPs, Include Routes and signaling Optimization Objective and metric bound

> Draft:†††† http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-01

>†††† http://tools.ietf.org/html/draft-ali-ccamp-te-metric-recording-01


> http://tools.ietf.org/html/draft-ali-ccamp-rsvp-te-include-route-01



> Presenter:†††† George Swallow

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-14.pdf



Lou Berger: (Slide x) Isnít the Objective Function an end to end construct rather than an hop by hop one?

George Swallow: Itís an end to end concept.

Igor Bryskin: Thank you for the examples, this is why we can use virtual link model, just to avoid all the things that youíve just explained.

George Swallow: I think there are different approaches here and they are not in conflict. We can keep this separate.

Igor Bryskin: I just hope that Lou doesnít ask us to merge.

Lou Berger: I see this work aligned with existing GMPLS UNI and as separate from yours, which is defining something more than the GMPLS UNI.

Gert Grammel: Is the SRLG a concept that is allowed in G.8080 to be passed by the UNI?

George Swallow: It is an issue of RFC4208, not G.8080.

Adrian Farrel (AD hat off): On the LSP exclusion, how would someone, processing an RSVP message that is not on the path of the LSP to be excluded, know the path of the LSP to be excluded?

George Swallow: Without getting into architecture detail, there is work on stateful PCE that the node can consult.

Lou Berger: Thanks for providing an update. We do not have time for further questions. Letís take further discussion to the list.


> 12†††††††††† 14:55†††† 10

> Title:††††† Expressing label set in ERO

> Draft:


> Presenter:†††† Cyril Margaria

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-15.pdf

Lou: No time for discussion, will poll interest on list

> Adjourn†††††††††† 15:05


Lou Berger: We run out of time, please send comments to the list.



>†††† Second Session

>†††† Wednesday, March 28, 2012.

>†††† 0900-1130 Morning Session I

>†††† Room Name: Maillot

> Presentation†††† Start Time†††† Duration†††† Information

> 0†††††††††† 9:00†††† 5

> Title:††††† Administrivia

> Draft:

> Presenter:†††† Chairs

> 13†††††††††† 9:05†††† 10

> Title:††††† General Constraints encode and RWA info

> Draft:


>†††† http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-14

> Presenter:†††† Young Lee

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-16.pdf


Lou Berger: There is some discussion on the list regarding these drafts.

Please remember that decisions taken via the list are as (or more) important than the WG sessions themselves as includes all interested WG participants.


> 14†††††††††† 9:15†††† 10

> Title:††††† Signaling Extensions for Wavelength Switched Optical Networks

> Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-03

> Presenter:†††† Giovanni Martinelli

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-17.pdf


Lou Berger: Are you planning on including additional mechanisms in this draft.

The current text is a little bit confusing on that.

Giovanni: No (plans to add additional mechanisms). We need to clarify the text.

Lou Berger: Are you planning to update the ABNF Giovanni Martinelli: two things make it consistent with info model and then update ABNF.

Lou Berger: Updating ABNF for consistency is good (as currently have some inconsistencies).

Cyril Margaria: You mention two ways of encoding parameters, is there a preferred solution, if so when will it will be resolved?

Giovanni Martinelli: No strong direction one way or another. I have a preference, but itís not so strong.

Lou Berger: As discussed in session 1, there are multiple drafts that need the same function. It's clear we need a non-technology specific solution.ERO and SERO are the current ways to provide information to specific nodes.

Giovanni Martinelli: I think there is also another draft from the OAM talking about the same topic.

Lou Berger: This is a common problem; do we have someone willing to work on this independent of technologies? Cyril?

Cyril Margaria: Sure.


> 15†††††††††† 9:25†††† 10

> Title:††††† WSON interface class and WSON signaling

> Draft:


> Presenter:†††† Giovanni Martinelli

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-18.pdf


Young Lee: When I saw this draft I thought there was a lot of confusion. We already have encoding for different drafts and it is future proof, this draft is very confusing to me on what problem it is solving, moreover it has to deal with impairments rather than impairment-free WSON.

Giovanni Martinelli: Two points. First, regarding interface class fiber type, the draft does not define semantics. These will be defined elsewhere.

Giovanni Martinelli: We are not being explicit, these will be referenced elsewhere. You can carry proprietary information (modulation format).

Malcolm Betts: The ability to encode standard interface information (standard interface class) is very useful.

Lou Berger: What you want to happen is to influence WSON documents. Is this correct?

Giovanni Martinelli: Yes

Lou Berger: You should have a look at existing docs and propose specific changes you're proposing to these documents individually on the WG list.

Giovanni Martinelli:we have the appendix already, but we can take this to the mailing list as well.

Young Lee:One point, if you refer to ITU documents you need to be specific as to the identifiers. Fiber Type is not currently in scope of the base WSON documents. To me this is out of scope as Fiber Type definitely belongs to WSON impairments.

Giovanni Martinelli: I want to avoid discussing the internals of the interface class.

Malcolm Betts: The ITU has defined a set of parameters that make the WDM networks interwork. If you take those parameters separately it can be risky, while having all of them into an interface class is for sure more powerful.

Lou Berger: Looking forward to seeing the follow-up (proposals) on the list.


> 16†††††††††† 9:35†††† 8

> Title:†††††† A framework for Management and Control of G.698.2 optical

interface parameters

> Draft:


> Presenter:†††† Ruediger Kunze

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-19.pdf


Malcolm Betts: This doc is addressing a very important area but I have a major concern. There is confusion on what is internal to the black link and what is external. A further problem (an ITU-T problem) in Q6 they talk about SNR reference point, when you talk about G.698.2 you talk about that. It is not clear what interface we are talking about. I can help clarify these points.

Eve Varma: I have some similar comments. Malcolm and I sat in the same meetings, Q.12, how you model black link. The discussion re: inside/outside comes up. When you have application codes, supported at certain wavelengths, when you talk about support you treat the black link as media, itís a fixed entity. This confuses how you set something up (as an operator) as a black link. You need to consider how and what you setup, including application codes. Then the questions will not arise like how to use GMPLS UNI, say with black link.

Ruediger Kunze: (Secretary Missed Response)

Malcolm Betts: maybe we need more work to better define the interface. What is strictly in a black link now, we have a G709 OMS (multi-wavelength), by selecting the transmitter I can determine where to exit the black link. I hope you not trying to configure the internals of a black link Deborah Brungard: It is a good discussion I suggest to continue it on with Malcolm and Eve on the list. I see there are still inconsistencies with ITU language and Recommendations and still need refining.


> 17†††††††††† 9:43†††† 7

> Title:††††† A SNMP MIB to manage black-link opticalinterface

parameters of DWDM applications

> Draft:


> Presenter:†††† Gabriele Galimberti

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-20.pdf


Malcolm Betts: same comment, it would be useful to encode ITU interface types, it would be for consistency for compatible interfaces. As up to now all of them are treated separately. The other comments I would like to make is there is much about how you structure the MIB rather than what parameters are needed. This is not a simple extension of the MIB. We would also like to synch information elements. So we have protocol independent MIB that can be used for both (SNMP/LMP).

Gabriele Galimberti: Yes this is something we need to address.

Eve Varma: I have some sympathy in looking at protocol independent extensions, a homogeneous semantics also with different encodings being used. IEEE has not defined yet what the next bit rates are, when IEEE decides the bit rate and ITU accepts it we can go on the work.

Gabriele Galimberti:Yes, this is the next step and we will react accordingly.

Manuel Paul: On the protocol agnostic definition, the priority was extending LMP, it's just a matter of prioritization.

Deborah Brungard: The original version is not really related. It is important to look at the issue of what is in and outside the black link.

If you are within the black link (WSON for instance) it is not relevant.

Lou Berger: A few comments: make sure the work is not too far ahead of dataplane definitions; when looking at generalizing function, please look at more generic MIB definitions too; finally, we need to coordinate with OPSWG on where the MIB work would be done.


> 18†††††††††† 9:50†††† 9

> Title:††††† Framework for GMPLS and PCE Control of Spectrum Switched

Optical Networks

> Draft:†††† http://tools.ietf.org/html/draft-zhang-ccamp-sson-framework-00

> Presenter:†††† Fatai Zhang/Ramon Casellas

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-21.pdf


Lou Berger: We have ten minutes scheduled at the end of the draft presentations to discuss. One question is, is this work a different switching technology or another aspect of WSON. We do not want to answer this now, consider it for the time we allocated for discussion.

Igor Bryskin: Are you going to consider non-contiguous aspect. Is it worth considering non-contiguous (2-4-6-8)? In theory it would be provide flexibility. I think itís a question for the WG. So should this be a requirement (contiguous versus non-contiguous)?

Malcolm Betts: I think we should be focusing on the single contiguous slot. How a signal is used over a media path is independent on the media path. If you choose to use multiple carriers for a signal it is independent on the media path. We should just consider the media path.

Lou Berger: As is the case, we do not define data plane, we follow ITU in the case of the WSON data plane. If the WSON data plane allows it, then we should allow control of it, if it doesn't we shouldn't define CP support.


> 19†††††††††† 9:59†††† 9

> Title:††††† Framework for GMPLS Control of Flexible Grid Network

> Draft:


> Presenter:†††† Qilei Wang

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-22.pdf

[No time left in slot, discussion will continue in the general discussion agenda slot]

> 20†††††††††† 10:08†††† 9

> Title:††††† A Framework for control of Flex Grid Networks

> Draft:


> Presenter:†††† Rajan Rao

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-23.pdf


Deborah Brungard: We do not need multiple framework documents. We encourage authors to work together. Please align with ITU-T language.

Lou Berger: These comments are applicable to all three (framework) documents.

Eve Varma: It would be good to stay in line what is defined in ITU, it seems the super channel is a sort of inverse muxing of spectrum portions and it is not aligned with actual ITU-T work.

Malcolm Bets: I echo Eveís concern, Re: fixed slot (Q.6/Q.12) neither has looked at virtual concatenation, we (CCAMP) should steer clear until its better defined.


> 21†††††††††† 10:17†††† 10

> Title:††††† Requirements for Guard Bards in Spectrum Switched Optical

Networks and GMPLS OSPF-TE Extensions in support of Flexible Grid in DWDM Networks

> Draft:



> Presenter:†††† Daniele Ceccarelli

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-24.pdf


Malcolm Betts: I think it is very important to consider Guard Bands, although I think it will take time to get feedback from Q6. If we take a step back and say we are trying to setup pre-qualified paths, with modulation a, to modulation b, I think it is useful to have encoding for the optical path (say 100ghz) which is the Guard Band.

Daniele Ceccarelli: Do you want explicit?

Malcolm Betts: I am favor of an explicit guard band.


> 22†††††††††† 10:27†††† 10

> Title:††††† OSPF Extensions for Routing Constraint Encoding in

Flexible-Grid Networks and OSPF extensions for support wavelength range allocation in flexible grid supported network

> Draft:




> Presenter:†††† Qilei Wang

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-25.pdf


Igor Bryskin: Slide 3 is missing you have to take into account switch asymmetry and that a channel could be co-routed. Optical switches may be asymmetrical and co-routed. From the optical impairments point of view they should have equal conditions.

Xian Zhang: How do you insure the consistency of label usage in signaling and routing?

Lou Berger: Remember that we're still early in the process and still have multiple approaches, once we have WG documents we will need to ensure a consistent approach.

Deborah: In the interest of time, let's move these questions to the list.


> 23†††††††††† 10:37†††† 8

> Title:††††† OSPF-TE extension to support GMPLS for Flex Grid

> Draft:




> Presenter:†††† Rajan Rao/Iftekhar Hussain

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-26.pdf


[No Questions]


> 24†††††††††† 10:45†††† 7

> Title:††††† Super-Channel Assignment on Flexible Grid Label and Signaling

> Draft:




> Presenter:†††† Iftekhar Hussain

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-27.pdf


Lou Berger: It would be useful to hear from the ITU re: Super Channel status? This would help guide us.

Unknown Speaker: Why not reuse VCAT mechanisms rather than defining something new

Lou Berger: This is where understanding how the ITU-T is modeling the data plane could help us determine how to define control.†† If there is a specific solution for the data plane, we will need to follow it, if not then we can debate here.


> 25†††††††††† 10:52†††† 8

> Title:††††† RSVP-TE Signaling Extensions in support of Flexible Grid

> Draft:


> Presenter:†††† Fatai Zhang

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-28.pdf

Rajan Rao: on the m parameter, in the future when we'll have optical conversion it could be useful to have them in the label.

Fatai Zhang: You think M should be indicated as traffic parameter and carried in the label??

Rajan Rao: No.


Lou Berger: keep in mind there is also the AD SPEC that changes hop by hop

> 26†††††††††† 11:00†††† 10

> Title:††††† LMP extensions for link grid property correlation

> Draft:†††† http://tools.ietf.org/html/draft-li-ccamp-grid-property-lmp-01

> Presenter:†††† Fei Zhang

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-29.pdf

[No Questions]


> 27†††††††††† 11:10†††† 10

> Title:††††† Discussion & next steps on Flexible Grid


Lou Berger: Is this an extension to WSON, or a new method of switching?

There are different positions, some drafts say it is an extension of WSON, other define it as a different switching capability, others make a sort of combination calling it SSON. Keep in mind we need to start bringing documents together, there are too many of them. We're not going to bring all these documents to WG.

Igor Bryskin: To answer your question, no to all your suggestions. It would be useful to introduce generic channel, it may not be bound to existing data plane. A use case would be flexi grid, but there other scenarios.

Lou Berger: This would be separate from existing WSON work.

Igor Bryskin: Yes. A second comment on Guard Bands, why do we need to have explicit Guard Bands and not simply allocate a wider chunk of spectrum? A PCE-P extension asking for considering a wider chunk of spectrum should be enough without anything to signal.

Daniele Ceccarelli: If Band Guards are implicit there is a risk to allocate them twice instead of being able to share them between adjacent channels.

Malcolm Betts: Let me start with disagreeing with everything Igor mentioned. So going back to your (Lou) question, on one hand its WSON, with tweaking its not. We need more investigation to understand if we need an extension to WSON and my current feeling is it should be based on an extension (to WSON).

Lou Berger: One way to think about it: can we carry the new/needed information in the existing messages? If so it is the same technology. The other thing to keep in mind is that a link can be carrying fixed grid and flexi grid applications at the same time. Would it be a hybrid node or same switching technology?

Malcolm Betts: agree. Talking about guard bands, many presentations (this in particular) deal with impairments, it would be necessary to speed up the definition of extensions for impairments so to provide a PCE running a proprietary algorithm with the parameters needed for GB computation. Another reason for keeping them explicit is that if you go and perform the computation of how big it is going to be you get the answer ďit dependsĒ and depending on which company you ask the reply is a long list of parameters, so I think explicit guard bands are the correct way to address them but I donít foresee in the immediate future a common way of computing them.

Pierre Peloso: Answering the question whether flexi grid is WSON or not, my answer is WSON is a subset of flexi grid.

Eve Varma: A general comment that echoed the one made by Adrian Farrel. I just get the sense that we should walk before we run. Starting with the label and the moving to signaling, routing and so on is reasonable. We need to be careful not to jump ahead with architecture/extensions that assumed and not actually agreed. In the interest of focusing effort and maximizing impact, it would be better to have smaller number of focused set of drafts.

Ramon Casellas: in order to make docs converge we need to solve the issue: is flexi grid an extension of WSON, the label structure and also if contiguous and non contiguous spectrum portions must be managed or not. On the switching capability I would stay with LSC also for flexigrid. A question that is not clear to me is: do we need to reuse what has been done for WSON? Is this work backward compatible?

Igor Bryskin: Re: WSON/Flexi grid. There are control planes in the WDM layer that are not WSON based. I do not care much about WSON but I do care about flexigrid so I do care that the work is independent. Another comment consist on the fact that multi-channel is a very powerful concept in my opinion.

Lou Berger: So far we have heard there is a lot of interest, some think we need to be high level, others suggest we need detail to support the high-level.

Fatai Zhang: Iím not sure whether we need a new switching capability or not, but a new switching capability does not mean that flexi grid is totally different from WSON, for example in the case of OTN, OTNv3 and

OTNv1 have different switching capabilities but are not different things.†††

Yu Wang??? - I am concerned about the range of the flexi grid topic. It covers single and multi carrier technology, our focus is on single carrier and the ITU has not provided a detail description of multi carrier technology. My feeling is we should cover both single and multi carrier not to throw away what we do in the single carrier technology once we will be dealing with the multicarrier one.

Oscar Gonzalez de Dios: You mentioned the possibility of combining WSON and SSON. Letís say the carriers are investing in WSON, then the only way forward is definethe SSON as an evolution of WSON and allow the coexistence of fixed and flexi channels, maybe this needs to be takes into account in ITU first. Both in the case of WSON and SSON what is switched is a portion of the spectrum, I donít care what is inside, so SSON should be evolutionary.

George Swallow: This technology is being developed rapidly and there is a lot of proprietary stuff going on. It would be difficult to do anything more than a general attack. The question is can we reuse existing objects (or not)? The answer is "of course".

Malcolm Bets: two quick comments: when we talk about WSON and SSON we talk about managing frequency slots, we donít care whatís going over that slots. We should keep the multicarrier issue off the table.

Lou Berger: It would be great to have the requirements and framework documents authors work together to see what they agree and donít agree on and come with a single document including agreements and non agreements.


> 28†††††††††† 11:20†††† 10

> Title:††††† Discussion & next steps on Charter

> Draft:

> Presenter:

Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-30.pdf

Chairs: Out of time but an important topic, will take discussion to list.

> Adjourn†††††††††† 11:30



Lou Berger: Just introducing the problem and continuing on the list. The main point is that some goals and milestones need an update but there is no need to re-charter. Weíre not closing the WG in November 2012 and we donít know when it will happen. There is a lot to do and there are a bunch items we have identified in the past that we should work on, some of them derived from the ĖTP requirements, the flexi grid discussion, and some other areas. If you have a candidate work area that is not in the listed slides, post it on the list.