================================================================ Layer 1 VPN WG (l1vpn) Minutes ================================================================ TUESDAY, July 11, 2006 1520-1720 Afternoon Session II CHAIRS: Hamid Ould-Brahim Tomonori Takeda Adrian Farrel ================================================================ Agenda, admin and WG Status and milestones (Adrian) ================================================================ - Status report (Adrian) - framework passed WG LC, now with A-Ds - applicability - to be split into basic and enhanced - basic mode signaling and bgp/ospf discovery in progress - milestones slipping (esp. enhanced mode work) but not overly so ================================================================ Plans for Applicability (Tomonori) draft-ietf-l1vpn-applicability-01.txt ================================================================ - split missed draft submission deadline, basic mode will be more like an AS - questions: do we need nesting, stitching and shuffling? Do we need CE-PE TE information? What do we need on recovery? - currently support pe-pe recovery via segment recovery, also notification - also ce-pe recovery and ce-ce recovery (last is out of scope for basic mode) - plan to publish basic mode AS, resubmit enhanced evaluation, separate recovery I-D Dimitri: why are we still discussing nest/stitch/shuffle? T: not clear at last IETF D: you need shuffling if you have private addressing D: Are we going to hang on to do recovery before completing basic mode T: Yes. still a question on how to document recovery, but part of basic (exc. Ce-ce) Question to be resolved ================================================================ Basic mode signaling (Don Fedyk) draft-ietf-l1vpn-basic-mode-00.txt ================================================================ - updated to WG draft and made minor reference corrections - translation of CE port indexes to provider port indexes - next steps: Filtered Record Route object, then WG LC T: Need to spell out in what situation shuffling is used Don: OK Dimitri: Segment recovery. Is there a single segment between PE and PE, or can the segments be smaller. Don: not specified. Adrian: how many subsegments are protected is not part of the spec. John Drake: is record route described in Overlay RFC? Don: Think so. John Drake: If already described please reference it. John Drake: Should also discuss whether you get control channel between Ces. Tomonori: have some discussion about this in the framework, various options. - dedicated channel - overhead (if available) - re-use core control channel Peter: in the research area, push for having applications ask for wavelengths (Grid applications). Can the CE device be a Grid application? Can CE be a host with an application? Don: does not matter what the CE is. Yes, nothing to prevent it. Peter: should specify case of a Grid application. Tomonori: if you have specific requirements for this, you should state these. Lou: just add mention in the framework. Hamid: Has the NSAP support been removed? Don: Gone ================================================================ Basic mode discovery using BGP (Yakov) draft-ietf-l1vpn-bgp-auto-discovery-00.txt ================================================================ - nothing changed since last IETF - still need to handle CE TE information over BGP - hope to republish in a months time ================================================================ Basic mode discovery using IGP (Lou) draft-ietf-l1vpn-ospf-auto-discovery-00.txt ==================================================== - Minor updates, removed OSPF opaque LSA spec - OSPF spec did not allow validation, so this is moved to a draft specifically for the OSPF WG. L1VPN PE address TLV removed, reused other methods instead, for AS-external routes. Now a WG draft. Waiting on implementations. Adrian: we will take BGP changes to IDR ========================================================= AS-scope Opaque LSA validation -Igor- ================================================================ to be presented in OSPF WG - fixes issue in RFC 2370 by reusing mechanism for AS external route (type 5) LSAs. - problem: no way for OSPF nodes in remote areas to check availability of a type-11 originator. Have such originators act as ASBRs, using the E-bit - no backward compatibility issues known - does not apply for stub areas - we propose this as a WG draft Tomonori: Submitted for OSPF? Igor: Yes, will present tomorrow ================================================================ Basic mode discovery using directory server (Dan) draft-li-l1vpn-ds-info-distribution-00.txt ================================================================ - defines push or pull mode, inter-AS support via single or multiple directory servers - security issues: authorization limited to PE, also DoS attack concerns - The first part is new to the group, can it be separated out? Dan: yes. - needs more discussion on the list Tomonori: 2 parts: - register CE to VPN - pull or push information Tomonori: The first part is new to the group, can it be separated out? Dan: yes. Hamid: how many have read the draft? --- 2 Hamid: so need discussion on the list ================================================================ Inter-domain TE (Tomohiro) draft-otani-ccamp-interas-gmpls-te-04.txt ================================================================ - originally in CCAMP, but not adopted yet. Asked to include VPN support. - may fit future charter items. - endpoint reachability list in EGP, may optionally include VPN information - looking for where to pursue this work, possibly in L1VPN or CCAMP. - Dimitri: is this intended for a specific protocol? - Tomohiro: no, in this draft it is protocol-neutral. - Dimitri: solution could use something other than existing EGP? - Tomohiro: document does not say. - (Gert): how does this apply to basic vs. enhanced mode? - Tomohiro: document does not say yet, originally created for general inter-domain. Believe equally applicable to both. - (Gert): does it align with BGP for basic mode, then? - Tomohiro: protocol neutral. - Yakov: IGP and BGP carry basically the same information, so it should apply to both or neither. - Dimitri: support of multi-AS is still an open issue here. - John Drake: in CCAMP, this was talking about announcing characteristics of AS. Here, is it talking about AS or about CE, two different topics. - Hamid: Need to continue discussions and map requirements to L1VPN ================================================================ Inter-domain recovery (Tomonori) draft-takeda-ccamp-inter-domain-recovery-analysis-00.txt ================================================================ - presented to CCAMP on Monday - For information here. Identifies different cases, esp. with/without confidentiality, per-domain or collaborative computation, sequential/simultaneous computation - 12 cases - related to CE-CE recovery, which includes 3 domains, confidentiality. End domains are only 1 node each, so no path computation issue. Private addresses may be used. - propose that L1VPN WG reviews this to ensure that CE-CE recovery is covered. Dimitri: If there is a solution for this but not for the general case, where will we do it? Tomonori: Probably CCAMP Adrian: CCAMP must not hold up the work here. any solution for L1VPN should be included in CCAMP, solution should be solved here and pushed into CCAMP if L1 VPN is finished first Gert: Is this basic mode or extended? Tomonori: yes, not within scope of basic mode, this is more of a look ahead Gert: Are the requirements stable? Tomonori: Probably not. For CCAMP the requirements are more generic. L1VPN may need to stabilize requirements Gert: doesn't that mean that we have to understand all of the extended mode requirements first Adrian: Yes, but we can't get bogged down in that ================================================================ Plans and next steps (Hamid, Tomonori) ================================================================ - Need to complete basic mode solution, with cross-WG review; also need to look at recovery, Ethernet transport, and manageability. - Enhanced mode: four models, overlay, virtual node, virtual link, peer. More discussion encouraged, analysis of sub-models with the goal of reducing the number to be worked on. Especially looking for carrier feedback. Dimitri: "extended" should be "enhanced", also dual-homing should be included, not shown. - if interested, get in touch with the chairs. - OAM requirements - Kireeti: references GTTP work as possibly applicable; Adrian notes RFC was limited to hierarchical LSPs. Kireeti: large part of L1VPN is tunnels, may not be instantiated as 1:1 tunnels in the provider network. Adrian: shuffling may be interesting as a different case - OAM may be different. Dimitri: looking at point-to-point only or point-to-multipoint? Kireeti: need to learn how to walk first... Adrian: inevitably needed. Dimitri: manageability issues affected, need to consider management by itself and management plus control plane. Don: data plane OAM standardized elsewhere. Adrian: we are talking here about control and coordination of existing OAM techniques. But also need OAM for control plane connectivity. Kireeti: OAM for data plane requires doing something in LMP. Note that L2VPN found problems with point-to-multipoint - we need to have an idea of how to solve problems in L1 VPN. Dimitri: will we consider protection as a type of CE-PE recovery? What was done in CCAMP considered both. Tomonori: somewhat implementation dependent, some routers can do 1+1 others not. Don: ITU supports drop and continue, protection. If anything is different, should send liaison to SG 15.