Layer-1 VPN WG (l1vpn)
======================
WEDNESDAY, November 9, 2005
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>
NOTES: Adrian and Deborah
===============================
Chairs: Agenda bashing
Status update
Slides
Hamid reviewed agenda
- No issues raised
Adrian reviewed working group status and milestones
- No quesitons or issues
===============================
========================================
Tomonori: Update on Framework draft
draft-ietf-l1vpn-framework-00.txt and
Framework draft discussion
Slides
Specific questions
- Anyone interested in scheduling of services?
- no response from meeting
- anyone interested should voice on list or send mail
- Does anyone want to do TDM emulation?
(i.e. use pseudowires to build a virtual TDM mesh that is managed as a L1VPN)
- no response from meeting
- anyone interested should voice on list or send mail
Noted further changes needed as per slides
Planned action
- keep alive for a while and update
- WG last call around end of 2006
- align with protocol solutions
- liaise to SG13
Adrian observed that the default position, if no one has anything to add on the
open questions, is that the text will remain as is in the draft and the WG will
move on.
==============================
==============================
Basic Mode Discussion
Don: draft-fedyk-l1vpn-basic-mode-00.txt
Slides
Several questions were discussed
- Is there a requirement to support NSAPs?
The mechanisms for embedding NSAP in IPv6 (RFC 1888) is now marked as historic
We could bring this back alive simply by republishing, if we need the function
Question is whether we actually need the function.
- A poll of room showed slight interest in supporting NSAPs , and no opposition
Since there is very low cost to supporting this it is easy, but we don't usually
do things without specific demand
- What protocols should be available for PE-PE basic mode auto-discovery?
Currently we have a proposal for using BGP (see Hamid's slides later)
Is anyone interested in proposing an IGP alternative?
- Lou and Dimitri indicated that they would write a draft
- Can we us LMP for CE-PE?
- Is the use of LMP for CE-PE discovery/management a basic mode or extended
mode function?
- Agreed that there is value in discovering local CE-PE link parameters
- Agreed that LMP is an option not a requirement
- Agreed to limit this to vanilla LMP in the basic model at the moment
- Shuffling and Stitching
- Noted that in Stitcing there are two LSPs i) PE-PE ii) CE-CE
- RFC 4208 seems to meet the requirements, but some additional documentation
of process may be required. Not expecting any protocol changes
- Stitching and Shuffling text to be clarified with reference to CCAMP
multi-domain work
- All agreed handle pre-config of PE-PE FA LSPs as well as dynamic establishment
- Recovery
- CE-CE recovery is opaque to the PE, and the problem reduces to how to
configure/compute/route protection paths
- We need to look at the GMPLS UNI (RFC 4208) because this does not include
CE-PE recovery.
- We need a common approach with CCAMP to solve this
- We may also need a way to request PE-PE recovery when signaling at the
CE-PE interface
Plan is to respin this draft once more before debating whether to make it a WG
document.
==============================
================================================================
Hamid: draft-ouldbrahim-l1vpn-bgp-auto-discovery-00.txt (10 min)
Slides
- Discussion of the BGP parameter exchange.
- The advertisement of reachability include the port-id and if-id
- The exchange will support numbered and unnumbered interfaces
- Hamid: yes
- Tomonori: if numbered, exchange number else unnum?
- Hamid yes
- Are all ports of homogenous capability?
- Currently this is open with only basic information documented, but could
carry extended capabilities information
- Dimitri will send mail to the list with a suggestion of which additional
parameters might be provided
================================================================
============================
Extended Mode (10 minutes)
Discussion led by chairs.
Slides
- The Extended Mode is considered to offer greater optimality. What is
"optimality"?
In general this may mean the ability to have a "better" LSP compared with
basic mode
But is this optimality in the client network, the core, or both?
Discussion is to continue on the list
- In the pictures on the slides, where does the TDM connection start? Is C-C
connectivity supported.
C-C is technically out of scope, but we do not want to prevent it
- We do need to represent the L1VPN model including C-C connectivity
Thus, since the CE-CE connection is just a TE link in the C-network, C-C
connectivity may reduce to just an applicability statement
Note that C may initiate signaling for C-C connectivity and this may trigger
CE-CE connectivity across the L1VPN or may use existing CE-CE connectivity
This is nothing special - it is just RFC 4208 (GMPLS Overlay)
- Control plane connectivity service between CEs
This is a separate service for the provider to offer. We need to be sure we
can enable it.
- Solution depends on how you architect the control plane
Comapre virtual node model with overlay model
- There is a clear need to exchange out of band control plane information
between CEs in the extended mode unless we limit to soft-permanent
connectivity
Need further discussion on the list for this issue
- The slides don't show the overlay extension properly because the CE-CE links
are missing and the C nodes are not always shown
- Valuable exercise would be to examine the routing instance modeling
- cf BGP
- where are the routing exchanges?
We need to clarify where the routing happens for each model i.e. where the
TE links are and where the routing instances are
- Need to think about how to treat/flood routing information in the per-VPN
model
- are the P-nodes visible to Cs?
- is the information flooded to the VPN network?
- do we need per-VPN address spaces?
It seems that answer to all of these question may be "yes" but more thought
is needed
It would be possible to block flooding at the CE (i.e. prevent core topology
from reaching the Cs)
- Which extended models to do first?
There are four main models and several variants and options
We will not work on all of them at once
Need to analyse architecture to decide which model we want to look at
Should be driven by early deployment plans where CE is a packet router
- Suggestion from the floor
- not per VPN peer
- overlay is good
- after that virtual node
Provision of control plane connectivity should be part of this discussion
============================
============================
Next steps:
- further discussions on list
- continue to work on I-Ds
- send liaison to ITU-T SG13 to report status
============================
|