IETF 62 L2VPN draft minutes

"Vach Kompella" <vkompella@timetra.com> Tue, 22 March 2005 17:01 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05119 for <l2vpn-web-archive@ietf.org>; Tue, 22 Mar 2005 12:01:18 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmq9-0002pe-Me for l2vpn-web-archive@ietf.org; Tue, 22 Mar 2005 12:06:50 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmeo-00054T-EK; Tue, 22 Mar 2005 11:55:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmem-00054G-QB for l2vpn@megatron.ietf.org; Tue, 22 Mar 2005 11:55:05 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04440 for <l2vpn@ietf.org>; Tue, 22 Mar 2005 11:55:01 -0500 (EST)
Received: from [64.47.51.130] (helo=exchange.timetra.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmk3-0002bO-11 for l2vpn@ietf.org; Tue, 22 Mar 2005 12:00:32 -0500
Received: from vkompellaxp ([172.22.184.202] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 22 Mar 2005 08:54:40 -0800
From: Vach Kompella <vkompella@timetra.com>
To: l2vpn@ietf.org
Date: Tue, 22 Mar 2005 08:52:42 -0800
Organization: Alcatel USA
Message-ID: <008a01c52eff$91fb2260$cab816ac@eng.timetra.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
X-OriginalArrivalTime: 22 Mar 2005 16:54:40.0264 (UTC) FILETIME=[D6A59080:01C52EFF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503
Content-Transfer-Encoding: quoted-printable
Subject: IETF 62 L2VPN draft minutes
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: vach.kompella@alcatel.com
List-Id: l2vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
Sender: l2vpn-bounces@ietf.org
Errors-To: l2vpn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad
Content-Transfer-Encoding: quoted-printable

Here are the draft minutes for the L2VPN session at IETF62.  Thanks to
Ananda and Rick for taking down the minutes, and Rick for collating
them.

Please email comments to the mailing list, so we can submit the final
minutes to the IETF.  Thanks.

March 8, 2005, 1:00 pm: Layer 2 Virtual Private Network WG Meeting
Minutes
Co-Chairs: Rick Wilder, Vach Kompella, Loa Andersson

Rick Wilder opened the meeting. No change on agenda. 

Loa  Andersson announced that he will step down as Layer 2 chair, as he
is becoming an IAB member. Mark Townsley is the new AD for the Internet
Area. 

Agenda bashing: The last item, Cheng-Yan Lee's presentation is
cancelled.

Status update on documents in progress: 
Framework document is in RFC queue. 
Requirement doc is in IESG review.
Vpls-bgp and vpls-ldp are on standards track, under review.

Himanshu on ARP mediation draft - see presentation slides: no
discussions on mailing list, no draft update since last WG meeting. Some
ID nits on IANA allocation and security section. IPLS draft is in same
state. Both ready for last call after final updates to become IETF
draft.

Tomas Narten - Stepping down as AD. Wants to ensure there are at least
one or two implementations, otherwise it can prevent a document from
moving forward.

Loa: requests clarification on whether implementations are a definite
requirement for progression of documents in the Internet area.

L2VPN provisioning and signaling (authors Eric Rosen, Bruce Davie and
Vasile Radioca) - presented by Bruce Davie of Cisco
Draft now covers provisioning, discovery and signaling. New change
addresses inter-AS issues. This builds on Luca Martini's draft on
pseudo-wire switching. Clarifying text on BGP autodiscovery. Same
options in multi-AS as for RFC2547-bis. Bruce presented a picture
similar to Option C. Possible drawback - advert PE loopback address, no
control on inter-AS signaling. Presented next picture similar to
2547-bis option B. Signaling sessions are not PE-PE any more but in
segments.
Slide on BGP autodiscovery. AFI, SAFI piece needs to get nailed down so
that there is single AFI for all L2VPN solutions, and different SAFI for
l2vpn-ldp and l2vpn-bgp.
Next slide describes signaling previously defined didn't work for
inter-AS VPN case. Talking to Hamid Ouldbrahim to keep everything
in-synch with BGP autodiscovery draft. Also have to finalize IANA
section. Requested last call.

Yakov Rekhter: What is the relationship between VPN ID in L2VPN and
Route Target for L3VPN. If AGI and route targets are the same we should
not have two terms for the same thing.

Bruce Davie: AGI is defined in requirements for L2VPN. 

Eric Rosen: AGI can be VPN ID for non-BGP and Route Target for BGP.

Vach Kompella: Last call to be done after next draft version.


L2VPN OAM requirements and framework:
Dinesh Mohan, Nortel 

Framework proposse OAM layering across entities - L2VPN service layer,
pseudo-wire layer, PSN layer - also includes customer, SP, Network
Operator roles. 
Requirements: Focus on Service Layer, Pseudo-wire layer

General status update provided from last  IETF meeting - Editorial
updates to VPWS and IPLS sections added. VPWS is TBD and IPLS - for
future study. OAM framework updated - VPLS can be a service, network or
emulation. Dinesh read from next slide. ECMP implications and priority
considered. Periodicity of OAM depending on protection considered. VPWS
and IPLS OAM requirements to be added. Drafts on these have been
introduced, and will be included as applicable.
See presentation slides for next steps.

Vach: Spirited discussion in last IETF as unclear where it was going.
Comment: presentation is more informative than draft, so need to edit
text to make it more relevant to IETF work.
 
Rick: summary of last meeting is scope of work, and that's still not in
document.

Diunesh: some work in PWE3 is following the layers constructs that have
been introduced in this draft.

Alex Sajassi, Cisco: VPLS as service, network and LAN/VLAN was discussed
in last mtg, and that has been put in the doc. 

Dinesh introduced a backup slide on how different layers come together -
Services (Service OAM), Network (Network OAM) and Transport Links/PWE3
(Ethernet Link OAM, PW/MPLS OAM, EoSONET OAM or Other OAM)

Vach Kompella (not as Chair): Service may traverse Ethernet bridge
network or VPLS. Need to be clear what we are working on here. The
service model should be clearly in the context of VPLS.

Dinesh: We are not following IEEE which is focusing on Ethernet bridge,
but on PWE3/PSN.



Using RADIUS for PE-based VPN discovery: Greg  Weber
Mark Townsley, Wei Luo, Skip Booth, Greg Weber, Juha Heihanen

Now version 01 is WG draft. This doc specifies RADIUS specific mapping
for protocol independent model.
L2VPN authorization steps: New text in this draft, to ensure that
terminology is in line with signaling draft, generalized to cover VPLS,
VPWS. 
RADIUS transactions and examples.
To do: A lot left to do: Address accounting, authorization changes,
presenting this draft to RADIUS extension (RADEXT) WG to get
ideas/feedback.

Vach: We agreed in last meeting that this is a direction should be
taken, and we are seeing a better picture of what Mark T was talking
about, but little discussion on mailing list. Like to see lot more
participation to ensure that we are headed in the right direction.

Ron from Resolute: Is the problem being solved for authentication or for
provisioning?

Greg:  more provisioning, RADIUS server is already being used for this
type of role in deployments. The servers could also be used in dial-up
scenarios.

Mark: Discovery using RADIUS for specifically centralized server based
discovery and provisioning. The opinion has been that RADIUS is
preferred over LDAP and DNS for auto-discovery with a centralized
server.


Supporting IP Multicast over VPLS: Venu Hemige

Problem: Multicast traffic being sent to all PE's, goal to not send
traffic to sites without receivers.
PIM snooping of PW's can overwhelm PEs, PIM-refresh reduction and
snooping CE-PE link helps overcome burden of PIM snooping in the core,
and address reliability of join-prune PDU.
Defined LDP TLV defined to flush snooping state.

Eric Rosen, Cisco: PIM Refresh-reduction has to be friendly - but PIM WG
is not likely to take this as a serious requirement in defining
refresh-reduction. This is a hack, and will be fragile. Many providers
take it as a serious requirement to pass on all that is put on the link
and this violates that.

Vach: So should we take to PIM group? Let's work on this draft in this
WG till it matures enough and has enough consensus  to send to PIM WG

Yakov Rekhter: Is packet retransmission being proposed to solution to
unreliability of PIM control messages?

Venu: yes

Yakov Rekhter: In unreliable situation, retransmit message is not part
of PIM and is not sufficient.  Use something in the way of PIM refresh
reduction.

Kireeti Kompella: As IGMP snooping and PIM snooping are hacks, why
should we need to do it now? 

Further discussion required on the mailing list.



Multicast in VPLS: Rahul Agarwal
Yuji Kamite, NTT, and Luyuan Fang, ATT

Update: VPLS mechanisms are in separate drafts and both have limitations
for multicast.
Slide on limitations. Replication of traffic on ingress is possible, and
optimizes state in P routers, but not bandwidth. 
Optimizing bandwidth and state are conflicting goals. 
VPLS multicast architecture control plane - use existing auto-discovery
mechanisms, allow flooding elimination - PE-CE snooping in
draft-serbest-l2vpn-vpl-mcast: PE does not maintain L2 adjacency with
CE.
PIM snooping - and how there is a scalability problem
Use reliable exchange of multicast control messages between PE's to
avoid PIM snooping on PWs.
Design goals include using as little state as possible beyond VPLS
unicast, and elimination of flooding
Aggregate P-multicast trees, to allow one P-multicast tree to be shared
across multiple VPLS's. Next slide described inclusive mapping.
Request to move forward.

Ali Sajassi: Suggesting solutions without having requirements in
framework and requirements draft. Terminology doesn't match. Issue is
IGMP and PIM snooping's applicability in SP network is questionable,
maybe in Enterprise network. Also it is limited to IP traffic of user.
What about VPLS.

Rahul: 2 SP's on draft - so requirements being addressed. Snooping
mentioned for PE-CE link only. 

Alex: Offering diff services over same UNI is solved, why have new
mechanism
Rahul: Specific solution for VPLS multicast.

??: Rather than use of  IP addresses, the solution use MAC addresses -
that covers Layer 2 mutlicast better. Can we make this more generic?

Rahul: Open if there is interest

Vach Kompella: This has requirements support - but need to formalize the
requirements to cover mutlicast. Comment on using BGP to distribute
state from PIM's soft state to BGP hard state.

Yakov Rekhter: Looking at history, PIM's refresh reduction makes it more
hard state.

Vach: If PIM refresh reduction is done, why not snoop at that point.

Yakov: questioned if CE's will implement refresh reduction. In this,
multicast use in service provider is addressed in text.

Loa: Cut discussion here, as running short of time. Ask AD's about
document structure, and refer further discussion to mailing list.

Soft PVC ATM-MPLS interworking for PW
George Swallow
..
Eric Gray
Not much change in draft presented in PWE3 group. Currently taken this
to MPLS and Frame Relay Alliance, and probably is a better place to
discuss this draft. This draft is probably going to get reduced to code
points. 

OAM procedures for VPWS interworking
Mustapha Assoui

See presentation slides for scope of draft and  changes from last
revision.
Ask WG to progress document to WG status. All or nearly all people who
said they have read this draft agreed to make this a WG doc. 

Mutli-hop PW Service
Dave McDysan, MCI and Florin Balus.

See presentation slides for MH PW challenges and solutions and for Use
Cases on Inter-provider and  Metro Access Interconnection. 
Solutions addressed in 2 drafts: draft-martini-pwe3-switching,
draft-balus-mh-pw-control
Further work to include: signaling, admission control, resiliency,
explicit routing
Operational Consistency - Service Management, refer to
draft-ietf-pwe3-control-protocol and balus draft
LDP extensions defined including MH PW TLV in LDP label mapping message
Operational walkthrough highlighting steps specific to MH PW
Slide on next steps: Does this work belong to PWE3 or L2VPN
Connections belong to PWE3, but discovery belongs to L2VPN
Bruce's draft is for cases where BGP exists at stitching points, but
that is not assumed here.

Bruce Davie: You can add discovery to the other draft. Very similar to
martini-pwe3 draft. So, why need to introduce this in PW signaling
instead of using FEC 129. 
Keep signaling separate from routing. 

Vach: Take discussion to mailing list as it's first time this draft
discussed. We are out of time.


Vach Kompella
IP Division, Alcatel
vach.kompella@alcatel.com
+1 650 623-2556