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.