Subject: Re: [CCAMP] rough minutes for Berlin CCAMP meetings

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Aug 2013 15:15:00 +0100

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: [email-masked] [mailto:[email-masked]] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 2 Aug 2013 09:51:36 +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.

===========================================================================================================
using Exclude Routes
>                 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

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 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).

Lou

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

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.

‒ 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

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

TE Metric of a LSP
>                 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).

using Exclude Routes
>                 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.

RSVP-TE
>                 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.

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

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

Bandwidth availability
>                 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.

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.

>                 Presenter:     Dhruv Dhody

Deborah Brungard: [Poll]
How many think it's useful? [good number], How many have read [good number] Take to the list

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

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

No comments.

Lou Berger: polling on usefulness, reading and support as foundation of WG work. Good support. Confirm on the list.

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.

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

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

>                 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

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

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.

and Latency Support
>                 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.

(MELG)
>                 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.

based on OTN

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.

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

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