Draft minutes - Session II

Sixty-eight IETF, Prague, March 2007

Tuesday, March 20, 2007
1300-1500 Afternoon Session I
RTG     ccamp     Common Control and Measurement Plane WG

CCAMP Working Group Agenda Session II
======================================
CHAIRS: Adrian Farrel
        Deborah Brungard

Note takers: Giles Heron, Julien Meuric, Tomonori Takeda
============================
0. Administrivia (chairs) [5, 5/120]

Slides

============================

Agenda agreed.

=======================================================
1. Control plane requirements for GELS (Loa and Don) [30, 35/120]

Slides

Background reading
- draft-andersson-gels-exp-rsvp-te-01.txt
- draft-fedyk-gmpls-ethernet-pbb-te-00.txt
=======================================================

Don - Fedyk draft (PBB-TE) is rev of PBT draft. Tracking IEEE work on
      data plane. Project will be approved imminently in IEEE. Done in
      appendix as data plane is IEEE-defined. IETF just defining how to
      use GMPLS for control.

Loa - Andersson draft (GELS-EXP-RSVP-TE) is updated post comments. Not
      just doc of an experimental implentation (not impl. this version
      yet). Use GMPLS for "all" modes of connection types (where "all"
      is P2P - not using yet for P2MP though have soln). Variance with
      Fedyk is have more than one label type.

Don - GELS concluded that needed IEEE data plane.   IEEE doing 802.1Qay.
      IEEE projects are rolled up into larger specs - so Qay will be
      rolled up into Q spec.

Loa - Acreo did 802.1Q-based implementation. Describes certain
      conditions that we operate under. Works for 802.1Q.

Don - trying to define superset that will work for other defined
      switching paradigms.

Don - presented "Conventional Ethernet Bridging" and then "Configured
      Ethernet Bridging" where STP is removed and configure connections
      instead. So now have data plane and management plane. Finally
      GELS - where GMPLS is used to add back the missing control
      plane...

Loa - I looked at Don's pictures and didn't understand them until I
      slept on it!

Don - there is a std for partitioning the VLAN space as part of existing
      project on shortest path bridging... So will be an official way
      to do it.

Dimitri - when I looked at your "triangle" diagrams.   Issue is we have
          some 802.1 impacts. Cross-correlation in terms of what you
          can do even if you segment the VLAN space. That will be the
          major points in terms of getting this accepted by IEEE.

Loa - yes, agree is important to record interactions. But what has
      happened to me repeatedly is that when I come up with a problem
      and tell the IEEE guys they tell me there's an ongoing project
      that will fix the problem...
      that also needs to be part of documentation...

Don - diagram where remove CP dependencies is part of an IEEE project...

Don - back to GELS motives. Dave Allen has draft on PW interworking
      with PBT.

Loa - we have draft using MPLS with some G-MPLS extensions on top of L2
      Ethernet and optical L1. Takes about an hour to learn to
      configure all 3 layers. If you want to run different layers in
      "augmented" mode where can request services from lower layers you
      have good automatic support here with GMPLS.

Don - We separated components so could e.g. use management plane with
      signalling. So limited IP control plane for signalling.

Loa - need to be careful not to get packet forwarding through the
      control plane!

Don - LMP is like a superset of 802.1AB link management. So can
      leverage AB and use LMP.

Stewart - did I hear "sending control plane traffic through the data
          plane"?

Loa - no the reverse.

Stewart - well we mix the two all the time in the IP world

Loa - CP is not dimensioned here to handle data plane traffic. If you
      don't get costs on links you'll advertise the CP links into the
      data plane.

Adrian - issue is that is bad to send data traffic down control "
         channel", not control "plane"

Kireeti - issue here is that GMPLS is out-of-band, MPLS is in-band CP.

Zafar - how do you solve this? In GMPLS we normally have completely
        separated CP network and data network. So no way data can get
        into control network.

Loa - problem here is how do you define "completely different". Is
      totally separated in that no other IP connectivity between
      Ethernet LSRS than control plane but rides on same wavelengths
      etc.

Adrian - could use one fibre for control and one for data? Alternative
         seems to be to implement the LSRs correctly so they don't
         forward data on control channel.

Loa - so this is the issue of vendors' routers + inexperience setting up
      IP networks.

Dimitri - problem here is that always left flexibility as to how to
          route the IP traffic. Not been work in CCAMP since inception.
          Something unintelligable...

Loa - model we used for other data planes works quite well...

Don - GELS axioms. Some discussion on list on asymmetric b/w
      reservation. Idea is to fully exploit what Ethernet data plane
      can do - hence choice of VID configuration or VID+MAC
      configuration...

Dimitri - PBB-TE being done in IEEE. Not speaking about labels in IEEE?

Don - yes, don't call things "labels" in IEEE.

Dimitri - we know IEEE will speak of bridging. Are we forward looking
          about what IEEE will do?

Don - we took details of what IEEE is doing out, partly because is not
      an official project yet.

Adrian - assumption is that if we go back to IEEE and say we've started
         on a CP to control this sort of switching and they say "no",
         then we'll stop.

Dimitri - if PBB-TE is bridging with TE then doesn't it mean this sort
          of config is acceptable for bridging.

Loa - yes you can do this from a management station.

Loa - ATM forum talked about ATM headers. It was only in IETF that we
      talked about ATM labels.

Dimitri - we know PBB is operating. We don't know about PBB-TE at this
          point. Would like more info on how their initial framework is
          detailed.

Dave - given that PBB and PBB-TE can work together we won't alter the
       semantics of MAC addresses.

Don - pretty far along. Point is taken that we're not defining a data
      plane here but are using a defined one.

Loa - we know how .1Q, .1ad, .1ah etc. work. Will be amendments to .1Q.
      If we expect something new to turn up we have to consider that
      now. But according to IEEE credo all new standards will be
      backwards-compatible.

Dimitri - are we relying on backwards-compatibility of bridging to make
          these steps now?

Don - yes.

Don - (Types of LSPs). Been looking at P2P and P2MP in our draft. Loa
      can talk to the other aspects. Terminology differences.

Loa - there is shared forwarding in .1Q. Rely on source address to have
      an identity that is extended to exactly where things are going.
      In our mindset we drop the source address (not sure is right thing
      to do). So then have a MP2P LSP. Is largely overlapping with
      what Don talks about as P2P. We have done experiments on MP2MP
      LSP. Standard IEEE VLAN. Same VLAN configured on multiple ports
      and turn on learning/STP etc. once set up. But basically a
      standard VLAN. Possible to configure it pretty quickly with
      scripts etc. (as need to reset testbed several times a day).

Igor - my understanding of PBB is single source.

Loa - not implemented PBT. What I've done is .1Q plus a couple of
      deltas we find in most switches.

Igor - so don't require single source for the connection...

Loa - only use VLAN ID and dest address to point to an LSP.

George - When you say .1Q do you mean .1ad Provider Bridges? Are you
          doing QinQ?

Loa - no. Just using one Q tag. Though the next step is QinQ. Behaves
      the same way as the start of an MPLS tunnel. Set it up and put
      traffic in.

Kireeti - what signalling do you use for MP2P and MP2MP LSPs?
          Signalling or provisioning?

Loa - All signalled except MP2MP (which is set up with a script - mgmt
      plane).

Kireeti - so what signalling do you use for MP2P? Do you swap VLANs?

Loa - no, same VLAN through LSP. That's one of the differences with
      what we did earlier.

Don - changes we need in Gen label request for Ethernet.

Dimitri - Quesiton on MP2P techniques. Is Loa's implemantation
          compatible with Don's?

Loa - need to compare and clarify. We can do P2P with MAC and dest addr
      and then allow or not allow merging. Need to sort out terminology
      for shared forwarding.

Don - our view of MP2P is shared forwarding. Two independent LSPs that
      share the same label at the merge point. No difference
      signalling-wise if they don't share the label.

Kireeti - so basically MP2P LSP is multiple P2P LSPs that happen to
          share the last few hops.

Igor - is MP2P same as N x P2P which merge at same destination.

Don - "shared forwarding" is two individual LSPs sharing same tail-end
       label.

George - do all sources use same dest address? And how do you avoid
         paths that criss-cross?

Loa - criss-cross can be solved in routing protocol. Once you merge you
      merge.

George - so not sending explicit path in RSVP message.

Loa - send explicit path to merge point, but once resolve is same as an
      existing path we allow you to merge onto it unless we set that you
      can't do it.

Adrian - George and I need to work on this. MP2P-TE needs to be solved
         in a generalised way for MPLS, GMPLS and GELS.

George - this sounds a little non-standard as compared to what RSVP-TE
         does at the moment.

Loa - I admit to that.

George - so you have full ERO and then if you hit a merge point and
         merge is allowed then you merge?

Loa - yes. And don't have b/w reservations. If TSPEC is the same can
      merge.

Don - shared forwarding is a limited version of merging. No merging of
      b/w etc. More definition required around this term in the
      documentation.

Loa - what you can accuse me of is using RSVP-TE in an LDP fashion. We
      admit this is not standard. We are building our experimental
      platform. If what we do is good then fine, of not will change
      it...

Loa - this slide (Gen Label Request) is additions, not changes.

Don - using Dimitri's T-spec as a good starting point.

Don - 2 diags stolen from Dave Allen as to where this is applicable:
      1) PBB net with edge and core bridges offering a native Ethernet
         VLAN over the top. Looks like VPLS but is all native Ethernet.
      2) case like a PW for aggregation.

Loa - my comparible picture shows network from "above" and "the side".
      Yellow part is GELS. So have MPLS over GELS over X? X != optical
      switches in this testbed.

Igor - you said GELS could help for optical networks.

Loa - was a bit more careful than that. When we get people into our
      network we want to do test incorporation. Want to help people
      understand the idea. The operational paradigms of the layers are
      very close. If you want inter-layer signalling that works over
      UNI.

Igor - so in your opinion the CP similarity helps integration.

Loa - yes, helps operational side at least.

Igor - so people need to learn less? If familiar with optical CP can
       learn Ethernet CP?

Igor - you also said GELS helped interwork configured Ethernet with
       MPLS. What did you mean? I read it as it helps by removing MPLS.
       Is that correct?

Don - is interfacing Ethernet MAN to an MPLS network.

Igor - I don't see MPLS here.

Don - is in the WAN.

Dimitri - Where does the LSP start and finish in these diagrams? Is it
          an S-PVC mode or an SVC mode.

Loa - in our network Ethernet LSP starts at Ethernet I/F of the IP
      router. Optical LSP starts on Optical interface of Ethenret
      switch.

Dimitri - is is always a switched mode from access to S-PE?

Don - in this case would have a PW that could be terminated or stitched.
      You can always choose to terminate and then ?

Dimitri - this is one of the limitations in UNI deployments today. Do
          we gain something by only having a switched mode that goes
          router to router, or do we need a mode that goes edge to edge.
          So from ingress PE to egress PE that doesn't impact the IP
          routers (S-PVC mode rather than SVC mode). When I look at
          usage of GMPLS we may need to consider both modes.

Adrian - don't see anything in protocol that prohibits either mode. If
         something shows up then should flag it as we need to keep both
         modes available.

Dimitri - asking other way round. If we only have switched mode then
          can only deploy GMPLS on nodes that today aren't able to do
          it. I'm stating about our experience of deployment... That's
          a concern. Let's look at today's access nodes...

Loa - I've kind of lost the Q? I suggest you write the Q down and put
      it on the list...

Don - we don't need to add that much to GMPLS. Next step is to add a
      milestone for WG charter for experimental GELS spec (Loa's
      suggestion). Add milestone to develop a spec for GELS
      signalling/routing (combined suggestion).

Adrian - at all future meets GELS will be at end of agenda and you can
         carry on in your own time. Think we're premature for milestone
         requests. Both of you can continue experimental work, but
         doesn't come into WG quite yet. Rules still apply as to how to
         bring stuff into WG. Consider yourselves lucky that you were
         allowed to present this. Rules say that if you believe you
         have an IEEE-conformant data plane then we liase to IEEE and
         say that we wish to control it, is that ok?

Loa - brought 802.1Q.

Adrian - just say "please" ;-) let's talk offline, I need to understand
         the dataplane we're liasing a request about...

=======================================================
2. ARP over GMPLS (Zafar) [10, 45/120]

Slides

Background reading
- draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
=======================================================

Zafar went over the slides, explaining changes and requesting to be a
WG I-D. Suggest to use tunnel interface address for ARP request.

Lou - Why is it different from other p-to-p link between routers?

Zafar - This is ethernet, so need ARP.

Lou - It exists without GMPLS, right? Is your solution applicable to
      those spaces?

Zafar - We never have two addresses for the same physical address, this
        is what you see in GMPLS.

Lou - The issue of p-to-p ethernet is new for some router vendors?

Zafar - Typically we don't use unnumbered ethernet IF. The second point
        is that we typically don't use two addresses.

Lou - The first point is just unnumbered ethernet, and some vendors
      don't understand it. Sounds like it is not CCAMP issue.

Zafar - Why? We are using signaling.

Lou - That is the second problem.

Lou - The second problem sounds like GMPLS stuff. But it seems just a
      broken implementation.

Zafar - It is unclear implementation.

Lou - What category do you intend for this I-D?

Zafar - BCP.

Igor - Where does the optical LSP start and end?

Zafar - Between routers.
Igor - Where is the ethernet connection?

Zafar - It is also netween routers

Igor - What type of connection?

Dimitri - Good point. You can carry anything over optical LSP, so need
          to be sure whether we want to say framing etc.

Deborah - Good discussion. Igor raised a good question - is the
          connection optical or ethernet. Take it to the list.

Adrian - (To Zafar) Please drive the discussion so we get progress
         before the next IETF.

=======================================================
3. Traffic Engineering Extensions to OSPF in support of inter-AS TE
(Mach Chen) [10, 55/120]

Slides

Background reading
- draft-chen-ccamp-ospf-interas-te-extension-01.txt
=======================================================

Mach went over the slides, explaining motivations and protocol
extensions.

Yakov - Overlap with OSPF auto-discovery in L1VPN. Encourage you to look
        at L1VPN WG.

JP - You say this is mandatory for BRPC, please clarify in which case
     you may need it. Can you also make sure you do a cut and paste of
     the "not to do" slide into the draft. The draft is fine. Want to
     make sure that the draft tells us what we're not trying to do to
     prevent people coming up with silly ideas. Are you writing down in
     the document that not doing TE aggregation?

Mach - Yes.

Acee - Could you replace extensions to OSPF to extensions to OSPF-TE?
       Add OSPFv3 for refernece as well. This should be applicable to
       both, but need to define if that is the case. Also not sure I
       agree that it should be bundled with L1VPN autodiscovery.

Stewart Bryant - The reason for ASs and BGP, etc, is for info hiding.
                 Can we make sure that you are not feeding private
                 information?

Adrian - doesn't that follow from saying that don't share TE info
         outside AS?

Stewart- Yes, but need to be v. strict...

=======================================================
4. Bidirectional LSPs with asymmetric bandwidth requirements
(Attila) [10, 65/120]

Slides

Background reading
- draft-takacs-asym-bw-lsp-00.txt
=======================================================

Attila went over the slides explaining motivations, options for
achieving this, and futher works.

Zafar - can you explain why you need both LSPs to follow the same route?

Attila - in some scenarios is beneficial to do that for management and a
couple of other issues.

Zafar - think Q is back to requirements of draft. I think you need to
        spell out more on the application why you need same path.

Julien - I agree that co-routed asymmetrical services is needed. But
         you may have missed possible scenario where you could associate
         bidirectional LSP at ingress.

Lou - I think Zafar has a good point. Before we jump into
      implementation need to say that this is a needed service and that
      what we have today is not sufficient. We did bidirectional
      symmetric service because the transport network needed it. if we
      don't have such a transport network then what we have here may be
      sufficient.

Attila - this extension is an optional optimisation. Not a requirement

Lou - so need to enumerate the cases where it's useful and what the
      benefit is.

Rowen Soloman - sometimes bundling 2 unidirectional LSPs and doing low
                level config of egress traffic management is complex.
                but want to see a relationship between this new object
                and CAC funtionality. When do you go to CAC to reserve
                b/w for the alternate direction? When is error sent if
                there's insufficient b/w.

Attila - this is implementation Q.

Rowen - would like to see recommendation.

Igor - like to see whether we need such service. If have service that
       is symmetrical in all contexts except b/w then this might be
       reasonable. The reason for bidirectional LSP wasn't just driven
       by technology but also by benefits in setup time and recovery.
       Much easier to handle one bidirectional LSP than a combination of
       two LSPs.

Attila - so summary is: do we have a strong use-case for this? Need
         mailing list discussion.

Lucy - need to think about P2MP as an application.

Dimitri - What is P2MP asymetric bidirectional LSP about?

Lucy - Discuss offline.

=======================================================
5. Data Channel Status using LMP (Dan) [10, 75/120]

Slides

Background reading
- draft-li-ccamp-confirm-data-channel-status-01.txt
=======================================================

Dan went over the slides, explaining changes and protocol extensions

Adrian - We don't have many people doing LMP here, but two on this
         draft. Who in the room read this? -> 5
         Any strong feeling against? None, but...

Zafar - Raised some concern

Dan - Have you read this I-D?

Zafar - Some comments. Personally not sure about requirements. Not sure
        if the group has enough interest to solve this problem.

Adrian- we do have to be sure we're solving a problem that needs
        solving. Just because vendors are on the draft doesn't mean they
        intend to implement and deploy. Would like feedback from
        carriers as to whether this is a real problem and whether they'd
        look to LMP to solve it.

Diego - We have implemented LMP. This draft solves a real problem.

Julien - Feel that this is an interesting issue to solve. This may be
         specific to transmission devices. Not really issue for packet
         networks.

=======================================================
6. LSP Dynamical Provisioning Performance Metrics in GMPLS Networks
(Guoying Zhang) [10, 85/120]

Slides

Background reading
- draft-xie-ccamp-lsp-dppm-00.txt
=======================================================

Guoying went over the slides, explaining motivations and open issues.

Adrian - is this project alive, or complete? Is the draft + the
         research finished?

Guoying - project is still going. Want to do work on e.g. multipoint
          LSPs and rerouting.

Adrian - feedback you want from group is questions, also what else the
         group would like measured?

Guoying - also whether the group thinks this is useful.

Adrian - please comment/discuss on mic or on list.

Zafar - why is graceful release delay important?

Guoying - why graceful, or why release?

Zafar - why is graceful release delay important?

Guoying - release delay is important as both setup and release impact
          the application performance. if release is not good then
          won't meet requirements. So need to define performance for
          release. Only looking at graceful release here as forced
          release will cause problems anyway...

Lucy - when you talk about control plane management, is that just
       signalling or also data plane setup?

Guoying - only CP setup time today. Issues with control/data sync.
          hard to measure the sync.

=======================================================
7. Transport Resource Management and Time-Based Bandwidth Services
(Lucy Yong) [10, 95/120]

Slides

Background reading
- draft-yong-ccamp-ason-gmpls-autobw-service-00
=======================================================

Lucy went over the slides, explaining motivations and asking the group
whether this is interesting.

Dimitri - what shall we standardise here?

Lucy - we need to have a CP that can handle reservation.

Dimitri - is there something today that prevents you using this model?
          What do we need to standardise here (where we work on
          protocols)?

Adrian - yes, we do protocols. In order to decide if we need a protocol
         we need to see what architecture we're trying to build. If we
         can solve the architecture with existing protocols then we're
         done. If we need new protocol then we need to do it (either in
         CCAMP or elesewhere). But before we even define the arch we
         need to answer Lucy's Q of whether this is something we need to
         solve.

Lucy - I don't think the current protocol and architecture lets you do
       this.

Dimitri - what prevents us today from saying we'd establish a connection
          at a given point in time?

Lucy - all three options today don't work.

Zafar - can't see what we need beyond what GMPLS provides.

Lucy - your connection request doesn't have a future time in it.

Zafar - there are so many ways you could do it. Nothing to do with
        protocol.

Lucy - carriers currently rely on management plane to do it. If we have
       a CP then how do we combine them?

Zafar - local decision?

Lucy - A network resource you need to reserve. Signalling doesn't let
       you know time.

Zafar - can take offline...

Rowen - you do signalling to future allocate resources? So do you keep
        full state of future services?

Lucy - we can work that out in implementation.

Rowen - do you keep states in network for services that aren't running?
        That's a major scaling issue.

Lucy - that's an implementation issue.

George - It's a major scaling issue in building a switch. Also issues
         in terms of recovering stuff in event of failure. Better to
         leave stuff in the mgmt system and have CP as a slave.

Lucy - we already have PCE etc. so don't need to embed this in the nodes

George - when pull out of network, it is mgmt plane.

Lucy - PCE is out of network but is CP.

George - PCE isn't part of GMPLS CP. Not suggesting we put this in
         routing and signalling? E.g. signal with RSVP-TE ahead of
         time?

Lucy - there are different ways to implement this, not suggesting one
       here.

George - don't think is good idea to put this in the switches. Topology
         may change between making request and reserving it. So not
         very useful to embed the info too close to where you're going
         to deploy it.

Lucy - I agree.

George - two things need to happen before we consider this. (1) need to
         hear from SPs that it's a real need. Not many SPs want to keep
         dark fibre around to light up instantaneously. (2) need to
         clarify the architecture in terms of what is control and what
         is management...

Gert - we have application like this running for two years. Never had
       req. from service provider to put anything in the control plane.
       So doubt if this is useful...

Dimitri - I have one question. where shall I put the resource
          management state. If I don't see a cost/benefit ratio which
          is better than what we do today then won't do it. There is a
          temptation to make the control plane have all the features of
          the management plane - really dangerous as end up with a
          distributed management plane...

Adrian - Keep hearing people say don't put mgmt plane in CP. I think I
         heard Lucy say that too. So we all agreed...

=======================================================
8. CCAMP Liaison responses (chairs) [25, 120/120]
- OIF Signaling for MEF Requirements
- OIF VLAN ID Requirements
- OIF Interworking Cookbook
- SG15 Related

Slides

Background reading
- CCAMP incoming correspondence
=======================================================

Dropped from the agenda due to lack of time.
Adrian - please look at slides on liaison work.