minutes for IETF61 L2VPN meeting

Rick Wilder <rick@rhwilder.net> Fri, 10 December 2004 21:41 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 QAA00649 for <l2vpn-web-archive@ietf.org>; Fri, 10 Dec 2004 16:41:08 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccscz-00016p-Bk for l2vpn-web-archive@ietf.org; Fri, 10 Dec 2004 16:48:41 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcsPE-0007YL-MX; Fri, 10 Dec 2004 16:34:28 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcsI1-0002eD-0N for l2vpn@megatron.ietf.org; Fri, 10 Dec 2004 16:27:01 -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 QAA26867 for <l2vpn@ietf.org>; Fri, 10 Dec 2004 16:26:58 -0500 (EST)
Received: from web201.biz.mail.re2.yahoo.com ([68.142.224.163]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CcsPG-0000Ln-HV for l2vpn@ietf.org; Fri, 10 Dec 2004 16:34:31 -0500
Message-ID: <20041210212628.9710.qmail@web201.biz.mail.re2.yahoo.com>
Received: from [128.251.97.130] by web201.biz.mail.re2.yahoo.com via HTTP; Fri, 10 Dec 2004 13:26:28 PST
Date: Fri, 10 Dec 2004 13:26:28 -0800
From: Rick Wilder <rick@rhwilder.net>
To: l2vpn@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA26867
Subject: minutes for IETF61 L2VPN meeting
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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: 2.0 (++)
X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b
Content-Transfer-Encoding: quoted-printable

The minutes for the Washington DC meeting are below.

Many thanks to Mustapha Aissaoui and Cheng-Yin Lee for taking notes.

Rick


-----------------------------------------------------------------------------

L2 VPN Working Group Meeting
Nov. 9, 2004 Washington DC

Chairs:   Vach Kompella
          Loa Andersen
          Rick Wilder


1. Agenda

1. Agenda bashing

2. Working group status (10 min)
   draft-ietf-l2vpn-l2-framework-05.txt
   draft-ietf-l2vpn-vpls-bgp-02.txt
   draft-ietf-l2vpn-vpls-ldp-05.txt
   draft-ietf-l2vpn-requirements-01.txt
   chairs

3. Working group documents - Author/ Editor feedback (15 min)
   draft-ietf-l2vpn-vpls-ldp-applic-00.txt
   Marc Lasserre
   draft-ietf-l2vpn-signaling-01.txt
   Eric Rosen
   draft-ietf-l2vpn-arp-mediation-00.txt
   Himanshu Shah
   draft-ietf-l2vpn-ipls-01.txt
   Himanshu Shah
   draft-ietf-l2vpn-oam-req-frmk-01.txt
   Dinesh Mohan

4. Radius based L2VPN's (20 min)
   draft-ietf-l2vpn-radius-pe-discovery-00.txt
   draft-ietf-l2vpn-l2tp-radius-vpls-00.txt
   Note: Drafts has dated, but it is the intention have this update anyway
   Greg Weber

5. Supporting IP Multicast over VPLS (10 min)
   <draft-serbest-multicast-vpls> 
   Yetik Serbest 

6. OAM Procedures for VPWS Interworking (10 min)
   <draft-aissaoui-l2vpn-vpws-iw-oam-02.txt> 
   Mustapha Aissaoui

7. VPLS Interoperability with CE Bridges(10 min)
   <draft-sajassi-l2vpn-vpls-bridge-interop-00.txt> 
   Ali Sajassi

8. Multicast in BGP/MPLS VPNs and VPLS(10 min)
   draft-raggarwa-l3vpn-mvpn-vpls-mcast-00.txt 
   Rahul Aggarwal

9. Testing Hierarchical Virtual Private LAN Services (10 min)
   <draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt>
   Vach Kompella

10. Meeting closes

2. Working Group status reported by Vach Kompella

- draft-ietf-l2vpn-l2-framework-05.txt:  Sent to IESG, in RFC editor’s queue
- draft-ietf-l2vpn-vpls-bgp-02.txt: IDR review done. Minor PWE3 dependency.
- draft-ietf-l2vpn-vpls-ldp-05.txt:  Minor PWE3 dependency.
- draft-ietf-l2vpn-requirements-03.txt: publication requested

3. Author/Editor feedback on Working Group Documents

VPLS Applicability – Marc Lassere

draft-ietf-l2vpn-vpls-ldp-applic-00.txt 

Document updated to address comments received. Ethernet to VPLS migration scenarios added
and alignment with IEEE 802.1ad (VLAN translation). Further comments solicited from
mailing list.

Provisioning Models and Endpoint Identifiers in L2VPN Signaling – Eric Rosen
draft-ietf-l2vpn-signaling-01.txt

A new revision of this document will be produced. Dependencies to and from this document
will be checked.


ARP Mediation for IP Interworking of Layer 2VPN - Himanshu Shah

draft-ietf-l2vpn-arp-mediation-00.txt

Author stated that this draft was multiple independent implementations with demonstrated
interoperability. 

IANA value assignment needed to support CE address TLV.

IP-Only LAN Service (IPLS) – Himanshu Shah

	draft-ietf-l2vpn-ipls-01.txt

No new updates, but feedback has been received and updates planned for BGP-based
signaling, clarification of MAC-to-IP address learning, and support for other traffic, eg
IPv6, IS-IS. These may be addressed in a future draft.

4. VPLS OAM Requirements and Framework  - Dinesh Mohan
draft-ietf-l2vpn-oam-req-frmk-01.txt

Since previous revision: have added reference to BGP-based VPLS, clarified client-server
relationship, updated normative/informative references.

Next steps: address VPWS OAM requirements and framework.

Discussion:  Joel Halpern thought this was a well-written draft but thought this applied
to an end-to-end Ethernet service. He does not think that the IETF should tell the IEEE
requirements for Ethernet OAM. 

Extensive discussion followed of whether this draft is within the WG scope. Further
clarification  is needed of the VPLS-specific nature of the requirements to resolve this
issue. Vach thought this document contains out of scope material because it goes beyond
VPLS (learning, PW encapsulation) into Q-in-Q. 
Dave suggested that we focus the document on how to make sure that end-to-end emulated
Ethernet service is not compromised by the VPLS service. Thus, VPLS OAM requirements
should be about making sure that it does not break end-to-end service characteristics and
OAM. This discussion will continue on the mailing list.

5. Radius/L2TP based VPLS 
draft-ietf-l2vpn-radius-pe-discovery-00.txt, Greg Weber
draft-ietf-l2vpn-l2tp-radius-vpls-00.txt, Mark Townsley.

The drafts have expired, but the authors intend to publish new versions. 

Loa: Even if new versions are not done, it is correct to re-submit the drafts to keep
them alive.

Current document focus was narrow as it only addressed VPLS. It does not take advantage
of new RADIUS CoA extensions as in RFC3576. 
Future updates: generalize to VPWS. Allow stateless operation. 
Author walked over an example of transactions for VPWS and VPLS. To reduce the number of
transactions, some can be collapsed. Radius accounting messages may be used for billing. 
Author requests feedback before making updates

Discussion
Ali Sajassi  thinks that this work should continue and drafts should be updated. Himanshu
Shah had a question on how this interacts with NM systems which do the configurations in
today’s networks. Yakov Rector thought that the new value in Mark’s proposal was for AC
configuration and authentication. Network side has been addressed by other protocols,
e.g., BGP.

Chairs suggested that detailed discussion should take place when Mark posts his draft. At
that time, we will now if we can retire draft-ietf-l2vpn-l2tp-radius-vpls-00.tx.
6. Supporting IP Multicast over VPLS – Yetik Serbest
draft-serbest-multicast-vpls-00.txt

Current VPLS behavior is to flood frames for destination MAC addresses which have not
been learnt and for multicast and broadcast destination MAC addresses. 
An objectives of this draft is to not send frames where there are no receivers who  need
it. 
Solution is based on snooping IGMP and/or PIM. 
Author walked through an example of IPTV in SBC network. Proposal is made to solve the
traffic duplication problem: detect it and drop the traffic coming from/to the AC/PW. 
Author requests comments.

Discussion: Alignment with Multicast work in L3VPN is needed. How about mixed router/host
network? Also, there is a bug in the description of the BATR PIM support. Support for
IPv6 is another thing missing in this draft. How does PIM refresh reduction fit? Can
snooping be relied upon? The draft should describe the overhead of PIM snooping. 
Discussion is to continue on the mailing list.

7. OAM Procedures for VPWS Interworking – Mustapha Aissaoui
draft-aissaoui-l2vpn-vpws-iw-oam-01.txt

This draft specifies the procedures for OAM interworking for the following VPWS: IP L2
interworking (ARP-mediation), FR-ATM interworking (FRF8.2), Ethernet interworking.
It complements draft-ietf-pwe3-oam-msg-map-01.txt, which covers the homogeneous VPWS.
Addressed three issues raised by coauthors. 

Issue 1: Defect loop operation. Single emulated end-to-end loop versus multiple coupled
loops.
settled on a modified "coupled loop" model which we believe works in all scenarios
addressed in the draft.

Issue 2: Should the receipt of a defect in the reverse direction of a remote AC or a PW
result in a different action at a PE? we analyzed the defects for all scenarios in the
draft and we have now updated the text to treat this as a separate defect.

Issue 3: Check the behavior in the case of L2TPv3 PSN Updated PW defect handling
procedures using StopCCN and CDN messages after discussion with Mark Townsley in
San-Diego.
Next steps: Add support for inband fault notification based on BFD. Authors would like to
make this document a Working Group draft and progress it as the basis for OAM for IP L2
Interworking work item. Sent message to mailing list to request more feedback.

Vach asked to make the additional updates and then make a call for WG document.

8. VPLS Interoperability with CE Bridges – Ali Sajassi
draft-sajassi-l2vpn-vpls-bridge-interop-00.txt

VPLS is a bridged LAN service which can also support CE bridges. There was not much data
plane discussion in the VPLS work in L2VPN WG. Most of the work and discussions centered
on the data plane and control plane over the IP/MPLS network. There are a number of
service types defined for bridges in IEEE which are not covered by the VPLS drafts. 

Bridge interoperability issues: CE bridge protocol handling; customer network topology
changes; redundancy; MAC address scalability; partial mesh PWs; multicast traffic;
interoperability with 802.1ad bridges.

Further discussion of this draft to take place on the mailing list.

9. Multicast in BGP/MPLS VPNs and VPLS – Rahul Aggarwal
draft-raggarwa-l3vpn-mvpn-vpls-mcast-00.txt

Issues with existing VPLS proposals include: no PIM peering between CE and PE, nor
between PEs. VPLS makes use of ingress replication by the PE. Also traffic is sent to
sites with no receivers. PIM/IGMP snooping is a possible approach, but requires PIM join
suppression to be disabled by VPLS customers. Problem is snooping needs to be performed
at AC and PW sides. 
Proposed solution is trying to address the above issues with common trade-offs for L3 VPN
and VPLS. IGMP/PIM snooping is not performed for remote sites. Use of multicast tree
which can be shared across multiple VPLS instances. It can makes use of PIM-SM, PIM-SSM,
or p2mp TE LSPs.  Author illustrated how this works through an example.

Feedback requested from the email list.


10. Testing Hierarchical Virtual Private LAN Services – Vach Kompella

draft-stokes-vkompella-l2vpn-hvpls-oam-00.txt


Updates since last revision (draft expired and is renamed):  Added two modes of
identifying and detecting OAM messages. Router Alert label at bottom of label stack and
control word based one (PWE3 PID).
Relation to OAM framework: OAM for a service carrying ethernet packets. Service operates
at a layer below the Ethernet packets. Wants to refer to framework to make sure that
end-to-end Ethernet OAM is not broken.  Author to provide updates to mail list for
further discussion.