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

WEDNESDAY, March 22, 2006
1300-1500 Afternoon Session I

CHAIRS: Hamid Ould-Brahim <hbrahim@nortel.com>
        Tomonori Takeda <takeda.tomonori@lab.ntt.co.jp>
        Adrian Farrel <adrian@olddog.co.uk>

MINUTE TAKERS: Richard Rabbat
               Adrian Farrel

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

Meeting Report:

===================================
1. Agenda and admin (chairs)
Slides

No changes to the agenda.

===================================
2. WG Status and milestones (chairs)
Slides

There are 2 drafts in the WG, the framework and the applicability drafts
WG last call after the meeting for the framework
Applicability i-d will be a living document to be updated when gaps
are filled (to be split eventually for basic and extended mode)

Solution work: 3 drafts to cover signaling and auto-discovery (BGP and OSPF)
The objective is to move them to WG drafts soon

Some milestones completed. A little behind in basic mode specs.

Want to start working on enhanced mode by June.

===================================
3. Update and plans for Framework and Applicability (Tomonori)

Framework
Slides
draft-ietf-l1vpn-framework-02.txt

Document scope: overview of L1VPNs
01 version submitted in January
02 version submitted in March

Document is now stable
Liaison relationship with ITU-T SG13 is going well

Richard Rabbat: What is the status of the liaison?
Tomonori: SG 13 is in the loop
Adrian: We told SG13 that the WG is planning last call
Adrian: We will go to working group last call after the meeting


Applicability
Slides
draft-ietf-l1vpn-applicability-01.txt

Document scope: analyse how GMPLS is applicable to L1VPN
2 new sections cover recovery aspects and CP connectivity between CEs
Considering splitting the draft:
- basic mode solution is on-going, and expected to be finished soon

Need a new I-D for Recovery:
- focus on analysis
- CCAMP has a work item

Adrian: CCAMP has a work item for multi-domain recovery.
        The L1VPN CE has a different visibility from the core network so is like multi-domain.
        For the unprotected case in multi-domain, CCAMP found that PCE would be a good approach
        I may expect a similar approach from CCAMP for protected multi-domain.
Dimitri Papadimitriou: Please clarity the use of PCE
Tomonori: As Adrian said, CCAMP has selected PCE. L1VPN is not requiring the use of PCE,
          but recognising the possiblity of using PCE for P&R
Dimitri: Are you discussing a specific application of P&R?
Tomonori: We don't have much context yet
Dimitri: Shouldn't we clarify the need?
Tomonori: We think P&R is a good idea; we should think whether PCE is a good solution;
          so we need an analysis as a starting point
Dimitri: Need further discussion of requirements for protection
         Is CE dual mode needed?
Tomonori: I think so
Hamid: We'll discuss on the mailing list the needs and requirements
       Does the working group think it is OK to split the applicability I-D?
Richard Rabbat: What would you do with the basic mode applicability I-D?
Tomonori: Complete it when we complete the basic mode work
Dimitri: Is CE dual homing part of basic mode or extended mode?
Tomonori: It is more than basic and less than extended mode
Dimitri: Then don't hold up the basic mode for that function.
         If we want to deploy very fast, we should stick to basic mode as more complex
         features will not make basic mode more useful
Hamid and Tomonori: Agree

===================================
4. Basic mode signaling (Don Fedyk)

Slides
draft-fedyk-l1vpn-basic-mode-01.txt

Main changes are to align with the framework document
Changes were:
- Editorial changes
- NSAPs were allowed on the customer edge as an addressing mechanism, so we've removed it out of the document
- Made auto-discovery generic
- Improved LMP descriptions
- L1VPN globally unique identifier for signaling (an 8-byte identifier)

It was noted that there is an error on one slide
- "GVPN signaling" should read "GMPLS signaling"

Dimitri: Why are we including/removing features such as VPN ID?
         Why aren't these identified in or removed from the framework I-D?
Don: We need a global VPN ID (obviously)
     However, we don't need a globally unique VPN ID in the signaling so there is no requirement in the framework

Tomonori: The I-D says there is shuffling and stitching/nesting. Is there any difference?
Don: The mapping of identifiers is different (not necessarily 1:1 in the nesting)
Yakov: You have to unbundle stitching and nesting. Do we need stitching and nesting only? Or do we need shuffling in addition?
Dimitri: Stitching and nesting are not the same
         There is translation of identifiers in shuffling
         There is control plane tunneling in stitching
Yakov: Then we need all 3
Don: That's what we have

Dimitri: We need to have procedures for IF-ID.
         For example, in the case of failure, a PathErr will have information that the CE
         will not be able to handle
         This should be put in the base signaling mode
Adrian: Is this any different from standard GMPLS overlay mode processing?
Dimitri: Not so much description in the overlay I-D of the client UNI side process.
         It may be worth including a clarification section in this I-D
Adrian: Understood and the editor said yes

Julien: I didn't see a discussion on the mailing list about NSAPs.
        I thought there was clear support for including it in Vancouver
        Did you exlude it indefinitely?
Don: Originally I thought we needed it, but then I was convinced about this
     In Vancouver, there was a discussion, and if you care about it, please let us know
Hamid: We need a discussion on the list
Yakov: IPv6 is in context (TSpec) and there's a document to embed NSAP in IPv6 addresses
       So it isn't right to say we don't support NSAPs.
       We do support them, but not as an address family
Dimitri: We did poll the WG. If we rephrase as Yakov suggested, we're perfectly fine with it

Hamid polled the meeting. About 15 had read the I-D and about 15 thought that it should be a WG I-D.
There were no objections.
The chairs will take this to the mailing list.

===================================
5. Basic mode discovery using BGP (Yakov)

Slides
draft-ouldbrahim-l1vpn-bgp-auto-discovery-01.txt

Yakov: Update on the BGP-based auto-discovery
       We don't want to have a new AFI, we just need a new SAFI
       New format for l1vpn NLRI
Dimitri: We discussed this on the mailing list
Yakov: Write the text. You need to write what to do with this encoding and we'll include it
Adrian: Let's hear the next set of slides to talk about discovery as well before discussing WG status

===================================
6. Basic mode discovery using IGP (Igor?) - 15 mins

Slides
draft-bryskin-l1vpn-ospf-auto-discovery-00.txt

Igor: He discussed the need for IGP discovery
- in the transport network, BGP is not deployed well
- IGP is an alternative:
- Intermediate nodes do not use L1VPN information, but participate in the flooding, so there is a scalability issue
- No ISIS implementation yet, only OSPF
- Integration with TE is easier with IGP than BGP
There is a question: do we need a generic mechanism for validation of AS-scope opaque advertisements?

Dimitri: What do you need by "validation" in terms of protocols?
Igor: The validation of material originating from other areas.
      LSA's that are advertised in other areas could appear in the tables but could be considered stale information

Yakov: How can we cross AS boundary with OSPF?
Igor: We cannot
Yakov: With IGP, you carry a single identifier: how can you control arbitrary topology?
Igor: We don't need to control topology
Yakov: You can't assume so for VPN
Igor: Not needed for L1VPN
Yakov: If you are restricting the solution to single/simple mesh then you should say so

Adrian: In a multi-area L1VPN core there are ABRs that are not PE routers.
        Is there a change in their behaviour?
Igor: No, not different from TE advertisement

Tomonori: Are you going to allow advertisement of CE-PE TE attributes?
Igor: Yes
Tomonori: How?
Igor: This is optional. We do it like TE link LSAs, but put the information in the new L1VPN LSA

Dimitri: The fact that this is multi-area implies that P routers that are ABRs must do something different
Adrian: To clarify: the ABR is in the core and is not a PE
Igor: Yes we need a change in behaviour on those nodes

Lou Berger: In passing external info in OSPF (e.g. external route) a validation mechanism already exists
            But no mechanism is defined for opaque LSAs so we needed a new definition
            Chose not to do generic mechanism for all opaque LSAs
            Note that JP has another document that needs the same thing
Dimitri: What does validation mean?
Lou: You don't have information about whether the router is still there. We just needed that mechanism
Igor: I raised this point when discussing membership information
Adrian: If we're interested in the generic case, we should talk to the OSPF working group
Igor: I will do this
Adrian: Qestion now is do we need to update routers for multi-area?
Lou: This is an optimization

Richard Rabbat: To ask the question again: do you need to upgrade routers or is it nice to have optimization?
Igor: You need to upgrade PEs and ABRs
Lou: ABR upgrades aren't critical

Richard: Suggest that you focus this draft on single area so we can move on
Igor: The overhead for multi-area is small

Adrian: Need the opinion of the working group about whether the solutions (BGP and IGP) provide different functions
Lou: Is it either or or? There are networks out there that don't plan to use BGP
Dimitri: We want to start with a simple solution that allows PEs to fill their table
Yakov: My perspective different from other speakers. Why is the IETF involved in a beauty contest?
Lou: This is about what routing protocols people want to run
Yakov: Let the market decide; If it works/doesn't for multi-AS, multi-area, etc. just document
Kireeti Kompella: We did auto-discovery with many protocols; now we're doing it with BGP.
                  It sounds like Lou is saying that VPLS devices are too dumb to run BGP
                  We've made the mistake before and as a result, we've come back to BGP.
                  The IETF decided before. Here's history.
Lou: Agree with Yakov that the market should decide
     The network operators won't do the BGP solution.
     How many operators are willing to run BGP in their layer 1 network?
Yakov: We've heard the story before
Dimitri: It is a timing issue; They have today an OSPF environment and are willing to deploy quickly.
         No doubt that BGP is a sensible approach, but if we have to base our timing
         by relying on IGP deployment experience, BGP may be the solution of choice
         in 4-5 years.
Yakov: This is a very real problem. What operators ship today is constrained by vendors
Don: You can sell a box by the protocol. With TE, you have an IGP. It's one less protocol we have to run.
Ross Callon: In my mind, what resolves much is to let people pursue their solutions by letting everyone do the work.
     Standing at the mic and giving opinions doesn't work well
Igor: Discovery mechanism should be protocol dependent; L1VPN application will be delivered much faster
Adrian: Significant opinion that we should work on both options.
        The chairs will take it to the mailing list.
        We can expect both to be working group drafts unless told otherwise on the mailing list

===================================
7. Working group plans and next steps (Tomonori)

Slides

Time for other vendor to get involved
Looking for solutions for enhanced mode
- before starting on protocols, we need to get to a common understanding on what features to support
- There are 4 models for enhanced mode
  - how much visibility into the provider network do we want to allow the CE?
  - There has been some suggestion that virtual node is interesting

Richard: Need to identify why a model is needed.
         Please consider recovery while looking at ther service models
         Before work on a solution we should add a draft that puts in requirements that will allow us to decide
         Need to see more service providers' opinions. They've been quiet lately.
Dimitri: Basic mode is a non-external routing simple application of signaling (which includes some recovery aspects)
         Need to be careful to partition recovery between basic and extended modes
Adrian: If we can do all the protection we need with existing GMPLS overlay then it is just an issue of documentation
Dimitri: Yes. Just don't block progress of the basic mode