[CCAMP] Comments on draft-ietf-ccamp-lsp-diversity-02// 答复: rough minutes for Berlin CCAMP meetings

Fatai Zhang <zhangfatai@huawei.com> Fri, 02 August 2013 09:52 UTC

Return-Path: <zhangfatai@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA86A21E8271 for <ccamp@ietfa.amsl.com>; Fri, 2 Aug 2013 02:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level:
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=3.181, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSeVQD2losiF for <ccamp@ietfa.amsl.com>; Fri, 2 Aug 2013 02:52:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 26C4B11E8210 for <ccamp@ietf.org>; Fri, 2 Aug 2013 02:51:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUA50163; Fri, 02 Aug 2013 09:51:56 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 10:51:29 +0100
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 2 Aug 2013 10:51:44 +0100
Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 2 Aug 2013 17:51:37 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Lou Berger <lberger@labn.net>, "George Swallow (swallow)" <swallow@cisco.com>
Thread-Topic: =?utf-8?B?Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1jY2FtcC1sc3AtZGl2ZXJzaXR5LTAy?= =?utf-8?B?Ly8g562U5aSNOiBbQ0NBTVBdIHJvdWdoIG1pbnV0ZXMgZm9yIEJlcmxpbiBD?= =?utf-8?Q?CAMP_meetings?=
Thread-Index: AQHOjg4zm356AwRGlUOmRvnwiH+V6pmBrWaw
Date: Fri, 2 Aug 2013 09:51:36 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF84EE449EA@SZXEML552-MBX.china.huawei.com>
References: <51F9405B.5040008@labn.net>
In-Reply-To: <51F9405B.5040008@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.218.249]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: CCAMP <ccamp@ietf.org>
Subject: [CCAMP] =?utf-8?q?Comments_on_draft-ietf-ccamp-lsp-diversity-02//?= =?utf-8?q?_=E7=AD=94=E5=A4=8D=3A__rough_minutes_for_Berlin_CCAMP_meetings?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2013 09:52:30 -0000

Hi George,

I meant RSVP-TE Path Key Subobject defined in RFC5553 rather than PCE stuff when I mentioned Path Key.

I am making a draft to use Path Key Subobject to address your diversity requirement, which is quite simple and straightforward. 

If you are interested in my draft that I am making, welcome you to join us.


===========================================================================================================
> 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 comp0lext solution. Why not use existing solution like path-key?
George Swallow: The operator may not be using PCE. We did discuss the solution early on before this document became a WG document.
Deborah Brungard: Make sure you read the document and trigger discussion on the list, not wait for the meeting.

===========================================================================================================================


Thanks

Fatai



-----邮件原件-----
发件人: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] 代表 Lou Berger
发送时间: 2013年8月1日 0:51
收件人: CCAMP
主题: [CCAMP] rough minutes for Berlin CCAMP meetings


As before, it would be best to enter corrections on http://tools.ietf.org/wg/ccamp/minutes (send mail to list if you can't).

Discussion should take place on the list and *not* in etherpad.

Much thanks to our secretaries and all who contributed to the notes.

Lou

> CCAMP Agenda For IETF 87
>                     CCAMP Agenda For IETF 87
>                     Version: Jul 22, 2013
>
>                     First Session
>                     TUESDAY, July 30, 2013
>                     1700-1830 Afternoon Session III
>                     Room: Potsdam 3
> 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           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 that you addressed Adrian's [Farrel) comment. I suggest you check with him via the list to confirm.

> 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           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:
Daniele Ceccarelli: How about we merge the drafts to minimized the number of drafts to read?
George Swallow: We initially had this plan, but we wanted to avoid holding up the other draft.
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.
Dan: We used to do that but our AD suggested to stop.
Lou Berger: It's not temporary assignment it is just a way to ensure that documents do no collide and avoid implementation issues. 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: Different times wrt RFC4020. People wanted to implement and start interop. 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).


> 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 comp0lext solution. Why not use existing solution like path-key?
George Swallow: The operator may not be using PCE. We did discuss the solution early on before this document became a WG document.
Deborah Brungard: Make sure you read the document and trigger discussion on the list, not wait for the meeting.


> 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.
Lou Berger: another XRO might be present and you need to consider it.
Adrian: Suggest that you rename subobject. As there might be confusion.
George Swallow: An easy change, do you have an suggestion?
Lou Berger: "Inclusion"?
George Swallow: "Follow the breadcrumb"? Ok, we (authors) will discuss.


> 6           17: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.
George Swallow: This is signaled from the IP plane, so we assume that you are in a maintenance window.
Dieter Beller: There are technologies out there that allow soft set up of resources. Are you envisaging to cover also those technologies?
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.
Xian: I don't follow the motivation for the second type of inquiry. What is its usage? Have you considered using calls?
George Swallow: I'm not familiar with that particular mechanism.
Lou Berger: Not sure how it would help.

> 7           17: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: how many people think it's a useful function (good number) How many read? (slightly less) How many think this is a good foundation? (slightly less) Cyril Margaria: Mechanisms defined in draft-ietf-ccamp-lsp-attribute-ro are meant 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; we followed the approach that we can distribute path computation.
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.


> 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?], there could be overlap with your draft.
Khuzema Pithewan: you might end up multiple lengths to satisfy a bandwidth request.

> 9           18: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.

> 10           18: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 it's useful? [good number], How many have read [good number] Take to the list

> 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 perfectly in relation to the WSON work.
Fatai Zhang: General comment. When do we need MIB drafts? Do we need it in this case? Some MIB drafts are on the CCAMP page and are not updated for years.
Deborah Brungard: Some people use SNMP as management interface, some others use different management protocols
Adrian: You are not required to write MIB modules. You are required to discuss how your network may be managed.

> 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, and a computation capability to compute end-to-end, find this work a little early?
Giovanni: 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.
Dieter From the discussion in Orlando interop is not currently capable, so is development of an information model too soon?
Giovanni: The compatibility will come, we cannot make any public statement now. There are some parameters that no one cares how are computed.
Dieter Beller: We are supposed to develop standard that provide interoperability
Giovanni: Yes. At the control plane.
Deborah Brungard: I suggest to talk with Q6 guys. Interim meeting, to help define.

> 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
> Presentation         Start Time     Duration     Information
> 0           13:00     5     Title:     Administrivia
>                 Draft:
>                 Presenter:     Chairs

> 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. G.872 was consented?
Malcolm: G.872 has been consented.
Deborah Brungard: has it been sent to the CCAMP?
Malcolm: I think it is worth sending a specific Liaison to Q6.
Lou Berger: polling on usefulness, reading and support as foundation of WG work. Good support. Confirm on the list.

> 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: what happens if the LSP needs to be resized?
Xian:
Lou Berger: The document is in an early stage of development. [Poll] How many have read? How many support? Pretty good number but less than FWK.
We may poll before the next meeting, assuming adoption of the framework document.
Iftekar: It seems that this document isn't as well developed.  Does it make sense to adopt.
Lou Berger:  We can adopt early if it makes sense. 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: [?]
Giovanni: WG can judge if the document is suitable, but it maybe early.
Lou Berger: So you feel adopting the document is premature?
Giovanni: Yes.

> 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

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.

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           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           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: These two drafts are 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 document? [Not too many] Hopefully we will see a Liaison to help us progress these documents.

> 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: If you not use the application codes, the set of parameters you are defining is enough to provide interoperability?
Gert Grammel: If it is a standard application code then it is interoperable. If it is not a standards application code, then...
Deborah Brungard: it would be good to take it to Q6 [Poll] Is draft-dharinigert-ccamp-opt-imp-lmp-00 useful, [a reasonable number]. Poll for 698.2 lmp same number. Poll for opt imp lmp same number -1


> 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           13:58     8     Title:     Applicability of Generalized
 Multiprotocol 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 go for option 1 fine, if we go for option 2 I would not support. I do not think the approach is good or even possible. This is not how we should build networks.
Lou Berger: Do you believe that sharing network information between domains is not acceptable?
Adrian Farrel: No, in fact I am working on a document that facilitates this. My issue is the mechanisms used to exchange information.
Lou Berger: At the overlay provider, what used to be called L1VPN enhanced mode would this be acceptable?
Adrian Farrel: architecture or protocol? We did discuss solutions, three options including an inter-domain routing protocol.
Lou Berger: In theory you support this, but you have an issue with one of the solutions.
Adrian Farrel:
Lou Berger: Layer you communicate at Vs. ...
Adrian Farrel: My view as a WG participant is that we need to step back and discuss the architecture, then solution work.
Oscar; 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           14:06     5     Title:     Extensions to RSVP-TE for
Error Notication 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 notification is not received?
The edge node will not find out.
Igor Bryskin: most of that solutions don't work. What you need is some reliable mechanism to do it.
Matt Hartley: It'll work the way RSVP-TE always works.
Igor Bryskin: you should think about a reliable notify delivery Lou Berger: This is a general issue with RSVP and beyond the scope of this single document Matt Hartley:
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: 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           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 and ] 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           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.
Igor Bryskin: we did consider this and we think to expand the concept of SRLG. [Will poke Igor to provide his comments.] Deborah Brungard: [poll] how many think this is interesting? not to many, try to raise interest.

> 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           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

Lou Berger: Do you need anything from routing to make the signaling work?
Cyril Margaria: You don't know where you originate Lou Berger: I do not understand, can you discuss with the previous authors and see if anything needs to be aligned.
Cyril Margaria: no we don't need igp extensions.
Khuzema Pithewan: If you are in a single domain you definitely need routing extensions Lou Berger: Please review RFC6107 as some of these mechanisms may already be described.


> 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: Cyril are you willing to work on a BCP with the authors, 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.


> 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 4427 and 6372, but this draft only covers 4427.  Also I was mistaken in my statement WRT 4427, as it doesn't state relative priorities.  That is stated only in 6372. There are other discussions on this topic going on, and this draft should be taken forward in a manner consistent with those discussions.

> 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
> Adjourn           15:00


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp