> CCAMP Agenda for the
> 82nd IETF Meeting
> Version: Nov 06, 2011
>
> First Session
> Tuesday, November 15, 2011.
> 1300 - 1500 Afternoon Session I
> Room Name: 3F Banquet
>
Chairs: Deborah Brungard & Lou Berger
Scribes: Daniele Ceccarelli & Dan King
> Presentation Start Time Duration Information
> 0 13:00 5
> Title: Administrivia
> Draft:
> Presenter: Chairs
> Notes:
> 1 13:05 10
> Title: WG status, RFCs, drafts, milestones, charter, errata
> Draft:
> Presenter: Chairs
> Notes:
Chairs: status from WG draft authors who are not presenting?
Dan Li: LMP behavior negotiation - draft complete, waiting for feedbacks from WG
Lou Berger: Do you know if there is any implementation of this draft?
Dan Li: we are waiting for them.
[DPM author]: DPM – 3 revisions since meeting in Beijing, latest revision mainly editorial. Draft stable and can be moved forward.
Fei Zhang: associated LSP – Updated since last meeting. One comment received from Lou. Looking for feedback on the WG list
Lou Berger: For Resource sharing - waiting for association extensions that we are going to talk about.
> 2 13:15 15
> Title: Framework and Information model for GMPLS and PCE Control of G.709 Optical Transport Networks
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-05
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-02
> Presenter: Sergio Belotti
> Notes:
Lou Berger: There have been many on-line and off-line discussions on how to handle TSG and a suggestion of using the PT instead of the TSG. Can you elaborate on current thinking of authors?
Sergio Belotti: The same information carried by the TSG can be deduced by PT and server layer information. Two values for PT are defined, PT=20 for TSG=2,5Gbps and PT=21 for TSG=1,25. The reference to OPUk is needed as there is a particular case (OPU1) in which PT=20 and TSG is equal to 1,25 Gbps.
Lou Berger: Are there any other conclusions among the authors we want to talk about now and share with the WG?
Sergio Belotti: No specific discussion about info model but about encoding
Lou Berger: What about open issues you’d like to discuss now?
Sergio Belotti: At the moment there is the need to understand which is the best way to carry these pieces of information. A good solution could be a new object with hierarchy plus PT (I.e. adaptation information rather than encoding).
Lou Berger: looking forward to see discussion on the ML. Don't forget about the comment from the last IETF, to include a compatibility section in the framework document (perhaps taking some of the text from the current routing and signaling drafts.)
> 3 13:30 15
> Title: Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-00
> Presenter: Daniele Ceccarelli
> Notes:
Lyndon Ong: Typo on slide 4: ISCD and SCSI reversed on slide.
How is “unstructured traffic” used?
Daniele Ceccarelli: It is used for non OTN traffic where there is no client-server relationship between two ODU LSPs but a non OTN traffic is carried over an OTN LSP.
Deborah Brungard: How would you choose which one to use?
Daniele Ceccarelli: Those types of interfaces can be chosen when non OTN traffic needs to be carried.
Jonathan Sadler: TSG issue is only relevant to ODU into ODU adaptation and not e.g. in Ethernet over ODU.
Rajan Rao: trying to clarify: the idea is to use PT instead of TSG, so you are going to have more than two values (20 and 21) intent is to allow for non-OTN clients to be mapped onto OTN
Jonathan Sadler: Is a general multi-layer issue, not specific to OTN
Lou Berger: Can you elaborate what authors think about bullet 1 (switch caps) and bullet 3 (max lsp bandwidth and unreserved bandwidth for odu flex)
Daniele Ceccarelli: Several comments, the most common is that using the switching capability field for the advertisement of the bottom most layer of the hierarchy is not in the scope of the field. It can be used to do that but it wasn’t meant to do that. Wrt bullet 3, type 2 TLV was supposed to be an optional object as not always needed but only helpful.
Lou Berger: if it can be misleading why including it all?
Daniele Ceccarelli: There are cases in which it can be helpful (example of section 5.3 of the draft quoted).
Lou Berger: As a general rule options lead to interoperability problems, if you think it is needed make it required, otherwise get rid of it.
Daniele Ceccarelli: I’d prefer to leave it but it’s just my opinion. Don’t think the waste of bandwidth is big.
Lou Berger: Authors should come back with a statement saying if the unreserved bandwidth TLV for ODUflex is needed. With respect to bullet one keep in mind we do have examples of different switching capabilities in the same technology e.g. PSC1-2-3-4.
> 4 13:45 10
> Title: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-01
> Presenter: Fatai Zhang
> Notes:
Lou Berger: Ensure informative language has matching conformance [RFC2119] language where appropriate. This is a general comment on all PS drafts.
> 5 13:55 10
> Title: GMPLS RSVP-TE extensions for OAM Configuration
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-06
> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-eth-oam-ext-06
> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-06
> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-03
> Presenter: Elisa Bellagamba and Attila Takacs
> Notes:
Rajan Rao: Comment on the SDH-OTN draft. It doesn't seem to cover all the cases for the OTN case, it only covers TTI configuration.
Elisa Bellagamba: not author of that draft, will report to him
Deborah Brungard: I asked this question at the last meeting and the answer was that the TCM was excluded.
Deborah Brungard: POLLING number of people having read the drafts. Good indication.
Lou Berger: Has comments from last meeting been resolved? In particular the ones from George?
Elisa Bellagamba: One comment was that a clear statement on unnecessary configuration on intermediate nodes needed to be added. And there were comments on the FMS tlv, unnecessary flags deleted and unclear ones clarified.
Lou Berger: So have they been addressed?
Elisa Bellagamba: Yes, Can check offline
Lou Berger: What about changes related to LSP ping in the –TP docs?
Elisa Bellagamba: Changes are related to intermediate nodes, which are not considered in the –TP ID.
Lou Berger: [To WG] Please have a look at this version and make sure there are no additional comments and then we'll decide how to progress them. They have been around for a while
Deborah Brungard: As part of the last call we should send a liaison to the ITU-T wrt to the Ethernet and SDH-OTN docs.
Adrian Farrel: Deborah, did you say we should liaise the Ethernet and SDH-OTN IDs to the ITU-T? Why Ethernet to the ITU and not IEEE and not -TP?
Deborah Brungard: We can do that also. Ethernet is mainly based on Y.1731, so it is more ITU-T.
> 6 14:05 8
> Title: Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-13
> Presenter: Young Lee
> Notes:
[Dan Li presented for Young Lee.]
Cyril Margaria: sent comments regarding the info model and encoding (e.g. label set) and not all of them have been addressed.
Dan Li: Not author, so unable to answer question or discuss issues
Lou Berger: Unfortunately, discussion has to be kept to the list as the proper people are not here.
Greg Bernstein from Jabber: See no major issue
Cyril Margaria: Not a major one but updates needed. They are on the list
> 7 14:13 7
> Title: GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-07
> Presenter: Young Lee
> Notes:
[Dan Li presented for Young Lee.]
Lou Berger: Confused by the conclusion of the discussion on the list. I understood we were going to eliminate option 2 and rely on IP level fragmentation. Not sure the resolution on the list is reflected in the current text. To be reported to Greg and Young: make sure the docs reflect the decisions taken on the list and if we continue to keep the second option with multiple LSAs define when the receiving nodes can start using the received information because you could end up with info out of sync.
Greg Bernstein from Jabber: new version planned. We will be removing section 3.2, which has the additional options. We have that discussion in the text now. We address the sync issue in the current text
> 8 14:20 10
> Title: OSPF-TE Extensions for General Network Element Constraints
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02
> Presenter: Fatai Zhang
> Notes:
> 9 14:30 10
> Title: RSVP Association Object Extensions
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-assoc-ext-01
> Presenter: Lou Berger
> Notes:
Lou Berger: Option 1 keep the document as actually formulated and submit a new doc for CC-ICC support, Option 2 put everything into the same doc.
Julien Meuric: Let's keep moving on. Support option 1.
Eric Gray??>: Option 1.
Lou Berger: one last pass and then move forward.
> 10 14:40 10
> Title: Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operator Identifier Object
> Draft: http://tools.ietf.org/html/draft-chen-ccamp-mpls-tp-oio-01
> Presenter: Vero Zheng
> Notes:
Kam Lam: In the control plane different domains can use different identifiers, why the same e2e format is required?
Vero Zheng: There has been a discussion in the MPLS
George Swallow: There is no consensus in having different identifiers
Eve Varma: We are mixing data plane and control plane identifiers. Global control plane identifiers are a general issue, not an MPLS specific one. The draft is suggesting that all across the network each domain must use the same control plane identifiers. It is a generic issue and not a -TP issue. The one carried in the MPLS is a -TP issue.
Kam Lam: there is no need to redefine a global identifier as identifiers can be translated.
Lou Berger: Type 1 global id object is already covered by the association extensions which has been WG doc for a while. Why are you proposing an alternative.
Vero Zheng: The WG draft is deficient.
Lou Berger: If you think there is a deficiency in that document, plase state your issues on the mailing list and we can resolve it there. With respect to type 2, as discussed in the previous presentation there will be a new draft.
Vero Zheng: do you think carrying the Global ID is useful?
Lou Berger: Yes, the WG has already agreed to this.
> 11 14:50 10
> Title: RSVP-TE Extensions to Exchange MPLS-TP Tunnel Numbers
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-mpls-tp-rsvpte-ext-tunnel-num-00
> Presenter: Fei Zhang
> Notes:
PRESENTATION FROM SECOND SESSION MOVED HERE
> 15 9:35 10
> Title: GMPLS-UNI BCP
> Note: This presentation will be moved to the end of session 1, if time permits
> Draft: http://tools.ietf.org/html/draft-beeram-ccamp-gmpls-uni-bcp-00
> Presenter: Igor Bryskin
> Notes:
Eve Varma: It seems like the VPN type of application, what's the distinction?
Igor Bryskin: We are not talking about VPN, we will talk about that in later releases of the draft. Basically what we do is providing a limit view of the underlying topology
Lou Berger: Looking forward to see the next version with this clarified and also the scope of the draft: info, standard track.
> Second Session
> Friday, November 18, 2011.
> 0900-1100 Morning Session I
> Room Name: 3F Banquet
>
> Presentation Start Time Duration Information
> 0 9:00 5
> Title: Administrivia
> Draft:
> Presenter: Chairs
> Notes:
> 12 9:05 10
> Title: Label Switched Path (LSP) Provisioning Performance Management Information Base for Generalized MPLS (GMPLS) / MPLS-TE networks
> Draft: http://tools.ietf.org/html/draft-sun-ccamp-gmpls-perf-mib-00
> Presenter: Weiqiang Sun
> Comments:
Lou Berger: Does the device provide the info itself? Usually measurements are done by third-party devices, not the device being measured itself.
Weiqiang Sun: It is not a matter of measurement; it's a matter of storing the data.
Lou Berger: The document is within scope of the WG, but can I see a show of hands of how many are interested in working on this draft? [No hands shown] I am not sure the WG is interested in pursuing this. Please take this to the list and see if anyone is willing to work on this.
> 13 9:15 10
> Title: RSVP-TE Extensions for Configuration SRLG of an FA
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-srlg-fa-configuration-04
> Presenter: Oscar González de Dios
> Comments:
Lou Berger: The authors misunderstood the comments received at the last (IETF 81) meeting. The comment from the last meeting was “processing mechanics/procedures are good but application usage is out of scope”. You should add the text you removed back into the document. We can clarify this on the list. I will flag the comments.
González de Dios: Ok.
Lou Berger: Those commenting that they did not like the application usage, please post to the list and say "this is what I would like dropped".
Deborah Brungard: Poll on who read the document [Not too many, but less than the last meeting], anyone not comfortable with taking this to the list? [No] Ok we will take this to the list.
Lou Berger: As always you (authors) need people to indicate that they want to work on this in order to be accepted as a WG document.
> 14 9:25 10
> Title: Requirements for GMPLS Routing for ASON
> Draft: http://tools.ietf.org/html/draft-wang-ccamp-rfc4258bis-00
> Presenter: Qilei Wang
> Comments:
[Dropped at request of authors]
> 15 9:35 10
> Title: GMPLS-UNI BCP
> Note: This presentation will be moved to the end of session 1, if time permits
> Draft: http://tools.ietf.org/html/draft-beeram-ccamp-gmpls-uni-bcp-00
> Presenter: Igor Bryskin/John Drake
> Notes:
[This draft was presented in session 1]
> 16 9:45 10
> Title: Requirements for GMPLS Control of Flexible Grids
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-requirements-01
> Presenter: Fatai Zhang
> Notes:
Lou Berger: [Slide Impacts on WSON: Flexible Grid Specific Info] you are introducing the spectrum definition. Why are you not using the WRA term we've been using for a while?
Fatai Zhang: We are trying to differentiate from existing terminology, specifically flexible and fixed.
Lou Berger: The differentiation among the two terms is something that matters only to those who are deeply involved.
Fatai Zhang: Ok I can understand we can use ITU terminology.
Deborah Brungard: The work is in (in the ITU) progress, we will continue to Liaise with them.
Malcolm Betts: We need to be cautious about moving ahead here. There is no mention of components that support it (including application codes). We may need new terminology; if it is different from a central wavelength. There are various things to consider versus fixed grid. This assumes tunable filters, yet this likely to be limited. Yes, interesting but let’s be a little cautious.
Lou Berger: So to clarify. You are saying this work is early? Also that you’d like to use the new term.
Malcolm Betts: Yes, but it is also dangerous to use terms that may be different.
Lou Berger: Ok and you think the term flexible grid is not enough? Yes.
Iftekhar Hussain: The ITU is defining the grid not how the grid is used.
Fatai Zhang: This kind of question cannot be assumed.
Lou Berger: We need to be clear (from a process perspective) that we are not defining data plane functionality; that belongs to the ITU-T.
Jon Sadler: I am concerned with some of what is being said and presented. I think we need to wait for ITU to further evolve the work.
Julien Meuric: If we are too early for technology, let’s discuss terminology. Stacking too many terms, in our context, is a waste of time.
Eve Varma: I agree with Malcolm. It is not a good idea trying to make the flexi-grid fit the current terminology.
Rajan Rao: From GMPLs perspective, we do not need to constrain ourselves.
Deborah Brungard: No one is against doing the work, just to be cautious about what we work on. We should send a liaison to the ITU-T notifying them that we are beginning this work.
> 17 9:55 8
> Title: GMPLS OSPF-TE Extensions in support of Flexible-Grid in DWDM Networks
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-ospf-ext-00
> Presenter: Fatai
ZhangDaniele Ceccarelli
> Notes:
Malcolm Betts: It will be interesting to see how extensions can be achieved for routing constraints, especially via cross connects.
> 18 10:03 7
> Title: RSVP-TE Signaling Extensions in support of Flexible Grid
> Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-rsvp-te-ext-00
> Presenter: Fatai Zhang
> Notes:
Lou Berger: There are some open issues being discussed on the list, which span across multiple documents. Let us discuss those issues after the flexi-grid presentations.
> 19 10:10 10
> Title: OSPFTE extension to support GMPLS for Flex Grid
> Draft: http://tools.ietf.org/html/draft-dhillon-ccamp-super-channel-ospfte-ext-01
> Presenter: Abinder Dhillon
> Notes:
Lou Berger: A clarifying question, if you found some issues (with WSON documents). Please send comments to the authors and ideally via the list.
Eve Varma: If I had not been familiar with Super Channel terminology I thought you were changing the G.872 architectural concepts. I'm really uncomfortable with any work on control plane addressing super channel issues.
[Missed additional speakers question]
Deborah Brungard: We need to stick with ITU.
Rajan Rao: Yes.
> 20 10:20 10
> Title: Generalized Label for Super-Channel Assignment on Flexible Grid
> Draft: http://tools.ietf.org/html/draft-hussain-ccamp-super-channel-label-01
> Presenter: Iftekhar
Hussain Marco Sosa
> Notes:
Adrian Farrel: We have methods for concatenating labels, why do you see your proposal being required?
Iftekhar Hussain: This is viewed purely from the optical spectrum.
Adrian Farrel: Again, your super channels are a composite. So back to my question? [no response.] Perhaps we need to take this to the list.
> 21 10:30 10
> Title: Generalized Labels for the Flexi-Grid in Lambda-Switch-Capable (LSC) Label Switching Routers
> Draft: http://tools.ietf.org/html/draft-farrkingel-ccamp-flexigrid-lambda-label-01
> Presenter: Dan King
Adrian Farrel
> Notes:
No Questions.
> 22 10:40 10
> Title: OSPF-TE Protocol Extension for Constraint-aware RSA in Flexi-Grid Networks
> Draft: http://tools.ietf.org/html/draft-zhangj-ccamp-flexi-grid-ospf-te-ext-00
> Presenter: Yongli Zhao
> Notes:
No comments
> 23 10:50 10
> Title: Discussion & next steps on Flexible Grid
> Draft:
> Presenter:
> Notes:
Deborah Brungard: We are not reinventing the data plane. We will synch with ITU
Malcolm Betts: Something to consider are the use case scenarios. Basically flexi-grid to support bit rates beyond 100Gb, are these in isolation or with existing services over new flex-grid. Also do we signal for old services over flex-grid?
Lou Berger: What level of compatibility do we need? I think we will see combined usage, at control plane, not data plane.
Adrian Farrel: That is exactly one of the questions I have. It begins to sound that one interface may give you a variable label or a fixed label, and then we need to consider other information. Do we need to support separated or mixed?
Lou Berger: If the data plane allows multiple types.
Adrian Farrel: would we model it as two data planes
Lou Berger: Keep in mind labels are data channel identifiers.
Malcolm Betts: We have c-band and l-band amplifiers, so it’s entirely possible to have mixed grids. An OXC with some ports fixed, some flex.
Lou Berger: That can also occur with fixed.
Adrian Farrel: Multi-port is easier to handle
Young Lee: We saw a lot of solutions documents (for flexi-grid) already,
we need a framework document but there are no clear requirements. Then from
there we can move forward. By the way, the WSON framework (and solutions) took
4 years.
Lou Berger: Are you volunteering?
Young Lee: No.
Eve Varma: I agree with Young. Also a caveat, the super-channel, this term is being used too loosely.
Malcolm Betts: We should think about waveband.
Iftekhar Hussain: The wavelengths may not be strictly contiguous.
Lou Berger: Clearly a lot of interests, we’re early, including a number of individual drafts. We also see some overlapping drafts so encourage authors to collaborate and combine. We will send a Liaison to ITU-T that we’re beginning work on this area.
> Adjourn 11:00