[L1vpn] l1vpn wg meeting minutes

["Hamid Ould-Brahim" <[e-mail]>]

Folks,

Please review the minutes for the ietf66 meeting for l1vpn wg.

Comments on the list or to the chairs.

Thanks to Lyndon Ong and Adrian Farrel for taking the minutes.

Hamid.

================================================================
Layer 1 VPN WG (l1vpn) Minutes
================================================================

TUESDAY, July 11, 2006 
1520-1720 Afternoon Session II 

CHAIRS: Hamid Ould-Brahim <[e-mail]>
        Tomonori Takeda <[e-mail]>
        Adrian Farrel <[e-mail]>

================================================================
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.



_______________________________________________
L1vpn mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l1vpn