Draft minutes - Session II
"BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com> Wed, 28 March 2007 20:02 UTC
Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWeLy-0005j4-Ud for ccamp-archive@ietf.org; Wed, 28 Mar 2007 16:02:43 -0400
Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWeKs-00029g-0D for ccamp-archive@ietf.org; Wed, 28 Mar 2007 16:02:42 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1HWeDG-0003mS-W8 for ccamp-data@psg.com; Wed, 28 Mar 2007 19:53:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.1.7
Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with smtp (Exim 4.63 (FreeBSD)) (envelope-from <dbrungard@att.com>) id 1HWeD5-0003kU-M4 for ccamp@ops.ietf.org; Wed, 28 Mar 2007 19:53:39 +0000
X-VirusChecked: Checked
X-Env-Sender: dbrungard@att.com
X-Msg-Ref: server-14.tower-121.messagelabs.com!1175111604!11599919!1
X-StarScan-Version: 5.5.10.7.1; banners=-,-,-
X-Originating-IP: [134.24.146.4]
Received: (qmail 11177 invoked from network); 28 Mar 2007 19:53:24 -0000
Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 28 Mar 2007 19:53:24 -0000
Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2SJrGp6013704 for <ccamp@ops.ietf.org>; Wed, 28 Mar 2007 15:53:23 -0400 (EDT)
Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2SJr7DQ013550 for <ccamp@ops.ietf.org>; Wed, 28 Mar 2007 15:53:10 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77172.ACFFD779"
Subject: Draft minutes - Session II
Date: Wed, 28 Mar 2007 14:52:53 -0500
Message-ID: <449B2580D802A443A923DABF3EAB82AF0DE4F342@OCCLUST04EVS1.ugd.att.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Draft minutes - Session II
Thread-Index: Acdxcqx8wpWu6N5DTrymWL2znGo4cw==
From: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>
To: ccamp@ops.ietf.org
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.1 (/)
X-Scan-Signature: f3d7fb2a0d447735ba6cf7b00ace0bfe
Here's the minutes of the second session, much thanks to the great notes of Giles Heron, Julien Meuric, and Tomonori Takeda. Please check them, comment on missing items or corrections, and start to work on the items identified (e.g. liaisons). Thanks, Deborah and Adrian -------------------------------- 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.
- Draft minutes - Session II BRUNGARD, DEBORAH A, ATTLABS