[CCAMP] rough minutes for Berlin CCAMP meetings

[Lou Berger <[e-mail]>]

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