Re: [CCAMP] IETF87 CCAMP Session 1 Minutes - Questions/Responses

Lou Berger <lberger@labn.net> Tue, 30 July 2013 22:17 UTC

Return-Path: <lberger@labn.net>
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 C7E9911E81ED for <ccamp@ietfa.amsl.com>; Tue, 30 Jul 2013 15:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.384
X-Spam-Level:
X-Spam-Status: No, score=-101.384 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100]
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 cpsYBiEHC7k8 for <ccamp@ietfa.amsl.com>; Tue, 30 Jul 2013 15:16:57 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 3E51011E8125 for <ccamp@ietf.org>; Tue, 30 Jul 2013 15:16:56 -0700 (PDT)
Received: (qmail 6034 invoked by uid 0); 30 Jul 2013 22:16:33 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 30 Jul 2013 22:16:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=fx+ntnImSmsCJUjkQD96//y77ch9GH4Y47505cbD218=; b=e+yC8bevtX07YNneInU7EuOsja6uM4vaXU5FtK00XSKzgRHlAxe8Yo0Yc1Kgt0WETjErwb+a04PRCEtb2RZkNWlt5XwD1nBQ+nh1Kd3h/PikC46rJ39qPPZwVSwQWvJt;
Received: from box313.bluehost.com ([69.89.31.113]:35912 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1V4IDZ-0005Eo-3h; Tue, 30 Jul 2013 16:16:33 -0600
Message-ID: <51F83B40.8000906@labn.net>
Date: Tue, 30 Jul 2013 18:16:32 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: ccamp@ietf.org
References: <024301ce8d46$5aa08720$0fe19560$@olddog.co.uk>
In-Reply-To: <024301ce8d46$5aa08720$0fe19560$@olddog.co.uk>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Subject: Re: [CCAMP] IETF87 CCAMP Session 1 Minutes - Questions/Responses
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: Tue, 30 Jul 2013 22:17:01 -0000

I've enclosed the raw notes from etherpad below for those who might be
interested. It would be best to enter corrections directly into
etherpad.  Discussions/additions not said int he meeting should take
place on list.

Thanks,

On 07/30/2013 01:00 PM, Daniel King wrote:
> Hi All,
> 
> If you were a presenter, or asked a question, during IETF87 CCAMP
> session 1 would you please review the minutes:
> http://tools.ietf.org/wg/ccamp/minutes
> Directly modifying the etherpad minutes to clarify your (actual)
> question or response would be very much appreciated!
> Br, Danielle and Dan.
> 


> 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 requeested on non presented WG drafts status:
‒ draft-ietf-ccamp-rsvp-te-srlg-collect
Oscar: 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: 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: Regarding IANA requestsCollision with IANA assignment. We need to
align on temporary assignments to avoid collisions.
George:
Daniele: How about we merge the drafts to minmised the number of drafts
to read?
George: We intially had this plan, but we wanted to avoid holding up the
other draft.
Lou: Regarding IANA assinments, 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: I fully support it.
Dan: We used to do that but our AD suggested to stop.
Lou: 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 resposnbility
for the CCAMP page?
Oscar: 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 allcoation 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 requst 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 developemen, 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 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: I understand the motivation, but I have an issue with the
comp0lext solution. Why not use existing solution like path-key?
George: The oeprator may not be using PCE. We did discuss the solution
early on before this document became a WG document.
Deborah: 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: There are elements (constraints) influencing a section or
complete path of an LSP, these need to be managed.
George: If you cannot meet all the existing contraints, as well ameet
diverse objective, then an error will be issued. This is described in
the document.
Lou: another XRO might be present and you need to consider it.
Adrian: Suggest that you rename subobject. As there might be confusion.
george: An easy change, do you have an suggestion?
Lou: "Inclusion"?
George: "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 exisitng mechnisms is good, if you manage
to reuse also existing terminology it's better.
George: Yes.
Khuzema: This will affect existing services.
Geoirge: This is signaled from the IP plane, so we assume that you are
in a maintenance window.
Dieter: There are technologies out there that allow soft set up of
resources. Are you envisaging to cover also those technologies?
George: We see this being used for shared mesh protection in optical
enviroments.
Dieter: 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 secon type of inquiry. What
is its usage? Have you considered using calls?
George: I'm not familiar with that particular mechanism.
Lou: 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: how many people think it's a useful function (good number)
How many read? (slightly less)
How many think this is a gpood foundation? (slightly less)
Cyril:
Oscar: 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 computatoin.
OScar: Not what I meant. I mean that if there is already a complete
syntax to express path compuations constraints, inclusions/exclusions,
etc, why dont't reuse it?
Lou: Can you make this suggestion on the list?
Fatai: 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: See the TSV WG [Tunnel Congestion I-D?], there could be overlap
with your draft.
Khuzema: you might end up multiple lenghts to satisfy a bandwdith 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: Should this be an OSPF WG draft?
Lou: 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: [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: I think this document is timed perfectly in relation to the WSON work.
Fatai: 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: 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: 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 discussoin in Orlando interop is not currrently 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: We are supposed to develop standard that provide interoperability
Giovanni: Yes. At the control plane.
Deborah: I suggest to talk with Q6 guys. Interim meerting, to hlpe 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