>†††††††††††† CCAMP Agenda
>†††††††††††††††††††† for the
>†††††††††††† 84rd IETF Meeting
>†††††††††††† Version: Jul 31, 2012
>†††††††††††† First Session
>†††††††††††† WEDNESDAY, August 1, 2012.
>†††††††††††† 900 - 1130 Morning Session I
>†††††††††††† Room Name: Regency D
> Presentation†††† Start†††† Duration†††† Information††††
> 0†††††††††† 9:00†††† 15†††† Title:†††† Administrivia & WG Status
>†††††††† Presenter:†††† Chairs
Deborah Brungard: draft-ietf-ccamp-lmp-behavior-negotiation is ready for last call
Oscar Gonzalez de Dios: provided an update on draft-ietf-ccamp-rsvp-te-srlg-collect. No update since becoming WG document few months ago. Have received some comments, as well as request to merge with an individual draft (http://tools.ietf.org/html/draft-ali-ccamp-te-metric-recording-00) that is being presented later.
Deborah Brungard: Itís time to provide ITU-T Q6 with an update via liaison
Lou Berger: The KARP WG chair, Joel Halpern has request that we identify individuals interested in contributing to the KARP WG security analysis of LMP and RSVP. If interested, please contact Joel.
> 1†††††††††† 9:15†††† 10†††† Title:†††† WSON Info/Generic Encoding/OSPF-Generic Constraints
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-08
>†††††††† Presenter:†††† Greg Bernstein
> 2†††††††††† 9:25†††† 10†††† Title:†††† WSON Encoding/OSPF-WSON Signal Compatibility
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-14
>†††††††† Presenter:†††† Greg Bernstein
Giovanni Martinelli: The signal compatibility it's not only for OEO.
Greg Bernstein: In the WSON specific document it is as the only place where we use it is the resource blocks. We can add new stuff to the document but itís new functionality.
Malcolm Betts: First question, or shall we wait?
Lou Berger: Is it clarification of these slides?
Malcolm Betts: It's exactly on this point. We have been working in ITU on the OTN architecture and on the list of parameters defining signals and after some discussion with experts in Q6 we decided that we should throw that stuff out and simply use application identifiers which include the application codes defined by Q6, because signal compatibility is well beyond just FEC type and modulation type, itís a list of other parameters which are interesting but have no sense unless they are in a coherent set.
Lou Berger: This is a set up for the upcoming discussion after Lyndonís presentation.
Giovanni Martinelli: How about the wavelength priority, how authors want to deal with the wavelength priority added in general constrain encoding WG doc?
Young Lee: The priority label concept was proposed by Rajan Rao. We solicit to have a look at the archive of the mailing list to see Rajan's proposal. We try to accommodate requests from the WG and I think Rajan is happy with what we came up with. This is the background, just to clarify.
Giovanni Martinelli: I did a couple of mails on mailing list around last IETF meeting and just before this one.
Lou Berger: Please resend the mail to the list to restart the discussion
Giovanni Martinelli: Already resent and waiting for response.
> 3†††††††††† 9:35†††† 10†††† Title:†††† WSON interface class and WSON signaling
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-martinelli-wson-interface-class-03
>†††††††† Presenter:†††† Lyndon Ong
Greg Bernstein: Clarification of "no application codes are NOT only for G.698[1 and 2]".
Lyndon Ong: There is a mistake, it should be "application codes are NOT only for G.698[1 and 2]".
> 4†††††††††† 9:45†††† 10†††† Title:†††† Discussion & next steps on WSON and interface class (if needed)
Malcolm Betts: Application codes cover also DWDM (G.694.1) and CWDM (695), the important point of an app code, is that it defines coherent set of parameter and not a set of individual parameters. A list of parameters is not enough to provide compatibility, Iím heavily in favor of encoding these parameters. There are cases in which you want to be able to read some of these values but it doesnít mean that you should be able to deal with application codes. The term application identifier should be used in a more general way than just strictly ITU defined application codes.
1)OIC is a routing constraint. We brought up FEC and Modulation issues, as these could cause blocking condition in setting up the path. The question is, this OIC is a routing constraint that the CCAMP should be concerned about? Or this is something more fundamental in the low level fundamental that needs to be checked when setting up a legacy path. Is this really a routing issue or maintenance issue?
2) If you look at OIC in the G.695.1 it includes several parameters including fiber type, hence impairments, which are not in WSON impairments free scope.
Lyndon Ong: On 1) the application code is used to state whether two interface are compatible or not, itís something you should do during the path computation. On 2) was the question abot the links, the part of the application code has to do with type of fiber. The application code is not necessarily a single one, you might have multiple of them that are supported by an interface, one for each type of fiber for example. The interfaces just need to have a single OIC in common.
Young Lee: I want people to be aware of the context. This may fall into impairment WSON, instead of trying to replacing our encoding. Maybe a new draft supplementing ours is more appropriate as OIC doesnít apply there.
Malcolm Betts: Slightly confused with comments. The mapping between application code and OIC is straight forward. Nothing is changed. In terms of impairments aware or not is a matter of what assumptions are made over the link. If you want to start talking about implementation impairment aware we must start from application codes related to the links, if we ignore impairments we have implicitly compatible application codes. Again I think nothing changes.
Julien Meuric: This proposal allows me easily controlling my network and connect different networks together. This is an easy way, I like it. It is an efficient way to do it.
Kam Lam: Q14 is working on information management and information model protocol neutral and management of those information codes. Actually it is more general and application codes are called application identifiers. Transponders along a path select a common set of application identifiers among the ones supported. Picking the same application code enables interworking but there are additional things that need to be specified.
Lou Berger: What is the timing of the document you are describing
Kam Lam: Requirements in September if things are progressing well, information model is part of a bigger work but the goal is September too.
Lou Berger: Youíre suggesting to move from an application code to an application identifier?
Kam Lam: Yes, in order to support also proprietary ones. Application codes are only the standard ones. Application identifiers cover cases, standards and proprietary one.
Lou Berger: We try not to get too far ahead of where the ITU is, so if there is new terminology coming out it needs to be specified formally. If these documents are coming out in September a liaison would be very useful.
Greg Bernstein: I have nothing against application codes, G659 is around since 2006 (698.1, 698.2), do you want to use these for encoding; just trying to figure out what changes I may need in the document. We are routing signals after they have been split off, not looking at interface compatibility; this is internal to the box going to OEO resources we have modeled. These contain sets of regens of convertors, we are not trying to solve the issue of compatibility between interfaces. No problem in principle, but should we look at a bigger picture and which document. I would like to finalize this document. We have no issue with application codes, it is possible to fill them in later but if you want us to remove those, fine.
Giovanni Martinelli: with the optical interface class we demand ITU to state if two interfaces are compatible, WSON just provide protocol object to carry them around. And this is not only for OEO but for ingress/egress point as well.
Lou Berger: this brings up the question: does the application code have the information that is being proposed to be replaced implicitly defined within the scope of the code.
Greg Bernstein: Iím looking at G.959.1; there are 5-6 fields in it. It has the tributary signal type (the one we use), it does not have the FEC type. Thatís why I was asking, are we going to make our codes based on ITU codes? If so weíre going to remove that field and leave the FEC type and that satisfies our requirements.†
Deborah Brungard: proprietary FEC would not appear in the application codes but in the application identifiers.
Lyndon Ong: There are some discussion on how the stuff in the WSON documents is being used, there seems to be some confusion about that. With the FEC there is a single standard FEC, other ones are either proprietary or informational.
Lou Berger: Do the app codes have the information that is being prosed, already defined?
Eric Gray: question for clarification. I don't understand the statement "No application codes are NOT only for G.698.1/2"
Lyndon Ong: you should read it as: "Note, application codes are NOT only for G.698.1/2
Malcolm Betts: Going back to some off-line discussions on flexi-grid, the question is: what is it we are switching, setting up. GBs remarks on WSON scare me. We setup paths/signals, so you check signal transmitters/receivers to make sure it works. So if we want interconnections to work we need to make sure there is compatibility at signal layer.
Greg Bernstein: we added a long time ago in WSON wavelength converters and OEO, so we agreed on that.
Cyril Margaria: Then I think compatibility applies.
Deborah Brungard: You said we miss a WSON LMP document, so itís hard for people to sort out where this information is applicable for.
Greg Bernstein: WSON was initially only for wavelength switching. An important special case came in with wavelength converters.
Lou Berger: Going back to Malcolmís first statement. There are two ways †to represent optical signal, ITU-T started working on composite fields then realized there were too many and went with application codes. This is an old document and we started with individual fields. The proposal in the last draft is to follow what the ITU has done using the composite fields instead of the individual fields. This doesnít mean losing information but representing it in a different form. The question to the WG is: do we follow how the ITU-T represents the optical signals.
Question from Giovanni for Greg: according to the previous comment it seems that signal compatibility is not necessary for wson-rwa (no-impairment) so I'm wondering why signal compatibility are there
Greg Bernstein: are we going to represent it as a string and we are done?
Lou Berger: There encoding is represented in the draft. There are two points:
1) Do we want to represent optical signals as per ITU-T representation of the optical signals?
2) How do we want to represent it?
Lou Berger Question to the WG: Who thinks we should keep the current approach: small number
Lou Berger Question to the WG: Who thinks we should move over to the proposed application codes? [A large number of people]
That's a good consensus; we will take to the list. Also discuss format on list if you have issues.
> 5†††††††††† 9:55†††† 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-08
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-04
>†††††††† Presenter:† †††Daniele Ceccarelli
Lou Berger: Comment on Compatibility text - This implies that all new nodes will always have to support the old encoding; this is a higher bar than we typically impose on new functionality. Typically weíve said that you must not break whatís out there, detect what is old and it is ok if you donít interoperate with older implementations. Is this an intentional raising of the bar to require brand new implementations to also support the legacy approach?
Daniele Ceccarelli: Personal comment, this is not a problem as i donít think there are RFC4328 based implementations.
Lou Berger: It is a problem because it says that if youíre a new implementation you need to be compatible with the old stuff.
Fatai Zhang: If my memory is correct the framework says that the new nodes may support the legacy approach, not always.
Lou Berger: No, the text in the slides is what is present in the framework document.†
Jon Sadler: I am aware of implementations of RFC4328. I am concerned about the approach being taken here as the changes are not only in the label format but also in the generalized label request object and traffic spec.
Lou Berger: Are you commenting about a gateway function where an approach can be used downstream and a different one upstream?
Jonathan Sadler: No, the question is what happens with traffic specs.
Gert Grammel: concern about the definition of new node. When g709v4 will be available, the definition will be out of date.
Lou Berger: So is this intentional?
Daniele Ceccarelli: It was intentional but we can discuss about it, can be modified.†
Lou Berger: Chair hat off. I will make a proposal to the list to relax the requirement. There is the requirement not to brake what already exists.
> 6†††††††††† 10:05†††† 10†††† Title:†††† Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-02
>†††††††† Presenter:†††† Daniele Ceccarelli
> 7†††††††††† 10:15†††† 10†††† Title:†††† Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-03
>†††††††† Presenter:†††† Fatai Zhang
Eric Gray: First, good draft. I noticed a new section where you update values from RFC4328, you should indicate that this ID updates RFC4328 in the header.
Lou Berger: You need to review procedure section and make sure conformance language is used correctly. I checked the latest version and seen no update in the language e.g. in section 8 from the comment made at the last meeting.
Fatai Zhang: Ok, will check again.
> 8†††††††††† 10:25†††† 10†††† Title:†††† Multi Layer Implications in GMPLS controlled networks
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-bcg-ccamp-gmpls-ml-implications-01
>†††††††† Presenter:†††† Dimitri Papadimitriou
Lou Berger: We have an opportunity for G709 discussion after the next presentation.
> 9†††††††††† 10:35†††† 10†††† Title:†††† Revised Definition of The GMPLS Switching Capability and Type Fields
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-berger-ccamp-swcaps-update-02
>†††††††† Presenter:†††† Julien Meuric / Lou Berger
Deborah Brungard: Been discussed at various prior meetings. No resistance to deprecating PSC 2-3-4. Any concern better raising now.
Deborah Brungard Question to WG: How many people have read? [Good number]
Deborah Brungard Question to WG: Does anyone have concerns? [None] We will take to list a quickly mode to adoption.
> 10†††††††††† 10:45†††† 15†††† Title:†††† Discussion & next steps on OTN and multi layer (if needed)
Rajan Rao: On the MLN implications presentation. Single pool model is understandable, what I need to understand is why we need the ISCD for the SDH.
Dimitri Papadimitriou: You have the possibility to directly inject/extract the SDH to the line interface.
Rajan Rao: So in the multiple pool case you're saying there is an interface for SDH?
Dimitri Papadimitriou: Yes. What the IACD provides is information of the interconnection between the switching capabilities.
Rajan Rao: Question on the muxing hierarchy, the switch cap and encoding type alone are not enough to distinguish a layer, we need more information possible in the ACSI.
Dimitri Papadimitriou: Yes. You have two possibilities: There are several possibilities to explore. If you want to restrict access between switching capabilities then simply do not advertise the IACD.
Rajan Rao: comment on the muxing hierarchy. Switch cap and encoding type are not enough to understand in which branch of the hierarchy the client layer is muxed
Dimitri Papadimitriou: Two things, relation between ODUs, so you know the IACDs are related or put a description inside the technology specific part of the IACD.
Rajan Rao: We did respond to this draft. We think it has on implications to the [G.709v3] routing draft.†
Lou Berger: How do you think this has implications on the routing draft?
Rajan Rao: we can define a new switching capability for each ODU
Lou Berger: The switch cap document does not modify switching capabilities for OTN. The agreement is a single switching capability. There was a statement in the routing presentation that may have been confusing on this point.
Steven Shew: General comment, I support generalizing description of adaption instead of being OTN specific. 2 years ago Q12 sent an extensive liaison to CCAMP describing a model for handling hierarchies using a concept of transitional links. It shows an example which covers all these cases. Whatís helpful is that it shows you can have a model which represents various switching capabilities without dependencies on the hardware. Iíd encourage looking at that liaison as it could be helpful with modeling.
Daniele Ceccarelli: 1) The work being presented by Dimitri is purely inter-switch cap, nothing changes in intra switch cap issues (e.g. OSPF OTN)2) with OSPF OTN presentation, in the list of open issues there is a ticked line with the multiple switch caps. It means the issue has been solved, not that one switch cap per layer has been adopted. Perhaps I should have added some description saying that it has been removed.
Julien Meuric: Just to clarify my previous presentation. My draft says is that if your SCSI is different you need a different switch cap.
Fatai Zhang: Daniele mentioned that this draft focuses on inter switch cap, letís focus on that. Iím trying to understand what is missing in RFC6001 to address this scenario.
Dimitri Papadimitriou: There is a checklist; we need to define what are green ticks and what are red crosses.
Daniele Ceccarelli: Response to Fatai with an example. First example: actually the IACD tells you that you can put a given switch cap over another (e.g. SDH over ODU) but not which branch of the client hierarchy over which branch of the server hierarchy. Second example: you cannot advertise the type of adaption from one hierarchy to one to the other. There are different types of adaptation that can be used.
Lou Berger: Couple of topics going on here. No one is questioning path on G709 documents, there seems to be good consensus on those documents. We expect that the WG drafts will be updated base on comments, and that WG drafts will rapidly progress to last call. The discussion has also highlighted that there isa discussion on reusing MLN to support itra-OTN switching, which is new. Clearly this are will require more discussion and work.
> 11†††††††††† 11:00†††† 10†††† Title:†††† Link Management Protocol (LMP) extensions for G.708 Optical Transport Networks
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-g709-lmp-discovery-06
>†††††††† Presenter:†††† Xian Zhang
Lou Berger: How many have read draft? (not many) Suggest reading the draft as if it is needed functionality it may be brought into the working group.
> 12†††††††††† 11:10†††† 10†††† Title:†††† LMP test messages extensions for OTN
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-g709-lmp-test-04
>†††††††† Presenter:†††† Daniele Ceccarelli/Dieter Beller
Lou Berger: Question, do the authors think that the last two drafts should be kept separate? Can you implement one without another? Why not look at merging?
Daniele Ceccarelli: It could be possible to implement them separately, but it is possible to merge them.
Lou Berger: Itís up to you to keep them separate now, but we may want to look at merging once/if they become WG documents.
> 13†††† ††††††11:20†††† 10†††† Title:†††† RSVP-TE extension for recording TE Metric of a Label Switched Path
> (may slip into 2nd session)†††† Draft:†††† http://tools.ietf.org/html/draft-ali-ccamp-te-metric-recording-00
>†††††††† Presenter:†††† George Swallow
> Adjourn†††††††††† 11:30†††††††††††††††††
Lou Berger: Quick question, do you think the same issue applies with an FA /hierarchical LSP?
George Swallow: it depends whether the FA/HLSP is advertised or not. If it is advertised, then no, if it is not, yes.
Eric Gray: I remember some RSVP-TE scalability work to be used when nothing changes. It seems in this case conditions will change and updates will be required all the time.
George Swallow: No, these parameters are one shot; they are not intended to change. The advertisement remains the same for the life of the LSP.
Lou Berger: wrt merging with the WG ID, it takes into account only fully standard parameters; this draft would introduce routing parameters which we don't know how fast they will progress.
George Swallow: I'm happy with asking for WG adoption of this doc and then merge
Lou Berger: we'll keep them separate for now and keep track of progress in the OSPF WG.
Lou Berger: How many have read the document?
How many have reservations (none).†
>†††††††††††† Second Session
>†††††††††††† Thursday, August 2, 2012.
>†††††††††††† 1300-1500 Afternoon Session I
>†††††††††††† Room Name: Regency C
> Presentation†††† Start Time†††† Duration†††† Information††††
> 0†††††††††† 13:00†††† 5†††† Title:†††† Administrivia
>†††††††† Presenter:†††† Chairs
> 15††††††† †††13:15†††† 10†††† Title:†††† A SNMP MIB to manage black-link optical† interface parameters of DWDM applications
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-galikunze-ccamp-g-698-2-snmp-mib-00
>†††††††† Presenter:†††† Gabriele Galimberti
Dieter Beller: How is this document related to the document(s) discussed yesterday (Application Code)?
Gabriele Galimberti: We have text that supports the application code. We vcan add some more text.
Malcolm Betts: My opinion on Application Codes are pretty clear from yesterday. Need to ensure not setting paramters that are set by application code.What is a read-only needs to be clear. This is configuring transmitters and receivers, why is this just black link?
Lou Berger: Another way of asking the same question -- how did you address the comment from the last IETF on a generic WSON MIB document.
Gabriele Galimberti: We need to look at three documents: a generic GMPLS MIB, a WSON MIB, and a black link MIB. We have an early draft on the generic MIB.
Deborah Brungard: need to look at all the MIBs together and †ensure there isnít redundancy.
Adrian Farrel: As an individual contributor. Re: Malcolm, need to be careful at what can be and what cannot be set. Also do people want write functions unless demand exists?
Lou Berger: Question to AD: If they do decide they want configurable parameters, should it be MIB or other?
Adrian Farrel: If they want to use SNMP, clearly you cannot configure that is not configurable.
Lou Berger: If the authors decide they want to configure it. Does the AD care if they put write parameters in the MIB.
Adrian Farrel: No opinion, if they want them fine. But, some other documents seem to put write functions for completeness rather than based on specific demand.
Kam Lam: Clarification, if the use decides it should be configurable, should other protocols be considered (YANG, etc).
Lou Berger: Two clarifications: other protocol, write function is ok today.
Gabriele Galimberti: To Adrian: Would it be helpful to add some text in this sense to the ID?
Malcolm Betts: Clearly parameters should be configurable; if set via SNMP is required we may need protocol independent framework first so we have a clear list of whatís required. My colleague is working on an ITU document that does this. Also, re: Lou, generic. It would be nice if we had a signal MIB info model that deals with all these equally and drive towards something that is extendable.
Adrian Farrel: 1st the OPSA WG will meet after this session. Should this document review set functions, the security section should review what is configurable and what happens should people have access. SNMP is quite clunky as a tool and SNMP get is useable. For example, what is the interface to configure your home router? Web GUI.
On the protocol neutral it could be helpful to have feedback from ITU on the work being carried on.
Deborah Brungard: the information model will be ready in September. IT is important here to generalize and not be only focused on black links. You could attend SG15 meeting and give feedback directly to Q6 and Q14 on this.
Fatai Zhang: Agree we need monitor ITU work. Slide 2, beyond 100gb we need to wait as itís too early to define MIB here.
> 16†††††††††† 13:25†††† 10†††† Title:†††† Extensions to LMP for DWDM G.698.2 optical line systems
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-00
>†††† ††††Presenter:†††† Gert Grammel
Fatai Zhang: So this draft lists a number of parameters, but why? Are there use cases or scenarios, why discovery etc. How do we use this discovery info? My opinion, when we connect end-points using black links we know which wavelengths can be used. So there is no need for LMP extensions, whatís the reason this is needed?
Rudiger Kunze: it is already explained in the framework document on the G.698.2. Please read it.
Malcolm Betts: This is not a black link. [Slide - Extended LMP Model]
Gert Grammel: No, this is not the black link but the LMP model
Lou Berger: The idea is to cover all the WSON work, it is worth specifying what is related to WSON and what to black links.
Malcolm Betts: If you say this is a complete WSON network, then I do not have an issue with discovery within WSON network. Trying to call this a black link, when its clearly not.
Gert Grammel: There is clearly collision of different views.
Deborah Brungard: You need to generalize, as well as align with ITU (Q6, Q14)
> 14†††††††††† 13:05†††† 10†††† Title:†††† RSVP-TE extension for Routing Diversity using Exclude Routes, Include Routes and signaling Optimization Objective and metric bound
> (may move to 1st session) ††††Draft:†††† http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-02
>†††††††† Presenter:†††† George Swallow
[Presented after Gabriele & Gert (15 & 16)]
Adrian Farrel: Are the OFs the same for this (UNI) and PCE, for PCE maybe I want the least loaded path. Where at UNI, the client may have service path computation request.†
George Swallow: The assumption is that the UNI-N can do whatever it wants with the information it gets.
Adrian Farrel: Maybe you need to define new objective function.
George Swallow: Looking into it.
Lou Berger: please specify which drafts are not useful
Adrian Farrel: Not sure about XRO, when already have existing mechanism.
Julien Meuric: I have some concern on the object function draft
Dimitri Papadimitriou: Already foresees the include and exclude capabilities. Can you make it independent so you do not assume you have a PCE?
Lou Berger: He is not assuming you have a PCE.
George Swallow: The PCE may be in the network or co-located at the UNI(?).
Gert Grammel: Overlay network with multiple LSPs being queued, need to look at the impact.
Julien Meuric: Back to the assumption of having PCE-capable optical edge, then why not simply send a PCEP request?
Lou Berger: there is some interest in some of the drafts. Then best to send messages to the list to understand any objections with each draft.
> 17†††††††††† 13:35†††† 10†††† Title:†††† RSVP-TE extensions for Lock Instruct and Loopback in MPLS-TP
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-03
>†††††††† Presenter:†††† Jie Dong
Lou Berger: General comments from last IETF were that this isinteresting work.† Need to wait to see how Cyrilís draft (draft-margaria-ccamp-lsp-attribute-ero) progresses.
> 18†††††††††† 13:45†††† 15†††† Title:†††† Framework for GMPLS based control of Flexi-grid DWDM networks
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-ogrcetal-ccamp-flexi-grid-fwk-00
>†††††††† Presenter:†††† Ramon Casellas
Lou Berger: is media path really used in ITU-T terminology? Is it consented? You should get rid of it as in IETF it has a totally different meaning.
Malcolm Betts: will take into account
Gert Grammel: question on the layering. I'm a bit confused on layering at the media layer. The terms need to be clarified.
Lou Berger: good to discuss on the list. Progress is a lot faster than we expected. We are planning an ITU-T liaison so perhaps will include this activity in the liaison.
> 19†††††††††† 14:00†††† 10†††† Title:†††† Expressing LSP attribute in ERO
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-margaria-ccamp-lsp-attribute-ero-01
>†††††††† Presenter:†††† Cyril Margaria
Lou Berger: Who has read the document? [A few] Is functionality needed? [Same few] Anyone not think itís needed? [No]
Julien Meuric: Solution relying on pointers doesn't look like in the spirit of original ERO and wouldn't be really efficient to implement.
Cyril Margaria: A further option would be a new C-type.
Lou Berger: [Chair hat off] that last option sounds like the secondary ERO. The other approach (in the current text) of using pointers between objects, I would personally hate to implement that one. Any other would be †better.
Jon Sadler: Since this discusses switching capability/types, does this address those attributes?
Cyril: the draft does not want to address those attributes
> 20†††††††††† 14:10†††† 10†††† Title:†††† Relaxing RSVP Loop Checking
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-balls-ccamp-relax-loop-check-01
>†††††††† Presenter:†††† Jonathan Hardwick
Adrian Farrel: You should look at ingress node protection work which was presented in the MPLS WG. It uses a similar looping control plane mechanism.
Jon Hardwick: Ok.
Lou Berger: The use of secondary ERO has been discussed in the past, dating back to 2001.This problem has been around for a while, see what exists already and see how you might adapt this. This strategy would avoid breaking existing RSVP.
> 21†††††††††† 14:20†††† 10†††† Title:†††† Applicability Statement for L1VPN Enhanced Mode
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-belotti-app-statement-l1vpn-em-00
>†††††††† Presenter:†††† Don Fedyk
Lou Berger: What are you asking for? Is this a technical or procedural request?
Don Fedyk: you mean the L1VPN versus CCAMP or the †drafts would not resurrect the L1VPN WG
Lou Berger: are there any required technical changes
Don Fedyk: no, just want to have the draft published
Lou Berger: do you see any issue in putting other technologies in the scope of the draft? Maybe extending to "Common Control"?
Don Fedyk: good idea
> 22†††††††††† 14:30†††† 10†††† Title:†††† L1VPN Enhanced Mode - Overlay Extension service model
>†††††††† Draft:†††† http://tools.ietf.org/html//draft-fedyk-ccamp-l1vpn-extnd-overlay-00
>†††††††† Presenter:†††† Dieter Beller
Steven Shew: Does the client (CE) see the contents of the SRLG object?
Dieter Beller: there is a draft identifying how to record SRLG information.
Steven Shew: Is the CE that receives the information understand the information (Security issue).
Dieter Beller: itís just a list of 32bit information
Gert Grammel: What about the UNI interface?
Dieter Beller: The information can be included, no problem
Gert Grammel: How can the CE know that SRLG diversity is possible?
Don Fedyk: We are thinking about requesting a diverse route and providing feedback to the CE
Lou Berger: for me the term L1VPN is confusing, GMPLS UNI or ENNI would be better.
George Swallow: One of the options in the exclude extension of our drafts allows asking for the exclusion of a set of LSPs.
Lou Berger: Do you see an opportunity to work together on this draft?
George Swallow: I will investigate.
> 23†††††††††† 14:40†††† 10†††† Title:†††† GMPLS ENNI: virtual link enhancements for the overlay model
>†††††††† Draft:†††† http://tools.ietf.org/html/draft-beeram-ccamp-gmpls-enni-00
>†††††††† Presenter:††† V.Beeram
Julien Meuric: I think the terminology may be confusing. If you do not feel comfortable with UNI,ENNI, etcl, get rid of them. Focus on protocol signaling, IGP or other.
Deborah Brungard: This was also suggested at the last WG session (IETF83), as the authors add content I too am getting confused.
Stephen Shew: Did you consider the concept of virtual node? [yes] My other comment is how the control plane components communicate. In ITU we call it signal control network, itís helpful to state your assumptions and how elements communicate.††
Deborah Brungard: Look at L1VPN RFCs, they have a whole section on this.
Daniele Ceccarelli: Why the previous presentation was related to L1VPN and not UNI/ENNI. The drafts are covering the same issues from a different perspective. (When the client needs to setup.) I think we could merge drafts and create a single document and cover the topic.
Lou Berger: Sounds like a good idea. Look forward to see you work with the authors to create such a document.,
Lyndon Ong: A suggestion, look at the RFCs defined for ASON routing (Req, evaluation, Protocol Ė 4258, 4652 5787)
> 24†††††††††† 14:50†††† 10†††† Title:†††† Milestones Update
>† †††††††Draft: -
>†††††††† Presenters: Lou & Deborah
Adrian Farrel: [AD Hat On] Milestone work, good. This is how I monitor WG performance. RE: new Work - Seems to me quite a lot. It might be wise to prioritize work, to help with progress.
Lou Berger: Okay this will get us thinking. We will continue discussion on list.
> 25†††††††††† 15:00†††† 5†††† Title:†††† RSVP-TE Extensions for Associated Bidirectional LSPs
> (If time permits)†††††††† Draft:†††† http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-03
>†††††††† Presenter:†††† Xu Yunbin
Debora Brungard: Who read document?
Lou Berger: There is a TP requirement. I think that the authors of this document should propose text that could be included to the existing WG document (draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp); we can see if we can get consensus on merging documents.†
> Adjourn†††††††††† 15:00†††††††††††††††††