> 83rd IETF --
>
> for the
> 83rd IETF Meeting
> First Session
> Monday, March 26, 2012.
> 1300 - 1500 Afternoon
Session I
> Room Name: Maillot
>
> Presentation Start Time Duration Information
> 0 13:00 10
> Title: Administrivia & WG Status
> Draft:
> Presenter: Chairs
> Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-0.pdf
Lou Berger: Status of WG drafts
not on agenda?
OAM configuration documents
(Attila Takacs): some update on SDH and OTN OAM configuration documents to add
delay measurement support. MPLS-TP doc updated based on comments on the list,
documents are stable and ready for last call.
Lou Berger: Have you closed
the loop with the ones that made the comments?
Attila Takacs: Yes.
draft-ietf-ccamp-gmpls-general-constraints-ospf-te
(Fatai Zhang): waiting for updates on
related documents (WSON information model and encoding drafts). Continue monitoring
them.
draft-ietf-ccamp-lmp-behavior-negotiation
(Dan Li): Updated half year ago. We are waiting for comments and feedbacks on
implementations. No issues raised so far.
Lou: is anyone willing to
comment on their own implementation. [no one raised issues] If no one wants to
speak publicly please write to the chairs or our AD. Please comment, if no
implementations then perhaps no reason to progress it.
Deborah: Liaisons. We have
sent one over to Q6 on flexible grid and we have a reply. Hopefully after this
meeting we can send them back a response. We have an update on the OTNT
standardization plan, they asked us to review and we should respond on that, so
please review these.
> 1 13:10 10
> Title: Framework and Information model for GMPLS
and PCE Control
of G.709 Optical Transport
Networks
> Draft:
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-06
> Draft:
http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-03
> Presenter: Sergio Belotti
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-3.pdf
Lou Berger: Last IETF we
discussed support for payload types other than 20/21. Do you think we need to
include anything in these documents for non-payload type 20/21 clients?
Sergio Belotti: You need to
take into account Type/TSG
Lou Berger: Do you think the
Info and fwk document has sufficient info (payload type)?
Sergio Belotti: We think the
document has sufficient information for 20/21
Lou Berger: What about other
PT values from G.709?
Sergio Belotti: We think the
info in these two docs is sufficient for multiplexing.
> 2 13:20 10
> Title: Traffic Engineering Extensions to OSPF
for Generalized
MPLS (GMPLS) Control of
Evolving G.709 OTN Networks
> Draft:
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-01
> Presenter: Daniele
Ceccarelli
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-4.pdf
Deborah Brungard: Do you
have a resolution for the outstanding one? Do you want to include FAs?
Daniele Ceccarelli: We do
not think we need additional extensions.
Deborah Brungard: What about
type-2 type-3?
Daniele Ceccarelli: I think
there’s agreement on moving from three to two TLVs, there are examples on how
to advertise them and I think the issue is solved.
Deborah Brungard: We think
we have a solution.
Lou Berger: Two questions:
Do we need to advertise payload type for adaptation? It’s going to be vendor
dependent, some of them are going to support multiple of them, some others are
not. Do we need to address the client adaptation at the routing layer?
Daniele Ceccarelli For
intra-OTN we have a solution, the combination of Payload Type and TSG is
enough. For inter-switching capability multiplexing the adaptation
advertisement is needed and we should address it in another document.
Lou Berger: Are you
volunteering to author another document?
Daniele Ceccarelli: Yes
Deborah Brungard: Why not
keeping things together?
Daniele Ceccarelli: This
document is OTN specific and no more info is needed for intra switching
capability advertisements. If you want to address also inter switching
capability issues in MLN/MRN more extensions are needed but to the IACD rather
than to the ISCD.
Lou Berger (Chair hat off):
For using switching caps, issue is closed assuming we have consensus from the
WG on handling of swcaps going forward. I have an individual draft on this that
will be presented later, but is an individual draft at this point and may not
represent WG consensus.
> 3 13:30 10
> Title: Generalized Multi-Protocol Label
Switching (GMPLS)
Signaling Extensions for the
evolving G.709 Optical Transport Networks Control
> Draft:
http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-02
> Presenter:
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-5.pdf
Lou Berger: Same question
(payload type and adaptation object). This document is quite different because
you have an adaptation object defined.
Lou Berger: if you have a
generic field in which you can carry the information all the time (G-PID), why
introduce an adaptation object in one case and using the generic field in the
other? It doesn’t seem to be consistent.
Fatai Zhang: it is
consistent
Lou Berger: It seems there
is a contradiction but maybe I’m just confused. Discussion will continue
off-line and be summarized on the list. Also, in order to be ready for last
call please make sure you have conformance language in sections where
procedures are defined. Notably section 8. (Rest of document shows good
improvement on usage of conformance language.)
> 4 13:40 10
> Title: RSVP-TE Extensions for Associated
Bidirectional LSPs
> Draft:
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-03
> Presenter: Fei Zhang
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-6.pdf
Kam Lam: You assume this is triggered
by the NMS? What happens if the two ends belong to different domains and
different NMSs are used?
Fei Zhang: Just an example,
it could be triggered by CLI.
> 5 13:50 5
> Title: RSVP-TE Extensions for Associated Bidirectional
LSPs and
Exchange of MPLS-TP LSP
Identifiers
> Draft:
http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-02
> Presenter: Fei Zhang
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-7.pdf
Lou Berger: (Slide 3) We
heard in the prior talk about associated bidirectional LSP that have two association
types, if you had the need to carry this ID why do you need both mechanisms?
Fei Zhang: This is different from the previous
(bidirectional) solution as association object may carry different
information. The prior types required
identical.
Lou Berger: How many read
this document? [two hands] This draft is derived from MPLS-TP discussions, and
has requirements.
Lou Berger: How many think
this TP requirement needs to be satisfied?
[More hands]
Lou Berger: We need to
understand if people think this solution satisfies the requirement(s), will
poll on the list to give people time to review the document.
> 6 13:55 10
> Title: RSVP-TE Extensions for Lock Instruct and
Loopback in MPLS-TP
> Draft:
http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-02
> Presenter: Jie Dong
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-8.pdf
Lou Berger: As mentioned,
these are also TP related functions. The functionality looks similar to the
lockout function provided by RFC4872, have you checked to see if those
mechanisms satisfy the requirements?
Jie Dong: I see protection lockout as different than
lock instruct as it includes ability to send test traffic.
Lou Berger: I think that
RFC4872 would provide a solution, together with the existing Admin status bits
would be suitable. Consider reviewing existing solutions and highlight why they
are not suitable.
Lou Berger: A second point,
you also introduce a new way of providing information to an intermediate node
(using notify) rather than use/extend an existing mechanism (ERO or SERO).
Jie Dong: We are reusing the
call mechanisms.
Lou Berger: This is an
end-to-end usage, please consider reuse and justify why shouldn't leverage one
of the existing mechanisms.
Julien Meuric: What I would
like to see is the motivation for this work, see RFC6435 already.
Lou Berger: Well, TP is a
motivator but we try to avoid a technology specific solution and have something
we can apply to other technologies, and this is applicable to other
technologies, e.g. Lambda.
> 7 14:05 10
> Title: GMPLS-UNI BCP
> Draft: http://tools.ietf.org/html/draft-beeram-ccamp-gmpls-uni-bcp-01
> Presenter: Igor Bryskin/John Drake
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-9.pdf
Lyndon Ong: We received a
number of questions internally regarding this document. It was not clear why
this was GMPLS UNI, this was more multi-layer than GMPLS UNI
Igor Bryskin: This is not
multi-layer, UNI and E-NNI is peering at the same layer, a question might be
why is this UNI and not ENNI. The same companies that implement this UNI with
routing have additional implementations that use just routing as described in this
draft but not signaling. Why then is ENNI, UNI + routing.
Deborah Brungard: We have
established there is a gray area of what is UNI, ENNI and peer-to-peer and
various shades of gray. This document gathers a lot of information from the
multi layer documents; if you really want to have a BCP then you need to refine
the document and the aspects (multilayer, virtual TE link, et al.) you need to
focus. Scope the document, if Lyndon and others cam help refine for GMPLS UNI.
Malcolm Betts: I share the
concern of what is the intention of the document, especially as it is a BCP. I
also have a lot of detailed comments on the draft.
Lou Berger: OK great, a few
comments. Document status should be in the document status and not ID title.
Also the term UNI does not include routing, it sounds like you're defining more
of an ENNI and by using the ENNI term, you help fulfill a requirement that is
on the WGs plate (from MPLS-TP).
Igor Bryskin: Question for
Lou Berger: May I answer as
a chair, we will discuss any draft put forward and progress documents that have
support of the WG, without it, we won't.
Deborah: We can define whatever
we want, but as long as you mention e.g. G.8080 we must get alignment.
Eve Varma: A few comments,
one issue the draft mixes concepts, if you scoping GMPLS UNI RFC4208, PCE is
not in scope, routing info not in scope. You need to cite what are the commercial
available instantiations of GMPLS UNI if you want to draft a BCP. The other
thing I noted is that the addressing options provided at the edge nodes in
4208, were there were two options that may or may not come from the same
addressing space while you are saying that they must come from the same one.
Again if there are some modifications there needs to be a justification for
them. Also there are new areas on SRLGs, again any modifications proposed must
be discussed in context of (existing) drafts.
Igor Bryskin: In L1VPN, we
recommend to use the same address space.
Eve Varma: Section 6 of your
doc refers to RFC4208 indicating that the same address space is to be used.
Igor Bryskin: Please re-read
the draft, we say there are two options and recommend to use one of them.
Eve Varma: That’s exactly
what I say, but agreeing that it is a best practice is another story.
Deborah: Scope the
application.
> 8 14:15 10
> Title: RSVP-TE Extensions for Collecting SRLG
Information
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-srlg-fa-configuration-05
> Presenter: Oscar Gonzalez de
Dios
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-11.pdf
Lou Berger: if you would
like to move forward as a proposed standard, please make sure you use
conformance language appropriately. Please look at Section 4.1 (Signaling
Procedures) especially and refer back to RFC2119.
Lou Berger: How many read
the draft? [a reasonable number], how many would like to move forward with the
document - [a few more]. Will discuss on the list.
> 9 14:25 10
> Title: Revised Definition of The GMPLS Switching
Capability and
Type Fields
> Draft: http://tools.ietf.org/html/draft-berger-ccamp-swcaps-update-00
> Presenter: Lou Berger
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-12.pdf
George Swallow: I support
the main proposal and deprecating PSC-2-4 in particular, I thought it was a bad
idea when it was introduced.
Lyndon Ong: I also support this
idea, removing the ambiguity is a good idea.
Xian Zhang: Question on new
Ethernet switch caps, why there are two of them instead of using the L2SC
switch cap?
Lou Berger: These are really
past decisions by the WG and examples where different values are used for
different versions of switching of the same type. The reason was insuring no
ambiguity between old and new implementations.
Xian Zhang: With respect to
ILH, are you proposing modifying the OTN documents?
Lou Berger: There was an
example discussed on the list, as I said on the list I'm not proposing any
change to the G.709 docs as they are more mature, but just using OTN as an
example. In that example I said copy the value from the stage 0 of the SCSI,
and no modification to the SCSI. The draft doesn't specify specific mapping of
ILH values for specific technologies, just says will be different for each
sublayer/multiplexing level.
Xian Zhang: Does the ILH
define a specific hierarchy for each technology?
Lou Berger: It indicates a
different level of multiplexing but what that level is, is a technology
specific answer.
Deborah: There are two parts
to this draft. It looks like there's
good support for the first part. We will need to look carefully if we need to
separate out the second part. I suggest that you read the documents and comment
on the list.
> 10 14:35 10
> Title: Requirements for Combined Protection and
Restoration and
Revertive Recovery
Requirements
> Draft:
http://tools.ietf.org/html/draft-roch-ccamp-combined-recovery-reqts-00
> http://tools.ietf.org/html/draft-roch-ccamp-full-reroute-reversion-00
> Presenter: Lyndon Ong
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-13.pdf
Slide 2: 4873 should be
4872.
Gert Grammel: Anything (document-wise)
that needs to be referenced from ITU?
Lyndon Ong: We will check.
Igor Bryskin: Good news, the
functionality described is available. It is good to standardize. One good
example is reversion done in a hitless manner, is good.
Lou Berger: General
observations, anything not references in an RFC is allowed. Use case would be
informational, an update to an existing document (RFC) would be an Errata.
Lyndon Ong: I expect that it
is the latter
> 11 14:45 10
> Title: RSVP-TE extension for Routing Diversity
using Exclude
Routes, recording TE Metric
of LSPs, Include Routes and signaling Optimization Objective and metric bound
> Draft: http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-01
> http://tools.ietf.org/html/draft-ali-ccamp-te-metric-recording-01
>
> http://tools.ietf.org/html/draft-ali-ccamp-rsvp-te-include-route-01
>
http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-bound-01
> Presenter: George Swallow
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-14.pdf
Lou Berger: (Slide x) Isn’t
the Objective Function an end to end construct rather than an hop by hop one?
George Swallow: It’s an end
to end concept.
Igor Bryskin: Thank you for
the examples, this is why we can use virtual link model, just to avoid all the
things that you’ve just explained.
George Swallow: I think
there are different approaches here and they are not in conflict. We can keep
this separate.
Igor Bryskin: I just hope
that Lou doesn’t ask us to merge.
Lou Berger: I see this work
aligned with existing GMPLS UNI and as separate from yours, which is defining
something more than the GMPLS UNI.
Gert Grammel: Is the SRLG a
concept that is allowed in G.8080 to be passed by the UNI?
George Swallow: It is an
issue of RFC4208, not G.8080.
Adrian Farrel (AD hat off):
On the LSP exclusion, how would someone, processing an RSVP message that is not
on the path of the LSP to be excluded, know the path of the LSP to be excluded?
George Swallow: Without
getting into architecture detail, there is work on stateful PCE that the node
can consult.
Lou Berger: Thanks for
providing an update. We do not have time for further questions. Let’s take
further discussion to the list.
> 12 14:55 10
> Title: Expressing label set in ERO
> Draft:
http://tools.ietf.org/html/draft-margaria-ccamp-label-set-ero-00
> Presenter: Cyril Margaria
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-15.pdf
Lou: No time for discussion,
will poll interest on list
> Adjourn 15:05
Lou Berger: We run out of
time, please send comments to the list.
> Second Session
> Wednesday, March 28, 2012.
> 0900-1130 Morning Session I
> Room Name: Maillot
> Presentation Start Time Duration Information
> 0 9:00 5
> Title: Administrivia
> Draft:
> Presenter: Chairs
> 13 9:05 10
> Title: General Constraints encode and RWA info
> Draft:
http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-07
> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-14
> Presenter:
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-16.pdf
Lou Berger: There is some
discussion on the list regarding these drafts.
Please remember that
decisions taken via the list are as (or more) important than the WG sessions
themselves as includes all interested WG participants.
> 14 9:15 10
> Title: Signaling Extensions for Wavelength
Switched Optical Networks
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-03
> Presenter: Giovanni
Martinelli
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-17.pdf
Lou Berger: Are you planning
on including additional mechanisms in this draft.
The current text is a little
bit confusing on that.
Giovanni: No (plans to add
additional mechanisms). We need to clarify the text.
Lou Berger: Are you planning
to update the ABNF Giovanni Martinelli: two things make it consistent with info
model and then update ABNF.
Lou Berger: Updating ABNF
for consistency is good (as currently have some inconsistencies).
Cyril Margaria: You mention
two ways of encoding parameters, is there a preferred solution, if so when will
it will be resolved?
Giovanni Martinelli: No
strong direction one way or another. I have a preference, but it’s not so
strong.
Lou Berger: As discussed in
session 1, there are multiple drafts that need the same function. It's clear we
need a non-technology specific solution.
ERO and SERO are the current ways to provide information to specific
nodes.
Giovanni Martinelli: I think
there is also another draft from the OAM talking about the same topic.
Lou Berger: This is a common
problem; do we have someone willing to work on this independent of
technologies? Cyril?
Cyril Margaria: Sure.
> 15 9:25 10
> Title: WSON interface class and WSON signaling
> Draft:
http://tools.ietf.org/html/draft-martinelli-wson-interface-class-02
> Presenter: Giovanni
Martinelli
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-18.pdf
Giovanni Martinelli: Two
points. First, regarding interface class fiber type, the draft does not define
semantics. These will be defined elsewhere.
Giovanni Martinelli: We are
not being explicit, these will be referenced elsewhere. You can carry
proprietary information (modulation format).
Malcolm Betts: The ability
to encode standard interface information (standard interface class) is very
useful.
Lou Berger: What you want to
happen is to influence WSON documents. Is this correct?
Giovanni Martinelli: Yes
Lou Berger: You should have
a look at existing docs and propose specific changes you're proposing to these
documents individually on the WG list.
Giovanni Martinelli: we have the appendix already, but we can take
this to the mailing list as well.
Young Lee: One point, if you refer to ITU documents you
need to be specific as to the identifiers. Fiber Type is not currently in scope
of the base WSON documents. To me this is out of scope as Fiber Type definitely
belongs to WSON impairments.
Giovanni Martinelli: I want
to avoid discussing the internals of the interface class.
Malcolm Betts: The ITU has
defined a set of parameters that make the WDM networks interwork. If you take
those parameters separately it can be risky, while having all of them into an
interface class is for sure more powerful.
Lou Berger: Looking forward
to seeing the follow-up (proposals) on the list.
> 16 9:35 8
> Title: A framework for Management and Control
of G.698.2 optical
interface parameters
> Draft:
http://tools.ietf.org/html/draft-kunze-g-698-2-management-control-framework-02
> Presenter: Ruediger Kunze
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-19.pdf
Malcolm Betts: This doc is
addressing a very important area but I have a major concern. There is confusion
on what is internal to the black link and what is external. A further problem
(an ITU-T problem) in Q6 they talk about SNR reference point, when you talk
about G.698.2 you talk about that. It is not clear what interface we are
talking about. I can help clarify these points.
Eve Varma: I have some
similar comments. Malcolm and I sat in the same meetings, Q.12, how you model
black link. The discussion re: inside/outside comes up. When you have
application codes, supported at certain wavelengths, when you talk about
support you treat the black link as media, it’s a fixed entity. This confuses
how you set something up (as an operator) as a black link. You need to consider
how and what you setup, including application codes. Then the questions will
not arise like how to use GMPLS UNI, say with black link.
Ruediger Kunze: (Secretary
Missed Response)
Malcolm Betts: maybe we need
more work to better define the interface. What is strictly in a black link now,
we have a G709 OMS (multi-wavelength), by selecting the transmitter I can
determine where to exit the black link. I hope you not trying to configure the
internals of a black link Deborah Brungard: It is a good discussion I suggest
to continue it on with Malcolm and Eve on the list. I see there are still
inconsistencies with ITU language and Recommendations and still need refining.
> 17 9:43 7
> Title: A SNMP MIB to manage black-link
optical interface
parameters of DWDM
applications
> Draft:
http://tools.ietf.org/html/draft-galimbe-kunze-g-698-2-snmp-mib-02
> Presenter: Gabriele
Galimberti
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-20.pdf
Malcolm Betts: same comment,
it would be useful to encode ITU interface types, it would be for consistency
for compatible interfaces. As up to now all of them are treated separately. The
other comments I would like to make is there is much about how you structure
the MIB rather than what parameters are needed. This is not a simple extension
of the MIB. We would also like to synch information elements. So we have
protocol independent MIB that can be used for both (SNMP/LMP).
Gabriele Galimberti: Yes
this is something we need to address.
Eve Varma: I have some
sympathy in looking at protocol independent extensions, a homogeneous semantics
also with different encodings being used. IEEE has not defined yet what the
next bit rates are, when IEEE decides the bit rate and ITU accepts it we can go
on the work.
Gabriele Galimberti: Yes, this is the next step and we will react
accordingly.
Manuel Paul: On the protocol
agnostic definition, the priority was extending LMP, it's just a matter of
prioritization.
Deborah Brungard: The
original version is not really related. It is important to look at the issue of
what is in and outside the black link.
If you are within the black
link (WSON for instance) it is not relevant.
Lou Berger: A few comments:
make sure the work is not too far ahead of data
plane definitions; when looking at generalizing function, please look at
more generic MIB definitions too; finally, we need to coordinate with OPSWG on
where the MIB work would be done.
> 18 9:50 9
> Title: Framework for GMPLS and PCE Control of
Spectrum Switched
Optical Networks
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-sson-framework-00
> Presenter:
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-21.pdf
Lou Berger: We have ten
minutes scheduled at the end of the draft presentations to discuss. One question
is, is this work a different switching technology or another aspect of WSON. We
do not want to answer this now, consider it for the time we allocated for
discussion.
Igor Bryskin: Are you going
to consider non-contiguous aspect. Is it worth considering non-contiguous
(2-4-6-8)? In theory it would be provide flexibility. I think it’s a question
for the WG. So should this be a requirement (contiguous versus non-contiguous)?
Malcolm Betts: I think we
should be focusing on the single contiguous slot. How a signal is used over a
media path is independent on the media path. If you choose to use multiple
carriers for a signal it is independent on the media path. We should just
consider the media path.
Lou Berger: As is the case,
we do not define data plane, we follow ITU in the case of the WSON data plane.
If the WSON data plane allows it, then we should allow control of it, if it
doesn't we shouldn't define CP support.
> 19 9:59 9
> Title: Framework for GMPLS Control of Flexible Grid
Network
> Draft:
http://tools.ietf.org/html/draft-wang-ccamp-gmpls-flexigrid-framework-01
> Presenter: Qilei Wang
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-22.pdf
[No time left in slot,
discussion will continue in the general discussion agenda slot]
> 20 10:08 9
> Title: A Framework for control of Flex Grid
Networks
> Draft:
http://tools.ietf.org/html/draft-syed-ccamp-flexgrid-framework-ext-00
> Presenter: Rajan Rao
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-23.pdf
Deborah Brungard: We do not
need multiple framework documents. We encourage authors to work together.
Please align with ITU-T language.
Lou Berger: These comments
are applicable to all three (framework) documents.
Eve Varma: It would be good
to stay in line what is defined in ITU, it seems the super channel is a sort of
inverse muxing of spectrum portions and it is not aligned with actual ITU-T
work.
Malcolm Bets: I echo Eve’s
concern, Re: fixed slot (Q.6/Q.12) neither has looked at virtual concatenation,
we (
> 21 10:17 10
> Title: Requirements for Guard Bards in Spectrum
Switched Optical
Networks and GMPLS OSPF-TE
Extensions in support of Flexible Grid in DWDM Networks
> Draft:
http://tools.ietf.org/html/draft-cbcs-ccamp-sson-guard-bands-reqs-00
> http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-ospf-ext-01
> Presenter: Daniele
Ceccarelli
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-24.pdf
Malcolm Betts: I think it is
very important to consider Guard Bands, although I think it will take time to get
feedback from Q6. If we take a step back and say we are trying to setup
pre-qualified paths, with modulation a, to modulation b, I think it is useful
to have encoding for the optical path (say 100ghz) which is the Guard Band.
Daniele Ceccarelli: Do you
want explicit?
Malcolm Betts: I am favor of
an explicit guard band.
> 22 10:27 10
> Title: OSPF Extensions for Routing Constraint
Encoding in
Flexible-Grid Networks and
OSPF extensions for support wavelength range allocation in flexible grid
supported network
> Draft:
http://tools.ietf.org/html/draft-wangl-ccamp-ospf-ext-constraint-flexi-grid-01
>
http://tools.ietf.org/html/draft-wang-ccamp-flexigrid-wavelength-range-ospf-00
> Presenter: Qilei Wang
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-25.pdf
Igor Bryskin: Slide 3 is
missing you have to take into account switch asymmetry and that a channel could
be co-routed. Optical switches may be asymmetrical and co-routed. From the
optical impairments point of view they should have equal conditions.
Xian Zhang: How do you
insure the consistency of label usage in signaling and routing?
Lou Berger: Remember that
we're still early in the process and still have multiple approaches, once we
have WG documents we will need to ensure a consistent approach.
Deborah: In the interest of
time, let's move these questions to the list.
> 23 10:37 8
> Title: OSPF-TE extension to support GMPLS for
Flex Grid
> Draft:
http://tools.ietf.org/html/draft-dhillon-ccamp-super-channel-ospfte-ext-02
>
http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param-ospfte-00
> Presenter: Rajan Rao/
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-26.pdf
[No Questions]
> 24 10:45 7
> Title: Super-Channel Assignment on Flexible Grid
Label and Signaling
> Draft:
http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-03
>
http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-param-sig-00
> Presenter:
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-27.pdf
Lou Berger: It would be
useful to hear from the ITU re: Super Channel status? This would help guide us.
Unknown Speaker: Why not
reuse VCAT mechanisms rather than defining something new
Lou Berger: This is where
understanding how the ITU-T is modeling the data plane could help us determine
how to define control. If there is a
specific solution for the data plane, we will need to follow it, if not then we
can debate here.
> 25 10:52 8
> Title: RSVP-TE Signaling Extensions in support
of Flexible Grid
> Draft:
http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-rsvp-te-ext-01
> Presenter:
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-28.pdf
Rajan Rao: on the m
parameter, in the future when we'll have optical conversion it could be useful
to have them in the label.
Rajan Rao: No.
Fatai:
Lou Berger: keep in mind
there is also the AD SPEC that changes hop by hop
> 26 11:00 10
> Title: LMP extensions for link grid property
correlation
> Draft: http://tools.ietf.org/html/draft-li-ccamp-grid-property-lmp-01
> Presenter: Fei Zhang
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-29.pdf
[No Questions]
> 27 11:10 10
> Title: Discussion & next steps on Flexible
Grid
Lou Berger: Is this an
extension to WSON, or a new method of switching?
There are different
positions, some drafts say it is an extension of WSON, other define it as a different
switching capability, others make a sort of combination calling it SSON. Keep
in mind we need to start bringing documents together, there are too many of
them. We're not going to bring all these documents to WG.
Igor Bryskin: To answer your
question, no to all your suggestions. It would be useful to introduce generic
channel, it may not be bound to existing data plane. A use case would be flexi
grid, but there other scenarios.
Lou Berger: This would be
separate from existing WSON work.
Igor Bryskin: Yes. A second
comment on Guard Bands, why do we need to have explicit Guard Bands and not
simply allocate a wider chunk of spectrum? A PCE-P extension asking for
considering a wider chunk of spectrum should be enough without anything to
signal.
Daniele Ceccarelli: If Band
Guards are implicit there is a risk to allocate them twice instead of being
able to share them between adjacent channels.
Malcolm Betts: Let me start
with disagreeing with everything Igor mentioned. So going back to your (Lou)
question, on one hand its WSON, with tweaking its not. We need more
investigation to understand if we need an extension to WSON and my current
feeling is it should be based on an extension (to WSON).
Lou Berger: One way to think
about it: can we carry the new/needed information in the existing messages? If
so it is the same technology. The other thing to keep in mind is that a link
can be carrying fixed grid and flexi grid applications at the same time. Would
it be a hybrid node or same switching technology?
Malcolm Betts: agree.
Talking about guard bands, many presentations (this in particular) deal with
impairments, it would be necessary to speed up the definition of extensions for
impairments so to provide a PCE running a proprietary algorithm with the
parameters needed for GB computation. Another reason for keeping them explicit
is that if you go and perform the computation of how big it is going to be you
get the answer “it depends” and depending on which company you ask the reply is
a long list of parameters, so I think explicit guard bands are the correct way
to address them but I don’t foresee in the immediate future a common way of
computing them.
Pierre Peloso: Answering the
question whether flexi grid is WSON or not, my answer is WSON is a subset of
flexi grid.
Eve Varma: A general comment
that echoed the one made by Adrian Farrel. I just get the sense that we should
walk before we run. Starting with the label and the moving to signaling,
routing and so on is reasonable. We need to be careful not to jump ahead with
architecture/extensions that assumed and not actually agreed. In the interest
of focusing effort and maximizing impact, it would be better to have smaller
number of focused set of drafts.
Ramon Casellas: in order to
make docs converge we need to solve the issue: is flexi grid an extension of
WSON, the label structure and also if contiguous and non contiguous spectrum
portions must be managed or not. On the switching capability I would stay with
LSC also for flexigrid. A question that is not clear to me is: do we need to
reuse what has been done for WSON? Is this work backward compatible?
Igor Bryskin: Re: WSON/Flexi
grid. There are control planes in the WDM layer that are not WSON based. I do
not care much about WSON but I do care about flexigrid so I do care that the
work is independent. Another comment consist on the fact that multi-channel is
a very powerful concept in my opinion.
Lou Berger: So far we have
heard there is a lot of interest, some think we need to be high level, others
suggest we need detail to support the high-level.
OTNv1
have different switching capabilities but are not different things.
Yu Wang??? - I am concerned
about the range of the flexi grid topic. It covers single and multi carrier
technology, our focus is on single carrier and the ITU has not provided a
detail description of multi carrier technology. My feeling is we should cover
both single and multi carrier not to throw away what we do in the single
carrier technology once we will be dealing with the multicarrier one.
Oscar Gonzalez de Dios: You
mentioned the possibility of combining WSON and SSON. Let’s say the carriers
are investing in WSON, then the only way forward is define the SSON as an evolution of WSON and allow
the coexistence of fixed and flexi channels, maybe this needs to be takes into
account in ITU first. Both in the case of WSON and SSON what is switched is a
portion of the spectrum, I don’t care what is inside, so SSON should be
evolutionary.
George Swallow: This
technology is being developed rapidly and there is a lot of proprietary stuff
going on. It would be difficult to do anything more than a general attack. The
question is can we reuse existing objects (or not)? The answer is "of
course".
Malcolm Bets: two quick
comments: when we talk about WSON and SSON we talk about managing frequency
slots, we don’t care what’s going over that slots. We should keep the
multicarrier issue off the table.
Lou Berger: It would be
great to have the requirements and framework documents authors work together to
see what they agree and don’t agree on and come with a single document
including agreements and non agreements.
> 28 11:20 10
> Title: Discussion & next steps on Charter
> Draft:
> Presenter:
Slides: http://tools.ietf.org/agenda/83/slides/slides-83-ccamp-30.pdf
Chairs: Out of time but an
important topic, will take discussion to list.
> Adjourn 11:30
>
Lou Berger: Just introducing
the problem and continuing on the list. The main point is that some goals and
milestones need an update but there is no need to re-charter. We’re not closing
the WG in November 2012 and we don’t know when it will happen. There is a lot
to do and there are a bunch items we have identified in the past that we should
work on, some of them derived from the –TP requirements, the flexi grid
discussion, and some other areas. If you have a candidate work area that is not
in the listed slides, post it on the list.