CCAMP IETF 86
Mar 13 & 15, 2013

0 - Administrivia & WG Status
1 - G.709 Optical Transport Networks (OTN) Update
2 - LSP Attribute in ERO
3 - RSVP-TE Extensions for Collecting SRLG Information
4 - RSVP-TE extension for recording TE Metric of a LSP
5 - RSVP-TE LSP Route Diversity using Exclude Routes
6 - Problem Statement and Architecture for Information Exchange Between Interconnected TE networks
7 - Overlay Networks - Path Computation Approaches
8 - Applicability of Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI)
9 - UNI extensions for diversity and latency support
10 - Multi layer implications in GMPLS controlled networks
11 - Include Routes - Extension to RSVP-TE
12 - Extended Encoding Scheme for Shared List Link Group (SRLG)
13 - Mutually Exclusive Link Group
14 - GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
15 - RSVP-TE Recovery Extension for data plane initiated reversion, protection timer and SNC options signalling
16 - Extensions to Resource Reservation Protocol For Fast Reroute of Bidirectional Co-routed Traffic Engineering LSPs
17 - RSVP-TE Extension for Label Switched Path (LSP) Inquiry
18 - Routing Extensions for Discovery of Role-based MPLS Label Switching Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership
19 - RSVP-TE Signaling Extension for Bandwidth availability
20 - CCAMP update/overview for Q6
21 - Signaling Extensions for Wavelength Switched Optical
22 - WSON Status Overview & WSON Signal Compatibility OSPF
23 - WSON Impairment Info
24 - WSON Impairment Encoding
25 - Information Model for Wavelength Switched Optical Networks (WSON) with Optical Impairments Validation.
26 - Encoding for WSON Information Model with Impairments Validation.
27 - An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications
28 - Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for DWDM Optical Line Systems to manage black-link optical interface parameters of DWDM application
29 - Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks
30 - OSPF extensions for support spectrum sub-band allocation
30A - Generalized Label for Super-Channel Assignment on Flexible Grid
31 - Q6 Update for CCAMP
32 - Discussion Topics

First Session
WEDNESDAY, March 13, 2013
900 - 1130 Morning Session I
Room: Caribbean 4

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Administrivia & WG Status†††††††††††††
0††††††††††††††††††††††††††††† 9:00††††††††††††††††††††††† 10†††††††††††††††††††††††††† Presenter: Chairs††††††††††††

[No comments]

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: G.709 Optical Transport Networks (OTN) Update
1                ††††††††††††† 9:10†††††††††††††††††††††† 10†††††††††††††††††††††††††† Presenter: Daniele Ceccarelli

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-12
http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-06
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-05
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-07

Lou Berger: with regards to future proofing, we have resisted including values and fields that do not have clear requirements and intention.
Deborah Brungard: the ITU data plane discussions with ITU experts have been off [CCAMP] list. This field is not aligned with the dataplane.
Lou Berger: [to WG] is it important to keep tolerance field? [No raised hands]
Fatai Zhang: Zafar Ali and John Drake have responded on the list that they support this [tolerance field].
Lou Berger: they are both in the room, would you like to comment?
Zafar Ali: keeping the [tolerance] field would be nice, this could a fixed value for implementations to allow interoperability. 
Lou Berger: so you are supporting that this should be kept? 
Deborah Brungard: please remember that this is only for ODUflex, we are currently in step with the ITU as this is a new defined signal type.
Zafar Ali: this is the specification for OTN, so we can discuss this offline. 
Lou Berger: this is a good time to discuss. We should avoiding modifying this issue in the future. ODUflex will impact code as the object type also needs to be changed [not just this field].

Rajan Rao: [Separate comment on slide 3]
Lou Berger:  Please send your question to the list.

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: LSP Attribute in ERO
2††††††††††††††††††††††††††††† 9:20††††††††††††††††††††††† 8††††††††††††††††††††††††††††† Presenter: Cyril Margaria

http://tools.ietf.org/html/draft-ietf-ccamp-lsp-attribute-ro-01

Adrian Farrel: I have two concerns. The first issue, this document seems to be reinventing a new mechanism, despite all the references. Please give a new example of an attribute that needs to be targeted. The second issue, which is a semantic problem, what you are doing here is hop attribute for a specific hop?
Cyril Margaria: should we redefine the semantics?
Adrian Farrel: yes.
Lou Berger: why do you think there is no need to put it into the RRO?
Adrian Farrel: the RRO reports what the nodes have done regarding the LSP attribute.
Lou Berger: it seems it is worth noting Adrianís comment regarding expanded usage in the I-D.

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: RSVP-TE Extensions for Collecting SRLG Information
3††††††††††††††††††††††††††††† 9:28††††††††††††††††††††††† 7††††††††††††††††††††††††††††† Presenter: Oscar Gonzalez de Dios

http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect-02

Lou Berger: the partial SRLG-list flags needs to be separated into an individual draft if it is a generic function. If it is not a generic function, then its inclusion needs to be justified. 
Oscar Gonzalez de Dios: it is generic, what's the procedure for documenting it.
Lou Berger: just write it up and then publish as an individual draft

 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: RSVP-TE extension for recording TE Metric of a LSP
4                 †††††††††††† 9:35††††††††††††††††††††††† 5††††††††††††††††††††††††††††† Presenter: George Swallow

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

[No comments]

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: RSVP-TE LSP Route Diversity using Exclude Routes
5                 †††††††††††† 9:40††††††††††††††††††††††† 7††††††††††††††††††††††††††††† Presenter: George Swallow

Lou Berger: [poll] how many people read the draft? [A few.]
George Swallow: please review the draft. 
Lou Berger: we appreciate the clean-up effort, can you also apply some effort to attribute flags and exclusions processing, specifically the combinations, type definition, and processing. You may find in documenting the details that there are some unneeded flags.

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Problem Statement & Architecture for Information
6††††††††††††††††††††††††††††† 9:47††††††††††††††††††††††† 10†††††††††††††††††††††††††† Exchange Between Interconnected TE Networks
††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††† Presenter: Daniele Ceccarelli

http://tools.ietf.org/html/draft-farrel-interconnected-te-info-exchange-00

Gert Gemmel: regarding the scenario with multiple client and server links, are the interfaces a choice? 
Daniele Ceccarelli: having multiple links between client and server domains is intentional in order to show all the different levels of complexity that we can have in overlay interconnection of multiple domains.
Lou Berger: [to the queue at the mic] we are out of time on this topic, Igor and Dimitri please send your comments to the list. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Overlay Networks - Path Computation Approaches
7††††††††††††††††††††††††††††† 9:57††††††††††††††††††††††† 10†††††††††††††††††††††††††† Presenter: Snigdho Bardalai

http://tools.ietf.org/html/draft-bardalai-ccamp-overlay-path-comp-00

[No comments]

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Applicability of GMPLS Label Switching UNI
8††††††††††††††††††††††††††††† 10:07†††††††††††††††††††† 10†††††††††††††††††††††††††† Applicability of Generalized Multiprotocol Label Switching
††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††† Presenter: Xian Zhang

http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-uni-app-03

Lou Berger: [request by presenter for WG adoption] we have a number of drafts in this area, please discuss the work together. Until then I think it is premature for adoption. 
Deborah Brungard: Nice presentation. For the Q6 discussion on Friday, please make sure presentations are clear, state assumptions and key issues. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: UNI extensions for diversity and latency support
9††††††††††††††††††††††††††††† 10:17†††††††††††††††††††† 5††††††††††††††††††††††††††††† Presenter: Dieter Beller

http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-01
Presenter:        Dieter Beller

[No questions]
Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Multi-layer implications in GMPLS controlled networks
10†††††††††††††††††††††††††† 10:22†††††††††††††††††††† 10†††††††††††††††††††††††††† Presenter: Dimitri Papadimitriou

http://tools.ietf.org/html/draft-bcg-ccamp-gmpls-ml-implications-04

Lou Berger: when I read the document, there is a lot of material and it was not clear what the objectives were. The bullets towards the end of the document on the other hand were very clear. Therefore it would be good to improve the readability.
Dimitri Papadimitriou: yes, we did update the document and we will continue to improve it. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Include Routes - Extension to RSVP-TE
11†††††††††††††††††††††††††† 10:32†††††††††††††††††††† 5††††††††††††††††††††††††††††† Presenter: George Swallow†††††††††††††††††††††††

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

Lou Berger: you are including the EIRS (Explicit Inclusion Route Subobject), why are you defining a new suboject that includes subobjects rather than just using the subobjects directly? You are carrying a subobjects in the ERO that includes sub objects that are sub ERO, I don't understand why. I will take this question offline.
Adrian Farrel: it might help adding a quick BNF to the document?
Zafar Ali: the structure is in line with XRO semantics. 

Lou Berger: [poll] how many think the functionality in the draft is useful? [Small number] How may read? [A few more] I am reluctant to poll the WG on a draft that very few find a useful functionality. We need more time for the WG to understand what is proposed. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Extended Encoding Scheme for SRLG
12†††††††††††††††††††††††††† 10:37†††††††††††††††††††† 8††††††††††††††††††††††††††††† Presenter: George Swallow

http://tools.ietf.org/html/draft-ali-ccamp-extended-srlg-00

Lou Berger: [to queue at the mic] we are out of time for this presentation. Please will Dimitri and Fatai take your comments to the list. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Mutually Exclusive Link Group
13†††††††††††††††††††††††††† 10:45†††††††††††††††††††† 10†††††††††††††††††††††††††† Presenter: Vishnu Pavan Beeram

http://tools.ietf.org/html/draft-beeram-ccamp-melg-00

Dieter Beller: why is this needed?
Pavan Beeram: the MELG construct is needed by a computation entity that operates on the client TED to compute concurrent paths. Without MELGs, the computed concurrent paths would be incomplete and only a subset of the computed paths would be successfully provisioned. 
George Swallow: have you done any scalability studies?
Pavan Beeram: no. We will [include] discussion regarding scaling [within] the document.
Fatai Zhang: why you need to introduce a new concept, why not use the SRLG?
Pavan Beeram: the SRLG shows the shared risk but they can be used at the same time. The MELG indicates that they cannot be used at the same time.
Dimitri Papadimitriou: with a scalable abstraction mechanisms we may solve both problems at the same time. 
Pavan Beeram: even with a scalable abstraction mechanism in place, there is a need to advertise mutual exclusivity information.

 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: GMPLS RSVP-TE Ext for Lock Instruct and Loopback
14†††††††††††††††††††††††††† 10:55†††††††††††††††††††† 10tle:       ††††††††††††† Presenter: Jie Dong or Mach Chen

http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-05

Lou Berger: [poll] how many think it is a useful function? [A few] How many have read? [A few more] How many have reservation? [None]
Lou Berger: mild support to adopt, not overwhelming. Notable that no one objects. We will take to the list. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: RSVP-TE Recovery Extension for data plane initiated
11:05†††††††††††††††††††† 5††††††††††††††††††††††††††††† reversion, protection timer and SNC options signalling5
††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††† Presenter: Zafar Ali

http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08

Lou Berger: I think you misunderstood my comment from the last meeting. You should look at leveraging the OAM configuration work which came after the earlier versions of your draft. 
Zafar Ali: this is applicable to multiple technologies. 
Lou Berger: yes, the OAM configuration framework is also applicable to multiple technologies. You need a strong reason not to follow the WG in this area. Please look at the OAM configuration document [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state why your work is justified in not following the existing WG solution in this area.

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Extensions to Resource Reservation Protocol FRR
16                 ††††††††† 11:10†††††††††††††††††††† 5††††††††††††††††††††††††††††† †††††††††††† for Bidirectional Co-routed Traffic Engineering LSPs
††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††† Presenter: Zafar Ali

http://tools.ietf.org/html/draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-00

Greg Mirsky: I will send my comments to the list. I think that co-routed local protection should use association, and not be performed ďon-the-flyĒ.  
Lou Berger: FRR is in MPLS WG domain, GMPLS extensions are in CCAMP's. The chairs will coordinate with the MPLS chairs as to where the discussion needs to take place.

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic:
17                 11:15        5        Title:        RSVP-TE Extension for Label Switched Path (LSP) Inquiry
†Draft:       
http://tools.ietf.org/html/draft-ali-ccamp-lsp-inquiry-00
†Presenter:        Zafar Ali

[Out of time for discussion]

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Routing Extensions for Discovery of Role-based
18†††††††††††††††††††††††††† 11:20†††††††††††††††††††† 5††††††††††††††††††††††††††††† MPLS LSR Traffic Engineering (TE) Mesh Membership
††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††††† Presenter: Zhenbin LI or Mach Chen

http://tools.ietf.org/html/draft-li-ccamp-role-based-automesh-00

Lou Berger: [poll] how many are interested in the function described. [One] We clearly need more discussion to justify its existing in the WG. 

 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: RSVP-TE Signaling Extension for Bandwidth availability
19†††††††††††††††††††††††††† 11:25†††††††††††††††††††† 5 †††††††††††††††††††††††††††† Presenter: Min Ye

http://tools.ietf.org/html/draft-long-ccamp-rsvp-te-bandwidth-availability-00

Fatai Zhang: question for chairs. I am trying to find the right WG for the work. 
Lou Berger: it is reasonable for GMPLS related extension to be brought to CCAMP.

[Meeting over. Adjourned at 11:30]                           

Second Session
FRIDAY, March 15, 2013
0900-1100, 12:30-3:30
Room: Caribbean 2

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: CCAMP update/overview for Q6
20†††††††††††††††††††††††††† 9:051†††††††††††††††††††† 5††††††††††††††††††††††††††††† Presenter: Chairs

Peter Anslow:  [RFC6566 slide - impairment computation question] the difference between C and D, C would be some magic, very simple path computation, that accounts for non-linear effects, while D considers accurate non-linear impairments while performing path computation. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Signaling Extensions for Wavelength Switched Optical
21†††††††††††††††††††††††††† 9:20††††††††††††††††††††††† 10†††††††††††††††††††††††††† Presenter: Giovanni Martinelli

http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-05

Lou Berger: is there anything left to do other than the minor comments and Cyrilís comments?
Giovanni Martinelli: need to double check the Wavelength Assignment (WA) [TLV?]. Also need to check PCEP object [PCE WG draft] to synch the encoding.
Lou Berger: are you move likely to change it there [PCE WG], than here?
Giovanni Martinelli: no.
Lou Berger: [to WG] there was a substantive technical change in this latest revision. Please review and send comments to the list. It's likely that after the next revision we'll start the Last Call process on all of the non-impairment WSON documents.

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: WSON Status Overview & Signal Compatibility
22†††††††††††††††††††††††††† 9:30††††††††††††††††††††††† 10†††††††††††††††††††††††††† Presenter: Xian Zhang

http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-11

Lou Berger: the next revision will be editorial, rather than technical. Please review and send comments to the list. Any comments made now will help with Last Call. 
Peter Anslow: version of G.694.1 is not up to date, is it intentional as you do not take into account flexi-grid?
Deborah Brungard: this work [WSON] has been progressed over several years so reference is older one. This work does not include flexi-grid, but it still should reference the latest version. 
Lou Berger: it is worth highlighting in the document that it does not include flexi-grid.
Deborah Brungard: Can make note of it and use latest reference.
Malcolm Bets: I want to check that the new version of G.694.1 does not deprecate the old encodings of fixed grid.

Peter Anslow: no. We were very careful to not change for the fixed grid definitions. We have been careful to add definitions and not changing existing ones. Although, the new flexible grid terminology can be used to describe any of the fixed grids.

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: WSON Impairment Info
23†††††††††††††††††††††††††† 9:40††††††††††††††††††††††† 5 †††††††††††††††††††††††††††† Presenter: Xian Zhang

http://tools.ietf.org/html/draft-bernstein-wson-impairment-info-02

Deborah Brungard: any questions at this time? We will be revisiting this [Q6] topic later in todayís [Q6] session. It is good to hear that you will try to work together [with the other draftís authors]. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: WSON Impairment Encode
24†††††††††††††††††††††††††† 9:45††††††††††††††††††††††† 5††††††††††††††††††††††††††††† Presenter:        Xian Zhang

http://tools.ietf.org/html/draft-bernstein-wson-impairment-Encode-06

Deborah Brungard: again, we will revisit this topic in our Q6 session today. 
Lou Berger: although this is not a normal session you may ask any clarifying comments on the draft. Although we will discuss this topic at the Q6 Meeting this afternoon. 
Peter Anslow: we have to discuss all the details this afternoon. If we're discussing the fiber impairments regarding G.680 you need to put quite a lot of information in routing, have you been thinking about that?
Xian Zhang: we have not decided yet.
Malcolm Betts: you are using WSON model, modeling against ports in optical switch, have you considered fiber parameters against the link. This is just a comment, we can look at this again in the afternoon. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Info Model for WSON Optical Impairments Validation
25†††††††††††††††††††††††††† 9:50††††††††††††††††††††††† 10†††††††††††††††††††††††††† Presenter: Giovanni Martinelli

http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info-01

Lou Berger: any comments? Remember this will be part of the Q6 Meeting this afternoon. 
Peter Anslow: most of this discussion has to occur this afternoon. We would not expect full monitoring of various parameters, and will need others, filter function for instance. The question we must consider whether it would be helpful for ITU to include parameters that can't/aren't monitored. We could look to add to the existing table, if you [IETF] felt that would be useful. 
Dieter Beller: connectivity matrix: is the idea to enhance the information and how? 
Giovanni Martinelli: yes, I will provide details on the next draft. 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: Encoding for WSON info model Impairments Validation
26†††††††††††††††††††††††††† 10:00†††††††††††††††††††† 10 ††††††††††††††††††††††††† Presenter: Giovanni Martinelli

http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-01

[No questions]


 

 

Presentation†††† Start Time†††††††††† Duration††††††††††††† Topic: An SNMP MIB extension to RFC3591 to manage
27                 ††††††††† 10:10†††††††††††††††††††† 10†††††††††† ††††††††††††††† optical interface parameters of DWDM applications
††††††††††††††††††††††††††††††††††††††††††††††††† †††††††††††††††††††††††††††††††††††††††††††††Presenter: Gabriele Galimberti

http://tools.ietf.org/html/draft-galikunze-ccamp-g-698-2-snmp-mib-02

Deborah Brungard: the discussion that will take place this afternoon will help you clean up your slides regarding the ITU-T references.
Lou Berger: the previous meeting comment was that the parameters were not needed. 
Gabriele Galimberti: not all the parameters can be set. Sometimes you configure the fibre type from the NMS. This helps path computation.
Deborah Brungard: there is always the issue of a "moving target" when you develop. 
Malcolm Betts: this confuses me. I thought it was a matter of controlling transponders at the end of a link. 
Gabriele Galimberti: there may be new parameters, [or] maybe not. We are still discussing.
Deborah Brungard: do you think we need two separate MIB documents [generic WSON and G.698.2]? 
Gabriele Galimberti: no. However we would like to have ITU feedback. I am not giving a statement but rather asking for support.
Deborah Brungard: so you are asking technology questions, not necessarily this document [this I-D].
Malcolm Betts: one more question, is this aligned with the info model of G.874.1? Which is the model for OTN terminals.
Deborah Brungard: we should discuss this in the afternoon. We will need to understand what needs to be read or write. 
Malcolm Betts: this is a Q14 issue. One more question on slide 6. The frequency definition, is this based on the definition of flexi -grid?
Gabriele Galimberti: no.
Paul Doonan: is this a WG document?
Gabriele Galimberti: no.
Deborah Brungard: this is an individual doc, not yet accepted by the WG.
Paul Doonan: time frame forecast? 6 months? 12 months? This is related to BBF liaison.
Lou Berger: once the I-D is a WG document, we will consider sending a Liaison. 
Peter Anslow: this is one of the docs I do not understand. Why would you want to use MIBs to distribute specification information?
Dieter Beller: I think we will reach consensus on the utilization of application codes Q6 defined, what could make sense here.
Gabriele Galimberti: ok. 
Deborah Brungard: thank you Dieter. We will discuss this in the afternoon. Gather further insight, then work with ITU.
Lou Berger: I did not understand the answer regarding the generic WSON MIB document?
Gabriele Galimberti: with regards to the generic WSON MIB. We still have intent, and it is work in progress. 
Giovanni Martinelli: we simply did not have time but we will provide an update for the next IETF.


> 28                 10:20        10        Title:        Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for DWDM Optical Line Systems to manage black-link optical interface parameters of DWDM application
> Draft:       
http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-02
> Presenter:        Dharini Hiremagalur

Malcolm Betts: The ITU had a recent interim meeting and agreed to work on black links with OTN architecture.† We sent a Liaison to OIF and BBF, probably need to send also to CCAMP. I make the same comments as previous draft, this needs to be based on the info model in G.874.1.† It would save time. 

Lou Berger: is that about exchanging or modifying parameters?
Dharini Hiremagalur: just exchange

Malcolm Betts: You may be asking parameters that do not exist (i.e., not included in G.874.1).
Lou Berger: [to Malcolm] you are saying that the parameters should not come from Q6 parameters but from a different Q14 doc?

Deborah Brungard: You want to use LMP here, but why are these parameters extended beyond the WSON application codes?
Dharini Hiremagalur: if you have a standard application code it might be enough, but if you don't have standard, you might need all the parameters.

Lou Berger: why not use a vendor application code?

Dharini Hiremagalur: Because of interoperability issues.

> 29                 10:30        10        Title:        Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks
> Draft:       
http://tools.ietf.org/html/draft-ogrcetal-ccamp-flexi-grid-fwk-02
> Presenter:        Oscar Gonzalez de Dios


Adrian Farrel: AD Hat On - 3 thanks, 1 criticism. 
Thanks for driving the work and putting together a lot of different peopleís perspective. Thanks for proving that ASCII art is good enough. I asked this group of people not to make a private group but make it a WG work. Thanks for starting to move the conversation to the WG list.

Oscar Gonzalez de Dios: We always tried to prepare text for the list, but it has been hard to get ideas together from so many people [working on the draft]. 

Lou Berger: As the ID goes from individual to WG, the consensus must be WG consensus and not authors consensus. We look forward to have a new version after the meeting and we might consider polling the WG for adoption before the next meeting.
Consensus of the authors is actually irrelevant for WG documents.  

Peter Anslow: More of a statement than a question, a lot of questions in the document. A few comments: 1. A number of questions are not Q6 items. ; 2. Most of the questions regard ongoing work which is ongoing in different Qs in ITU.
A concern is that terminology is not fluid. I would point to OCh. We should try and separate concepts and terminology. Keep the OCh term out and define a new one.

Malcolm Betts: I concur, we need to be careful with terminology. 
I don't think the answers to the questions depend on the definitions.

Giovanni Martinelli: I would ask to post new revisions of the draft more often as there are many updates each time.

Peter Anslow: response to Malcolm. We are clear about concepts; it's a matter of terminology. 

Lou Berger: of course as you clarify terminology in ITU, we can find some terminology used here [in IETF] being overused. In a previous session we discussed "Media" and possible confusion in the IETF context.

Peter Stassar: it's a historical mistake of terminology (re term optical channel).

> 30                 10:40        10        Title:        OSPF extensions for support spectrum sub-band allocation
> Draft:       
http://tools.ietf.org/html/draft-wang-ccamp-flexigrid-wavelength-range-ospf-02
> Presenter:        Qilei Wang
[no comment]

> 30A                 10:50       10         Title:     Generalized Label for Super-Channel Assignment on Flexible Grid
> Draft:
http://tools.ietf.org/htmldraft-hussain-ccamp-super-channel-label-04
> Presenter:Iftekhar Hussain 

Malcolm Betts: we've already discussed this in the† flexigrid framework. At the moment it is not a standardized ITU-T data plane concept. It's worth covering this issue within the context of the framework document.

Xihua Fu: It seems that super channel is a confusing term.

Iftekhar Hussain: will use the standard terminology once defined.

Daniele Ceccarelli: Since the scope of the framework is just a media channel, does super channel belong to the media channel or is a signal issue?

Malcolm Betts: The framework defines media channels; groups of media channels would be included as well.

Igor Bryskin: Please keep it separate, we can do many things e.g, groups of virtual links

Lou Berger: within the group we've done some work on it: waveband and channel set which allowed to have non contiguous labels managed in a single LSP.

Oscar Gonzalez de Dios: my view is that from a framework perspective we need to consider it as a group of labels that need to be managed together keeping separate media channels and multiply them together.

Iftekhar Hussain: encoding will be analysed later. Some modification needed on the framework.

Deborah Brungard: there is confusion on what you really mean with super channel, don't get stuck on the term but try to make it clear what the concept is. Maybe it is worth keeping it in a separate doc for now and then merge with the framework.

> Lunch Break                 10:50                           

> Resume                12:30                        

> 31                 12:30        30        Title:        Q6 Update for CCAMP
> Presenter:        TBD

> 32                 13:00        150        Title:        Discussion Topics
> (To include items identified prior to meeting and in earlier session)
> Moderators:        Chairs
> Adjourn                 15:30                           


=====================================================
WSON Impairments [Slide 3]
=====================================================

Q From Q6 experts: what is the object of this work?

Peter Stassar: G.680 only covers the linear problem, non linear problem not addressed yet in any document. Q6 experts unsure if it can be solvable in a standard form. We need to clearly state what is the goal of the working group so to understand if it is possible to achieve it and† how.

Peter Anslow: Agree with Peter. We understand that the† high level goal is doing path computation, but what are you expecting to do now? Are you trying to solve the overall path computation issue? Are you happy to start work on the linear part and hope that it will be possible to do the non-linear part later? I can't make any forecast on when it will be possible to be able to solve the non linear path computation too. It might be possible to address non-linear issues in a "private" network but it is extremely hard to solve the problem for any arbitrary network.

Loa Anderson: We have 2 problems, one linear and one non linear. What would be the impact on the linear solution if we assume that we can solve the non linear one vs we canít solve it?

Lou Berger: are we providing an incremental solution? This is what we've done in the past. We can't solve everything. With lambdas we solved a part of the problem and over time filled the gaps. We haven't got to the point of whether we're solving linear today and non-linear tomorrow.

Peter Anslow: There isnít a linear and a non linear problem, but if you want to categorize it that way, you have to do what G.680 does in its current version. G.680 addresses the linear problem saying that† a clear separation between linear and non-linear problems is needed. You need to create a set of rules to keep the problem linear, Q6 has agreed that this could be one approach where we live with non-optimum but standardized system. As long the rules provide enough separation to perform linear calculations, then this may be enough. For G.680 no one has yet proposed a candidate set of rules.

Lou Berger: I was going to ask the authors of the individual drafts to say what they want to do with their drafts.

Giovanni Martinelli: We need some numbers to flood through the network to allow path computation. Metrics actually used are different: e.g. cost, bandwidth. In WSON we need different metrics: e.g. OSNR. In other words a number to be associated to networks components so that the PCE can understand whether the computed path is feasible or not.

Lou Berger: A difference in our approach, opposed to pre-planned, is that the solution (identified by path computation) may not be optimal or even right. It may be good enough or, in the not unlikely event that the control plane can fail in setting up a cross connection, we provide mechanisms and options to deal with those failures. In the non control plane scenario you need exact information, we need to have something more than zero, which is what we have now in the non impairments solutions.

Giovanni Martinelli: I like the comment from this morning: it's better to speak about approximation rather than linear and non linear. We need to figure out which are the essential information that we need, the rest is approximation.

Peter Stassar: What we can have from Q6 is mutually exclusive to what you need. We can provide a linear model, but a network doesnít work in a linear model. What is a better path, what are the criteria to judge it? What can be done to provide a better path?

Lou Berger: A short answer. 2 dimensions of better path: i) higher probability that it is a viable path and ii) that allows saving resources i.e.longer reach in the network without regen. Solving both would be great but solving one would provide value.

Peter Stassar: How reconfigurable, is it live traffic, when does it happen. You need to make it clear what digging the canal means and making the boat go through it.

Malcolm Betts: Currently, in WSON the path computation is performed after you consider and validate all the possible paths in the network. Impairments are considered, but are considered before you start to operate the network. (Lou Berger: Thatís one way to operate the network, not the only one.). Thatís the only safe way to use it. The other problem is that in an analog world the path you set up can impact existing paths in the network. Thatís why if we only deal with the linear problem we might make more damages than good.

Lou Berger: does that problem exist with the current working group solution?

Malcolm Betts: as long as you deal with prequalified paths, no. Otherwise good question.

Lou Berger: The risk exists today and itís how you build your network whether you run in that problem. Can we make things better, and if so how?

Malcolm Betts: good question. My point is that if we only think of linear impairment we might think weíre making things better but weíre only making things worse.

Xian Zhang: Maybe Q6 can add the new parameters to the G.697 so that we can reference it and add the parameters to our drafts instead of referencing the G.680 that only covers the linear case.

Peter Anslow: I would not characterize a linear calculation as an approximation of non-linear. 
I would say in most cases it is an optimistic version and not an approximation.  If it was acceptable for you, when you ignore the non linear effects you may get an approximation to a calculation where Iíll tell you if it definitely wonít work. It does move things forward. I agree with Malcolm when saying that in such a way, you would put existing paths at risk. The linear model puts a lower bound, if it says a path doesnít work, it wonít, but if it says it will work, it will not necessarily work. Secondly you have to accept additional impairments on existing paths. If this is acceptable then we can say this is a reasonable basis for your work.

Lou Berger: Note for the editors of the individual drafts: please make sure there is an applicability section in your docs saying where the solution applies and where it fails.

Oscar Gonzalez de Dios: if I correctly understood the impairment work will serve at most as a guess whether the path will work or not. This could be split into providing a good enough solution for now, but will require optimization in the future, as a path working now might not work in the future (3rd dimension of the ďbetter pathĒ problem).

Lou Berger: I don't believe we've ever considered that use case and it is an interesting one.

Giovanni Martinelli: Precomputing all the paths is a way to go, not the only one. WSON networks are becoming fairly meshed; the number of paths can become quite huge. It is true that the path may not work, but you have the same problem establishing a path manually, you're not sure it will work until we test it. On the applicability statement, I was wondering whether applicability applies to the framework document.

Lou Berger: Different solutions will have different applicability. Iím not sure you can say something totally abstract to the solution.

Deborah Brungard: Re: abstraction - seeing Q6 folks are here, maybe we can go through the parameters as it would help to have a common understanding. 

Malcolm Betts: is it possible to define a set of conditions under which we can say we only work with linear impaiments?† This is a fundamental question. To address the earlier point Giovanni and Oscar made, unless you look at the global scope you are not going to be certain that the path will work (without looking at the network).

Dieter Beller: what we need is a model based on approximation to understand whether a path is feasible or not. The point that a new path might impact existing ones is a matter of how the system behaves and the network is built.

Peter Anslow: disagree very strongly. Pre-computation took the factors into account and computed the candidate paths and capabilities for n channels to better understand the risk.

Oscar Gonzalez de Dios: What is the order of magnitude between exact calculation and approximation? Is it a margin that may be a 1km, or >20km.

Lou Berger: the answer is we can't tell you here. Itís based on the vendors equipment, how you deploy it and your fiber plant.

Peter Stassar: there is no answer. If the linear induces risk, then you need to pre-compute and test the path. We do not want to recommend something that does not work. Do you [operators] want to accept responsibility for the risk that introducing a service may have?

Gabriele Galimberti: new paths must not impact existing ones. And if you do want that to be possible you must deal with non linear impairments too. But we can't stop here. We should allow the control plane to share those parameters, if we want to avoid proprietary solutions.

Lou Berger: are you saying that it should be possible to pass around proprietary info to be used in a proprietary way?

Gabriele Galimberti: Yes. At least as intermediate step.

Lou Berger: Are you asking the Q6 experts to help us identify those parameters. Question for Q6 experts: we presuppose Q6 has the parameters for linear calculation that can be used for proprietary non linear calculation.

Peter Stassar: Status update: G.697 and G.680 are clearly written on 2.5G and 10G. It may be useful to help operators use proprietary systems. We need to have clear requirements from the users, if linear model does not work then let us know. 

Peter Anslow: There are parameters in G.697 that have different goals. As an appendix, we could include parameters that you may want to monitor, this may be helpful. 

Lou Berger: take away:† we can improve our ability to know which paths won't work.
Are there any parameters that might be useful in the non linear calculation?
My fear as chair is that we might be required to pass around a huge amount of parameters.

Peter Anslow: please send a liaison so that we can work on that. It is easier if you could send the list of parameters and we say which one is needed and which is not, rather than asking what the list is.

Giovanni Martinelli: A while ago we submitted a document with these parameters. Would it be better to submit via ITU or IETF.
The question for Q6 experts is about modulation formats and coherent transmission. Non coherent transmission can impact existing paths. Coherent systems may be better. Any comments about it?

Peter Anslow: The problem will not go away with coherent receivers. An easy thing to do is increase power, you want to operate networks as best as possible and you design them to push the limits. 

Lou Berger: summary
1. modify appendix of G.697. You need a liaison for it? (Peter Anslow: yes). Lou Berger: will discuss doing.
2. we can use G.680 to incrementally modify the control plane to represent a system operating with linear impairments (Peter Anslow: yes, but it doesn't help you establishing the budget)
3. there may be parameters that could be helpful in a non linear based approach and you're willing to review that list if we're sending them along

Igor Bryskin: this information [power levels, OSNR, etc.] could be discovered and advertised. 

Peter Anslow: My view is you cannot auto discover a budget. You cannot ask a receiver for a budget. 

Igor Bryskin: why not, it comes down to comparing OSNR and power.

Peter Anslow: No, not true. Spectral excursion for example. You can't ask a receiver for the spec on transmitter spectrum,† spectral width. 


=====================================================
G.698.2
=====================================================

Lou Berger: Question from earlier: why MIBs?

Peter Anslow: we don't need MIBs for standard applications as we capture all the parameters in application codes. Transmit power may be useful, beyond that I cannot think of anything else you may want to set. So I am not sure why I need to see all these parameters on the list [see slide].

Gabriele Galimberti: Here and in LMP we specify the application codes. Why preclude to a customer to knowing the characteristics of the network and make their own computation based on parameters not covered by application codes?

Peter Stassar: you say some transponders are better that "Standard ones". Q6 specs define BER 10^-12. Not relying on specs but on individual computation and parameters management could be very risky.

Gabriele Galimberti: I do not want to preclude knowing this information. 

Peter Stassar: Then you are going towards a proprietary solution. 

Deborah Brungard: the title of this is G.698.2, then you're using the standard application codes. Nothing else is guaranteed. So what you are saying now is no longer G.698.2, itís to support proprietary.

Gabriele Galimberti: We do not want to give the value of parameters 

Peter Stassar: you would want to transfer the info declared by manufacturer, tested or what?

Gabriele Galimberti: tested

Malcolm Betts: We should look at G.874.1, most of the parameters in this list are not relevant. 

Peter Anslow: there are 2 options: 1 get the values out of relevant ITU specs, 2. get them by manufacturers datasheet. You are only interested in the values and the relevance on the link.

Gabriele Galimberti: the manufacturer data sheet can be available. 

Peter Anslow: what is being proposed is advertising the data sheets of the devices?

Lou Berger: Then you (authors) need to update the document to reflect this.

Deborah Brungard: are you going to need the MIB to store this huge amount of info?

Dharini Hiremagalur: Also application codes can be stored so to reduce the amount of data. 

Deborah Brungard: You need to rationalize this and why you need it. If you have other applications then you should not use the title, G698.2, you currently have.

Peter Anslow: The basic info you need to setup a connection is application code and frequency

Lou Berger: how would you represent tuneable transponders? Is there an application code for them?

Peter Anslow: you enumerate all its capabilities. Btw it is out of Q6 scope how to do this.

Peter Anslow: if there is a standard, it is part of the application code. The codes must be standardized otherwise there is no way to know what they mean.

Gabriele Galimberti: which parameters are needed? 

Peter Anslow: Application codes, (and these 2 are the standard ones) frequency and Power in addition

Lou Berger: questions: whatís happening at higher rates?

Peter Anslow: not many new 10G codes expected. 40G, we only standardize application formats where there is a reasonable market share. We had an agreement to do 40G and then move to 100G. However, now 100G is actively under study. Currently there is only 1 modulation format candidate for 100G standardizations. What we're struggling with is doing fundamental work on standardizing phase modulated transmission.

----------------------------------

Slide 10

Lou Berger: From slide: How will transceivers that meet a set of application codes be represented?

Peter Anslow: I don't really understand the question. It's been true that transmitters/receivers have met multiple application codes for many years. 

Lou Berger: is that an acceptable answer for those who asked it? I see drafts authors nodding. 

-----------------------------------

From slide: What future management parameters will be introduced to support colorless, directionless, contentionless ROADMS?
    -- not a Q6 question

=====================================================
FLEXI GRID and SSON
=====================================================

***********************************************************************
THE ETHERPAD RESET AT ABOUT THIS POINT, SOME NOTES LOST!
***********************************************************************
Peter Stassar: there are 2 parts wrt flexi-grid: a passive one (the digging of the channel) and the active one (the boat). The definition of the passive thing is quite stable (G.694.1 and network media channel). Everything that goes on it (beyond 100G discussion) is an open issue. For 100G deployments the 50Ghz channel spacing is enough. The mapping between a data stream and an OCh and between an OCh and a network media channel is an active debate in ITU. Also terminology is not defined yet.

Lou Berger: what term should we use? Boat?

Peter Anslow: re the OCh when we split the data stream into separate network media channels we still donít know whether it will be a single or multiple OCh. The rest of the terminology shouldnít change. The key term already present in your documents is the Network Media Channel, end to end path through the network from transmitter to the receiver. Q6 has provisionally agreed to modify a term already existing which means the entire signal (independently on how many carriers it has) that gets put down in a network media channel: OTS : Optical Tributary Signal. It is the light that goes through a network media channel from TX to RX independently on the numbers of carriers.

Peter Stassar: there are 2 terms in your documents that are not defined in ITU: spectral slice and Superchannel.

Peter Anslow: the contiguous Superchannel would map with the OTS and the non contiguous Superchannel would map to 2 or more OTS. We donít have terms to define it.

Lou Berger: weíve used VCAT in one context the channel set term in another to identify it.

Iftekar Hussain: this group will not define the split spectrum case but there is the possibility to map a signal into 2 or more OTS, right?

Peter Anslow: yes. Btw we wonít have a term for it, it is two or more things.

Malcolm Betts: Calling it a ďsetĒ is the safer way.

---------------------------------
Flexi-grid Framework (slide 7) 
---------------------------------
Q1 - What is the relation between optical signal layer (OCh) and media layer
 
Malcolm Betts: Quick answer to 1 : we will name it OTS (optical tributary signal), what goes above is out of scope. We will have a single OTS on a single network media channel.
  
Q2. Do we need to consider express channel?
Oscar Gonzalez:  It is a media channel that holds several network media channels.

Peter Anslow: the Media Channel can carry single or multiple OTS, the Network Media Channel a single one.

Oscar Gonzales: so you can make infinite hierarchies of media channels?

Malcolm Betts: in the media there is no hierarchy. It is flat spectrum. From a management point of view it is possible to think of media channels inside media channels, but they donít exist.

Lou Berger: itís like the waveband concept, where you can switch a single lambda into a waveband even if it is a pure management abstraction.

---------------------------------
Flexi-grid Framework (slide 8) 
---------------------------------
Q. Oscar Gonzalez de Dios: Are there any other attributes that need to be categorized (other than N and M for links and connectivity matrices for nodes) ?

Peter Anslow: No, itís ok from allocation point of view. But if you want to know the values for a piece of fiber then you need to go back to the application code (either standard or a proprietary end to end description). The fiber may go outside some limits of the link as an end to end frequency. There might be cases in which all the components allow for the availability of a piece of spectrum but the fiber doesnít, and N and M change, or using a given modulation format rather than another, change the N and M along a fiber.

Oscar Gonzalez : So, strictly speaking what you can do on the fiber depends on the signal. And what about the nodes?

Peter Anslow: There is nothing new wrt what already debated re impairments aware WSON.

---------------------------------
Flexi-grid Framework (slide 9) 
---------------------------------
Q. Oscar Gonzalez de Dios: During the path, is it possible to have different slots or different N?

Peter Anslow: it's not Q6 question.

Malcolm Betts: I tend to say, unless really complicated, the protocol shouldn't care until we have a better understanding.

Peter Anslow: disagree. We need to be able to represent the resources of an effective frequency slot correctly. 

Oscar Gonzalez de Dios: what is not known is the amount of spectrum that is usable. There is some work on guardbands that here it could help a little bit. 

Peter Anslow: Still disagree with Malcolm, nothing to do with if it is useable or not. Different issue. We need a convention on how to describe it.

Lou Berger: conclusion - too early to give an answer.

Peter Anslow: will ITU solve and IETF follow or vice versa?

Lou Berger: it depends, if it is a data plane definition it's up to you (ITU), otherwise if it is a management construct, we can debate.

Malcolm Betts: Needs to be fixed in ITU for G.872 also.
---------------------------------
Flexi-grid Framework (slide 10) 
---------------------------------
Q. Oscar Gonzalez de Dios: do we need to consider the impact of signal characteristics on the link and represent in the control plane or forget about it?

Malcolm Betts: this is the impairments aware path computation issue. If we consider to be in an environment of only pre-qualified paths, the answer is no, otherwise the answer is the discussion we had before on impairment aware path computation issues.
Peter Anslow: agree. 

Oscar Gonzalez de Dios: Then it is a matter of the signal layer to compute all the impairments and not a matter of resource allocation in the media layer?

Malcolm Betts: if we say the flexigrid fwk is about media channel allocations, than we don't have to worry about it, otherwise we have to. From the current scope of the fwk we don't have to care. We will when we consider the signal also.

Lou Berger: Will be interesting to see how the document progresses. 


Oscar Gonzalez de Dios: we'll just consider the media layer and only jump to the signal layer when the media one is stable.

---------------------------------
Flexi-grid Framework (slide 12)  -† Superchannel
---------------------------------
From slide:

†† o Which concepts are well and less well defined?

†† o Which terminology is well and less well defined?

††††††††††††† - What should we use as placeholder terminology?

Q1 already covered above
Q2 not a Q6 issue.

Peter Anslow: Obvious this needs to be done, how needs discussion.

Malcolm Betts:  Agree. This needs to be done, how needs discussion.

Lou Berger: takeaway: it's still early. it's likely to happen. it's likely it won't be called superchannel. Waiting for a new term, maybe channel set? We need to avoid the superchannel term as there is a negative connotation related to it.

Peter Anslow: Two terms are needed to reflect the differentiation between signal and media. And in order to avoid confusion you need a term for a group of network media channels, another term for the group of optical entities that use it. I suspect actually superchannel is used for both.

Malcolm Betts: the second term is not needed, we're only dealing with media channels. We need it but not in this draft.

Lou Berger: it's an individual doc, it's up to the authors. we encourage discussion on the list. You need to move rapidly, this could become a WG document soon. At that point the WG decides.

Peter Stassar: Please be careful as in G.709 the OTS acronym is used for† Optical Transmission Section.
Malcolm Betts: Iím keen on focusing the doc on media channel only as it is a stable concept in the data plane. Please do not focus on the signal layer otherwise it might be delayed a lot.