CCAMP Minutes for IETF 87

 

http://tools.ietf.org/wg/ccamp/agenda

 

†††††††††††††††††††

††††††††††††††††††† First Session

††††††††††††††††††† TUESDAY, July 30, 2013

††††††††††††††††††† 1700-1830 Afternoon Session III

††††††††††††††††††† Room: Potsdam 3

 

0 - Administrivia & WG Status

Presentation†††††††† Start Time†††† Duration†††† Information††††

0†††††††††† 17:00†††† 10†††† Title:†††† Administrivia & WG Status

††††††††††††††† Draft:††††

††††††††††††††† Presenter: Chairs

 

Fatai Zhang: After this meeting we plan to update [draft-ietf-ccamp-otn-g709-info-model] and [draft-ietf-ccamp-gmpls-g709-framework] based on AD (Adrian Farrel) review.

 

Comments requested on non-presented WG drafts status:

 

- draft-ietf-ccamp-rsvp-te-srlg-collect

 

Oscar Gonzalez de Dios: The document is stable. There is one functionality (knowing if a RRO suboject is incomplete or has been edited) that needs to be made generic (there was a comment from Lou during IETF 86th). A mail was sent on 4th of July with several options to make the functionality generic. A new mail to the CCAMP list will be sent this with the options. Feedback is requested from the CCAMP list.

 

- draft-ietf-ccamp-rsvp-te-li-lb:

 

Daniele Ceccarelli: No changes from last meeting

†††

1 - draft-ietf-ccamp-lsp-attribute-ro-02

1†††† 17:10†††† 8†††† Title:†††† LSP Attribute in ERO

†††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-lsp-attribute-ro-02

Presenter: Cyril Margaria

 

Lou Berger: I suspect you think that you addressed Adrian's (Farrel) comment from last meeting with the changes. I suggest you check with him either privately or on the list to confirm. In any case send a note to the list.

 

2 - draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06

2†††† 17:18†††† 8†† ††Title:†††† RSVP-TE Extensions for Associated Bidirectional LSPs

Draft:†††† :http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06

Presenter: Matt Hartley

 

Lou Berger: I think we can move rapidly towards Last Call.

Matt Hartley: Splendid.

 

3 - draft-ietf-ccamp-te-metric-recording-02

3†††† 17:26†††† 8†††† Title:†††† RSVP-TE extension for recording TE Metric of a LSP

†††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-02

††††††††††††††† Presenter: George Swallow

 

Oscar Gonzalez de Dios: Regarding IANA requests Collision with IANA assignment. We need to align on temporary assignments to avoid collisions.

George Swallow: That is what the second bullet is about.

Oscar Gonzalez de Dios: Yes, the temporary registry is not updated.

Daniele Ceccarelli: How about we merge the drafts to minimize the number of drafts to read?

George Swallow: We initially had this plan, but we wanted to avoid holding up the other draft.Since one of them has dependencies on others while the other has not.

Lou Berger: Regarding IANA assignments, are you having similar issues in MPLS? (Re: collision of temporary assignments values). We used to have the wiki which has not been touched for a long time.

George Swallow: I fully support it. It would save a lot of headache and WG chairs time.

Lou Berger: Perhaps we need to find someone from the MPLS WG that contributes to that wiki and if youíre willing to help keep that wiki updated please let us know and weíll have a couple of focal point for that.

Daniel King: We used to do that on the MPLS wiki but our AD suggested to stop.

Lou Berger: To be clear it's not temporary assignment it is just a temporary registry, it should not be used as a way to ensure that documents do no collide and avoid implementation issues values will not changes but just to suggest assignments non colliding with each other. We will discuss this with Adrian Farrel. Do we have someone who will take responsibility for the CCAMP page?

Oscar Gonzalez de Dios: I volunteer.

Lou Berger: We think it would be a good idea to resurrect the wiki

Adrian Farrel: Different times with respect to RFC4020. (Early allocation). People wanted to implement and start interoperability. Now that we support early allocation which gives a codepoint for 2 years I don't think we need allocations outside IANA. What happens if we screw up that registry?

George Swallow: We will caveat the request.

Adrian Farrel: Why not go that extra bit further and request an early allocation. We should talk in more details chairs and ADs.

Loa Andersson: Suggestion: ask the WG chairs if the draft is stable enough to start development, then request an early allocation.

Adrian Farrel: I suggest that if I am uneasy with this the IESG may also have issues. We can take this discussion offline (with CCAMP and MPLS chairs).

Loa Andersson: Suggestion: ask the WG chairs if the draft is stable enough to start development, then request an early allocation.

Lou Berger: Drafts can be considered that stable once they become WG documents.

 

4 - draft-ietf-ccamp-lsp-diversity-02

4††† 17:34†††† 8†††† Title:†††† RSVP-TE LSP Route Diversity using Exclude Routes

†††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-02

††††††††††††††† Presenter: George Swallow

 

Fatai Zhang: I understand the motivation, but I have an issue with the complexity of the solution. Why not use existing solution like path-key?

George Swallow: The operator may not be using PCE. or may not permit for security reasons to let the client nodes speak with the serve PCE. We did discuss the solution early on before this document became a WG document.

Fatai Zhang: In the case of UNI we can take the Path Key to the UNI-C and the UNI-C computes the second path to be diverse wrt the first path. Itís very easy to do that.

Deborah Brungard: Make sure you read the document and trigger discussion on the list, not wait for the meeting.

 

5 - draft-ali-ccamp-rsvp-te-include-route-04

5†††††††††† 17:42†††† 6†††† Title:†††† Include Routes - Extension to RSVP-TE

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-ali-ccamp-rsvp-te-include-route-04

††††††††††††††† Presenter: George Swallow

 

Khuzema Pithewan: There are elements (constraints) influencing a section or complete path of an LSP, these need to be managed.

George Swallow: If you cannot meet all the existing constraints, as well as meet diverse objective, then an error will be issued. This is described in the document.

George Swallow: The draft says that if changes occur youíll be notified with an error message saying that you no longer have the diversity you asked for but we donít want the network to automatically re-groom things based on those changes.

Lou Berger: another XRO might be present and you need to consider making it explicit in the draft.

George Swallow: what I was saying is that if the constraints canít be met you receive an error message. Thatís already there.

Adrian Farrel: Suggest that you rename subobject. The sub-object, as there might be confusion between I want to use this LSP as a hop and I want to follow the same path.

George Swallow: An easy change, do you have any suggestion?

Lou Berger: "Inclusion"?

Adrian Farrel: Inclusion could be risky for stitching reasons. Follow the same path or something like that.

George Swallow: "Follow the breadcrumb"? Ok, we (authors) will discuss.

 

6 - draft-ali-ccamp-lsp-inquiry-00

617:48†††† 5†††† Title:†††† RSVP-TE Extension for Label Switched Path (LSP)Inquiry

Draft:†††† http://tools.ietf.org/html/draft-ali-ccamp-lsp-inquiry-00

Presenter: George Swallow

 

Lou Berger: Off course reusing existing mechanisms is good, if you manage to reuse also existing terminology its better.

George Swallow: Yes.

Khuzema Pithewan: This will affect existing services and require a maintenance window.

George Swallow: This is signaled from the IP plane, so we assume that you are in a maintenance window.

Dieter Beller: You are considering technologies where you need to tear down an LSP before you can establish an LSP using an optimized path but there are technologies out there that allow soft set setting up of resources. A temporary protection (SNCP for instance) that do not require to tear down an LSP before setting up the new one. Are you envisaging to cover also covering those technologies in this draft?

George Swallow: We see this being used for shared mesh protection in optical environments.

Dieter Beller: I'm talking about technologies that in tens of ms are able to tear down an LSP and setup the protecting one.

George Swallow: The main goal is covering optical networks.

Xian Zhang: I don't follow the motivation for the second type of inquiry. What is its usage? Have you considered using calls? Calls can help you check the availability without committing resources.

George Swallow: I'm not familiar with that particular mechanism.

Lou Berger: Not sure how it would help, ďCallsĒ is about the end points.

 

7 - draft-ali-ccamp-rc-objective-function-metric-bound-03
717:53†††† 5†††† Title:†††† RSVP-TE Extension for Signaling Objective Function and Metric Bound

†††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-bound-03

>Presenter: George Swallow

 

Lou Berger: [poll] How many people think it's a useful function? (a reasonable number) How many read? (about the same, maybe little less) How many think this is a good foundation? (Slightly less than before) Any comments on why not supportive?

Cyril Margaria: Mechanisms defined in hop encoding could be used for this kind of information.

Oscar Gonzalez de Dios: Not only in this draft but in others you add path computation constraints like include/exclude things. When path computation is done in the middle of the network one may want to pass all the path computation constraints in RSVP-TE. However, in the proposal, you are duplicating PCEP objects.†††

Lou Berger: we generally follow the approach that we can distribute path computation.and all the info is available at every point [along an LSP].

Oscar Gonzalez de Dios: Not what I meant. I mean that if there is already a complete syntax to express path computation constraints, inclusions/exclusions, etc, why not reuse it?

Lou Berger: Can you make this suggestion on the list?

Fatai Zhang: Not sure about the value of this draft. We are making the signaling too complex. We should let the path computation do the path computation and the signaling just do the cross connections.

George Swallow: we had this discussion a lot of time ago.

 

8 - draft-long-ccamp-rsvp-te-bandwidth-availability-01
8 17:58†††† 5†††† Title:†††† RSVP-TE Signaling Extension for Bandwidth availability

†††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-long-ccamp-rsvp-te-bandwidth-availability-01

Presenter: Min Ye

 

Lou Berger: See the TSV WG [Tunnel Congestion I-D?],Multi T-SPEC document], there could be overlap with your draft. You should see if thereís a way to combine with them.

Khuzema Pithewan: Do you mean that one particular hop you might end up using multiple links to satisfy a bandwidth request.?

 

9 - draft-long-ccamp-ospf-availability-extension-00

918:03†††† 5†††† Title:†††† OSPF Routing Extension for links with variable discrete bandwidth

††††††††††††††† >Draft:†††† http://tools.ietf.org/html/draft-long-ccamp-ospf-availability-extension-00

>Presenter: Min Ye

 

Matt Hartley: Should this be an OSPF WG draft?

Lou Berger: in the past we agreed with the OSPF chairs that it is possible to make OSPF changes in CCAMP. Same for ISIS.

 

10 - draft-dhody-ccamp-rsvp-te-domain-subobjects-02

1018:08†††† 7†††† Title:†††† Domain Subobjects for Resource ReserVation Protocol Ė Traffic Engineering (RSVP-TE)

Draft:†††† http://tools.ietf.org/html/draft-dhody-ccamp-rsvp-te-domain-subobjects-02

Presenter: Dhruv Dhody

 

Deborah Brungard: [Poll] How many think this would be useful? [a reasonable number], How many have read [slightly more] Take to the list and get discussion.

 

11 - draft-gmggm-ccamp-gencons-snmp-mib-02

11†† 18:15†††† 5†††† Title:†††† A SNMP MIB to manage GMPLS with General Constraints Support

††††††††††††††† >Draft:†††† http://tools.ietf.org/html/draft-gmggm-ccamp-gencons-snmp-mib-02

††††††††††††††† >Presenter: Giovanni Martinelli

 

Lou Berger: I think this document is timed well in relation to the WSON work. (Which will soon be in last call).

Fatai Zhang: General comment. When do we need MIB drafts? any time that we define signaling or routing extensions? Do we need it in this case? Some MIB drafts are on the CCAMP page and are not updated for years.

Lou Berger: We are contribution driven.

Deborah Brungard: In previous years we recommended to have MIB companion documents. Some people use SNMP as management interface, some others use different management protocols.

Adrian Farrel: You are not required to write MIB modules. You are required to discuss how you manage the networks in which your network may be managed protocols are running.

12 - draft-martinelli-ccamp-wson-iv-info-02

12††† 18:20†††† 5†††† Title:†††† Information Model for WSONs with Impairments Validation

†††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info-02

Presenter: Giovanni Martinelli

 

Dieter Beller: Considering we do not have data plane interop, interoperability and a computation capability to compute paths end-to-end, and validate them, I find this work a little early? bit premature.

Giovanni Martinelli: What do you mean that there is no data plane compatibility? The answer from ITU-T folks was that there could be some multivendor case. and the single vendor scenario only applies to the nonlinear case.

Dieter Beller: From the discussion in Orlando a transponder from vendor A and a transponder from vendor B would not necessarily interoperate. So it is not currently capable, so is too soon for a development of an information model too soon? .

Giovanni Martinelli: The compatibility will come, we cannot make any public statement yet. The information model doesnít include any formula. There are some parameters that no one cares how are computed.

Dieter Beller: We are supposed to develop standard that provides interoperability

Giovanni Martinelli: Yes. At the at control plane level.

Deborah Brungard: I suggest to talk with Q6 guys. They are having an interim meeting in Nurnberg, to help define.

 

13 - draft-martinelli-ccamp-wson-iv-encode-02
13 18:25†††† 5†††† Title:†††† Information Encoding for WSON with Impairments Validation

†††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-02

Presenter: Giovanni Martinelli

No comments.

 

 

Adjourn           18:30                  

†††††††††††††††††††

††††††††††††††††††† Second Session

††††††††††††††††††† WEDNESDAY, July 31, 2013

††††††††††††††††††† 1300-1500

††††††††††††††††††† Room: Potsdam 1

 

0 - Administrivia & WG Status
Presentation†††††††† Start Time†††† Duration†††† Information††††

0†††††††††† 13:00†††† 5†††† Title:†††† Administrivia

††††††††††††††† Draft:††††

††††††††††††††† Presenter: Chairs

 

14 - draft-ogrcetal-ccamp-flexi-grid-fwk-03

14†††††††††† 13:05†††† 8†††† Title:†††† Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks

††††††††† ††††††Draft:†††† http://tools.ietf.org/html/draft-ogrcetal-ccamp-flexi-grid-fwk-03

††††††††††††††† Presenter: Oscar Gonzalez de Dios

 

Deborah Brungard: We have a lot of liaisons from ITU-T. Has G.872 been updated? Has it been consented?

Malcolm Betts: G.872 has been consented. 

Deborah Brungard: Has it been sent to the CCAMP?

Malcolm Betts: I think it is worth sending a specific Liaison to Q6 about the non-integer values of N and M.

Lou Berger: [Poll] How many think this is a useful work? (good representation) How many have read the document? (same) How many think this is a good foundation for WG work? (same number) Good support. Will confirm on the list.

 

15 - draft-zhang-ccamp-flexible-grid-rsvp-te-ext-02

15†††††††††† 13:13†††† 8†††† Title:†††† RSVP-TE Signaling Extensions in support of Flexible Grid

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-rsvp-te-ext-02

††††††††††††††† Presenter: Xian Zhang

 

Giovanni Martinelli: What happens if the LSP needs to be resized? (i.e., N and M change.)

Xian Zhang: You need to change N and M, but the label changes hop by hop anyway. 

Lou Berger: The document is in an early stage of development. [Poll] How many have read? (Reasonable but less than framework document.) How many support? (Same number.) We may poll before the next meeting, assuming adoption of the framework document. 

Iftekar Hussain: We have not been speaking about solutions yet. It seems that this document isn't as well developed.  Does it make sense to adopt it?

Lou Berger:  We can adopt documents at different level of maturity. It shouldnít be assumed that once the document is adopted the technical issues are solved. Remember that adoption is the start of the WG's technical work, not a statement that a documented solution is completely correct. If you feel the document is not ready or heading in the wrong direction, then you should bring any comments to the list. 

Iftekar Hussain: I was asking because there are other solution documents as well.

Lou Berger: Bring them forward, please.

Giovanni Martinelli: WG can judge if the document is suitable, but it may be early. Solutions are quite below in the list of documents. Before we need framework, encoding, info model etc.

Lou Berger: So you feel adopting the document is premature? 

Giovanni Martinelli: Yes.

 

16 - draft-zhang-ccamp-flexible-grid-ospf-ext-02

16†††††††††† 13:21†††† 8†††† Title:†††† GMPLS OSPF-TE Extensions in support of Flexible Grid DWDM Networks

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-ospf-ext-02

††††††††††††††† Presenter: Ramon Casellas

 

Lou Berger: [poll] how many have read? (same as previous doc). How many have reservations? (one). Say at the mic.

Cyril Margaria: A bit too early to make it a wg document

Lou Berger: Specific technical issues?

Cyril Margaria: no. 

Lou Berger: Okay, then please review and send specific comments to the list.

Lou Berger: General comment. Please take advantage of the list to raise comments and objections, lack of discussion may be misconstrued as concurrence or disinterest. If you have alternate proposals put them into a draft and discuss them on the list. 

Fatai Zhang: We could adopt the framework and label drafts and then speak about signaling and routing.

Lou Berger: Can you make this suggestion on the list once the result of the framework adoption poll is known?

 

17 - draft-galikunze-ccamp-g-698-2-snmp-mib-03
17†††††††††† 13:29†††† 7†††† Title:†††† An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-galikunze-ccamp-g-698-2-snmp-mib-03

††††††††††††††† Presenter: Gabriele Galimberti

 

18 - draft-galikunze-ccamp-opt-imp-snmp-mib-00

18†††††††††† 13:36†††† 7†††† Title:†††† An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-galikunze-ccamp-opt-imp-snmp-mib-00

††††††††††††††† Presenter:†††† Gabriele Galimberti

 

Gert Grammel: Are these two drafts covering the same content of the one we discussed in Orlando?

Gabriele Galimberti: One is covering what is in the ITU-T recommendation and the other one what is not there. They are complimentary.

Deborah Brungard: [Poll] How many have read the documents? [Not too many]

Question 6 will have this as a discussion topic at the October meeting. Hopefully we will see a Liaison to help us progress these documents. 

 

19 - draft-dharinigert-ccamp-g-698-2-lmp-03

draft-dharinigert-ccamp-opt-imp-lmp-00

19†††††††††† 13:43†††† 8†††† Title:†††† Extension to the LMP for DWDM Optical Line Systems to manage optical parameters of DWDM applications

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-03

                    http://tools.ietf.org/html/draft-dharinigert-ccamp-opt-imp-lmp-00††††††††††††††††††††

††††††††††††††† Presenter: Gert Grammel

 

Deborah Brungard: You have split the document and this second one is covering the proprietary parameters based on G.698.2, but we understood from the Q6 folks that the application codes where selected based on a parameters selection that would allow interoperability, so if you not use the application codes, the set of parameters you are defining is enough to provide interoperability?

Gert Grammel: We consider a combination of both. If it is a standard application code then it is interoperable. Since the semantic of non standard application codes is not defined, all the parameters that you can find in G.698.2 need to be known to ensure that two application codes interoperate. 

Deborah Brungard: It would be good to take it to Q6 to understand whether it is sufficient. [Poll] How many have read the document? (more people than MIB docs) 

Lou Berger: [Poll] How many think this is a useful functionality? (less than above) 

[polling the documents separately]: Is draft-dharinigert-ccamp-opt-imp-lmp-00 useful? (same number, medium) Poll for 698.2 lmp (same number except one person). 

 

Adrian Farrel: Since many people are suddenly interested in LMP, Iíve just been contacted by someone in KARP WG (security for routing protocols WG) there is a draft coming out about security issues and potential fixes for LMP. They are crying for help. 

 

 

20 - draft-ceccadedios-ccamp-overlay-use-cases-01
20†††††††††† 13:51†††† 7†††† Title:†††† Use cases for operating networks in the overlay model context

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-ceccadedios-ccamp-overlay-use-cases-01

Presenter: Daniele Ceccarelli

 

(single presentation for next)

21 - draft-zhang-ccamp-gmpls-uni-app-04

21†††††††††† 13:58†† ††8†††† Title:†††† Applicability of GeneralizedMultiprotocol Label Switching (GMPLS) User-Network Interface (UNI)

††††††††††††††† Draft:††† http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-uni-app-04

††††††††††††††† Presenter:†††† Daniele Ceccarelli

 

Adrian Farrel: AD hat off - My name appears on applicability I-D, but not on the use cases. This is not an accident. If we were to go for option 1 I would have severe problems. I'm definitely an option 2 person, so I can be in favour of one document and opposed to the other. I don't think the ONI approach is good or desirable.

Daniele Ceccarelli: What do you oppose?

Adrian Farrel: I don't like the mechanism proposed for sharing routing information. It's not that I see the UNI definition as being you must, must not share routing information, I just don't see that that's the way we should build networks.

Lou Berger: Do you believe that sharing routing information between domains is not acceptable?

Adrian Farrel: No, in fact I am working on a document that facilitates this (draft-farrel-interconnected-te-info-exchange-01) and Daniele is one of the co-authors. My issue is not the exchange of routing information but the mechanisms used to exchange it. 

Lou Berger: If you were sitting at the overlay provider layer, do you think that what used to be called L1VPN enhanced mode would be a reasonable thing to consider? 

Adrian Farrel: Architecturally or protocol wise? I should say yes and no. We did discuss solutions, three options were discussed: 1. A common IGP with sharing of information, 2. An IGP instance between layers and 3. Well known inter-domain protocol between layers and I donít like any of them.

Lou Berger: In theory you support this, but you have an issue with solutions, both the ones in the past and this one?

Adrian Farrel: Yes, The enhanced mode in L1VPN recognised there was function there, but didn't need to call it any other special type of interface. It was just two networks talking to each other. 

Lou Berger: I had hard times understanding what is the difference between ONI and L1VPN?

Adrian Farrel: My view as a WG participant is that we need to step back and discuss the architecture, then solution work. 

Oscar Gonzalez de Dios: When I began this work I wanted to discuss the use cases and describe the architecture, rather than develop solutions.

Lou Berger: so maybe we should step back and review the architecture. Actually we have other documents that discuss the work.

Julien Meuric: [slide UNI/ONI Use case] this feels like transport recovery mechanisms being pushed into the packet layer. 

Daniele Ceccarelli: The intention was to demonstrate how it is possible mix the advantages of the two layers

Deborah Brungard: I suggest we break up the examples and post to the list and request feedback.

Lou Berger: Happy to hear the authors are looking at taking a step back and revisiting their drafts. When doing this please look at other individual drafts that may have related text and work with those other authors. Also consider the differences between UNI and ENNI, which operate in a single layer, and the concepts of L1VPN basic and enhanced mode which  can be leveraged for cross client/server layers -- which is perhaps what's intended by ONI. 

 

22 - draft-ali-ccamp-gmpls-uni-error-notification-00

22†††††††††† 14:06†††† 5†††† Title:†††† Extensions to RSVP-TE for Error Notification in GMPLS User-Network Interface (UNI)

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-ali-ccamp-gmpls-uni-error-notification-00

††††††††††††††† Presenter: Matt Hartley

Igor Bryskin: What happens if the path-error message is not received?

Matt Hartley: The edge node will not find out.

Igor Bryskin: Most of that solutions don't work. What you need is some reliable mechanism.

Matt Hartley: This is comment, not on my draft but the way GMPLS works in general. It'll work the way RSVP-TE always works.

Lou Berger: This is [reliable message delivery] a general issue with RSVP and beyond the scope of this document.

Cyril Margaria: This mechanisms seems to apply to UNI, we need a general mechanism.

Lou Berger: This leads to a question that I had, why is the general address mapping/hiding mechanism defined RFC4208 insufficient? 

Matt Hartley: will have to look at that

Adrian Farrel: The question I sent on the mailing list is that what you want to define is already there in RFC4783

Matt Hartley: If you can send this comment to the list I can review and comment. 

Deborah Brungard: Are you looking at segment protection in the core?

Lou Berger: What you are looking for is a single error value?
Matt Hartley: Yes. It seems it's going to be a short draft.

 

23 - draft-fedyk-ccamp-uni-extensions-02

23†††††††††† 14:11†††† 8†††† Title:†††† UNI Extensions for Diversity and Latency Support

††††††††††† ††††Draft:†††† http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-02

††††††††††††††† Presenter: Dieter Beller

 

Lou Berger: [slide - relationships with prior work] Do you think that your document is related to Daniele's [draft-ceccadedios-ccamp-overlay-use-cases] presentation?

Dieter Beller: Yes.

Lou Berger: I suggest you take advantage of the time this week and see how these documents fit together. And then update the documents/WG accordingly.

 

 

24 - draft-beeram-ccamp-melg-01
24†††††††††† 14:19†††† 8†††† Title:†††† Mutually Exclusive Link Group (MELG)

††††††††††††††† Draft:†† http://tools.ietf.org/html/draft-beeram-ccamp-melg-01

††††††††††††††† Presenter: Vishnu Pavan Beeram 

Lou Berger: [slide - 4] A clarification question, is this a virtual TE link, or an actual TE link?

Vishnu Pavan Beeram: A virtual TE link

Lou Berger: Based on existing work (RFCs), there is no distinction between virtual TE link and an actual TE link in the client topology. This is a significant change.

Vishnu Pavan Beeram: We can make a note of this in the document.

George Swallow: At what point would you advertise mutual exclusivity, do you wait until it is setup? If this is the direction, how many do you advertise, why not include this in the draft.
Vishnu Pavan Beeram: My co-author would be keen to answer that. 

Igor Bryskin: Basically we looked at this. Due to the nature dynamic, we want to expand the concept of SRLG and treat it as Share Resource Link Group. So for a diverse computation there is no difference, but when you advertise the available BW on each priority level. This would help client path computation, specifically for concurrent optimization. Why put this in a separate draft; wider problem than MEL, dynamics aside we may want to advertise when there is a change, and ignore all other links, this is to help scalability. In general IETF wants to have single solutions but I think we need multiple solutions for this area. ††

Deborah Brungard: [poll] how many think this is interesting? (Not too many, try to raise interest.)

    

25 - draft-rao-ccamp-mlnmrn-otn-ospfte-ext-02
†††

25†††††††††14:27†††† 8†††† Title:†††† OSPF-TE extensions for MLNMRN based on OTN

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte-ext-02

††††††††††††††† Presenter: Khuzema Pithewan

Lou Berger: Do you require anything from signaling? 

Khuzema Pithewan: yes, maybe yes.

Fatai Zhang:

 

26 - draft-zhang-ccamp-gmpls-h-lsp-mln-05 26†††††††††† 14:35†††† 8†††† Title:†††† GMPLS-based Hierarchy LSP Creation in Multi-Region and Multi-Layer Networks

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln-05

††††††† Presenter: Xian Zhang

Khuzema Pithewan: Yes, maybe. Once we compute the path, it involves multiple domains. The signaling could be handled in multiple segments, but you need OSPF to handle the first part.
Lou Berger: Ok, so you see where I am going with regards to the next presentation. Can you make sure you guys are aligned?

Khuzema Pithewan: Yes, thank you.

Lou Berger: Do you need anything from routing to make the signaling work?
Xian Zhang: The typical scenario is multi-domain, so no need for routing work.
Lou Berger: So if I understand you response, no because everyone will use PCE?
Xian Zhang: No, Cyril can help me clarify.

Cyril Margaria: You don't know where you originate. 

Lou Berger: Even though this says MLN, you are scoping this to MRN? 

Cyril Margaria: No, we don't need IGP extensions.

Lou Berger: I do not understand, can you discuss with the previous authors and see if anything needs to be aligned?

Khuzema Pithewan: If you are in a single domain with multi-regions, you definitely need routing extensions to compute a path across layer transitions.

Lou Berger: Please review RFC6107 as some of these mechanisms may already be described. 

 

27 - draft-gandhi-ccamp-gmpls-restoration-lsp-01
27†††††††††† 14:43†††† 5†††† Title:†††† RSVP-TE Extensions For Signaling GMPLS Restoration LSP

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-gandhi-ccamp-gmpls-restoration-lsp-01

††††††††††††††† Presenter: Gabriele Galimberti

Igor Bryskin: Why are you requesting feedbacks if 2 years ago we presented a similar draft and there was no interest?

Lou Berger: Igor are you willing to work on a BCP with the authors on how we do this. I think we agree that mechanisms exist but we need to document how they might be used. We do not have time to discuss, so letís take this offline.
Cyril Margaria: This new protection type seems to be about policy at the ingress node, rather than intermediate nodes.
Lou Berger: Ok, letís take this to the list, I did not understand that [last comment].  

 

28 - draft-helvoort-ccamp-fs-priority-00
28†††††††††† 14:48†††† 7†††† Title:†††† Update Forced Switch Priority

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-helvoort-ccamp-fs-priority-00

††††††††††††††† Presenter: Huub van Helvoort 

Lou Berger: You mentioned on the list that this draft was in response to a message that I sent. The message stated that a combined change was needed to RFC4427 and RFC6372, but this draft only covers RFC4427.  Also I was mistaken in my statement with regards to RFC4427, as it doesn't state relative priorities.  That is stated only in RFC6372. There are other discussions on this topic going on (in the MPLS WG), and this draft should be taken forward in a manner consistent with those discussions.

George Swallow: We [MPLS WG] have been working on a way forward for [Protection and Restoration] PSC. This does not seem to reflect these discussions.
Lou Berger: Rather than getting into discussion of the specific proposal here, letís look at the larger problem and discussions.

 

29 - draft-zhang-ccamp-rsvpte-ber-measure-00

29†††††††††† 14:55†††† 5†††† Title:†††† RSVP-TE Extensions for Bit Error Rate (BER) Measurement

††††††††††††††† Draft:†††† http://tools.ietf.org/html/draft-zhang-ccamp-rsvpte-ber-measure-00

†††††††† Presenter: Zhenbin Li††††††

Lou Berger: Apologies but we are out of time. Please summarise the draft to the list. We appreciate your time and preparing the slide and again apologies for running out of time. The slides are on record for the WG session.

 

Adjourn