CCAMP First Session
Monday, March 22, 2010. 1300-1500 Afternoon Session I

0 - Administrivia

1 - WG status, RFCs, drafts, milestones, charter, errata

Presenter: Chairs

- RFC Editors Queue. A number of documents recently became RFCs (see slides).
- Co-chairs are looking for assistance on draft-ietf-ccamp-gmpls-ted-mib. The document needs to be updated based on the MIB Dr review.
- draft-ietf-ccamp-wson-impairments

Lou Berger
: What's the status of this [
draft-ietf-ccamp-wson-impairments] document?
Greg Bernstein: No updates.

- draft-ietf-ccamp-mpls-tp-control-plane-framework has been published as a WG document.  It is joint work with the PWE WG. The document will be presented in the MPLS-TP joint session as it is joint work..

- Ethernet provider requirements document is going to be abandoned for lack of interest.

Lyndon Ong: A question on MPLS-TP document.  This document is going to be discussed in the MPLS session this meeting? Is it coming back to this group at some point?
Lou Berger: The second MPLS session is  joint work. So it will be discussed in the joint session.

- ITU Liaisons: The co-chairs plan to answer these before the June Plenary.
- Charter updated per last meeting. The new text has been recently posted.

- Thank you to Ross Callon who is moving from the IESG to IAB

- RSVP related discussion to take place in the TSV AREA session

2 - ITU-T and OIF progress report

Presenter: Lyndon Ong

- OIF Status Update. In addition to the notes on the slides there are some active OAM projects as well as security in the control-plan.

Lou Berger: How do you foresee the OIF’s work related to the IETF OAM work?
Lyndon Ong: The OAM work in the OIF is a broad range of possible issues with input from carriers. Feedback for protocol specification could be done here. It will be mainly broader issues, processes and flows. If new work is identified it will be liaised here.
Lou Berger: If you do discover issues and requirements that are not covered with existing work, we would be interested to see them.
Nurit Sprecher: Clarification for G709 extensions for PCE extensions. Is it really PCE extensions or OTN extensions?
Lyndon Ong: I was referring to the new extensions in G709.

- Questions and comments.

Lou Berger: We expect the G709 documents being discussed tomorrow [CCAMP Session 2] will need to address the technical issues raised in the received liaisons.

3 - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)

Presenter: Young Lee

Lou Berger: How many people have looked at this document?
(A very good number)
Lou Berger: Anyone have reservations?
Lou Berger: Any feeling that it’s time to move forward?
(A notable number but not as many who read document)

Lou Berger: Not as many who read the document? Would anyone care to talk about why they feel the document should not move forward?
(No response)
Lou Berger: So I am not seeing any reservations on the document. We should take it to the list for moving document forward. One minor point to the authors. An additional constraint mentioned in a document later today is "Adjacent Lambda Constraints" [
10 - OSPF Link Information Model for OSPF], how do you see this fitting into the framework? Do we need to update the framework, or leave it outside the document?
Young Lee: We would like to see the discussion later today.
Lou Berger: I would like to request an offline or on list discussions as to how that particular constraint should be handled. You need to address it or leave it out, before we last call this document.

4 - Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks

Presenter: Young Lee

- Questions and comments.

Lou Berger: We should complete the generic encoding discussions.
Young Lee: Ok.

5 - Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks

Presenter: Greg Bernstein

- Questions and comments.

Igor Bryskin: Do you plan to address ROADM directionless technology [resources that are available from several links]?
Greg Bernstein: Sounds like this would be an additional constraint.
Igor Bryskin: During discussions with clients we had identified a problem where we had to address how to use protection path computation where it can only be used on one degree or another. It would be nice if your framework and model included this technology.
Lou Berger: Are those transponders being used for client signals or for regen?
Igor Bryskin: It could be a fixed regenerator or tunable, or client transponders.
Lou Berger:
The regenerator pool sounds similar to what you are discussing, but without clients.
Igor Bryskin: The regenerator pools are a separate discussion.
Greg Bernstein: We need diagrams and an email to the list and we can discuss.
Igor Bryskin: Ok. When people discuss colorless, they also mean directionless.

6 - General Network Element Constraint Encoding for GMPLS Controlled Networks

Presenter: Greg Bernstein

- Questions and comments.

Greg Bernstein: Should we expand this to cover other technologies. Right now examples are from WSON.
Lou Berger: I’d like to see how many have read the document.
Lou Berger: Of those that have read this document do you think this is a good direction to be taking? Should we keep this as WSON specific, or widen the applicability. Previously we have tried to generalize control plane technologies.
Igor Bryskin: I believe this is purely WSON. [Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks].

Greg Bernstein: Those parts are in the presented WSON specific draft. 

Igor Bryskin:  I can offer my opinion on General Network Constraints. They may occur in multiple layers, but I still say this is WSON specific.

Young Lee: I agree with Igor [Bryskin], but also the direction was initiated by [CCAMP] WG chairs. Certain things only apply to WSON so I prefer to stay on this direction.
Lou Berger: Sorry, which direction? Keep the document with the generic encoding, or go back to WSON specific encoding.
Young Lee: Some can be applied to other technologies, but when we say WSON specific, we mean resource level, regen, compatibility which may not be applied to other technologies.
Lou Berger: So you support the current technology breakout.

Young Lee: Yes.

Lou Berger: I think it would be worthwhile if we had other technology examples. If anyone has a technology that they would like to see applied would they be interested in contributing to this work?
(No takers)
Lou Berger: We have some support for both directions. The chairs and authors need to discuss this.
Igor Bryskin: When discussing WSON. When we discuss how to build cross-connects these have to be expressed in terms of lambdas. All other technologies may be a very different thing. Our experience in binding lambdas together is different from say multiple Ethernet links.

7 - OSPF Enhancement for Signal and Network Element Compatibility for WSON

Presenter: Greg Bernstein

- Questions and comments.

Lou Berger: It's worth reducing the number of independent drafts and try to match them to other work. It would be very beneficial to combine drafts wherever possible rather than have many drafts, none of which standalone.  We will need to resolve disconnects and overlaps [adjacency constraints] this does not change the high level objective or merge of the drafts as much as possible.

8 - Signaling Extensions for Wavelength Switched Optical Networks

Presenter: Greg Bernstein

- Questions and comments.

Igor Bryskin: [Signal Attributes Slide] What do you gain by signaling this information? This information needs to be considered during routing and traffic engineering. If a node doesn't like its FEC type or signal type it rejects. What can you do next? You will have to constrain your path computation and exclude this specific node. My point is this is needed in the routing but not the signaling.
Greg Bernstein: Yes, but what happens when your configuring equipment and your configuring pools of resources, and at a specific node you would like to specify the configuration?
Igor Bryskin: This signal type will work when your network is fine. Why do we need this? During initial path computation this can be done.
Greg Bernstein: We need this because once you change a parameter in flight and you may want to specify where regeneration can occur. You may want to indicate a modulator that supports two different modulation formats. Once you change any parameter in flight [during signaling] we assume the bit rate has to the stay the same, or the modulation stays the same.
Igor Bryskin: When you signal the path does the ERO contain the lambdas?
Greg Bernstein: We have distributed wavelength assignment or PCE (centralized) wavelength assignment. Neither of these affects the issue regeneration.
Igor Bryskin
: I have a problem seeing the value signaling these parameters.
Greg Bernstein: Ok.
Lou Berger: We have two separate discussions in your draft. It's important to make sure that any mechanism is in sync with our discussions tomorrow [CCAMP Session 2]. The document also discusses bidirectional issues this has not been discussed in a while. It would be good to have more discussion on this area. Especially to make sure that people agree to the changes proposed in this context.
Greg Bernstein: Ok.
Pierre Peloso
: In a previous version of this draft there used to be a wavelength metric. This has disappeared. Why?
Greg Bernstein
: We discussed previously that RWA algorithms were too experimental.
Pierre Peloso: I understand this. The wavelength metric could be used by an algorithm but the document does not have to discuss an algorithm.
Greg Bernstein: If we were to do something like that I think it would be more appropriate to do it in another draft. Putting a metric in a signaling protocol is not what I am used to.
Lou Berger: Propose text to the list and discuss there.
Pierre Peloso
: I will propose text.

9 - OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)

Presenter: Fatai Zhang

- Questions and Comments.
- Request that this document becomes WG document.

Lou Berger: As discussed earlier I think it would be worthwhile to converge on  documents that match our information encoding. So we should have one information encoding for WSON and one document for [WSON] routing. If we have a generic encoding document we need the generic OSPF routing document. We do not want to have multiple documents that do not support themselves. Please look at merging work that mirrors the encoding document
Young Lee: A third alternative. If we stay with two separate encoding documents we could avoid separating the OSPF document and have one OSPF document that points to two encoding documents.
Lou Berger: The problem is with any future non-WSON technology that wants to use that general encoding information. They will need to reference WSON technology to non-WSON implementations.
Young Lee: In respects to OSPF that’s fine.
Lou Berger: An example from the TDM world. You would not want the SONET gear to reference a WSON specification. It's better to have stand-alone documents just from a conformance perspective.
Young Lee: Either way is fine.
Lou Berger: Yes, just do not want to have conformance issues in the long term.

10 - OSPF Link Information Model for OSPF

Presenter: Dirk Schroetter

Igor Bryskin
: Are we discussing pools of regenerators. How is this advertised? Per node or per link.
Giovanni Martinelli: This info applies per node.
Igor Bryskin: What if a regenerator is available from a single link or subset of links? How would this be advertised?
Giovanni Martinelli: This constraint should be general OSPF information.
Igor Bryskin: Pools of regenerator are advertised per node.
Giovanni Martinelli: This document describes more detailed link information.
Greg Bernstein: The way I see this. This allows us to look at sub-sets of wavelengths to work with those as sub-links? This could be helpful. This is useful to see what restrictions we have, what modulations, etc. Is this something that should be included in info model and encoding drafts or separate them?
Giovanni Martinelli: Good question.
Lou Berger: Seems you are covering two issues. First comment, by optimizing particular pieces of information and by introducing a sub link you gain some optimization. Is this a correct characterization?
Giovanni Martinelli: Not really an optimization but a better description of the link
Lou Berger: Can this not be achieved with the current information model?
Giovanni Martinelli: No.
Lou Berger: Second comment. You have the new info; we have a better way of describing info. Should this new info not be brought into the document?
Giovanni Martinelli: Basically, yes.
Lou Berger: Is this new information [Adjacent Channel] something that should be brought into the general info document?
Greg Bernstein: I saw there was an admin grouping
Lou Berger: By grouping information you're optimizing. The document is also introducing new information. Does this become elevated to the framework and then is filtered down?
Greg Bernstein: It may not need to go all the way up to the framework but it should be in the info model.
Giovanni Martinelli: On the framework there are other comments from Igor.
Lou Berger: I think this could go either way. In your next update include how you are addressing this. We can then discuss this on the list.

11 - OSPF Extensions in support of O-E-O pools in GMPLS controlled all-optical networks

Presenter: Pierre Peloso

Igor Bryskin: You want to advertise in a single LSA all constraints.
Pierre Peloso: There are three LSA’s, one for node (spectral etc.).
Igor Bryskin: Each of them is separate TLV. We found it quite problematic to split link info across several LSA’s. Have you made an evaluation on using this on existing equipment and the affect on LSA size?
Pierre Peloso: For instance you are just updating OEO resources. (See Slide LSA describing OEO resources). These are fixed sizes, dependent on your pool.
Igor Bryskin: Well let's say you have a potential 80 channels what are the binding constraints and LSA size. Maybe you should have an appendix with examples?
Pierre Peloso: I would defer to Greg Bernstein. I am using his encoding descriptions.
Lou Berger: Before you do that we are out of time for this draft. I suggest you take this to the list. It might be useful to have examples in an appendix. Also same comment as before, please see how this work can be merged into existing documents as we do not want to have multiple drafts on the same topic.

12 - OAM Configuration Framework and Technology Spec Extensions

Presenter: Attila Takacs

Lou Berger: Fist point, the usage of 2119 conformance language. Please try to stay consistent. The second point, the framework document title. Maybe it's more than a framework, maybe "General OAM using RSVP-TE".
Curtis Villamizar: I agree it should be a base spec really, as opposed to a framework document. Also the attribute bits are in short supply. It would be better to put these somewhere else. If you ever want to address a MIP, it might be better to put some of this info in an ERO to identify a specific MIP. It would also be useful to set a loopback as per our recent email.
Attila Takacs: The bit addressing is being discussed. Perhaps by having a field where you can add this info.
Lou Berger: The discussion is where the object lives, not necessarily if the function is there.

13 - RSVP-TE Extensions for MPLS-TP OAM Configuration

Presenter: Elisa Bellagamba

Nurit Sprecher: Is this version three?
Elisa Bellagamba: This is version two.
Lou Berger: Any other comments?  No?  Time to adjourn, will reconvene tomorrow.

CCAMP Second Session
Tuesday, March 23, 2010. 0900-1130 Morning Session I

14 - Framework for GMPLS and PCE Control of G.709 Optical Transport Networks

Presenter: Fatai Zhang

- Questions and comments?

Igor Bryskin: I think this is a useful draft for implementers and operators. It would be good for the routing considerations. For instance you can create hierarchies, FAs, encoding types, etc. That would be useful.
Fatai Zhang: This is described in this draft; we just do not list them in these slides. The framework document describes those requirements from a high-level.
Igor Bryskin: We are looking to implement this as our part of a multilayer control plane. I was looking for a switching type for hierarchies that are advertised. It would be nice to have these defined.
Lou Berger: An example of that is in the Ethernet framework document. We did not define specific values this happened in the solutions documents. The intent and use was defined in the framework so I think the comment [from Igor] is valid.
Fatai Zhang: We can do this.
Lou Berger: Igor, independent of the comment is this a good foundation for the WG activity?
Igor Bryskin: Yes.Biao Lu: I did not see this document mention OTN multi-level muxing. In terms of multilayer forwarding, I would suggest that this should cover multilayer hierarchies as well.
Fatai Zhang: We have cases for multilayer. For example if we look at ODU 1, 2, 3 at multilayer. They are multilayer. At the moment we look at the single ODU layer. For multilayer we use this existing technology.
 Biao Lu: I suggest you mention this in the document.
Fatai Zhang: This is mentioned in the document.

Biao Lu: I didn’t see it, maybe I missed it.
Malcolm Betts: I support this draft it’s a good base for moving forward and I support it becoming a WG document. The work in the ITU is keeping pace so it's completely appropriate at this time. On the multilayer, as Igor [Bryskin] mentioned, some application examples / use cases would useful.
Lou Berger: That’s correct; the muxing issue would also be addressed with Igor's [Bryskin] comments.
Deborah Brungard: How many have read this draft?
(Quite a few)
Deborah Brungard: How many people would support this becoming a WG document?
(Similar number)
Deborah Brungard: Good response, we will take to list for WG status.
Lou Berger: Are the liaisons that came in from the ITU addressed?
Malcolm Betts: Answering my liaison, I think it's pretty much addressed. That's one reason why I would like to see this document become a WG document so we could have a formal liaison to make sure we stay aligned and do not drift.
Lou Berger: Do we liaise the 00 version of the WG document, or the 01 version that addresses the outstanding liaisons?
Malcolm Betts: We do not see open issues. Look at liaison if you see something let us know and we will try to respond.
Lou Berger: Well with your co-author hat on, can you review your liaison and see if there are still any holes?
Malcolm Betts: Yes.

15 - Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport N

Presenter: Fatai Zhang

- Questions and comments?

Lou Berger: Good comments on the previous document [14 - Framework for GMPLS and PCE Control of G.709 Optical Transport Networks]. Can anyone comment on this, is this a good document to continue activities within the working group on this area? How many people have read the document?
(a few)
Lou Berger: Definitely a much smaller showing [than the previous document]. Perhaps we need to address the issue raised at the framework level first. This can translate into technical changes at this level. I agree with previous comments that there will be some changes, including switching types. Hopefully we will have more people review and we can look at making this a WG document after the next version.

16 - Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN Network

Presenter: Daniele Ceccarelli

- No questions or comments.

Lou Berger: We look forward to the next version. This is good progress.

17 - Link Management Protocol (LMP) Test Messages Extensions for Evolutive Optical Transport Networks (OTN)

Presenter: Daniele Ceccarelli

- Questions and comments?

Jonathan Sadler: I see your referencing the appendix of G.7714.1. The CCAMP document that it was based on in the past, the bootstrap draft, never made it to completion. Is there an expectation that that it will be revived?
Daniele Ceccarelli: Yes.
Deborah Brungard: How many have read this draft?
(Not too many)
Deborah Brungard: I encourage people to read the draft.
Lou Berger: It’s good to see the next technical steps mentioned [see slide 8].

18 – LSP Data Path Delay Metric in Generalized MPLS-TE Networks

Presenter: Guoying Zhang

- Questions and comments?

Adrian Farrel: draft-shiomoto-ccamp-switch-programming is in limbo. It was informational; we did not say anything that was not already in existing RFCs. It seemed that people were not extracting the information correctly from existing RFCs. We are not quite sure what to do with it. No significant mailing list comments. We would like to know from the chairs and WG what they would like us to do. Maybe we could cut and paste our work into your document.
Lou Berger: A cut and paste concerns me a little. If we make this document a proposed standard I'm not sure that your document, which is informational, fits inside this document.
Adrian Farrel: I see three options [for draft-shiomoto-ccamp-switch-programming]. 1 Kill it. 2 Make WG draft. 3 Progress as an independent RFC.
Lou Berger: Does anyone have an opinion on this? Would anyone like to voice support for these options mentioned by Adrian? I do not see a lot of support.
(no comments)
Lou Berger: This is the issue with the [switch-programming] document, i.e., lack of support. Let's try again and see if we can make it an informational document. If that fails option 3 is better than option 1.
Curtis Villamizar: [On the presentation:] The motivation for signaling back a RESV before having the hardware signaled [with multiple hops] is the delay to get all the signaling completed, which is proportional to the delay by N of hops. The root cause of this is that the signaling is not separated from indication that the hardware that is set up. If we go back almost 10 years we had a draft that indicated the path as the signaling was being performed, without actual setup. That way the ingress would know that the hardware setup along the entire path has been completed, other than trying to indicate what you're expected your delay was and when you were done. Maybe we should revise this work instead of trying to estimate the delay.

Lou Berger: There are two separate topics. First, is it okay to signal before your hardware is there?
 Curtis Villamizar: I am suggesting a protocol extension that allows you to do this if the ingress understands the signaling.
Lou Berger: That would be an interesting piece of work. The work being presented here is really something along the lines of what you would see from a benchmarking group. Except that here we are benchmarking the relationship of control plane and data plane. This is something suitable for the lab. The chairs think this is important for the WG, and was requested to progress DPPM work, and being able to correlate the control plane transactions to the data plane. This was motivated from a request from the chairs. Is there a feeling that the work should be progressed as a WG product?
(Not many)
Lou Berger: How many have read this document?
(Not many)
The document is not getting a lot of attention. We will talk offline to discuss how to progress this document.

19 – GMPLS RSVP-TE Recovery Extension for data plane initiated reversion

Presenter: Attila Takacs

- Questions and comments?
- Request WG document.

Lou Berger: Who has read this document?
(A few)
Lou Berger: It seems a little light to take on a WG document. Of those that read the document do you think this is a good start?
(Same number of hands that read the document)
Loa Anderson: if you poll this document, please send the request also to the MPLS-TP list as well.
Lou Berger: It's a good idea for the authors to point out this work on the MPLS-TP list as well.
Deborah Brungard: The recommendation is that you give the document some more visibility.
 Nitin Bahadur: [Slide 1] The motivation seems to decide it reversion is dictated by the ingress, shouldn’t it be that the ingress or the PLR makes that make the decision?
Attila Takacs: This refers to both cases.
Lou Berger: Are you suggesting that different timers should be applied at different points?
 Nitin Bahadur: There may be a case where the PLR needs to decide to revert not.
Lou Berger: This document governs the timing not the decision point.

20 – Encoding of Attributes of LSP intermediate hops using RSVP-TE

21 – Use cases and alternatives for configuring intermediate nodes using RSVP-TE

Presenter: Attila Takacs

Lou Berger: We had a good discussion on the use of ERO at the last IETF [76]. What we are doing here is slightly different from the original intention of ERO. It started out as data path control, and now we are using it for targeted control plane operations. While we could encode it this way, it's not necessarily the right semantics. We should do what we have done in the past other instances. For instance we have similar issue with segment protection and we came up with a solution that provides a targeted object (SERO), and perhaps a similar approach is appropriate here. I think there are other options to explore. Given the previous discussion I do not think we should go down the path of ERO as a way to carry non-data path selection.
Attila Takacs: I think it depends on the use case. I think for say ROADM configuration you are probably right. I agree that we do need to consider use cases.
Deborah Brungard: How many read the draft?
(not many)
Deborah Brungard: We need to encourage more people to read the draft.

22 - On the association of GMPLS Recovery LSPs

Presenter: Lou Berger

Adrian Farrel: With my AD hat on. "Allow for non-GMPLS usage", is this in the CCAMP charter. Have you gone to the transport area with this work?
Lou Berger: We have not taken it to transport area. We do intend to find out what the plan is with the [RSVP] mini-bof on Wednesday. I was waiting on that session to help with the discussion of this document.
Adrian Farrel: That's wise, after the [RSVP] mini-bof you might setup a meeting with various ADs and chairs to see where we can perform this work, and if we need to do any chartering.
Lou Berger: Regarding the charter, I do not think it was envisioned in the charter, but its not clear if this is precluded.
Loa Anderson: I think at least a part of the non-GMPLS use, is within scope as there is a long list of WGs list on the charter page that CCAMP can cooperate with.
Lou Berger: I agree on the MPLS side, regarding INTSERV it's not so clear
Adrian Farrel: [Regarding Loa's comments] just because it [charter] says you will co-operate does not mean you do other work of WGs.
Fatai Zhang:
Clarification for LAN recovery usage, if we have two parallel LSPs, and they have no common nodes. Can we create a relationship between these two LSPs?
Lou Berger: If they have no common nodes? Other than ingress or ingress, what do you mean? Or are you saying no common node at all.
Fatei Zhang: No common at all.
Lou Berger: If they have no common node at all. The mechanism will work but there will be no node where the identification will be identified. From the management plane perspective you can establish association, but it cannot happen in the control plane because there are no shared nodes. Technically it works, semantically it's irrelevant. If two LSP's pass through the same node, then the association can be identified. 
Francois Le Faucheur: Concerning Adrian's [Farrel] point, how should we handle RSVP based on the mini-bof later in the week. Being pragmatic, we have this problem for RSVP for non-MPLS, RSVP-TE, RSVP for GMPLS and overlapping MPLS and GMPLS work. We have tried very hard to reapply work where possible. We are taking advantage of work that is useful in multiple WGs.
Adrian Farrel: I'm not saying kill the work. I'm saying take it to the right WG or re-charter.
Lou Berger: Two options. We can make changes that only affect MPLS and GMPLS, regarding INTSERV we do not know yet. Or we can recharter to expand allow for this work.
Julien Meuric
: The main usage is INTSERV, as a member of the CCAMP I do not know anything about INTSERV. I'm really not sure this is the right place.
Deborah Brungard: As Adrian mentioned discussions need to continue, if we were going to do the work we need to work with the other areas.

23 - RSVP Resource Sharing Remote Identification Association

Presenter: Francois Le Faucheur

Deborah Brungard: As Francois mentioned, we will see how this progresses.

24 – RSVP-TE Extensions to Realize Dynamic Binding of Associated Bidirectional LSP

Presenter: Fei Zhang

George Swallow: Have you read RFC4206, how would you compare this work to that document. This seems to be very similar where you combine two LSPS together. You should take a careful look at that document and see how it should be extended.
Lou Berger: I think it's good to have alternatives to meet requirements from TP. Its good to see solution documents from the TP framework mentions calls, but it should not restrict solution use, whether it's forwarding adjacencies or association. The association object approach should sync with the association document.
Deborah Brungard: We encourage you to please read this document as it is relevant to MPLS-TP work.

25 – OSPF ASON Routing Extensions

Presenter: Lyndon Ong

Andy Malis: I would like speak with my Verizon hat on. We are sponsoring the interop testing. We are interested in implementing and deploying and we are held up due to standards track documents and code points. The number one item is to get standards track documents and code points in order to get code in the network.
Lou Berger: By this do you document what was presented, or RFC5787?
Andy Malis: The fastest path to development is taking work that was already done. The second choice would be putting RFC5787 on the standards track.
Lou Berger: From an IETF process standpoint I think the latter is the fastest choice, which is the opposite of the first.
Andy Malis: The important thing is to get this work on standards track.
Lyndon: I would support Andy, getting this stuff onto the standards track. Secondly, effort on the OIF part is not a high priority within this group. We would find it faster and easier to implement the standard the closer it is the work that has already been implemented and tested.
Lou Berger: Proposals for RFC5787 BIS's would be interesting. Given that the document went thru the WG and the reason for being experimental rather than proposed standard was [lack of] intent of implementation. Given that I think it's really necessary to state the reasons to change the formats. There needs to be strong justification for changes. We look forward to seeing future drafts proposing RFC5787 BISs.
Lyndon Ong: I guess that strong justification is a judgment, I would hope that having running code provides something in favor of changes.
Eve Varma: As we are moving into the OTH work we are also finding the bandwidth quantification issue is something that does have an impact on the quality of the path computation. What I think is useful is to make sure that TDM-type or ODH routing that has fixed and flexible containers, have a common approach. A lot of work has gone on with the BW quantification to see how we can do things in a coherent way, and it moves forward smoothly and there is a balance to do everything in the same way. There are some opportunities for joint solution approaches and I don't think it's all or nothing and there will be things in common.
Julien Meuric: With respect to the earlier comment on running code. I know an LMP implementation that has been deployed on 10s of nodes, this is deployed on running code. It uses class type 30 instead of 18. Do you think we should update the RFC to take that into account? In my view the answer is obvious. Does it make sense in terms of processes to make minor changes?
Lyndon Ong: I understand, it’s really a two step argument. There is running code, and there is also an RFC that came out as experimental because of a lack of running code. We can converge on a solution and bring this to standards track.
Zafar Ali: For a BIS there needs to be a tactical reason, some gaps in the RFC, not just running code.
Lyndon Ong: From a technical perspective, the most serious concern is with the ISCD. Having to put in repeated versions of the ISCD. I think the other, local and remote, is more trivial difference. With addresses there is some preference for the length version rather than the network mask. I take it that one outcome from this discussion is that there is interest to start up a RFC5787 BIS.
Malcolm Betts: I would like to support the proposal that Eve [Varma] made. We need to take into account the extensions for OTN. If we're going to do an update to do one that covers all the cases, and not get caught with multiple updates. Let's also base this on proven implementation experience.
Deborah Brungard: This is not the first time that private implementations got ahead of standards. It's good to hear that there is willingness to come to an agreement. If you are willing to come to a compromise this is all good. Let's go forward with BIS, we really need to see the justification for technical changes.

26 – Requirements for auto-config of control plane adjacency

Presenter: Lyndon Ong

Igor Bryskin: I would support this draft; we analyzed the hierarchy draft in my company we concluded also that lots of things need to be advertised and controlled for dynamic hierarchies. For instance the TE metric. How can you do this on the receiver side, port colors, etc. You might need to support multiple clients and multiple layers to support the hierarchy. There is no way to specify how this can be done.
Lyndon Ong: I think LSP hierarchy mechanism provides ways to provide extensions; we just need to see if the extensions are necessary and how to do them. Perhaps further discussion on the list?
Lou Berger: If would be good if you guys can get together and bring in the issues that Igor [Bryskin] indentified. Then identify which aspects are already covered inthe standard GMPLS solutions. A number of requirements will go away but there will be the new additional requirements particularly based on Igor’s [Bryskin] requirements.  He can also  help and he can contribute to the work.

27 – PLR Designation in RSVP-TE FRR

Presenter: Jie Dong

Zafar Ali: [Requirements Slide] some resources can have resiliency. What makes a resource, a node or link, what makes the LSP not fail? What is the mechanism that allows the LSP to not fail when there is a node or link failure?
Jie Dong: This is based on network and local policy. GMPLS segment recovery already provides this. It can explicitly designate the start point and end point of the protection. In some scenarios we need to know which links all notes are reliable.
Zafar Ali
: I am not getting it. If something fails. What makes this LSP so permanent that it will not fail and you have to specify per hop behaviour?
Lou Berger: It’s a policy decision of the operator of where to place the PLRs. It's not that it cannot fail it's just that they have chosen not to protect it.
Jie Dong: Provides more control of backup LSPs.

Curtis Villamizar
: Some of the links may be in the same building in adjacent racks for instance. These tend not to fail quite as often. Some vendors have reasonably good redundancy in the control plane. Most equipment also has reasonably good redundancy in the fabric. There is a little less requirement for node protection, so I see the value in this.
Lou Berger: The point with segment recovery is that the SEROs could be used to indicate the PLRS points. It's not either or. It's using SEROs to support RFC4090 style protection.
Jie Dong: So using SEROs with RFC4090 for protection?
Lou Berger: Yes, it's not precluded. It may not be fully documented in the RFC and in your document could cover this. Now with my Chair hat on, I am not sure why you are bringing this to CCAMP versus MPLS?
Jie Dong: There is some relevance to other draft presented per-hop configuration. So we present this here.
Lou Berger: I would like to hear from Loa and George on this.
George Swallow
: This belongs in MPLS
(Unknown from NTT): I do not see much benefit for this. It does not save many resources, and it increases the operational burden for FRR deployment.
Jie Dong: Without enhancement every FRR node perform as a PLR, every node needs to establish and maintain. In some scenarios this is unnecessary. This reduces resource and bandwidth cost. In some nodes you just need local protection.
George Swallow: The biggest complaint from our users on RSVP-TE seems to be the difficulty to configure it. From the MPLS WG Chair perspective, I would like to hear a demand from people who deploy RSVP-TE that this is something they really need.
Lou Berger: Makes sense.  We look forward to seeing this in the MPLS WG.

28 – Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment

Presenter: Zafar Ali

Lou Berger: P2MP was done in the MPLS WG, RFC5151 was done here. The document does not mention RFC5151. Given this, it seems the document belongs in the MPLS WG.
Zafar Ali: I do not have any particular preference. I think its useful information for CCAMP.
Lou Berger: I think a document that extends RFC5151 to P2MP would be an interesting document to discuss here. In its current form your current document is interesting and thank you for presenting, please take it to the MPLS WG.
Zafar Ali: We will update it and discuss with MPLS chairs.

29 – RSVP Extensions for Multi-Topology Support

Presenter: Quintin Zhao

Lou Berger: As before. Why CCAMP and not the MPLS WG? Procedurally this is MPLS. The objects were defined by MPLS and should be modified in the MPLS WG. (Unless the WG chairs say do the work in CCAMP.)
(Unknown): For the requirement you need a description of not just the IGP to topology. For standards track it's not worth having options due to interoperability. For option 2 have you consider the implementation.
Quintin Zhao: The applicability should be discussed with SPs and we will define requirements from these discussions. The options question, option 1 is simple to implement. The concern we have is table space which is limited for large number of topologies.
Igor Bryskin: This is a logical compliment for multi-instance solutions discussed in OSPF. You need to identify the topology you are working on. Why not introduce a separate object that identifies the technology. The important thing is using multiple topologies to identify the topology.
Lou Berger: Thank you for the presentation. We look forward to seeing this work in the MPLS WG.