* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ccamp Status Pages

Common Control and Measurement Plane (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2001-Jan-31 —  
Chairs
 
 


IETF-102 ccamp minutes

Session 2018-07-17 1550-1820: Saint-Paul/Sainte-Cath. - ccamp chatroom

Minutes

minutes-102-ccamp-02 minutes



          IETF-102 ccamp agenda
          Session 2018-07-17 1550-1820: Saint-Paul/Sainte-Cath. - ccamp chatroom
          
          Agenda
          CCAMP Agenda For IETF 102
          Session I
          Tuesday, July 17, 2018 (EDT)
          15:50-18:20 Tuesday Afternoon session II
          Room: Saint-Paul/Sainte-Catherine
          Presentation                Start Time        Duration        Information
          
          0                 15:50        5        Title:        Administrivia -
          WG Status - Reporting on WG drafts not being presented
          Draft:
          Presenter:        Chairs
          1                 15:55        10        Title:        Transport
          Northbound Interface Applicability Statement
          https://tools.ietf.org/html/draft-ietf-ccamp-transport-nbi-app-statement-02
          
          Italo Busi
          
          Gert Grammel:How do you define vendor's domain?
          Daniele Ceccarelli: this is only different domains, not necessarily to
          be different vendors.
          Gert Grammel: Are they assumed to different control domain?
          Italo Busi: Transponder is in the network, not in the CE.
          Gert Grammel: Boundary is technology domain, but this is not necessarily
          true for all cases. Define more clearly on domain boundary.
          Italo Busi: Can be anything, any technology, ETH, STM, ODU.
          Gert Grammel: boundary is link basis here, but it can be a node??
          Italo Busi: Current assumption is that all links are ODU capable of
          switching at the ODU layer. Another individual draft is to solve the
          problem.
          Young Lee: what does it mean by 'boundary as a node'?
          Gert Grammel: It can be a single box, for both the client and
          transport. In this case the boundary is in the 'middle' of the box.
          Daniele Ceccarelli: One node is controlled by the same PNC control.
          Gert Grammel: There could be two clients to collect telemetry from one
          node. In such case, it is not necessarily true that one node is controlled
          by one controller.
          Fatai Zhang: Different SDOs may define different terminologies about
          domain, but we should use IETF language here. The IETF definition of the
          term "domain" should be used, the draft should reference to the related
          RFCs.
          Gabriele Galimberti: for the next step, is there plan for develop the
          case including L3?
          Italo Busi: not for now.
          Gabriele Galimberti: how about DWDM?
          Italo Busi: not yet. We can work if needed.
          
          2                 16:05        15        Title:        A YANG Data Model
          for OTN Topology and Tunnel
          Draft:
          https://tools.ietf.org/html/draft-ietf-ccamp-otn-tunnel-model-03
          Draft:
          https://tools.ietf.org/html/draft-ietf-ccamp-otn-topo-yang-03
          Presenter:        Haomian Zheng
          
          Mahesh Jethanandani: Since you will do the YANG doctor review soon or
          later, you could send the question to YANG doctor list, to ask an early
          review
          Gert Grammel: Where to put OTU: in the ODU or in the WDM? I think OTU
          should pair with ODU. The draft should have clear statement about where
          to put OTU.
          Haomian Zheng: OTU is not needed as it is a data plane modeling, but we
          can discuss this point in the list.
          Haomian Zheng: I do not think OTU has to be configured.
          Mahesh Jethanandani: Meet all the guidelines from RFC6087-bis before
          sending to YANG doctor's review.
          Daniele Ceccarelli: [TE Tunnel] draft did not finish for WG LC, while
          [TE-Topology] model is now stable. OTN topology will start the YANG
          doctor review first, and then OTN tunnel. Need to follow the guideline
          before that.
          
          3                 16:20        10        Title:        A Yang Data Model
          for L1 Connectivity Service Model (L1CSM)
          Draft:        https://tools.ietf.org/html/draft-ietf-ccamp-l1csm-yang-05
          Presenter:        Young Lee
          
          Mahesh Jethanandani: I work in IETF and MEF, MEF service YANG model,
          particularly service-type, MEF58.
          Dieter Beller: Support alignment with MEF models. Is a liaison necessary?
          Daniele Ceccarelli: Any feedback from MEF?
          Young Lee: Currently there is no data model in MEF, only info model. This
          work is welcome in MEF as long as alignment.
          Fatai Zhang: If the draft only cover L1, how about L0?
          Young Lee: We cover only L1. Also MEF does not have plan for L0
          services. Missing standard references from ITU-T.
          Gert Grammel: Is there any place define L0?
          
          4                 16:30        10        Title:        Information
          Encoding for WSON with Impairments Validation
          Draft:
          https://tools.ietf.org/html/draft-ietf-ccamp-wson-iv-encode-01
          Presenter:        Young Lee
          
          Young Lee: Where to define GMPLS encoding? In this document or another
          document? I propose to add specific protocol enhancements (e.g., OPSF-TE
          and RSVP-TE) in this document rather than creating separate documents.
          Daniele Ceccarelli: There are no strict rules. It's up to the authors'
          decision. If added to this WG document, the text to be added should be
          agreed by the WG.
          
          
          5                 16:40        10        Title:        A YANG Data Model
          for Microwave Topology
          Draft:        https://tools.ietf.org/id/draft-ye-ccamp-mw-topo-yang-01.txt
          
          Presenter:        Amy Ye
          
          Igor Bryskin: you said the topology can be divided into overlay/underlay,
          however they are not independent with each other. A tunnel in the
          underlying topology supports a link in the overlay domain. Therefore a
          MW tunnel supports an overlay ETH link, not a MW link.
          Igor Bryskin: it's server-client relationship, MW need to have a tunnel
          in network that carries the ETH.
          Amy Ye: Yes, the ETH link is supported by the mw tunnel, the mw tunnel
          is supported by the mw link. It's just one hop tunnel.
          Lou Berger: How much of this is MW technology-specific or generic?
          Amy Ye: Nominal and current b/w are microwave specific.
          Lou Berger: I think you are just talking a variable bit-rate media
          channel. I suggest to change microwave model to variable bit-rate
          model. Just change the name to make it generic.
          Rick Taylor: Change the name to radio.
          Amy Ye: I think radio is a good name.
          
          6                 16:50        10        Title:        Interworking of
          GMPLS Control and Centralized Controller System
          Draft:
          https://tools.ietf.org/id/draft-zheng-ccamp-gmpls-controller-inter-work-02.txt
          
          Presenter:        Sergio Belotti
          
          Daniele Ceccarelli: For interface 3, it could also be a routing protocol
          (IGP or BGP)
          Young Lee: BGP for optical?
          Gabriele Galimberti: There should not be BGP-LS for optical.
          Daniele Ceccarelli: OK, but IGP is an option.
          Daniele Ceccarelli: What is the value to have IGP resource updated (IF#2)
          if everything is centralized?
          Lou Berger: interesting work but my concern is that it is duplicated
          with RFC8283 saying the same thing with different words.
          Lou Berger: Why in CCAMP and not in TEAS? There is nothing which is
          technology-specific
          Young Lee: I do not think that PCECC (RFC8283) and this one have
          overlapping content.
          Lou Berger: It is not complete overlapping, so there is room for this
          work. Ok to have a poll about interest: Chairs and AD can figure out
          which WG should take responsibility.
          
          Daniele Ceccarelli: How many people has read the draft? A lot
          How many think it is an interesting work for the Routing Area? A lot,
          almost the same number as who read.
          
          7                 17:00        10        Title:        A YANG Data Model
          for Transport Network Client Signals
          Draft:
          https://tools.ietf.org/id/draft-zheng-ccamp-client-signal-yang-00.txt
          Presenter:        Haomian Zheng
          Igor Bryskin: What we need is a generic framework, should not dependent
          on special technologies. Besides using the tunnels to carry the client
          signal, how to select the tunnel is also needed.
          Haomian Zheng: done in the Transport-NBI applicability statement draft.
          Igor Bryskin: network operator want to backup tunnel, to tell this
          connection should be protected by this backup tunnel. L3, TE tunnel, to
          describe the network service, then another. Should be a draft in TEAS.
          Haomian Zheng: It's a valuable point, but this work based on giving the
          tunnel beforehand and just put the client signal into the given tunnel.
          Dieter Beller: Some of the data node are not well-know, miss
          reference. The work should be done in ITU-T and IEEE.
          Haomian Zheng: for transparent signals, it's clear, for non-transparent
          (carrier-Ethernet), we will align with other SDO, and add reference.
          Italo Busi: The mapping to the Tunnel is generic (reference Tunnel's
          name) but the client definitions is technology-specific. We have tried
          to generalize but the client technologies are different.
          
          8                 17:10        10        Title:        Signaling
          extensions for Media Channel sub-carriers configuration in SSON in LSC
          Optical Line Systems.
          Draft:
          https://tools.ietf.org/html/draft-ggalimbe-ccamp-flexigrid-carrier-label-04
          
          Presenter:        Gabriele Galimberti
          
          Daniele Ceccarelli: How many think we should work on this topic?
          How many think this is a good candidate for WG adoption?
          How many read the draft? Almost
          Daniele Ceccarelli: Julien is in favor of the draft.
          Gabriele Galimberti: Maybe it could be a different document with the
          same content but it is time to start working on a solution.
          Daniele Ceccarelli: need to increase the interest.
          
          9                 17:20        10        Title:        IP - WDM interface
          extensions drafts
          Draft:
          https://tools.ietf.org/id/draft-dharini-ccamp-dwdm-if-param-yang-05.txt
          Draft:        https://tools.ietf.org/id/draft-galimbe-ccamp-iv-yang-06.txt
          
          Draft:
          https://tools.ietf.org/id/draft-dharinigert-ccamp-dwdm-if-lmp-07.txt
          Draft:
          https://tools.ietf.org/id/draft-ggalimbe-ccamp-flex-if-lmp-05.txt
          Presenter:        Gert Grammel
          
          Daniele Ceccarelli: We can consider adoption only when ITU finish
          the revision of the DWDM framework document. Same comment to the
          dwdm-if-param-yang.
          Haomian Zheng: Some misalignment between this work (iv-yang) and existing
          WG draft (IV-encode, iv-info). This work focus on ROADM only, while WG
          drafts are between the Ss and Rs. You have different scope.
          Gert Grammel: The parameters (e.g. power) need to be get from the ROADM,
          so they must fit together.
          Haomian Zheng: But only some of them (ROADM parameters) are needed
          instead of ALL of them, for impairment validation.
          Gert Grammel: Let's wait for the ITU document.
          
          10                 17:30        10        Title:        ISIS Extensions
          for Flex Ethernet Link Advertisement
          Draft:
          https://tools.ietf.org/id/draft-zhu-ccamp-flexe-link-advertisement-00.txt
          Presenter:        Mach Chen
          
          Daniele Ceccarelli: Expecting framework (FlexE framework). The FlexE
          framework draft doesn't have much discussion on the list.
          Dave Sinicrope: My understanding is that FlexE is defined by OIF and
          the only client is Ethernet. Why the routing is interested to know about
          FlexE?
          Mach: An example is to use the protocol to trigger the configuration of
          the sub-interface.
          Dave Sinicrope: Using the routing to exchange the FlexE characteristic,
          which is contradict to OIF.
          Dave Sinicrope: My understanding of the OIF spec is that the FlexE is
          not visible to the upper layer: they only see an Ethernet interface.
          Daniele Ceccarelli: These are actually the concerns with the framework
          document. If we have progress in framework, this draft could be
          considered.
          
          11                 17:40        10        Title:        GMPLS Signaling
          Extensions for Shared Mesh Protection
          Draft:
          https://tools.ietf.org/id/draft-he-ccamp-gmpls-signaling-smp-00.txt
          Presenter:         Jia He
          
          Yuji: Is APS channel set up by the signaling?
          Fatai Zhang: APS channel is already there and is based on data plane,
          the draft is defining the signaling to prepare the LSP, and then the
          APS will be used once there is a failure.
          Dieter Beller: SMP is the most complicated scheme. In the past we have
          developed framework documents to describe how the protection mechanisms
          work
          , this is required for this mechanism. A separated draft to describe
          the motivation would be useful before providing protocol extensions.
          Vishnu Pavan Beeram: It only requests a simple extension of the protocol.
          Italo Busi: Understand Dieter Beller's concerns, but prefer to do within
          the same draft.
          Jia He: This draft deals with the generic SMP, not ODU SMP.
          
          12                 17:50        20        Title:        DLEP extensions
          Draft:
          https://tools.ietf.org/html/draft-ietf-manet-dlep-credit-flow-control-02
          Draft:
          https://tools.ietf.org/html/draft-ietf-manet-dlep-da-credit-extension-05
          Draft:
          https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extension-03
          Draft:
          https://tools.ietf.org/html/draft-ietf-manet-dlep-multi-hop-extension-05
          Draft:
          https://tools.ietf.org/html/draft-ietf-manet-dlep-pause-extension-04
          Presenter:        Lou Berger
          
          Rick Taylor: Prefer split into separate documents.
          Lou Berger: the technical part keeps unchanged even split into different
          documents.
          Lou Berger: Who think it should be split? 75%
          Igor Bryskin: why we are discussing here?
          Lou Berger: AD thinks this DLEP work belongs to CCAMP
          
          Stan Ratliff: We got make better discussion first.
          Lou Berger: Ask AD's opinion
          Rick Taylor: Manet is split into CCAMP and PIM and have a conflict today
          Lou Berger: Need to add PIM as WG not to conflict to¡­
          Deborah: Not formally decided yet. The result will be in one month. If
          it comes to CCAMP, it's related with LMP, ask people to review and help.
          Rick Taylor: Real development on DELP.
          
          13                 18:10        10        Title:        Finite state
          machine YANG model augmentation for Transponder Reconfiguration
          Draft:
          https://tools.ietf.org/id/draft-sambo-ccamp-yang-fsm-transponder-reconf-01.txt
          
          Presenter:        Daniele Ceccarelli
          Gert Grammel: Given that it is transponder, should wait ITU?
          Young Lee: Talk to Nicola, next IETF we can have some draft to model
          the transponder from the network perspective.
          Fatai Zhang: Is it possible to combine with WSON models?
          Young Lee: Maybe in the WSON impairment model.
          
          Adjourn
          
          



Generated from PyHt script /wg/ccamp/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -