85th IETF -- CCAMP Minutes
> First Session
> MONDAY, November 5, 2012
> 900 - 1130 Morning Session I
> Room Name: Grand Ballroom D
Minute takers: Dan King, Daniele Ceccarelli
CCAMP Minutes Session 1
Presentation††† Start Time††† Duration†††
> 0††† 9:00††† 15††† Title:††† Administrivia & WG Status
> Slides:††† †††† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-0.pdf
> Presenter:††† Chairs (Lou Berger)
Lou Berger: Deborah Brungard (CCAMP co-chair) had to cancel her attendance at the last minute due to Hurricane Sandy.
Adrian Farrel: Please note IPR
disclosures should be made often and early.
Lou Berger: A couple of agenda changes. One presentation removed today. One removed from tomorrow. ††
Lou Berger: We had a recent issue with a draft that the RFC-Editors were reviewing. It had a mismatch between the number of authors listed in the front page and at the back. Ultimately fewer than five is not a problem.
Adrian Farrel: RFC-Editors are looking for front-page names to match the authors section. They [RFC Editors] have a preferred maximum of five [authors].† The mailing list ďRFC-InterestĒ does provide some background on the current thinking.
Lou Berger: My experience is a reasonable limit, if they chose five I am not saying that is good or bad.
Adrian Farrel: We are going to have a joint meeting on Friday (in Orlando at IETF85) afternoon with the ITU-T SG15 Q6 members.
Lou Berger: This meeting is still being discussed and will be announced once confirmed.
Julien Meuric: In April you have a GMPLS E-NNI milestone. Is it going to be called E-NNI, has it already been decided or it can be changed?
Lou Berger: The name can be changed to match WG progress and will be changed as needed.
1††† 9:15††† 10†††
Title:††† RSVP-TE Extensions for
Collecting SRLG Information
>†††††††† Draft:††† http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect-01
>†††††††† Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-1.pdf
>†††††††† Presenter:††† ”scar GonzŠlez de Dios
Lou Berger: For
clarification. Your proposal includes both (LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES) to collect SRLG information, correct?
”scar GonzŠlez de Dios: Yes.
George Swallow: The text is not there yet, it's a proposal. The SRLG collection draft I will be presenting has both.
Khuzema Pithewan: A question on the use cases. When are we going to need this functionality?
Lou Berger: We already agreed this is a function we will be supporting.
Khuzema Pithewan: What are the use cases; do you have a pointer to framework?
Lou Berger: This is a mechanisms document, we don't require use cases. Do you have a use case in mind?
Khuzema Pithewan: Yes
Lou Berger: I do not see a reason that the draft could not include use cases, so please send your use case to the authors or the WG list.
Adrian Farrel: Do you intend to make this work multi-AS? I do not understand how this supports multi-AS. You will need an AS identifier.
Oscar GonzŠlez de Dios: The document requires the SRLG to be unified among different ASs.
Julien Meuric: As a multi-AS provider, you can have scenarios were you do not need to encode the AS number, but your comment is fair.
Zafar Ali: The metric collection draft [draft-ali-ccamp-te-metric-recording]
has use cases that could be used.
Lou Berger: A question on the partial recording. It is already supported [RFC3209]). There is no flag to say when that policy is applied. Why introducing it is this case? You need to make a general extension that applies to all cases.
Oscar GonzŠlez de Dios: Do you think we need to make this general functionality?
Lou Berger: [With contributor hat on] Either it should be a general RRO function or not done at all.
Oscar GonzŠlez de Dios: Ok we will take this to the list.
2††† 9:25††† 10†††
Title:††† Update from OTN/G.709
Working Group Last Call
>†††††††† Draft:††† http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-09
>†††††††† Draft:††† http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-04
>†††††††† Draft:††† http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-03
>†††††††† Draft:††† http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-04
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-2.pdf
>†††††††† Presenter:††† Daniele Ceccarelli
Lou Berger: Please authors, you need to provide IPR statements, if you have not already disclosed. The last two documents require review and update of conformance (RFC2119) language. A proposed standard RFC needs 3 things: (1) a narrative discussing what is being done; (2) then informative text describing how itís being done, and (3) RFC2119 conformance language telling implementers and testers what needs to be done to conform to the document. A (final) technical comment, error codes in signaling document needs to be looked at. A timer mismatch for crankback for instance.
3††† 9:35††† 10†††
Title:††† Link Management Protocol
(LMP) extensions for G.709 Optical Transport Networks
>†††††††† Draft:††† http://tools.ietf.org/html/draft-cecczhang-ccamp-gmpls-g709v3-lmp-00
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-3.pdf
>†††††††† Presenter:††† Xian Zhang
Lou Berger: [Poll] How many have read the document? [A small number, ~10]
[Poll] How many think this is important functionality (even if havenít read the document)? [About 1/2 the prior number.]
How many have read the document and think itís *not* useful? [No hands.]
Lou Berger: Interesting but mixed feedback.
Julien Meuric: There are three concepts in the document, so looking at it as a whole is a bit difficult. Perhaps the answers would be different if asking about each separately.
Xian Zhang: Maybe the lack of interest is due to the fact that LMP is optional in GMPLS?
Lou Berger: Perhaps, at
this point the document should continue as individual document and see if more
interest is generated. The discussion should continue on the list.
> 4††† 9:45††† 10††† Title:††† Multi-layer implications in GMPLS controlled networks
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-4.pdf
>†††††††† Presenter:††† Dimitri Papadimitriou
Rajan Rao: With regards to
example 1. What kind of LSP is it? Is the intent to have an end to end LSC LSP?
Dimitri Papadimitriou: The intention is to create an LSC LSP.
Rajan Rao: Why there is the need to use an IACD?
Dimitri Papadimitriou: The ISCD objective is to advertise capability to regenerate (Example 1).
Curtis Villamizar: In that example
 you are using the regeneration capabilities. The next slide [example 2] is
not really a LSC LSP from Node A to Node D.
Dimitri Papadimitriou: This is a different scenario. This is showing an add-drop multiplexor, injecting packet.
Curtis Villamizar: It is a PSC LSP. In any case you are making a new layer.
Lou Berger: This is an interesting topic. We have some issues that need to be addressed. Please continue discussing during the week, offline or on the mailing list. Please keep in mind that while the talk here has been about routing, we also have signaling implications.
5††† 9:55††† 10†††
Title:††† OSPF-TE extensions for
MLN-MRN based on OTN
>†††††††† Draft:††† http://tools.ietf.org/html/draft-rao-ccamp-otn-mlnmrn-ospfte-ext-00
>†††††††† Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-5.pdf
>†††††††† Presenter:††† Rajan Rao/Khuzema Pithewan
Daniele Ceccarelli: One comment. Why
are just considering OTN?
Rajan Rao: First slide, if you look at the OTN encoding, we encode everything on one encoding type.
Daniele Ceccarelli: I agree that the new definition of the OTN ISCD perfectly fits with multi-layer networks, but it should be extended to make it generic and cover the case of any hierarchy over any hierarchy.
Rajan Rao: Sure, maybe SDH. That is a valid point.
Khuzema Pithewan: This proposal talks about the upper layer and lower being OTN. We do not need to identify a specific layer.
Daniele Ceccarelli: Itís not clear why we should just cover OTN. Why not SDH over SSON?
Rajan Rao: Do you have use cases?
Lou Berger: We are a little over time on this topic, but we can continue it on the list. Itís not clear if the previous documents are solving the same problem. We should see if there is some commonality. Anything we can do to reach agreement on what problem the draft(s) are trying to solve will help the process. I suggest discussing this on the list.
6††† 10:05††† 10†††
Title:††† Expressing LSP attribute
>†††††††† Draft:††† http://tools.ietf.org/html/draft-margaria-ccamp-lsp-attribute-ero-01
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-6.pdf
>†††††††† Presenter:††† Cyril Margaria
Adrian Farrel: Having been an
author of other LSP Attributes I am having a problem with the use case for
Cyril Margaria: We have a use case.
Adrian Farrel: Document needs text and context. I am not saying this is a bad idea; I need the document to say why it is a good idea.
Lou Berger: Just a few references to the documents that will use this.
Cyril Margaria: Ok.
Jon Hardwick: A good idea to extend to the RRO, see Oscarís SRLG collection draft for requirement and use case.
Lou Berger: You are suggesting something slightly different, are you suggesting that we combine the function to have an RRO with larger object and deprecating the existing RRO?
Jon Hardwick: †I am not talking about deprecating the existing RRO. This new object would capture hop information.
Lou Berger: Your point of having a single function is a good one that we should think about. Are we optimising the wrong way for a special case? How often are we really going to have objects that are larger than an ERO? If itís common, than going down the current path makes sense.† If uncommon, than maybe we should deal with it as a special case within the ERO. Should we look at a fragmentation approach?
Cyril Margaria: In Vancouver (IETF 84) we did discuss the fragmentation approach. However fragmenting an object across multiple sub-objects was not ideal.
Lou Berger: Agreed, but itís very rare perhaps we should just take the approach with less correlation. [Comment as a contributor]
Lou Berger: Switching to high level questions:
[poll] How many think functionality is necessary? [An okay number]
[poll] How many people think the approach being taken is the
[Almost the same number]
[poll] Should this document be the foundation of the WG? [Almost the same number Ė as question 1]
[poll] How many think we should wait for the work to be more
[A small number, almost half and half]
7††† 10:15††† 10†††
Title:††† RSVP-TE extension for
recording TE Metric of a LSP
>†††††††† Draft:††† http://tools.ietf.org/html/draft-ali-ccamp-te-metric-recording-03.txt
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-7.pdf
>†††††††† Presenter:††† George Swallow
Lou Berger: [poll] How many think the functionality is needed? [A good number]
[poll] How many have read the draft? [About
the same number.]
[poll] How many think it is a good foundation? [Almost the same number]
Lou Berger: Good indication of support, letís take this to the list. Two comments, the flags for modification or partial is general capability so look at to see if a general solution makes sense.
George Swallow: Those flags are not in the draft but the attributes are.
Lou Berger: That makes it easier to poll for the document. The other comment is that we need to let the other working groups know the progress of the document.
8††† 10:25††† 10†††
Title:††† RSVP-TE Extensions for
Signaling GMPLS Restoration LSP
>†††††††† Draft:††† http://tools.ietf.org/id/draft-gandhi-ccamp-gmpls-restoration-lsp-00.txt
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-8.pdf
>†††††††† Presenter:††† Zafar Ali
Igor Bryskin: What you
described can be done with existing mechanisms [make-before-break].
Zafar Ali: This is an explicit indication for the egress node. [Slide 7] this shows how the egress knows what protection is used and allows coordination with the ingress node.
Igor Bryskin: Why does the egress nodes need to have this info?
Zafar Ali: This allows ingress to associate the LSPs.
Igor Bryskin: When you do make-before-break you have exactly the same situation.
Lou Berger: Another the way of saying this, consider the case when you're adding a protection path not because of a failure but just because you want to add a path. Once you address this case you also solve your case.
Igor Bryskin: Exactly true. Association
objects and existing IDs are sufficient.
Zafar Ali: I will take this offline with Igor.
Dimitri Papadimitriou: Do we want to keep the nominal path in dynamic restoration? Can you have a look at RFC4872 and state what cases are not addressed by the make-before-break and see if weíre talking about a BCP or new cases?
Lou Berger: You have enough information and feedback to discuss some use cases and explore offline. We have a number of good comments please take them to the list.
9††† 10:35††† 10†††
Title:††† RSVP-TE Recovery
Extension for data plane initiated reversion, protection timer and SNC options
>†††††††† Draft:††† http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-07
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-9.pdf
>†††††††† Presenter:††† Zafar Ali
Cyril Margaria: In the SNC mode
you address segment monitoring but this may require a TCM level, but it seems
Zafar Ali: If you feel there is the need for additional parameters we can discuss offline.
Lou Berger: Many things changed since the draft was last time presented, in particular the WG OAM documents. Please see if you can realign with those documents. If you can make an argument that there is no alignment necessary, thatís fine but you should take a look.
Dimitri Papadimitriou: With regards to the initial version from Attila, the question about setting up to the timers was not progressed. I need to try to remember why. It was related to the type of protection schemes supported, do we also need signaling to advertise to the other end? We never determined if putting this information in the signaling was a good thing. Having feedback on this would be good; as a cornerstone of this work is should an object be carrying timing information for setting up these protection schemes.
Zafar Ali: A use-case is OTN protection schemes.
Lou Berger: Also triggering some memories, the question (when we last discussed) came down to if the information was managed per-LSP or on a per-device basis.
Dimitri Papadimitriou: Not saying which was best, just saying it needs to be looked at.
10††† 10:45††† 10†††
Title:††† RSVP-TE Extensions for
Lock Instruct and Loopback in MPLS Transport Profile
>†††††††† Draft:††† http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-04
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-10.pdf
>†††††††† Presenter:††† Mach Chen
Lou Berger: There was a
comment at the last meeting. Is this scoped to -TP only?
Mach Chen: No, there is scope for other scenarios.
Lou Berger: If the answer was yes, a mechanism already exists and the answer would have been go use that mechanism. If not, the document should read as if it applies to any technology and this is not the case. I would suggest changing narrative text so it applies to GMPLS, rather than just MPLS-TP terminology. Go generalise your document, replace -TP specific terms with GMPLs terms then bring it back for further discussion.
Mach Chen: Ok.
George Swallow: Something that isnít documented anywhere is the interaction between locking an active path and protection switching? If youíre using end-to-end OAM you need lockout coordination. What are your assumptions, doing this in the control plane will be a lot slower [versus data plane].
Lou Berger: That is already discussed in RFC4872/3. That discussion may be beyond the scope of this document.
Greg Mirsky: Lou you are accurate, however that RFC6535 only defines operations related to ACh channels. Are you saying that TP control is through OAM and not signaling?
Lou Berger: I appreciate that Mach said this applies to all GMPLS controlled technologies and not -TP only, so we donít have to address that particular question. There is a general feeling to not define duplicative mechanisms. If was just TP scoped, Iíd be inclined to say use the existing mechanisms. Since the stated scope is beyond TP, we don't have to get into that -TP specific argument.
11††† 10:55††† 0†††
Title:††† Multi-domain network
integration framework in the context of overlay model
>†††††††† Presenter:††† Daniele Ceccarelli
[Draft not presented]
12††† 10:55††† 10†††
Multiprotocol Label Switching (GMPLS) External Network to Network Interface (E-NNI):
Virtual link Enhancements for the overlay model
>†††††††† Draft:††† http://tools.ietf.org/html/draft-beeram-ccamp-gmpls-enni-01
>†††††††† Slides:††† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-12.pdf
>††† †††††Presenter:††† Igor Bryskin
Khuzema Pithewan: What are the switching
Igor Bryskin: It could PSC, MPLS, WDM, anything.
Khuzema Pithewan: Is this an inter-layer issue?
Igor Bryskin: If a user selects this link, it is a virtual link, so it could be hierarchy of links, real links, but they have the same attributes of the virtual link advertized.
Khuzema Pithewan: What about F to A (slide 4)
Igor Bryskin: It could be anything, PSC for example. The only requirement is that the control plane is separated from the data plane. If you look at the use cases in the draft these are good examples.
Dimitri Papadimitriou: Did you look at VNT (Virtual Network Topologies). What has changed not to use existing mechanisms?
Igor Bryskin: We speak about overlay model and not a peer model. it could be an existing layer, there is not a conversation from the virtual link to a "real" link.
Dimitri Papadimitriou: See RFC6001.
Igor Bryskin: If we advertised a link it may have SRLGs.
Dimitri Papadimitriou: It may SRLG but it could be other properties.
Igor Bryskin: This draft is not a signaling mechanism, it is a model.†
Don Fedyk: We should define what's in the UNI model and then progress the ID as WG.
Igor Bryskin: We need to identify the label on the CP interface.
Snigdho Bardalai: this doc describes overlay network. You made assumptions that there is a link between overlay and core network, it can be also a node. Did you cover that case also?
Igor Bryskin: It is covered. It is all about domain separation.†
Kam Lam: You need to clarify client and the case of multiple server layers.
Igor Bryskin: The client is not aware of server layers. It is just about the client having layer that he wants to work at. The work is about virtualization layers into a client layer domain.
Lou Berger: A good discussion, but weíre over time, please send comments to list. I will send my comments as well.
> 13††† 11:05††† 10††† Title:††† Layer 1 VPN Enhanced Mode - Overlay Extension Service Model
>†††††††† Draft:††† http://tools.ietf.org/html/draft-fedyk-ccamp-l1vpn-extnd-overlay-00
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-13.pdf>†††††††† Presenter: †††Don Fedyk
Snigdho Bardalai: Not clear to me
which use cases this document is covering. If you have multiple UNIs not
converging at the client node and you still want to have them diverse. Is this
Don Fedyk: Yes. We would support diversity for that.
Snigdho Bardalai: So the SRLG information would have to be configured somehow?
Don Fedyk: Yes, say statically configured. It is discussed in the draft.†
Khuzema Pithewan: How does the second mechanism, path affinity identifier, works? If path from CE 3 is established to CE 4, which is dual homed and the first LSP is created then the next PE would need to know how the second LSP was related and needed to be disjointed.
Don Fedyk: The way we dealt with customer and provider addresses was to use IGP extensions. To be diverse, you need knowledge. It could be dynamic or static.
Lou Berger: As he [Khuzema Pithewan] mentioned similar function exists in other documents. Why is this only applicable to L1VPN?
Don Fedyk: Yes, we want to review this. We think we can apply to other cases.
Lou Berger: Why not strip L1VPN context, this could be just as applicable as those other extensions?
Don Fedyk: We are looking to change the name and review the references to L1VPN.
> TUESDAY, November 6, 2012
> 1700-1830 Afternoon Session III
> Room Name: Grand Ballroom D
> Presentation Start Time Duration Information
> 0 17:00 5 Title: Administrivia
> Presenter: Chairs
Lou Berger: Based on the private response to the chairís question on implementation of the WSON documents, the chairs see no reason to change the intended publication status/track of the WSON documents.
Julien Meuric: Can you comment on the order of magnitude of support, how many implementations?
Lou Berger: More than 1. If anyone is interested in putting together an implementation survey, please feel free. Such a survey is necessary when moving to the next standards level.
> 15 17:05 15 Title: Status update on WSON & Signaling Extensions for Wavelength Switched Optical Networks
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-15.pdf
> Presenter: Giovanni Martinelli
Lou Berger: If you didnít put in the common object, what solution would you take?
Giovanni Martinelli: We need to figure out which one. No preference.
Young Lee: We have a WSON specific encoding but we decided to use the LSP-attribute encoding and move aligned with draft-margaria. One question: is it possible to refer to an individual draft during the last call?
Lou Berger: You could but itís a risky approach. Since this is a normative reference your document could be published only after that. In case the referenced document never made it, your document would be forever blocked. In this particular case, since itís a small document and if it is a WG document, it might catch up quickly. The alternative is to use a new object dedicated to carry just this. One thing that came out yesterday was the size of the information that might be carried and it seems to be quite big.
Giovanni Martinelli: We need to add some text on this. The amount of information could be big but in particular in the signaling case it is likely to be much smaller (one resource block instead of the full list).
Lou Berger: I
would like to synch with Deborah on the result of the discussion on the
individual document (draft-margaria) in order to poll
the WG for adopting the document. Anything to add on the
Young Lee: Itís very close to WG last call. There are no pending issues except editorials.
Giovanni Martinelli: I have a couple of updates planned.
Lou Berger: Ok please provide an editorial pass to prepare for Last Call. Make sure you check procedures and format compliance with RFC2119 which will help speed the Last Call process.
> 16 17:20 10 Title: SNMP MIB to manage GMPLS with General Constraints support & A SNMP MIB to manage GMPLS TED with WSON specific support
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-16.pdf
> Presenter: Gabriele Galimberti
Lou Berger: MIBs are always something that are slow to follow functionality but are in the scope of this WG. Contributors are really appreciated.
> 17 17:30 10 Title: Information Model for Wavelength Switched Optical Networks (WSON) with Optical Impairments Validation & Encoding for WSON Information Model with Impairments Validation
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-17.pdf
> Presenter: Giovanni Martinelli
Igor Bryskin: Excellent idea to extend the connectivity matrix. I would like to further extend it with a vector of costs (e.g. delay, SRLG) saying what does going from a link to another link imply. The path computer could take these impairments into consideration and compute diverse paths also inside the node (also optical feasible paths as well).
Giovanni Martinelli: Thanks for the comment
Kam Lam: If I correctly remember we decided in Vancouver to progress the work with the ITU application codes, so we donít have to deal with these parameters individually, am I right?
Lou Berger: I think those are separate discussions. The work on impairments had not started yet and with the original set of WSON works coming to a conclusion we can start discussing this. These are individual documents, while the others are WG documents so we as a WG have not decided to start this specific work. Itís just a proposal.
Malcolm Betts: We have had strong feedbacks from our friends in Q6 that the approach they are taking on impairments is to define application codes, not to define individual impairments and try to match every parameter, so they define application codes that can be applied to receiver, transmitter and individual links. The other thing we have done from an architectural point of view is to generalize that to an application identifier so that there can be some proprietary extensions (e.g. an identifier saying that this transmitter, this receiver and this link can work together).
Lou Berger: How does this work through transit nodes like ROADMS?
Malcolm Betts: This is part of the link construction procedure, which is a non-trivial exercise.
Lou Berger: I think this is where the work is aimed.
Malcolm Betts: If you want to select a path on the fly you need to have done a lot of pre-computation to understand which application codes this path can support, then what youíre looking for is a path that can support an application code rather than try to figure out exactly what the impairments on a link are at the time youíre trying to set it up. Thatís some good material for discussion with Q6 at our next meeting.
Igor Bryskin: How do I do end to end optical path computation with impairments? It is a non-linear problem, wavelength and inter-wavelength dependent. How is it possible to e.g. evaluate OSNR in the path without full information and define where to put regeneration points?
Gert Grammel: Question to Malcolm. A couple of meetings ago you said the black link is not switchable at all, now it seems to me you are suggesting it is switchable. Whatís the current state?
Malcolm Betts: The black link is an approach that is being defined by Q6 to define compatibility, so the black link is not a thing is an approach. If I do path computation and have all these links that meet an application code I can choose to activate one of those links and know that if I connect it to compatible tx and rx it is going to work and that does mean taking into account all the other things that is expect to be on the fiber as well. In conclusion, no you canít switch black links but can use the concept to set up connections.
Gabriele Galimberti: We talk about pre-calculation impairments, while here we want to address post-calculation ones, we calculate the feasibility of a path when the path is identified, so we need all the info.
Lou Berger: Reading the docs I see you keep alignment with the ITU-T data plane definitions and thatís good to see. This is definitely a topic to be discussed in Orlando.
Malcolm Betts: There is a lot of sensitivity on black links and how can be used as it is not clear what can be done with them.
> 18 17:40 10 Title: Framework for GMPLS based control of Flexi-grid DWDM networks
>†††††††† Slides:††† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-18.pdf
> Presenter: Ramon Casellas
Lou Berger: When you say (in the slides) that there was an agreement after IETF84 are you referring to an output of the meeting or of offline meetings? Because it was not agreed during the CCAMP sessions
Ramon Casellas: Offline meeting.
Gert Grammel: I think media channels are pretty straightforward to be used with flexi-grid, what I was wondering is whether there is a correspondence in the ITU-T docs to media channel or there is a different notion?
Lou Berger: †This new terminology is coming straight from the ITU-T.
Ramon Casellas: We would appreciate feedbacks on the utilization of media channels and network media channels; setting up the media channel as huge pipes and then setting up a network media channel is worth it or could it be just enough to deal with one of the two entities?
Gert Grammel: My concern is just related to terminology, just to avoid confusion.
Lou Berger: Generally, in terms of what needs to be supported, if the data plane supports it you need to cover it, otherwise donít worry about it.
Ramon Casellas: The fact is that there is only one level of switching at the lower layer but some people suggest it is better to establish the media channel first and then the network media one.
Lou Berger: To me it sounds like the old discussion on waveband.
Ramon Casellas: Weíll discuss more, including an offline discussion tomorrow.
> 19 17:50
0 Title: RSVP-TE Extensions for GMPLS
control of Spectrum Switched Optical & OSPF extensions for support spectrum
sub-band allocation >
Presenter: Qilei Wang
> 20 17:50 10 Title: An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications
>†††††††† Slides:††† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-20.pdf
> Presenter: Gabriele Galimberti
Lou Berger: The third bullet in the final slide is very important. We need to make sure the document is aligned with any new ITU-T recommendation in order to avoid possible discussions.
Gabriele Galimberti: We reviewed it and believe itís aligned, please all interested people review it also to see if further readjustment is needed.
[poll] Ė How many have read the document? [A few] Ė
[poll] Ė How many think this is a good functionality to work on? [about the same].
Lou Berger: If you think this is important functionality, please review and comment on the list, even just to say that itís useful work
> 21 18:00 10 Title: Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage black-link optical interface parameters of DWDM application
>†††††††† Slides:††† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-21.pdf
> Presenter: Gert Grammel
Lou Berger: †
[poll] Ė How many think this is an important function to have? [About the same as last document Ė a few.]
[poll] Ė How many have read the document? [Slightly more.]
[poll] Ė How many like the approach proposed in this document? [same number]
[poll] Ė Anyone has reservations? [none].
Lou Berger: So about the same result and response as the prior document: Please take a look and comment, and if interested send comments to the list.
> 22 18:10 10 Title: Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-22.pdf
> Presenter: Dhruv Dhody
Lou Berger: It seems a pretty reasonable functionality. When you are going cross area, do you have an area ID and an AS ID?
Dhruv Dhody: Yes, you can include both or just one of them.
Lou Berger: It could be useful to add some narrative to explicitly state that.
Ramon Casellas: We came to the CCAMP for the encoding of the sub-objects, roles are specified in the PCE-P documents and there is detailed text on this case.
Lou Berger: Does this mean that you donít see this being carried by RSVP-TE?
Dhruv Dhody: No, It can be carried by RSVP-TE also. Weíll align the text in the two drafts.
Ravi ???: Policy needs to be in place to cross domains. What about PATHKEY?
George Swallow: Agree with you from a user point of view, but from a protocol point of view you just say you can do these things.
> 23 18:20 10 Title: RSVP-TE LSP Route Diversity using Exclude Routes
>†††††††† Slides:†† http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-23.pdf
> Presenter: George Swallow
Igor Bryskin: You can do all of this excluding links and SRLGs. You have a draft to collect SRLGs, so you can peer them.
George Swallow: There is a WG draft to gather SRLG information. A UNI is a policy interface, we do not expect every deployment to have the same trust level and not to open up their optical network to everyone.
Igor Bryskin: So you indicate which LSPs to exclude from the path computation. You can do that only from the same node, right?
George Swallow: If there was a PCE internal to the optical network and you had been informed (by other means) yes, but without that functionality you are excluding yourself.
Igor Bryskin: There could be a situation in which you create an LSP and then ask to go away from this LSP and the answer might be ďnoĒ, if you do it simultaneously it doesnít work, you need to do it sequentially.
Rob Shakir: The LSPs are identified by RSVP parameters, any interest in using an ID?
George Swallow: Managing a new name space might be an issue.
Adrian Farrel: source address, destination address and LSP ID should be sufficient
Lou Berger: Back to Igorís comment on why it this needed and your response being this just UNI, this should apply also in the case of inter domain, maybe even inter-area in some cases. In my personal read, I found it hard to parse the document sometimes. I like the function but the text needs to be improved.
George Swallow: Is that a requirement to fix to make it a WG document?
Lou Berger: That was an individual comment.
Adrian Farrel: I can remember when we closed the loop on the association object as an alternative to this function.
Lou Berger: So you would define a new association object type and that type would say: ďdonít match this association objectĒ?
Adrian Farrel: Yes, it is association, but for diversity.
Zafar Ali: XRO better fits with this application because all the machines support XRO, if you do it with the association you need to do more work.
Curtis Villazimar: For BRPC you are trying to associate with an LSP that is from another ingress, this is way I think the XRO works and the association object doesnít.
Adrian Farrel: Disagree.
Gert Grammel: Even if the ingress is different, the originator is the UNI, so it should be a single one.
Geroge Swallow: In one case is the UNI, in the others isnít. The point is that it is going somewhere we you donít have complete information.
Curtis Villazimar: Using BRPC and setting up two different LSPs, when setting up the second you have collected SRLGs but for the LSPs the mid-points have no association knowledge.
[poll] - How many think this is a useful piece of function? [A good number]
[poll] - How many have read the document? [About the same]
[poll] - How many think this is the right way to go for the WG if we decide to support the function? [A little more than half.]
[poll] - Does anyone want to express concern? [No]
> Adjourn 18:30