CCAMP Session 1
9 November 2010 (0900-1130)

CCAMP Administrivia

- We have a full agenda; presenters are asked to stick to the time allotted.
- At IETF 79 we have a total of 36 presentations across two sessions.
- Typically we have provided slots to anyone that requested one. This may need to be reviewed based on the increase in the number of requests. Comments are requested on the list. 

 CCAMP WG Status

- Please see the slides for CCAMP status updates.

draft-ietf-ccamp-lmp-behavior-negotiation-01
Presenter was Dan Li

Lou Berger: a couple technical comments. [Slide backwards compatibility] In this document you cannot define how current nodes operate using RFC 2119 language. This is because current nodes will not follow this document.
Dan Li: ok.
Lou Berger: just be careful on using RFC2119 language. You cannot dictate how non-conforming nodes will perform.
Dan Li: our intention is to define new behaviour.
Lou Berger: also you do not describe non-config objects, it's implied but not described. It's not clear why you're bringing this up as a compatibility issue.
Dan Li: multiple config objects is not explicitly stated in RFC4204.
Lou Berger: it's a good topic to discuss it's just not clear how existing nodes will handle this. We need to highlight this as an operational issue rather than a specification issue. Also did I previously ask you if you have considered BGP capability encoding?
Dan Li: I did consider this.
Lou Berger:  just for reference, BGP in RFC3392 can negotiate capabilities and provide variable length parameters. So if you wanted to negotiate capability and provide additional information you could use this mechanism. I'm not advocating one solution or another I just asking you to consider these mechanisms.
Julien Meuric: you mentioned there was a hole regarding multiple config methods/objects. Do you have some ideas regarding how to solve this issue?
Lou Berger: I'm just stating that you can't dictate requirements for  nodes that already exist in this document.
Julien Meuric: so it's more the language rather than the solution?
Lou Berger: that's right. We don't know if existing nodes (in the field) are capable of handling new capabilities described.
Richard Graveman: I think that the security consideration should at least point to the LMP document that points to things deprecated. So I'm not saying this document should fix this problem but it should state that the problem exists and may already be resolved.
Dan Li: this has been stated on the mailing list.

draft-ietf-ccamp-oam-configuration-fwk-04
Presenter was Attila Takacs

Deborah Brungard: did you align with ongoing MPLS-TP work?
Lou Berger: in terms of multiple documents, just focus on getting content correct. Cover MPLS-TP, but consider the wider scope within the framework and we can always break the document apart later.
Attila Takacs: I will confirm that all of the MPLS-TP requirements are covered.
Loa Andersson: I have not read version four, does this new document add any requirements on the other three documents?
Attila Takacs: I added a high-level description.
Loa Andersson: so we can split content into separate documents.
Lou Berger: as a follow-up, the same problem will exist when we cover the MIB requirements coming from MPLS-TP.

draft-takacs-ccamp-asymm-bw-bidir-lsps-bis-00
Presenter was Attila Takacs

Deborah Brungard: Note, document was already accepted as WG document at last IETF.  Did you address the errata?
Attila Takacs: yes.
Deborah Brungard: okay the working group should be reviewing the document and we will last call soon.
Lou Berger: just for clarification, associated bidir is out of scope for this document.

draft-ietf-ccamp-gmpls-g709-framework-03
Presenter was Fatai Zhang

Biao Li: I think this document addresses multistage multiplexing requirements. How capability will be discovered, how OSPF will handle this, how signalling will address this?
Fatai Zhang: in the framework document we do have text to address multistage multiplexing. That shall solution including OSPF and signaling, is not complete.
Biao Li: I think the requirements are not complete. There are more requirements that need to be defined in this document.
Fatai Zhang: please provide information to we can discuss additional requirements.
Deborah Brungard: definitely, if you have recommendations to refine requirements and please provide them.
Lou Berger: this is another example where language plays an important role. This document should be discussing what information should be propagated, not how information should be propagated.
Eve Varma: just a comment. I would like to reinforce Deborah's comments on the mailing list. G709 is silent in terms of equipment approaches and implementations.
Deborah Brungard: yes thank you Eve. We only define functionality not the equipment capabilities.
Lou Berger: yes. Of course this makes your job harder as the specification need to be flexible and does not restrict different capabilities. Have you considered how to manage change, on the data plane, and how to track that in the framework document? We have functionality that we are trying to standardise for the control plane but the functionality keeps changing.
Fatai Zhang: yes we are monitoring ITU progress, and update the framework document accordingly. Especially on the data plane technologies.
Lou Berger: well we need to consider that this document may never stabilise, until the data plane specification stabilises. This is an evolving process, perhaps we need to consider a way of managing and separating this.
Eve Varma: no.
Lou Berger: I'm not saying that this is the right thing to do; it’s a question we should consider. Otherwise this work will be gated.
Xihua Fu: based on the liaison this document should provide requirements and solution as soon as possible.
Lou Berger: so you endorsing a base document, and a separate document for evolving items?
Xihua Fu: the framework document should define requirements. A separate document should be useful solutions for multistage multiplexing.  
Eve Varma: for clarification the G709 (2009 version) is quite stable it includes ODU flex. The hitless resize application is targeted for consent in February (2010). So the topic under discussion is related to how the control and management plane interact, when your performing a resize operation. The data plane aspects, for the resize, is really stabilizing and will be completed by February.
Lou Berger: this is good information. I do not think we've had a liaison with a workplan for G709. If the data plane is stable and the specifications are stable in February then there is no reason to perform split. However if we meet again at the next IETF (March 2010) and there is continuing work in the data plane we may have to rethink this. This is not a specific chair requests this is something I would ask you to consider as a document and process management issue.
Fatai Zhang: yes we need to check progress data plane technologies.
Malcolm Betts: the workplan was liaised from SG 15 to various working groups including CCAMP. This will tell you the status of the work. There is also no new plan for G709, so the work is stable. The part under consideration is hitless resize. So if you're considering a pragmatic cut and run, cut off hitless resizing and continue with the rest of G709. I'm not advocating this should be done, just stating that this might be an appropriate point.
Lou Berger: right. That’s what I was implying.
Deborah Brungard: yes. We simply wanted to make sure that we weren’t going to be waiting too long.
Eve Varma: it's very important to consider hitless resize as it does have impact on calculations and trib slots. So my recommendation is to keep this work together.

draft-bccg-ccamp-otn-g709-info-model-02 to
Presenter was Daniele Ceccarelli

draft-zhang-ccamp-gmpls-evolving-g709-06

Xihua Fu: [slide 6] this depends on the network planning. The PCE can define where multi-stage multiplexing should occur. This draft does not provide a solution.
Daniele Ceccarelli: we analyse the problem and the draft provides an informational model.
Xihua Fu: so you need two drafts, this document and a protocol solution.
Daniele Ceccarelli: I believe capability is something that needs to be advertised not signaled.
Rajan Rao: it’s still not clear what does not work currently? What is the use of a termination switching flag? What is being advertised, via routing, for the ODU 0 connections [slide 6]?
Daniele Ceccarelli: we are saying that we advertise if an interface is capable of terminating or switching ODU containers being advertised.
Rajan Rao: it's still not clear what OTN service is not supported without this information. When you set up the ODU1 LSP it implied that one or more ODU are being terminated. There is no explicit indication required.
Danielle: in this example [slide 6] the load need to understand if the second level of multiplexing is capable or not.
Rajan Rao: it would simplify routing if you hide this information. All you need to know is if ODU1 can be set up from node A to E. Regardless of which mux layer it uses along the way.
Lou Berger: if the document describes required function. Then we need agreements on the requirements. Right now we are hearing feedback on mechanisms.
Deborah Brungard: as Lou mentioned you need to consider the requirements more not the solution.
Jon Sadler: Is the purpose of the TNS bits?
Daniele Ceccarelli: Not only bundle link.
Jon Sadler: is the purpose of TNS bits to remove ambiguity on the G-Z link if G-Z link? The intent is to show what can be used across the interior?
Daniele Ceccarelli: exactly.
Rajan Rao: the purpose of the draft is confusing; it's duplicating what’s in the framework document? The only new thing I see is terminating and switching capability.
Daniele Ceccarelli: the framework document defines that terminating capability must be known.
Rajan Rao: I do not think the framework document discusses that capability.
Lou Berger: since this is describing functionality we should see how much of this document and information can be moved into the framework document. The solution parts can be moved into the solutions document.
Cyril Margaria: you indicate in the framework that the tributary port information, in a label, is used to configure the data plane correctly.
Daniele Ceccarelli: in the information model, it needs to be considered.
Biao Li: certain vendor equipment may have different capability; you need information to advertise if you can only terminate a certain ODU. This is not included in this document.
Daniele Ceccarelli: that is not in scope of this document. The OSPF draft needs to be updated.
Biao Li: the solution should discuss multistage multiplexing.
Daniele Ceccarelli: yes.
Lou Berger: it should also be covered in the framework.
Dmitri Papadimitriou: why do you not call this an evaluation document? Your evaluating capabilities against what exists? You should look all the mechanisms defined and see if anything could be used and generalized.
Lou Berger: yes I think there is agreement that the will take existing solutions and see if there's anything can be reused.

draft-bccg-ccamp-otn-g709-info-model-02
Presenter was Fatai Zhang

Xihua Fu: please clarify how RFC4206 support multistage multiplexing.
Fatai Zhang: we know we need to create ODU connection. We know RFC4206 may have something missing. We need to follow a general solution.
Xihua Fu:  how could you determine which ODU tunnel should be used.
Fatai Zhang: you can put this kind of information in the signaling.
Xihua Fu: we should carry multi-stage, hierarchy, information.  
Fatai Zhang: that solution is not defined in this draft.
Lou Berger: please discuss more on the list.
Julien Meuric: regarding TPN question. It seems a check value in the data plane. It’s not a requirement. What the meaning of this field, where it should be used. Please elaborate.
Lou Berger: You may want to look at egress label control RFC4003.
Biao Li: ODU 0 is visible. We just look at this example, node C can support it. Do you want to setup FA.
Fatai Zhang: FA already supported.
Biao Li: You need FA to be supported. My question is does it mandate FA to support multistage/multiplexing.
Eve Varma: I wanted to clarify TPN, when you mentioned endpoints, it should relate to link endpoints.
Lou Berger: Then the comment on egress label control RFC4003 probably doesn’t apply

draft-bccdg-ccamp-gmpls-ospf-agnostic-00
Presenter is Daniele Ceccarelli

Lou Berger: I did ask you offline, we have two directions. 1) Build on work from before, or do as you suggest. 2) Throw out and start again. We need examples so we can make a decision. In order of magnitude, 140 bytes, versus 14-20 bytes, this is control plane data. Is that such a big deal for the networks, with existing RFCs?
Daniele Ceccarelli: my personal stand-point. For 100 bytes, per link basis. My initial reaction is no.
Rajan Rao: it’s still not clear to us. What is not in RFC4202 that this trying to address?
Lou Berger: this is trying to optimize the case when there are not many priorities. If you believe you will have a small number of priorities this is an attempt to optimise the case.
Daniele Ceccarelli: a lot of different containers. This could be summarised together into a single LSA/TLV.
Deborah Brungard: we need more comparison with the existing approach and what are the savings? How many priorities do operators have? From operators perspective this will introduce additional complexity, what are the real savings?
Rajan Rao: what is the implication the new routers which method but they support?
Daniele Ceccarelli: you can advertise different types of bandwidth.
Rajan Rao: that's clear, but what is the expectation of existing routers. You're calling it technology agnostic, but it's new and impacts existing routers.
Daniele Ceccarelli: we need to decide if this is necessary.
Lou Berger: yes we need to evaluate and discuss.
Lyndon Ong: in support of Daniele the technology agnostic aspect was a request. We also had a couple of proposals about technology agnostic extensions. It's not just about priority; there are other factors of the advertisement for OTN. Getting agreement on requirements is a good first step.7

draft-ceccarelli-ccamp-gmpls-ospf-g709-04
Presenter is Daniele Ceccarelli

No comments.

draft-ashok-ccamp-gmpls-ospf-g709-00
Presenter is Rajan Rao

Daniele Ceccarelli: your latest version solves some problems identified on the list.
Rajan Rao: backwards compatibility [slide 1]. ST knows what the ODU that can be carried is. There are examples in the slides.
Jon Sadler: [slide 7] is ODU5 correct I think it 80?
Rajan Rao: its 82, because…[missed comments].
Lou Berger: this sounds like a good discussion for the list. From the chair perspective, which requirements and way to optimize is an open question for the WG.

draft-zhang-ccamp-gmpls-h-lsp-mln-02
Presenter is Fatai Zhang

Dmitri Papadimitriou: this capability already exists. What is the benefit of having node A [Open discussion multi-carrier]?
Lou Berger: please answer question on the list. Same for Jonathon.

draft-fuxh-ccamp-boundary-explicit-control-ext-01
Presenter is Fatai Zhang.

No comments.   

draft-wang-ccamp-latency-te-metric-01
Presenter is Xihua Fu

Dave McDysan: people should read this draft. The composite links document defines requirements, this is a potential solution.
Deborah Brungard: I think this work is important but it needs further identification of requirements.
Lou Berger: when you consider solutions consider IntServ as it already has semantics for latency.

draft-khuzema-ccamp-gmpls-signaling-g709-00.txt
Presenter is Rajan Rao

No comments.

draft-zhang-ccamp-srlg-fa-configuration-01
Presenter is Oscar Gonzalez de Dios

Lou Berger: From a WG standpoint, this flag space is scarce. Please update the document as the mechanisms you are currently using will not go forward within the WG.
Oscar Gonzalez de Dios: ok.
Xihua Fu: [Daniel King: I did not hear the question]
Lou Berber: please send question to the list.

draft-malis-ccamp-rfc5787bis-01
Presenter is Acee Lindem

Lou Berger: traditionally we keep original authors on the document, unless they want to be removed. We can talk further offline. Also on the last slide. Can you elaborate on RFC4652 comment?
Deborah Brungard: regarding at the last meeting that you said you would check with the ITU on the capability which you removed, is there any feedback from the ITU on this?
Lyndon Ong: we did look at RFC4258 to see if there was anything we were removing from the requirements. We could not find anything. I did not get any comments back from the ITU that anything was missing.
Deborah Brungard: The difficulty is that it was highlighted in several ITU liaisons. So they previously saw this as a key capability.
Acee Lindem: that refers to recovery, not this discovery mechanism? There's nothing that mentions you need more than one router/RC advertising information between levels in an ASON hierarchy.
Lou Berger: this refers to discovery.
Acee Lindem: that was broken that's why it was removed.
Deborah Brungard: we need to understand why you are removing this capability at this time.
Lou Berger: it's fine to change it. If it's broken feel free to ask ITU to send a liaison removing the requirement. Currently it is our understanding that this discovery capability is a requirement.
Acee Lindem: I would like to see this specific requirement.
Lou Berger: sure, let’s take this off list. If we receive a liaison removing the requirement then we can remove it.

CCAMP Session 2
12 November 2010 (1300-1500)

Administrivia

- WSON switched to second CCAMP day due to OTN/G709 drafts.
- Link to agenda and slides is a little unstable from the IETF agenda page. Use the CCAMP tools link to the agenda.
- Pierre Peloso was unable to attend. Someone else will present his topic. [
draft-peloso-ccamp-wson-ospf-oeo-01]

draft-ietf-ccamp-wson-impairments-04
Presenter was Young Lee

Lou Berger: can you clarify the first two bullets. You believe you have completed the document and it’s ready for last call?
Young Lee: yes.
Lou Berger: how many people think it’s ready to move forward?
[About the same number as who have read it.]  Does anyone have any reservations?  [No]
Jon Sadler: useful to send a Liaison to ITU notifying of last call.
Lou Berger: agree a useful thing to do as part of the last call.

draft-ietf-ccamp-rwa-info-09
Presenter was
Greg Bernstein

Deborah Brungard: how many have read the document?
Lou Berger: this document represents what is being done in the solutions document. There was a discussion on waiting on the LC to wait on the solutions document, do that as a set.
Giovanni Martinelli: first comment, is on the same line of Lou’s comment.  The second comment, regarding BNF, to represent information. The same BNF represented in the encoding draft. Is it worth having two BNF definitions for the same thing?
Greg Bernstein: we can take that question offline. I'm happy to do it either way.
Lou Berger: it’s good to define in just one place and just to refer to it.

draft-ietf-ccamp-rwa-wson-encode-06
Presenter was
Greg Bernstein

No comments.

draft-ietf-ccamp-general-constraint-encode-03
Presenter was
Greg Bernstein

Young Lee: the only pending issue is the WSON specific encoding. The generic encoding is stable.
Lou Berger: Greg got it right when he said these documents were. As a general principle, these documents feed the other ones. We propose to move these document’s forward as a set.

draft-ietf-ccamp-wson-signaling-00
Presenter: Giovanni Martinelli

Greg Bernstein: on wavelength items we will try to go with something general.
Lou Berger: that’s good we do not restrict which algorithms we use. [Chair hat off] Bidir is not supported or described. You also need to justify why you need an additional mechanism for symmetric allocation. Crankback may be good enough, just document what’s available and why there are issues.

draft-ietf-ccamp-wson-signal-compatibility-ospf-02
Presenter was
Young Lee

Lou Berger: [With regard to the mailing list discussion and other draft,] certainly if holes exist, or have been raised, we should fill them. If you think we can merge great, if not lets discuss on the list.
Greg Bernstein: we have had discussions. There is not a strong reason to change things, or what is being asked. We will try to tie this up on the list soon.
Lou Berger: discussions are good, we would like to see this resolved. How many read the document?
[A small number, similar to the number discussing the issues on the list.]

draft-bernstein-wson-impairment-info-03
Presenter was
Giovanni Martinelli

Deborah Brungard: if we polled how many read, I suspect it will be a similar number. Any other comments?
Greg Bernstein: helpful with update to G.697, some other things we had assumed was a nice way to encode, was included in the update. This allowed us to reference their document.
Greg Bernstein: we encourage people to work with us on this.

draft-peloso-ccamp-wson-ospf-oeo-01
Presenter was
Giovanni Martinelli on behalf of Pierre Peloso

Igor Bryskin: what happens when the TLV becomes too large? It’s not just this draft, its other WSON work as well. I see a lot of drafts. Have you considered how much info can fit into a TLV?
Lou Berger: comments also apply to other OSPF documents.
Igor Bryskin: I would suggest not making the top level TLV to large. Do not put everything in the top level TLV.
Giovanni Martinelli
: in this case we add a new top level TLV, carrying additional information. T do not know what the final WSON solution will be.
Young Lee: let me try to elaborate. To represent OEO's elements, we agreed what node information needs to be propagated. Now you're bringing internal links, SLG< TE metric, admin group. Also do you still have identifies?
Giovanni Martinelli: yes.
Young Lee: if we need represent a link and if we need to advertise externally, PCE, is this legitimate? If the WG says this info is needed then we can address sit. Also as Igor says, do we really need another top level TLV. We also soon there is no ODU switching. This was based on current WSON scope. Once we agree, we can merge.
Giovanni Martinelli: the idea was to represent some property of OEO pools.
Igor Bryskin: this is a big problem. Let's take connectivity matrix, it could be huge. If you put this in the top level link TLV, it may not fit in one LSA.
Giovanni Martinelli: there is no disagreement.  
Igor Bryskin: we should provide a mechanism that is outside top level link TLV.
Acee Lindem: theoretical maximum (64k) flooding works a lot better if it fits in an MTU without having to fragment.
Young Lee: use existing opaque LSAs. We still need to answer if dissemination of internal link information is required.
Lou Berger: we have multiple points, Acee and Igor make a scaling point and this applies to all WSON OSPF documents.
Young Lee: we can discuss.
Lou Berger: I think we need a specific section on LSA scalability. The second is a requirement. Does the framework documents cover your [Giovanni Martinelli] requirements?
Giovanni Martinelli: the framework is good. The informational model is also OK. The encoding document is OK; except they define the sub TLV and suggest which top level TLV will use the sub TLV.
Lou Berger: please make that comment on the list. Also is OEO in the encoding document.
Young Lee: in terms of requirements, framework/information model, do we have OSPF support?
Lou Berger: It seems we’re having a requirements discussion in the context of a solutions document,  please go back to the top level documents and verify your requirements are being covered.  If they aren’t, the make a comment to  the list.  We can then discuss the requirement, and once there is consensus on the requirement we can debate mechanisms.

draft-zhang-ccamp-general-constraints-ospf-ext-00
Presenter was Fatai Zhang

Deborah Brungard: How many have read document? [A good showing] How many think it’s ready for WG document? [A reasonable number] Let’s take it to the list.
Deborah Brungard: I suggest some examples and scaling information.

draft-ietf-ccamp-assoc-info-00
Presenter was
Lou Berger

No comments.

draft-ietf-ccamp-rsvp-resource-sharing-00
Presenter was Francois Le Faucheur

Deborah Brungard: what applications do you have in mind?
Francois Le Faucheur: In telephony, home/office, we make two reservations. I do not want to reserve two amounts of BWs, only one phone will be answered. its only use to tell the receiver to say this is a good value to use.
Deborah Brungard: what about protection or multi-homing?
Francois Le Faucheur: perhaps, but may not be the best way.
Lou Berger: Is there ever a case where the receiver says “no”? [No] Then why not make it sender sharing?
Francois Le Faucheur: in RSVP all the BW allocation is at receiver time., so don’t want to use path state.
Lou Berger: this only happens if you have path state. Let’s talk offline.

draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-01
Presenter was
Fei Zhang

Lou Berger: If no one else has comments, I have some technical comments you discuss three cases. What is the provisioning model in MPLS-TP on associated bidirectional LSP? Here you allow either side to trigger, and then you associate. Do you think this is the right usage model? It's not clear to me that this is the right provisioning model for TP.
Fei Zhang: maybe some equipment doesn't support upstream labels. The solution supports that case.
Julian Meuric: as a reminder RFC3473, makes bi-dir LSPs available in MPLS.  
Lou Berger: That’s for co-routed case. This is the associated case, where paths are difference and such association is required [in MPLS-TP]. We need to discuss what is needed and define a model of operation based on requirements. Would like to see a definition of the provisioning model so that we’re all in agreement on what is to be done before we define how to support the function. Please bring this issue up in the wider MPLS-TP joint session or in mail.

draft-ietf-ccamp-dpm-01
Presenter was
Weiqiang Sun

Deborah Brungard: Poll. [A reasonable number, including the chair of BM WG]
Al Morton: I think you are using the term “availability” to mean something different than is typical.  You may want to choose a different term.
Weiqiang Sun: When we composed the draft. We discussed if this is applicable to other technologies. So I do not agree that availability is not a good term.
Deborah Brungard: The availability gets confused with the in-service usage of availability.
Weiqiang Sun: We borrowed the term from the Adrian/Shiomoto document [switch programming].
Lou Berger: We need to be careful to use their terms carefully. We need to select the right term for this. Please, work with Al.
Adrian Farrel: Author comment [switch programming] If I used the wrong term in my document we should change this and align it.

draft-zhangm-ccamp-metric-00

Presenter was Hui Ding

No comments.

draft-jiyf-ccamp-lsp-00
Presenter was
Weiwei Bian

No comments.

draft-zhangm-ccamp-reroute-00
Presenter was
Lifang Zhang

No Comments.

OIF Communications
Presenter was Lyndon Ong

Rajan Rao: the two clients are shown, are they the same or different clients?
Lyndon Ong: the assumption is they are the same type of clients.
Rajan Rao: there is probably an adaptation function needed when different types are supported.
Lou Berger: I think you want to two levels of feedback from the WG. The first is how to progress the document; please follow the standard WG process. This applies to both the requirements and solution documents. You can modify them and discuss on the list, if there are issues you can discuss them on the list. If no one is working on it the draft it will die. In terms of the technical topics, you seem focused on an ASON UNI, we do have a GMPLS UNI, and we also found we needed to extend that to support MEF requirements, so we now also have a MEF UNI. I would suggest you review the GMPLS and MEF UNIs and if we need an ASON UNI that’s fine.
Lyndon Ong: from an organizational standpoint we had been trying to progress the work, but we have not received a lot of feedback.
Lou Berger: in general the formal OIF Communications will not get you there; it requires WG discussion and participation.
Lou: has anyone read these
drafts [Not many]. Well that gives you the level of interest in this topic.

draft-roch-ccamp-lsp-hier-ason-00
Presenter was Lyndon Ong

draft-roch-ccamp-lsp-hiser-multi-client-00
Presenter was Lyndon Ong