IETF-75 CCAMP Working Group Minutes
Tuesday, July 28, 2009.
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
<![if !supportLists]>- <![endif]>No comments on agenda
1. WG status, RFCs, drafts, milestones, charter, errata
<![endif]>Any CCAMP work that uses BNF to
define message formats for RSVP will need to reference
<![if !supportLists]>- <![endif]>The document ccamp-gmpls-vcat-lcas has expired. If this is ready for WG last Call it will need to be refreshed.
<![if !supportLists]>- <![endif]>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
<![if !supportLists]>- <![endif]>MPLS TP Meeting (Slide 11): PWE wire is part of MPLS-TP, out of scope for CCAMP.
<![if !supportLists]>- <![endif]>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.
<![if !supportLists]>- <![endif]>Q.11/15 update to G.709 (100g support) expected at the October ITU-T meeting in Geneva
<![if !supportLists]>- <![endif]>Q.12 & Q.14/15 WSON, G.7713 new updates will be consented also at the meeting
<![if !supportLists]>- <![endif]>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
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
10b.† RWA Information Model for WSON
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
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
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
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.