* 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-105 ccamp minutes

Session 2019-07-25 1330-1530: Van Horne - ccamp chatroom

Minutes

minutes-105-ccamp-00 minutes



          Agenda
          Thursday, July 25, 2019 (EDT)    13:30-15:30   Thursday Afternoon session
          I
          Room: Van Horne
          
          13:30
          Title:Administrivia - WG Status - Reporting on WG drafts not being
          presented
          Presenter:Chairs
          Haomian Zheng: (draft-ietf-ccamp-client-signal-yang) the model and open
          issue is being tracked on the github, and will update to address the
          issue.
          Gabriele Galimberti: (draft-ietf-ccamp-dwdm-if-lmp) no update on the
          draft. We assume they are quite stable.
          Haomian Zheng: (draft-ietf-ccamp-l1csm-yang) L1CSM need to be updated
          and import the new Layer1-types.
          Gabriele Galimberti: (draft-ietf-ccamp-flexigrid-yang and
          draft-ietf-ccamp-flexigrid-media-channel-yang)flexi-grid need to be
          checked to better align with ITU-T work.
          Dieter Beller: (draft-ietf-ccamp-layer0-types) layer0 type files are
          also available on the github. May need to add reference.
          Italo Busi: (draft-ietf-ccamp-transport-nbi-app-statement) T-NBI design
          team is ready for final round of review (thanks to Dieter and Micheal for
          the valid review comments); it is planned to be finished in August and
          then we are ready for WG LC. Only issue is that the normative references
          are mainly in WG status with one document still individual.
          Daniele Ceccarelli: This is not a blocking issue for WG LC, we can do
          the last call and move the procedural processing to RFC editor.
          
          13:44
          Title:A Yang Data Model for Optical Impairment-aware Topology
          Draft:https://tools.ietf.org/html/draft-ietf-ccamp-optical-impairment-topology-yang-01
          
          Presenter: Dieter Beller
          
          Gabriele Galimberti: Actually this is not a question, but it is a
          recommendation. When introduce, for example, 3R generator, the layer
          0 type draft should be applicable. And then we are working together to
          keep this document in sync with our draft.
          Dieter Beller: we have general strategy to have common types
          yang module for the layer 0, including topology and interface
          model. Need better coordination between this work, layer0-types and
          draft-ietf-ccamp-dwdm-if-param-yang.
          Gabriele Galimberti: just reinforced again the message, on the github
          there are all these documents and then you can see how they are aligned
          and then keep all these jobs synchronized together.
          Fatai Zhang: (clarification) assumptions on P7; I think actually the
          three assumptions are correct. But based on the ITU-T recommendations,
          it says that OTSI may consist of one single carrier or a group of carriers
          or sub-carriers.
          Dieter Beller: Yes, we deliberately did not want to have that because we
          believe that it's not likely to have an OTSiG that can contain multiple
          OTSIs and so on, to have a second level of inverse multiplexing. And
          that was the message of the proposal in the ITU-T contribution. (C1505)
          We believe that this overcomplicates the management of the WDM network.
          Fatai Zhang: Yes, the purpose of the ITU-T contribution is clear but
          the contribution and the proposal were rejected by ITU-T. In IETF we
          don't define specific technologies, usually from the control plane
          perspective. We should follow the ITU-T recommendations. In this case,
          if it's not consistent with ITU-T recommendation, how can we handle the
          issue? ITU-T is not going to modify the definition of OTSi based on your
          proposal.
          Dieter Beller: Good question, if you look at the optical transponder
          today, all the vendors are using single carrier that is modulated to
          carry digital information. The Liaison from ITU-T indicated that 'in
          future there MAY be multiple carriers carried by OTSi' but today I think
          such modulation schemes do not exist in the real network.
          Julien Meuric: it is a terminology issue. ITU-T and IETF have separate
          terminology systems. We may have alternative terminologies if ITU-T has
          any restriction.
          Daniele Ceccarelli: Moreover, we are not defining the concept of OTSi,
          it can be composed by one or multiple carriers. We just support the
          configuration with a single carrier.
          Dieter Beller: Exactly.
          Gabriele Galimberti: Even if we decide to model multi-carrier inside an
          OTSi, we don't know how to do. There is no existing implementation,
          Daniele Ceccarelli: Probably be careful when writing the documents, don't
          write "we only assume single carrier" but instead "OTSi can carry one
          or multiple, but within the scope of document, we just assume a single
          carrier.
          Sergio Belotti: the mangement/control in ITU-T is single entity,
          so the number of carriers in the OTSi won't impact much on the
          control/management.
          
          14:11
          Title:A YANG model to manage the optical interface parameters for an
          external transponder in a WDM network
          Draft:https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-param-yang-01
          
          Presenter:Gabriele Galimberti
          
          Gert Grammel: (as co-author) to clarify, in this draft the proposed
          interface model is applicable to different carriers
          Fatai Zhang: does this draft need to be reviewed by YANG doctors?
          Gabriele Galimberti: Yes but not now.
          Dieter Beller: did you say you have a github? we should share them
          in the same github (as impairment-topology-yang), to ensure that they
          are consistent and reviewed by the people who are contributing to the
          project.
          Gabriele Galimberti: Absolutely, it's a good suggestion.
          
          14:10
          Title:Yang Models for OTN and Layer 1 Types
          Draft:https://tools.ietf.org/html/draft-ietf-ccamp-otn-topo-yang-07
          Draft:https://tools.ietf.org/html/draft-ietf-ccamp-otn-tunnel-model-07
          Draft:https://tools.ietf.org/html/draft-ietf-ccamp-layer1-types-01
          Presenter:Haomian Zheng
          
          Daniele Ceccarelli: process thing - the order for progressing the
          documents should be types, topology and tunnel. Layer 0 and Layer 1
          types are the next ones to be moved forward.
          Haomian Zheng: Right.
          Daniele Ceccarelli: the yang doctors are overloaded on reviews. Could
          we skip the yang doctor review for the types draft as it's relatively
          simple?
          Haomian Zheng: I'm not sure if I'm the right person to answer.
          Loa Andersson: do the yang doctors need to see these to reveiw the
          others?
          Haomian Zheng: it'd be efficient to have the same yang doctor review
          all three.
          Daniele Ceccarelli: Sure, I'll see if that's possible to have a 'cluster
          review'.
          Italo Busi: L1 types are used by OTN topology and tunnels and need to
          be understood to review them. I don't know if yang doctor review needs
          to be done before publishing an RFC
          Michael Wang: Yang doctors will want to review the types modules.
          Igor Bryskin: we've been through this many times already with other
          modules. I'd suggest we do the yang doctor review as early as possible as
          we get a lot of good feedback from it. If you don't get it right then many
          models that depend on the types module will also be affected by changes.
          Loa Andersson: a cluster review is possible, but you have to talk to
          the people running the yang doctor process. And then request the reveiws
          immediately after each other.
          
          
          14:31
          Title:Yang Models for Ethernet TE Topology
          Draft:https://tools.ietf.org/html/draft-zheng-ccamp-client-topo-yang-06
          
          Presenter: Italo Busi
          
          Daniele Ceccarelli: why TE topology and not just topology?
          Italo Busi: Because we are re-using some of the generic TE constructs
          such as:
              - inter-layer lock for inter-layer relationship between access link
              and server TTP
              - plug-id for inter-domain discovery of access links
              - client-id/provider-id to report who is providing the abstract
              topology
          Tarek Saad: so ethernet is a service layer and the underlay is something
          else?
          Italo Busi: yes
          Tarek Saad: When you are modeling L2, how is it different with other L2
          topology, L2VPN as a service topology? It's not TE constraint but it's
          still L2.
          Igor Bryskin: no, it's only TE.
          Italo Busi: the problem we solve in this draft is the client signal over
          TE tunnels. So when you set up a signal and you want to see what traffic
          is on that. You may need a particular signal to go over a particular
          tunnel.
          Tarek Saad: so it is not L2 topology.
          Italo Busi: Agree. What we want to say is just the traffic that enters
          the network from this access link with VLAN=10, I want this traffic to
          be carried by this TE tunnel, and this access link with VLAN=20.
          Tarek Saad: so the draft links the service and the tunnel.
          Daniele Ceccarelli: there is a service and there is a tunnel, so you
          said there is no swithching.
          Tarek Saad: Maybe they should be divided into a service model and a
          transport model, where the service is the access link and the tunnel is
          the PHY number.
          Italo Busi: Yes, this is an Ethernet signal that is basically accessing,
          that is also clarifying how the traffic is here, and which tunnel you
          are using.
          Tarek Saad: for L2VPN, they have L2VPN service model, and then they have
          the tunnel model.
          Italo Busi: it's different with L2VPN, the client signal goes over the
          TE (e.g. OTN) tunnel. But you have to reference the TE tunnel between
          the two client points, you have to model which traffic goes to here
          (tunnel start), and that's the client signal, and reference the right
          link. If you find a link that is not capable to carry this client signal,
          you cannot use it.
          Igor Bryskin: when talking about layer 2 service per se, we are talking
          about TE Layer 2 service. For example, if you have L2VPN with some kind
          of TE constraints or optimizations you will do that. So it's not about
          reachability but about traffic engineering. (Yes by Italo)
          Igor Bryskin: Second thing, you can think about this is basically an
          Ethernet link which is supported by E2E tunnel in the pseudowire. There
          is also important use cases, when it's not one E2E tunnel, but multiple
          tunnels. (Italo: Yes. )
          Italo Busi: There are two scenarios: one is to discover the access links
          and another is to support ETH TE Tunnel/LSP path computation&setup
          Igor Bryskin: What I understand from you is in most cases you can
          specify which tunnel the service is from; but in more general case,
          it may not from a single tunnel, but can be two or three with a node
          in between that can terminate the tunnel and service. In this scenario,
          it looks the service is switchable.
          
          
          14:40
          Title:Applicability of GMPLS for B100G Optical Transport Network
          Draft:https://tools.ietf.org/html/draft-ietf-ccamp-gmpls-otn-b100g-applicability-01
          
          Presenter:Qilei Wang
          
          No Comments/Discussions.
          
          14:46
          Title:Framework for FlexE
          Draft: https://tools.ietf.org/html/draft-izh-ccamp-flexe-fwk-07
          Presenter: Loa Andersson
          
          Daniele Ceccarelli: (clarification on P8) is it a FlexE link or a
          collection of FlexE links, from ingress to egress?
          Loa Andersson: the FlexE link(s) between two boxes have to be
          terminated. But in the control plane you can see which box has flexE
          links attached to which box. So you can pick the interfaces. You say
          you want to have an Ethernet link with the following characteristics
          and then sharing accross toghether with the other side. Each node should
          have the capability to select where the flow should go.
          Qilei Want: can flexE client be defined as a network layer?
          Loa Andersson: I don't really think so.
          Qilei Wang: I think you use RSVP to set up flexE client connection.
          Loa Andersson: Sure, and same way to set up another link.
          Qilei Wang: If you do this, it makes FlexE as a network layer.
          Loa Andersson: the thing I think we can model as a a network layer is
          the collection of existing FlexE client in the network, not in the single
          link.
          Qilei Wang: Let me ask in another way, so far according to the flexE
          standard, there is no information on the source/dest node address. without
          such information how you can set up a FlexE client connection?
          Loa Andersson: I don't clearly get the question, how do you do is model
          driven.
          Qilei Wang: I think there is no essential information like
          source/destination address, then it's not a layer.
          Loa Andersson: So you think you can do something with the same link to
          the same (like 5 in the example). But you cannot do it with the control
          plane.
          Qilei Wang: We want to set up the connection with RSVP, that is
          switchable;
          Loa Andersson: Then we should start working on signaling and routing part,
          it has been done before, and why cannot be done here?
          Julien Meuric: as an operator, why do I care the link is flexE or not? For
          example we are having a 200G Ethernet service, what we care is only the
          bandwidth, but not whether the link is flexE capable or not. I don't
          see the value on setting up FlexE LSPs on FlexE-capable links.
          Loa Andersson: The assumption here is that FlexE has a bandwidth that
          is much bigger.
          Julien Meuric: Sometimes the path selection can be FlexE capable when
          do path computation. But it's always the 'boss order' to decide whether
          to take it.
          Loa Andersson: it's way bigger in bandwidth, and it is possible to split
          them up in granularity. So you can actually allocate bandwidth on a flexE
          client for a specific purpose. You cannot allocate explicit bandwidth on
          normal Ethernet, but can do it via FlexE. On a particular FlexE group,
          you have a flexE client that has a certain bandwidth. We can give you
          all that bandwidth, to you ONLY. And there's no way of doing that on
          the regular Ethernet. And that's the point with FlexE here.
          Julien Meuric:  IT's just me that unifying FlexE as a kind of 'what will
          you use, a little stitching or kind of connection really Ethernet, which
          is not the way I understand FlexE today. So that's my problem to choose.
          David Sinicrope: I am kind of with Julien on this, I mean how is this
          any different than what we have with GELS on the Ethernet today?
          Loa Andersson: We don't have GELS.
          David Sinicrope: my understanding of the FlexE links is not visible
          to anything above the Ethernet.64/66B right? So how does any kind of
          control protocol know that it's even talking about FlexE links?
          Loa Andersson: we not use OIF.
          David Sinicrope: FlexE is hidden underneath and it looks like Ethernet
          to the upper layers. So you are saying it's not quite flex.
          Loa Andersson: in FlexE you define a flexE client over a FlexE group. That
          flexE client is visible to the control plane.
          David Sinicrope: So when you have an Ethernet client, they use a flexE
          link. No FlexE client, FlexE is configured underneath it. And it's done
          on a very coarse granular basis by configuration. So the idea that it's
          dynamic and we can switch the bandwidth down, you know with the control
          protocol to Qilei's point which I think I understood there is no handle
          for the control protocol get hold of unless you're exposing it out of
          the 64/66B layer, FlexE here may violate IEEE 802.3.
          Loa Andersson: So what do you use if you use it from a YANG model?
          David Sinicrope: Like the static configuration, I would forget the YANG
          model. I use the proprietary data model works the same way, but there's
          no control for us all to do.
          Igor Bryskin: Let me try to help. I think you are talking about different
          levels. it's true that in the upper layer it's not just Ethernet, but
          there can be a different story that requires different orchestration or
          control mechanism, think about L2VPN cases. Is my understanding correct?
          Loa Andersson: I think so.
          Igor Bryskin: it requires different models for different control
          mechanisms.
          Deborah Brungard (no hats): (P8) people are concerned on whether it's
          switching, the understanding is no.  As Julien said, we would not look
          as necessarily having to prefer FlexE capable, so when advertising flexE,
          you are advertising how much bandwidth can be supported on that link.
          Loa Andersson: So you are saying that based on a FlexE client, you can
          advertise bandwith?
          David Sinicrope: The way I understand this is you wouldn't advertise it
          as a FlexE client, but would advertise it as an Ethernet link with very
          good QoS characteristics. There's nothing exposed to advertise in routing.
          I can't send it in signaling protocol. To Igor's point, your distraction
          would be different. Why? Because it's in the interface configuration that
          I can figure the FlexE groups and the channels and associate them together
          not in the control protocol and not in the routing. It can be changed. And
          then that can be reflected into routing and into the control protocol.
          
          Gert Grammel: (to Loa) did you intend to extend LMP? From my perspective
          adding FlexE to LMP would be sufficient.
          David Sinicrope: there is work on flexE-switch technology and switching
          sub-layer. That part would request the control protocol in ccamp. It's
          called G.MTN and is progressing in ITU-T SG15 and we need to wait until
          it is complete to trigger protocol work.
          Daniele Ceccarelli: but this is not the scope of this draft.
          Qilei Wang: in ITU-T the FlexE is defined as a section layer of MTN.
          Daniele Ceccarelli: let the chairs discuss, and then announce on the
          list.
          
          15:15
          Title:YANG Data Model for FlexEInterface Management
          Draft: https://tools.ietf.org/html/draft-jiang-ccamp-flexe-yang-01
          Presenter: Michael Wang
          
          Qilei Wang: (P7) for the difference, (speaking on behalf of the other
          draft), it would be useful to analyze the pros and cons.  I think we can
          check something from Q11 in ITU-T SG15. Say ITU-T G.8023. That would be
          needed for calendar reconfiguration.
          Michael Wang: are you tring to configure the calendar A and B?
          Qilei Wang: it's reconfiguration.
          Michael Wang: First if your model support NMDA architecture the YANG
          models and the architecture also can provide the ability to help you to
          change the configuration transaction. NMDA can help you do so via intent
          datastore.
          Yuanlong Jiang (Remote): Are such YANG module itself already supporting
          multiple store capabilities such as the the startup/candidate/running. so
          we don't need to repeat the configuration. Another point is if you
          dynamically add a new client, usually it's done in sequence. And the data
          plane can still regard the first previous communication as Calendar A,
          and the newer configuration as Calendar B. So it doesn't matter. We
          provided it in the communication module as a Calendar A or Calendar B.
          David Sinicrope(speaking for BBF): there is ongoing works in BBF which
          is waiting for YANG model about flexE representation and configuration.
          
          15:25
          Title:Analysis for FlexE control & YANG Model for FlexE
          Draft:https://tools.ietf.org/html/draft-wang-ccamp-flexe-control-analysis-02
          
          Draft:https://tools.ietf.org/html/draft-xiaobn-ccamp-flexe-yang-mod-02
          Presenter:Qilei Wang
          
          David Sinicrope: this model seems more consistent with my understanding
          of FlexE. My question is have you confirmed this with OIF?
          Qilei Wang: No.
          Haomian Zheng: (comments to both presentations) even if there is related
          work in OIF/ITU-T, we should look into other IETF models, so far there
          is no clear augmentation.
          David Sinicrope: it won't be possible to have ITU-T model consistent
          with IETF model, they are mutually exclusive.
          Michael Wang: Received an email from my colleague with a lot of open
          issues. For the model design, there is still more discussions needed.
          Daniele Ceccarelli: there is no agreement a common way forward for the
          two drafts.
          David Sinicrope: I think it's a great place here (ccamp) to start the
          work.
          
          Adjourn15:30
          
          



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