Re: [CCAMP] rough minutes for Berlin CCAMP meetings

["Adrian Farrel" <[e-mail]>]

Thanks to chairs and note-takers for getting this together speedily and posting while we still remember (well, those of us who are not aged ADs) what happened. Good job.

Adrian

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Lou Berger
> Sent: 31 July 2013 17:51
> To: CCAMP
> Subject: [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp