IETF-75 CCAMP Working Group Minutes
Tuesday, July 28,
2009.
0 Administrivia
1 WG status,
RFCs, drafts, milestones, charter, errata
2 ITU-T and OIF
progress report
3 Last call
results Data Channel Status Confirmation Extensions for LMP
4 Last call
results Conversion Between PC and SPC
5 GMPLS LSP
Data Path Delay Metric
6 Association
of GMPLS Recovery LSPs
7a Merged
draft: OTN & G.709 Drafts
7b Merged
draft: OTN & G.709 Drafts
8 Extensions
for OTN and SONET/SDH OAM Configuration
9 RSVP-TE
extensions to GMPLS Calls
10a Framework
for RWA in WSON
10b RWA
Information Model for WSON
10c RWA
Encoding for WSON
11a WSON
Signal Characteristics and NE compatibility
11b Signaling
Extensions for WSON
11c OSPF in
Support of RWA in WSON
11d
Synchronized Signaling for Optical Lightpath Setup
12 Framework
for WSON Impairments
13a
Information Model for Impaired Optical Path Validation
13b
Information Encoding for Impaired Optical Path Validation
13c Optical
Impairment Signaling
- No comments on agenda
1. WG status,
RFCs, drafts, milestones, charter, errata
-
Any CCAMP work that uses BNF to
define message formats for RSVP will need to reference
RFC 5511.
- The document ccamp-gmpls-vcat-lcas has expired. If this is ready for WG last Call it will need to be refreshed.
- The document ccamp-gmpls-oam-requirements will be abandoned. It was suggested at the last meeting that a pointer to this document be sent to the MPLS-TP effort.
Attilla Takacs: Re: OAM requirements, we
looked at them for the MPLS-TP effort. There is some overlap; also some
requirements pertain to the control plane. We do not cover the control plane in
the MPLS-TP OAM requirements.
Lou Berger: Good comment to make.
Final comment from Lou Berger: We need to identify if we will re-charter or close the group. Considerations for re-chartering: MPLS-TP extensions, WSON, OTN, and other ccamp extensions. Comments can be sent to the WG list or to the co-chairs.
2. ITU-T and OIF progress report
- MPLS TP Meeting (Slide 11): PWE wire is part of MPLS-TP, out of scope for CCAMP.
- RFC4873 Errata (slide 12): No one was using the flag bit. Bits are limited in this area. Based on the last WG discussion we opened an erratum and polled the list to deprecate the flag. There was no discussion or objections to suggestion on WG list.
Lou Berger: Are
there any objections to this?
[No objections from audience]
Lou Berger: We will continue with our plan.
ITU-T Q.12
- Q.11/15 update to G.709 (100g support) expected at the October ITU-T meeting in Geneva
- Q.12 & Q.14/15 WSON, G.7713 new updates will be consented also at the meeting
OIF Interop
- OIF completed interop in June 2009: 7 carriers on 3 continents using 11 vendors (RFC 4872 full LSP rerouting was tested)
Ross Callon: Is this OSPF going to be
incompatible with IETF OSPF?
Lyndon Ong: OIF will work to try to get
the updates adopted by the IETF. There will be a draft brought to the IETF to
help fill the gaps the OIF sees in the standard. Any gaps will be brought up by
the liason.
Ross Callon: Are you referring to the draft that has been progressed in CCAMP?
Lyndon Ong: Yes. It's experimental.
[Question to chairs] Is there a reason it was experimental?
Deborah Brungard: We discussed this, we need implementations.
Lyndon Ong: You may have
implementations coming.
Deborah Brungard: Is the intention to bring a draft in with your proposals?
Lyndon Ong: Yes. We would also
appreciate cooperation with anyone interested.
OIF Interop Findings (Slide 6)
Lou Berger: If you think there is a need to
change the protocol, we need a draft.
Dmitri Papadimitriou: If you cannot ensure that the ID is unique. The
allocation is the problem.
Jonathan Sadler: The reason to add the area ID is to get into alignment. It’s
not just node ID alone.
Lou Berger: The same discussion is happening within the MPLS-TP context.
It's possible we could align, but without a draft there is not much to discuss.
David (Unknown): Well this in a section
of a draft that I submitted at IETF 72 and the trouble we had with assigning
unique IDs. When new drafts come up you should see what these drafts address.
You need to dig a little deeper.
Deborah Brungard: We need people to follow the CCAMP process. Bring in a draft
identifying a problem. Nicks last draft was excellent; it clearly stated the
details of the problem.
Lyndon Johnson: As far as uniqueness. It’s the responsibility of the
operator.
Adrian Farrel: Just to respond to David. If you look to setup a path from one
domain to another one, you map at domain borders, that’s how you achieve
uniqueness.
Jonathon Sadler: In the ASON architecture. There is no distinction
between AS and routing Area. The uniqueness issue of node ID is handled
orthogonally. Therefore its needed in all cases.
Malcolm Betts: This is being discussed under MPLS-TP. I hope that CCAMP
and the MPLS WG can discuss this and get a joint solution.
Lou Berger: Certainly it's our intent to get alignment.
Kireeti Kompella: I am confused. The IETF makes a difference between
areas and autonomous systems. I just heard that they are the same thing.
OIF Liaison on Demo Findings
Ross Callon: I have a quick comment that is
motivated by your presentation and Jonathan's earlier comment. This is
important work in the IETF. We need to look hard at the requirements. The IETF
needs to create the right technical solution to solve the problem. We should
consider the ITU architecture but we are not constrained to strictly adhering
to solutions from the ITU, or elsewhere.
Deborah Brungard: If you have requirements, you can bring in a solution.
Julien Meuric: How many carrier
requirements do you have for non IP addressing, like NSAP?
Lyndon Ong: That question would be better addressed to the operators.
3. Last call results Data Channel Status Confirmation Extensions for LMP
Lou Berger: Needs to have a clarification. To use the mechanisms all nodes must have the extension for compatibility. Once this is done we can move it forward.
4. Last call results Conversion Between PC and SPC
Lou Berger: Given the technical changes. We will request a second last call.
5. GMPLS LSP Data Path Delay Metric
Lou Berger: This is an important addition to the DPPM work. Thanks for the contribution, looking forward to seeing comments on the WG list.
6. Association of GMPLS Recovery LSPs
Lou Berger: Please review the details
covered in the presentation and in the document.
Malcolm Betts: On the Administrivia, I suggest that it becomes a WG draft. If
another organizational wants to reference it etc.
Lou Berger: It's an informational draft, that ok?
Malcolm Betts: That’s fine.
Adrian Farrel: Approved by IETF consensus. Not WG consensus.
Dimitri Papadimitriou:
Instead of writing another I-D to document that might lead to
misunderstanding in these two RFCs 4782 and 4873. Can we not just instead go
into these documents and update the text?
7a. Merged draft: OTN & G.709 Drafts
Lou Berger: An old topic made new again. ITU defining new OTN types, extensions needed. WG chairs want one document, but currently two options
Sergio: This is a good point. The signal type is not type. Support for the new functions.
7b. Merged draft: OTN & G.709 Drafts
[No Comments]
8. Extensions for OTN and SONET/SDH OAM Configuration
Deborah Brungard: This is a new draft, please discuss on the list. There is OAM defined for the optical channel. You need to align with ITU on OAM.
9. RSVP-TE extensions to GMPLS Calls
Lou Berger: How many people have read the document?
[Approx five hands raised.]
Lou Berger: Lets discuss on the list.
10a. Framework for RWA in WSON
[No Comments]
10b. RWA Information Model for WSON
[No Comments]
Lou Berger: We need to have more discussion
on the generalized piece.
Greg Bernstein: Yes.
Lou Berger: We should have discussion if we believe there is some use for other
technologies. It cannot be in the WSON document. It's ok if we have to break it
out. We can discuss that in detail offline.
Greg Bernstein: Ok.
11a. WSON Signal Characteristics and NE compatibility
Greg Bernstein: Possible next steps. “Add
optical tributary signal notions”.
Deborah Brungard: We can progress but we cannot get ahead of the ITU.
Greg Bernstein (to WG chairs):
Should we keep this document (on WSON signals and network element
compatibility) separate from the WSON RWA Framework draft, or combine the two
drafts?
Deborah Brungard: For now, let's
keep these separate.
Lou Berger: Where would the WG like to define its scope? There is work that needs to be done to
efficiently carry the information needed. Where do we limit.
Greg Bernstein: Yes.
Pierre Peloso: We have seen during the PCE WG, the
info model creates data for IGP. We are wondering on the OEO description and
how it's inserted in the nodes and used for wavelength availability. We cannot
only rely on PCE. There is work that needs to be done. Julien and I will work
with you and have a way to carry the info efficiently. We need to separate
what's dynamic and what is static.
Greg Bernstein: Yes.
Igor Bryskin: I tried to ask this
question in PCE but was sent to CCAMP. How do you know when you signal the path
to you decide which regenerators and properties to use, instead of just fixed
channel?
Greg Bernstein: So we could have an option where we have more than one type of
generator to use. I mention earlier that we may have parameters to set, but
your saying which one to use from the pool sounds similar. It sounds like it's
more a of configuration requirement. Something like configuration parameters.
We do not have hooks for that just yet.
Igor Bryskin: You need to advertise the resources, like regenerators in an
efficient way. You also need to be able to signal them within the path. [Igor had second question]
Lou Berger: Let's take this discussion to the list.
11b. Signaling Extensions for WSON
[No Comments]
11c. OSPF in Support of RWA in WSON
Pierre Peloso: When you
explain the WSON specific information that needs to be conveyed by OSPF. We
don’t need to say that the only way to achieve a route is to have all the detailed
information. It's not mandatory if you rely on a regular GMPLS implementation.
Lou Berger: What you're asking for is consistent with
other documents but if you want to see specific text please suggest text for
the authors.
11d. Synchronized Signaling for Optical Lightpath Setup
[No comments]
12. Framework for WSON Impairments
Malcolm Betts: With my ITU hat on, we
should scope this draft to linear impairments. We do not know how to
characterize non-linear impairments.
Lou Berger: Let ITU define and refer to reference.
Greg Bernstein: If all we are expected back is a qualified path, or set of
paths, in that sense we do not care if they are linear or non-linear
impairments. Other than that all impairments are linear and taken from the ITU
documents.
Eve Varma: Regarding G.680, you
constrain your scenario where you have linear impairments. You don’t know if you
have a qualified path if you only consider your linear impairments. An open
question is what scenarios do you have? It would be useful to get the scope,
scenarios.
Giovanni Martinelli: One quick comment on linear and non-linear is the
approximation.
Young Lee: We need to hear from Q6
Deborah Brungard: The document is aligned, we will see if we understood the
agreement.
Eve Varma: The parameters are fully aligned. The caution from Q6 is you can use
all of these parameters but it's not sufficient to perform path computation and
know you have a valid path unless you're considering the vendor specific.
13a. Information Model for Impaired Optical Path Validation
[No Comments]
13b. Information Encoding for Impaired Optical Path Validation
Eve Varma: I am sorry to raise this point
again. There really is the implication that you won’t be able to compute valid
paths. The Q.6 discussion was that the non-linear impairments are a big deal,
and you can only use, even with approximations, in constrained scenarios. Are
these scenarios useful to our operator community and check this.
Deborah Brungard: The impairment work is just beginning. The work ongoing is
the first scoped scenario where you don’t have to consider non-linear
impairments. Only at this time are we approaching the second class where we can
approach this as a black link. We are not entering the third scenario. I hope
Greg, et al., maintain this.
Pierre Peloso: First comment, non-linear
impairments have I think a prediction tool that’s half-blind and is not
useful. The second comment, I am not
sure on what you intend to convey? The appendix has a huge amount of parameters,
some of which not even known when you commission a network. What are these
parameters are they there to be exhaustive and there is no intention to use
them later on. Or do you intend to use them? If so, there is so much
information I am not sure if it is compliant with the control plane. What is
intended, four or five parameters?
Deborah Brungard: That’s a good question for the WG list. Please bring it up.
13c. Optical Impairment Signaling
Deborah Brungard: This is a new document. Please send your comments to the list.