CCAMP Minutes
for the
81th IETF Meeting
Version: August 11, 2011
First Session
Tuesday July 26, 2011
Morning Session I 0900-1130
Room Name: 206 B
Minute takers: Daniele Ceccarelli and Elisa Bellagamba
Presentation Start Time Duration Information
0 - 9:00 5 Title: Administrivia
Draft:
Presenter: Chairs
1 - 9:05 10 Title: WG status, RFCs, drafts, milestones, charter, errata
Draft:
Presenter: Chairs
2 - 9:15 10 Title: Framework and Information model for GMPLS and PCE Control of G.709 Optical Transport Networks
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-04
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-00
Presenter: Daniele Ceccarelli
[Lou Berger] Both routing and signaling docs are addressing compatibility – it would be best to address compatibility in a consistently in the framework and info model drafts rather than only separately in the solutions documents.
[Deborah Brungard] When saying that there could be no auto negotiation, do you mean at the data plane layer? The auto negotiation at the data plane layer is always there on new interfaces.
[Daniele Ceccarelli] Yes, but older interfaces don’t and backward compatibility needs to be addressed.
[Deborah Brungard] But a new interface, speaking with an old one, would auto negotiate the 2.5 Gbps Tributary Slot.
[Lou Berger] It’s also my understanding that the negotiation takes place when the first data channel becomes active.
[Deborah Brungard] When the link comes up the TS is known, there was an old discussion on the mailing list.
[Lou Berger] This was discussed on the list. Did we reach a common understanding?
[Deborah Brungard] Malcom? Would you like to add to that? [No] We need to better understand the network model. As soon as the interface is turned on, the TS is configured.
[Lou Berger] In either case, we need to support it properly for path computation and in routing, no matter when the discovery takes place.
4 - 9:25 15 Title: Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks
Draft: http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-06
Presenter: Daniele Ceccarelli
[Lou Berger][Regarding the F-flag] Generally when the fields change meaning, we use different types. Is there a reason why you use a flag rather than a different type field?
[Daniele Ceccarelli] There is no technical reason, different TLV types can be used.
[Lou Berger] I think it would cleaner to use a different type rather than overloading the type field and having to parse the F-flag in order to determine how to use the other fields. Note this is a comment as [WG contributor] not as chair.
[Daniele Ceccarelli] We can do this if the other authors agree.
(presentation ends)
[Lou Berger] Expresses this is a big change since the last meeting. Instead of having a list of ISCD, one per layer, you end-up having a single ISCD with all the layers depicted.
[Daniele Ceccarelli] You can still use multiple ISCDs.
[Lou Berger] Key point is that there is only one switching capability value for OTN (in the current draft), in the prior there was multiple. The old approach supported single layer path computation based on switch cap value, and only when multi-layer path computation was needed was any additional processing needed. In the new approach, there is just one switch cap value, and the ISCP(s) need to be fully parsed in order to do any path computation. This is a big change from an implementation standpoint. It is a big change,.Good to hear about implementers and the room.
Poll for who has read the draft: “a good number”
Poll for who has understood the technical change: seems “reasonable”
Poll for uncomfortable with the change: “none”
Poll for comfortable with change: “a reasonable number”
More comments would be good on the mailing list but the support from the room is clear. The routing document seems to have come together nicely.
[Lou Berger] Technical question: why are multiple SCSIs needed? Having a single SCSI is cleaner.
[Daniele Ceccarelli] The problem is that putting them together there is no mean to understand is a given ODU is, accordingly to the example shown, an intermediate layer of a hierarchy or a client layer of another. When the ODU0->ODU3->ODU4 hierarchy is being advertised, there are two TLVs, one for ODU0->ODU3->ODU4 and the other one for ODU3->ODU4. If also the ODU3->ODU4 hierarchy of a different component link is advertised, then it is no longer possible to distinguish among the two ODU3->ODU4 advertised.
[Lou Berger] So there is a correlation of information between the different TLVs. Why not solve this another way, e.g., putting the TS there, that keeps it in a single SCSI?
[Daniele Ceccarelli] It’s a new open issue. We need to think of it.
[Lou Berger] The problem can be solved using different SCSIs is it goes against the principles of bundling, with this solution you have a “half-unbundled” solution. It would be better to have a full bundled solution.
[Rajan Rao] If you bundle only homogenous hierarchies there is no need to have multiple SCSI. Whether we need to bundle or not dissimilar muxing hierarchies is a framework issue.
[Daniele Ceccarelli] This is the new open issue
5 - 9:40 25 Title: Discussion on OTN signaling: implicit vs. explicit
Draft:
Presenter: Chairs
Question 1
How many ODU switching levels can be represented in one signaled LSP?
Today 1, proposed more than one
[Kam Lam] I have concerns on the proposal. It creates implicit intermediate connection unknown to the management plane.
[Jonathan Sadler] I am also concerned. Need to work on terminology, term level corresponds to ITU term layer. Layers are managed independently (protected and restored) and this proposal does not allow that. My concern with the proposal is how to handle the different levels, in particular grooming.
[Khuzema Pithewan] Multiple layers in a shot only applies to a single hop, e.g., point to point links. No scope of rerouting intermediate layers in this case, just protection. Regrooming performed on the client or on the FA. Restoration need to pass from a different path, while here we’re talking about a single hop and the signal has already passed the switching fabric and is already on the output interface, so it is not possible to restore.
[Lou Berger] A link could be an FA, and an FA could be regroomed or restored.
[Jonathan Sadler] Regrooming is not a restoration action, is a Traffic engineering action. Understand the statement about restoration but concern about the fact that re-grooming is eliminated.
[Ghani Abbas] support Jonathan. Going to the question. There must be a correspondence between the layers in the data plane and the layers in the control plane. Grooming is just traffic engineering.
[George Swallow] I think this is a micro-optimization, and to accommodate it by modifying the architecture would be a mistake.
[Lou Berger] This is a very interesting and different comment. There are comments saying that it is something that can be standardized but then not used in the networks, this is saying that this is something we don’t want in our documents/ RFCs. This is an important point.
[Khuzema Pithewan] There are two cases for H-LSPs: one hop LSP, and multi-hop H-LSP. Multistage applies when the origin and termination of the FAs at the different layers are the same and there is no chance for restoration. Also there are no case where H-LSPs preclude regrooming.
[Deborah Brungard] Traffic cannot be moved independently at the different layers?
[Knuzema Pithewan] ODU3 can be regroomed in the example, ODU2 cannot.
[Deborah Brungard] What about if there are multiple interfaces? The ODU2 can be moved to one of them or you’re frozen?
[Lou Berger] Do you want to Instantiate a data plane without control plane correspondence?
[Khuzema Pithewan] yes, LSPs are a data plane concept and might not have a control plane correspondence. Control plane is optional.
[Lou Berger] In TP many LSPs can be single hop. How can they be set up?
[George Swallow] They are mapped one to one (data plane – control plane). The proposal does not manage layers independently.
[Deborah Brungard] We need to understand if the proposal is a real benefit or a micro optimization.
[Khuzema Pithewan] ODU2 is tight to the ODU3, ODU2 can be restored only if can use a different ODU3.
[Lou Berger] How many think that they would deploy a scenario with Intermediate level without control?
[Andy Malis] Not Verizon
[Lou Berger] Does anyone see the need? “no one”.
[Ghani Abbas] The scenario is an isolated island
[Deborah Brungard] In the data plane you wouldn’t have a frozen hierarchy. Very inflexible
[Khuzema Pithewan] It is something you could have or not.
[Lou Berger] The question at hand is do we want to standardize this case? While there is some support it is clearly outweighed by the opposition. Continue the discussion on the Mailing List but unless things change significantly at the moment, the results of the discussion are that requirement 1 is not a requirement. Given this, I don’t think it makes sense to go through Requirement questions 2 and 3. This really is start of the closing the door on this open discussion.
[Rajan Rao] In the SONET/SDH case, we already have a label stack and multi-layer in it. So why is this different?
[Lou Berger] Based on today’s discussion we should continue “closing the door” on this discussion, and complete the discussion on the list. If you think there is a point that hasn’t been sufficiently covered, please discuss it on the list. Note, we’re close to a final decision on this, but we need to confirm it on the list.
6 - 10:05 10 Title: Signaling Extensions for the evolving G.709 Optical Transport Networks Control
Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-08
Presenter: Fatai Zhang
[Fatai Zhang] Things change given that there is no support for the multistage label. Adoption?
[Lou Berger] Please review RFC2119 conformance language and improve specific procedures. There are open points on the list, these will need to be addressed in the future WG draft. Doing so in this document would be good preparation to become a WG document.
7- 10:15 10 Title: RSVP-TE Signaling Extension for Explicit Control of LSP Boundary in A GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
Draft: http://tools.ietf.org/html/draft-fuxh-ccamp-boundary-explicit-control-ext-03
Presenter: Xihua Fu
[Rajan Rao] You’re saying that there is no info in the advertisement for determining the boundary nodes? Not true. You can figure out the boundary nodes from the bandwidth advertisement. We should talk off-line.
[Lou Berger] You are presenting two points: requirements plus solution provided. Shouldn’t requirements be introduced into the framework document? Is the document generic or OTN specific?
[Xihua Fu] This draft is a generic draft, not related to OTN. OTN is a special case example.
[Lou Berger] ok, that’s not how I read the document. If generic, can build on MRN/MLN and ERO usage. If this is OTN specific, then it should be covered in framework if the WG agrees to support the function. You have to decide which path you want to follow.
[Xihua Fu] the requirement is related to multi-layer and multi-region, so I think the requirements are adequately covered. And this document is generic.
[Lou Berger] then this document should be very generic and focus on what is missing with the current MRN solutions.
8 - 10:25 10 Title: Behavior Negotiation in The Link Management Protocol
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-lmp-behavior-negotiation-04
Presenter: Dan Li
[Lou Berger] Big changes from last version. Additional reviews particularly from implementers is desired.
9 - 10:35 10 Title: Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis)
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-rfc5787bis-02
Presenter: Acee Lindem
[Deborah Brungard] Are people comfortable with this document and addressing the requirements in a separate document, if needed?
[Kam Lam] S15/Q14 agrees on addressing the requirements in a separate document.
[Lou Berger] Please document on the list your proposed response to the Liaison.
10 - 10:45 10 Title: GMPLS RSVP-TE extensions for OAM Configuration
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-06
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-eth-oam-ext-06
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06
http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-02
Presenter: Elisa Bellagamba and Attila Takacs
[Deborah Brungard] document have been there for a while, any comments
[George Swallow] FMS configuration is overly specified, we should have an offline discussion on FMS and amount of flexibility that is in there is needed
[Greg Mirsky] mpls-tp oam is stable but addresses only LSP case. Two more docs needed to address also section OAM and MIP OAM control that I’d like to start on. This is a good document and can advance as it is.
[Lou Berger] Do you see those documents already fitting in the framework?
[Greg Mirsky] Yes, they fit.
[Deborah Brungard] Alignment with ITU required on the SDH and OTN. Need to review as very close to WG last call. Once they are ready, we will last call, and send over a liaison to Q14. Everyone please take a look.
11 - 10:55 8 Title: Usage of The RSVP Association Object
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-assoc-info-02
Presenter: Lou Berger
12 - 11:03 7 Title: RSVP Association Object Extensions
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-00
Presenter: Lou Berger
[Adrian Farel] Hat off – May need to have a look at the latest changes on identifiers (especially ICC).
[Lou Berger] I’m aware of such changes. Those are in the content of the ICC not in the external format of the ICC.
[Adrian Farrel] Worried about the mixture of the ASN number as a global ID with the ICC. The ICC is different from the ASN. There are cases in which ASN and ICC are used together. A global ID is different from an ASN
[Lou Berger] two separate cases need to be covered, without ICC and with ICC. Will need to review offline.
[Loa Andersson] Extending the ICC to a global ICC is confusing. They are national values. Global unique ICC and ICC are not the same.
[Lou Berger] I’ll take a pass to ensure this document is in sync.
[George Swallow] The global ID is used for private networks. The global ICC is not an ICC, it is an ICC plus something.
[Lou Berger] let’s talk offline on the format.
13 - 11:10 10 Title: RSVP-TE Extensions to Establish Associated Bidirectional LSP
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-01
Presenter: Fei Zhang
[Deborah Brungard] This has been presented also in MPLS as it is where the requirements come from. We’ll send a message to the MPLS mailing list to raise the visibility and for everybody to check the requirements and have feedbacks.
14 11:20 10 Title: RSVP-TE Extensions to Notification for Shared Mesh Protection
Draft: http://tools.ietf.org/html/draft-he-ccamp-notification-shared-mesh-protection-00
Presenter: Fei Zhang
Adjourn 11:30
[Fatai Zhang] Shared mesh is a data plane protection mechanism, should be standardized in ITU-T Q9, independent from control plane. Modifications and procedures proposed can be implemented in the data plane.
[Fei Zhang] The same functions can be made at the control plane layer. Discussion will be continued off line.
=========================================================================
Second Session
Thursday, July 28, 2011
Afternoon Session I 1300-1500
Room Name: 206 A
Presentation Start Time Duration Information
0 13:00 5 Title: Administrivia
Draft:
Presenter: Chairs
13:05 5 Title: Intro to WSON Discussion
Draft:
Presenter: Chairs
[Lou Berger] We have a discussion on the open WSON related proposal. The objective of this discussion is to close on the direction that the WG will follow. Before we begin this discussion, we have some questions on the other open issues related WG drafts. We see that the drafts have not been updated on the open issues discussed at the last IETF and would like an update on when they might be addressed. So the first open point is in the OSPF document there was discussion on the need for a section on scaling implications and update rates (asked by Acee). What is the time line for adding that?
[Greg Bernstein] In our presentation we have a bit of a tutorial on how the various TLVs are used.
[Lou Berger] It would be good if this gets captured in the document, in particular scaling implications, update rates and synchronization of information across LSAs. Not a big deal, but needs to be in the document. The question is when will be addressed in the next round of updates.
[Greg Bernstein] Okay.
[Lou Berger] On the signaling side, there was a presentation by Giovanni Martinelli at the last IETF on an open signaling issue. When will that be addressed?
[Giovanni Martinelli] To update yet, will trigger a discussion on the list before the next IETF.
[Lou Berger] Great. We can’t let one open discussion prevent us from working the other issues in the drafts. With that we move on to the open WSON issue discussion.
15 13:10 20 Title: Discussion on proposed changes
Draft: http://tools.ietf.org/html/draft-peloso-ccamp-wson-ospf-oeo-04
Presenter: Pierre Peloso
Presentation:
3 changes to actual WG drafts proposed:
1. Introduction of resource pool
2. Use of node connectivity matrix TLV
[Acee Lindem] In both cases node connectivity is not specific to DWDM but is generic and hence goes into the generic node attribute. This is true for both drafts, correct?
[Pierre Peloso] Yes
3. Enhance resource block strength: describe the resource properties instead of the resource block properties.
[Lou Berger] A general comment: Changes motivated by (1) the feeling of lack of specificity in the documents that could lead to interoperability issues and (2) ease of implementation.
[Pierre Peloso] There’s also the reboot issue.
[Lou Berger] Well that’s either an interoperability or implementation issue.
[Pierre Peloso] or a mix of the two
[Lou Berger] From an interoperability stand point, this can be fixed by comments on and additional to the existing documents. So let’s not focus this discussion on the lack of specification issues, but rather on the second class of issues in our discussion, including support for reboot. Now to comments on the floor, particularly from the implementation perspective.
[Yao Li ] It should be possible to have several resource blocks in a resource pool in the proposal.
[Pierre Peloso] Yes, and in the working group doc it is only possible to have a single resource block for each resource pool.
[Yao Li] Another question re: modification 1, if multiple resource pool share the same wavelength access how is it encoded?
[Pierre Peloso] If two resource pools share the same wavelength access, they would be updated both at the same time. Needs to be documented.
[Lou Berger] Any other comments, no. Polling: how many are implementing either approach? about ten
Polling: Of those how many care? Almost the same
Polling: Of those who care, how many prefer one or the other? About (slightly more) half and about the other (slightly less) half
[Acee Lindem] As OSPF WG chair: it’s better to split static and dynamic information and to keep information together not to have to correlate them from different LSAs. Moreover to group information together as much as possible, resources that causes the same actions. With respect to multiple TLV levels, we need to support multiple layers in ASON, the best way is adding a third sub TLV level.
[Lou Berger] good general principles, suspect that both approach will claim to support these principles.
On restart, need to ensure that they are explicitly covered by which ever approach is selected.
[Young Lee] Where should restart be covered?
[Lou Berger] In all drafts.
16 13:30 15 Title: Discussion based on current WG drafts
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-11
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-11
Presenter: Greg Bernstein
[Lou Berger] What’s the method of correlation if the info is split into different LSA?
[Greg Bernstein] actually in GMPLS splitting info in different LSAs gets you blocked
[Lou Berger] Actually we don’t have this issue as there is no need to split info among different LSAs, we advertise independent information in different LSAs. Pay specific attention on synchronization of LSAs including correlated information.
[Adrian Farrel] I don’t understand how you can guarantee a linear assignment of identifiers
[Greg Bernstein] An automatic algorithm is suggested
[Giovanni Martinelli] A basic comment on the early text used all 2/4 degree nodes, the solution must address nodes with more degrees. Whatever solution will be accepted, this trend must be addressed (8/16/20 degrees)
[Greg Bernstein] Would welcome more diagrams of examples
[Young Lee] This is a generic question, out of scope of the debate
[Giovanni Martinelli] I’d like to see evaluation against these types of numbers. You said that the resource set can represent any kind of connectivity. The concept of the resource pool is something new and collects the connectivity constraints for some given resources so it clearly separates connectivity constraints from physical ones.
[Greg Bernstein] Using the resource set allows you separating any of the different constraint as it is just a grouping.
[Giovanni Martinelli] Disagree. Probably needs to be detailed in the doc, should just think about the possible constraints
[Greg Bernstein] We can do any type of grouping
[Giovanni Martinelli] just need details in the document.
[Lou Berger] The first comment by Giovanni on node complexity is something that could be helpful in the documents, the second one on how to encode information is something that really should be added to the document. Need the clarification and the specificity in the document.
[Pierre Peloso] You have some very powerful tools, but there are cases where you end up with the utilization of the resource set and block are the same, so there is no value.
[Greg Bernstein] This depends on the scenario, and this example isn’t a realistic scenario.
[Pierre Peloso] So complex nodes destroys the value of Resource Blocks. Sure you can assign many IDs, but why choose an approach that complicates implementation. [Young Lee] It’s a corner case; I’ve never seen so complex nodes. It’s not broken, but rather about implementation issues.
[Cyril Margaria] A clarification on resource black information, it contains the number of resources in the block.
[Greg Bernstein] I can’t do this on the fly
[Lou Berger] A reasonable comment, please provide the scenario/example on the list.
[Lou Berger] Polling: how many people have changed opinion based on the discussion? “No one” Which means that no need to repeate the questions from before. This means that we don’t have any resolution of this issue. The WG chairs will talk off line, and with input from the ADs, propose a direction forward.
[Adrian Farrel] As AD, a question for the room: of the people that care about this issue, how many people care more about their preferred solution rather than having a solution? “No one “
[Lou Berger] How man are not happy about that: “some, less than the total number from before”
[Young Lee] I hear that there is a good chunk of people don’t prefer the new approach. Nothing is broken; there is need for clarification, so I don’t see any issue with current document. What consensus has not been reached?
[Lou Berger] Definitive action requires discussion on the list. What you say is reasonable. All we can see is that about half care about one solution and about half care about the other. We’ll talk as chairs offline.
[Oscar Gonzales de Dios] Please try to put some numbers in the examples to see scalability and be able to compare the two approaches.
[Lou Berger] Please try to run the exercise on your own, and then ask for agreement or identify problems that you can’t solve.
17 13:45 10 Title: WSON Optical Interface Class
Draft: http://tools.ietf.org/html/draft-martinelli-wson-interface-class-00
Presenter: Giovanni Martinelli
[Ghani Abbas] What happens if you switch form old to new format and the length is different, for example adding dispersion compensation?
[Giovanni Martinelli] If you want to add something you must figure out the encoding for it. In term of protocol extension its just a pointer and then info can be added inside.
[Ghani Abbas] How do you know what bit rate it is on an interface?
[Giovanni Martinelli] There is a lot of parameters that can be put inside the class
[Young Lee] do you want to take down existing encoding and use the new proposed one?
[Giovanni Martinelli] yes
[Lyndon Ong] The proposal is consistent with the application code proposed in ITU. A particular interface could support multiple classes.
[Giovanni Martinelli] yes and the interfaces need to find a common subset of them
[Iftekhar-Infinera] Vendor specific extensions can be put in the class field?
[Giovanni Martinelli] Flags can be used before the class field encoding
18 13:55 10 Title: Flexible Grid Label Format in Wavelength Switched Optical Network
Draft: http://tools.ietf.org/html/draft-li-ccamp-flexible-grid-label-00
Presenter: Yao Li
[Lou Berger] Early draft, there is a similar one. Please work with the other authors and come with a single ID next time.
19 14:05 10 Title: Requirement and protocol for WSON and non-WSON interoperability
Draft: http://tools.ietf.org/html/draft-shimazaki-ccamp-wson-interoperability-00
Presenter: Daisaku Shimazaki
[Deborah Brungard] Connect the work to existing MLN issue and make it a generic MLN problem
20 14:15 10 Title: A framework for Management and Control of optical interfaces supporting G.698.2
Draft: http://tools.ietf.org/html/draft-kunze-g-698-2-management-control-framework-00
Presenter: Manuel Paul
[Ghani Abbas] This issue came out in the Chicago ITU meeting in June and didn’t fly, just to report.
21 14:25 10 Title: A SNMP MIB to manage the optical colored interfaces of a DWDM network
Draft: http://tools.ietf.org/html/draft-galimbe-kunze-g-698-2-snmp-mib-00
Presenter: Gabriele Galimberti
[Kam Lam] The parameters are different to the one present in the G.709 v3 ITU-T recommendation. ITU-T SG15 Q14 is working on a revision of the recommendation for OTN support of G.709 a and protocol independent version.
Q9 will work on what impacts black links have on G.798 and then Q14 will update G.874.1 for support. Too early for working on SNMP MIB as it is not still known which are the parameters that need to be managed.
[Deborah Brungard] Need to stay aligned with ITU work. For now, continue with this document. We’ll see if a RFC3951 bis is needed but need to wait for the definition of the parameters.
22 14:35 10 Title: RSVP-TE Extensions for Configuration SRLG of an FA
Draft: http://tools.ietf.org/html/draft-zhang-ccamp-srlg-fa-configuration-03
Presenter: Oscar González de Dios
[Deborah Brungard] How many have read the draft? 6-7
How many think this is a useful capability to? 6-7
[Lou Berger] The are two things going on in this document, one is how to add information to the RRO, the other is how to use it.
How many think collecting SRLG info in the RRO is a useful function? Same number, maybe different people
How many think taking prescribed actions on RRO changes is a useful function? No one
People like using the RRO for collecting SRLG info but do not like the second part of the document (describing what applications to do if an RRO changes)