From exim@www1.ietf.org Tue Dec 9 02:05:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06494 for ; Tue, 9 Dec 2003 02:05:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbvm-0003hU-AZ for l2vpn-archive@odin.ietf.org; Tue, 09 Dec 2003 02:05:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB975EtB014225 for l2vpn-archive@odin.ietf.org; Tue, 9 Dec 2003 02:05:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbvk-0003hM-RF for l2vpn-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 02:05:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05915 for ; Tue, 9 Dec 2003 02:04:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATbvh-0001pd-00 for l2vpn-web-archive@ietf.org; Tue, 09 Dec 2003 02:05:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATbvg-0001pZ-00 for l2vpn-web-archive@ietf.org; Tue, 09 Dec 2003 02:05:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbvZ-0003gX-D4; Tue, 09 Dec 2003 02:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATbv8-0003eh-MW for l2vpn@optimus.ietf.org; Tue, 09 Dec 2003 02:04:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05246 for ; Tue, 9 Dec 2003 02:04:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATbv4-0001pI-00 for l2vpn@ietf.org; Tue, 09 Dec 2003 02:04:30 -0500 Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il) by ietf-mx with esmtp (Exim 4.12) id 1ATbv2-0001p8-00 for l2vpn@ietf.org; Tue, 09 Dec 2003 02:04:29 -0500 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id hB973RXI024893 for ; Tue, 9 Dec 2003 09:03:27 +0200 (IST) Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112]) by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id hB973QgR024886 for ; Tue, 9 Dec 2003 09:03:27 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BE22.981EA6ED" Subject: question about VPLS forwarding Date: Tue, 9 Dec 2003 09:03:48 +0200 Message-ID: <27A0F290348F8E45AEF79889DDE65A52011205DA@exrad2.ad.rad.co.il> Thread-Topic: question about VPLS forwarding Thread-Index: AcO+IqA6at+8ku9sTrmcLcvth/RdoQ== From: "Keren Zik-Meirom" To: Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3BE22.981EA6ED Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable In the updated draft of Virtual Private LAN Services over MPLS = , In section 8.1. = (VPLS Encapsulation actions) there is a description of how should a VPLS = device handles an encapsulation received from the user, if it identifies = the customer then it should be stripped. My questions are as follows: 1. Whenever the VPLS device is working in qualified mode, the VID coming = from the user side always identify the VPLS instance and therefore = should be stripped according to the explanation in the draft. =20 What will happen if the user wants to create a VPLS instance based on = several VLANs? If the tag will be stripped at ingress there will be no way of restoring = it back at the egress? All the frames related to the same VPLS instance = will always be added with the same tag at the egress. Is that the way it should work? Does this draft intend to support such = application where several VLANs are mapped to the same VPLS instance? 2. At the egress a packet may be tagged or untagged,=20 To my understanding a VPLS instance must be configured with that = property to tag or not a frame before transmitting it to the user, is = that correct?=20 3. In the same section it is written:=20 Contrariwise, if a customer packet arrives at a customer-facing port=20 with a VLAN tag that identifies a VLAN domain in the customer L2=20 network, then the tag is not modified or stripped, as it belongs=20 with the rest of the customer frame. To my understanding a VPLS device working in unqualified mode, which = receive a VLAN, tagged frame match this description. Are their any other applications? Thanks Keren -------------------------------------------------------------------------= ------------------------- Keren Zik Meirom R&D Team Leader RAD Data Communication Tel: 03-7657025 Fax: 06-6440899 -------------------------------------------------------------------------= ------------------------- ------_=_NextPart_001_01C3BE22.981EA6ED Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable question about VPLS forwarding

In the = updated draft of Virtual Private LAN Services over MPLS  = </internet-drafts/draft-ietf-l2vpn-vpls-ldp-01.txt> , In section = 8.1. (VPLS Encapsulation actions) there is a description of how should a = VPLS device handles an encapsulation received from the user, if it = identifies the customer then it should be stripped.

My = questions are as follows:

1. = Whenever the VPLS device is working in qualified mode, the VID coming = from the user side always identify the VPLS instance and therefore = should be stripped according to the explanation in the draft.  =

What = will happen if the user wants to create a VPLS instance based on several = VLANs?

If the = tag will be stripped at ingress there will be no way of restoring it = back at the egress? All the frames related to the same VPLS instance = will always be added with the same tag at the egress.

Is that = the way it should work? Does this draft intend to support such = application where several VLANs are mapped to the same VPLS = instance?

2. At = the egress a packet may be tagged or untagged,

To my = understanding a VPLS instance must be configured with that property to = tag or not a frame before transmitting it to the user, is that correct? =

3. In = the same section it is written:

   Contrariwise, if a customer packet arrives = at a customer-facing port
   with a VLAN tag that identifies a VLAN domain in the = customer L2
   network, then the tag is not modified or stripped, as it = belongs
   with the rest of the customer frame.

To my = understanding a VPLS device working in unqualified mode, which receive a = VLAN, tagged frame match this description.

Are = their any other applications?

Thanks

Keren

----------------------------------------------------------= ----------------------------------------

Keren Zik Meirom

R&D Team Leader

RAD Data Communication

Tel:  03-7657025

Fax: 06-6440899

----------------------------------------------------------= ----------------------------------------



------_=_NextPart_001_01C3BE22.981EA6ED-- From exim@www1.ietf.org Tue Dec 9 04:45:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19780 for ; Tue, 9 Dec 2003 04:45:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeQp-00060l-JA for l2vpn-archive@odin.ietf.org; Tue, 09 Dec 2003 04:45:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB99jPPQ023096 for l2vpn-archive@odin.ietf.org; Tue, 9 Dec 2003 04:45:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeQh-00060K-0t for l2vpn-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 04:45:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19751 for ; Tue, 9 Dec 2003 04:44:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATeQa-0004Y3-00 for l2vpn-web-archive@ietf.org; Tue, 09 Dec 2003 04:45:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATeQa-0004Y0-00 for l2vpn-web-archive@ietf.org; Tue, 09 Dec 2003 04:45:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeQQ-0005yD-UW; Tue, 09 Dec 2003 04:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATePf-0005xd-FY for l2vpn@optimus.ietf.org; Tue, 09 Dec 2003 04:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19730 for ; Tue, 9 Dec 2003 04:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATePc-0004XJ-00 for l2vpn@ietf.org; Tue, 09 Dec 2003 04:44:12 -0500 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1ATePb-0004X1-00 for l2vpn@ietf.org; Tue, 09 Dec 2003 04:44:11 -0500 Received: from Dell8500 by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id BAA09602; Tue, 9 Dec 2003 01:43:23 -0800 (PST) Message-ID: <00d201c3be38$e5402c60$6501a8c0@Dell8500> From: "Marc Lasserre" To: "Keren Zik-Meirom" , References: <27A0F290348F8E45AEF79889DDE65A52011205DA@exrad2.ad.rad.co.il> Subject: Re: question about VPLS forwarding Date: Tue, 9 Dec 2003 10:43:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01C3BE41.4307EB50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C3BE41.4307EB50 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable question about VPLS forwarding ----- Original Message -----=20 From: Keren Zik-Meirom=20 To: l2vpn@ietf.org=20 Sent: Tuesday, December 09, 2003 08:03 Subject: question about VPLS forwarding=20 In the updated draft of Virtual Private LAN Services over MPLS = , In section 8.1. = (VPLS Encapsulation actions) there is a description of how should a VPLS = device handles an encapsulation received from the user, if it identifies = the customer then it should be stripped. My questions are as follows: 1. Whenever the VPLS device is working in qualified mode, the VID = coming from the user side always identify the VPLS instance and = therefore should be stripped according to the explanation in the draft. = Keren, What dictates whether the VLAN-Id is stripped off depends upon this = VLAN-Id being service delimiting (i.e. managed within the Service = Provider space to identify) or being part of the original frame issued = by the customer. In qualified mode, the VLAN-Id is obviously part of the original frame = and hence should NOT be stripped off. What will happen if the user wants to create a VPLS instance based on = several VLANs? In unqualified mode, all VLANs associated with a port are mapped to a = single VPLS instance. A specific implementation might be able to treat = multiple VLANs as being port of a "virtual" port and hence map these to = a single VPLS instance. This is sort of a hybrid mode between qual. and = unqual. learning which is not describe in the draft. Note that this would require specific processing of STP BPDUs in such = cases. STP BPDUs would have to be sent across the various VPLS = instances. This could be dealt with in a similar way as described in the = last paragraph of section 8.1.1. If the tag will be stripped at ingress there will be no way of = restoring it back at the egress? All the frames related to the same VPLS = instance will always be added with the same tag at the egress. Is that the way it should work? Does this draft intend to support such = application where several VLANs are mapped to the same VPLS instance? No, see above. 2. At the egress a packet may be tagged or untagged,=20 To my understanding a VPLS instance must be configured with that = property to tag or not a frame before transmitting it to the user, is = that correct?=20 Correct, it is a local decision of the egress PE to add (or translate) = VLAN tags. This needs to be configured explicitly. 3. In the same section it is written:=20 Contrariwise, if a customer packet arrives at a customer-facing = port with a VLAN tag that identifies a VLAN domain in the customer L2 network, then the tag is not modified or stripped, as it belongs with the rest of the customer frame. To my understanding a VPLS device working in unqualified mode, which = receive a VLAN, tagged frame match this description. My answer above should clarify this point. Thanks, Marc Are their any other applications? Thanks Keren = -------------------------------------------------------------------------= ------------------------- Keren Zik Meirom R&D Team Leader RAD Data Communication Tel: 03-7657025 Fax: 06-6440899 = -------------------------------------------------------------------------= ------------------------- ------=_NextPart_000_00CD_01C3BE41.4307EB50 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable question about VPLS forwarding
 
----- Original Message -----
From:=20 Keren = Zik-Meirom=20
Sent: Tuesday, December 09, = 2003=20 08:03
Subject: question about VPLS = forwarding=20

In the = updated draft of=20 Virtual Private LAN Services over MPLS =20 </internet-drafts/draft-ietf-l2vpn-vpls-ldp-01.txt> , In section = 8.1.=20 (VPLS Encapsulation actions) there is a description of how should a = VPLS=20 device handles an encapsulation received from the user, if it = identifies the=20 customer then it should be stripped.

My = questions are as=20 follows:

1. = Whenever the VPLS=20 device is working in qualified mode, the VID coming from the user side = always=20 identify the VPLS instance and therefore should be stripped according = to the=20 explanation in the draft. 

Keren,

What dictates whether the VLAN-Id = is stripped=20 off depends upon this VLAN-Id being service delimiting (i.e. managed = within the=20 Service Provider space to identify) or being part of the original frame = issued=20 by the customer.

In qualified mode, the VLAN-Id is = obviously=20 part of the original frame and hence should NOT be stripped=20 off.

What will = happen if the=20 user wants to create a VPLS instance based on several=20 VLANs?

In unqualified mode, all VLANs = associated with=20 a port are mapped to a single VPLS instance. A specific implementation = might be=20 able to treat multiple VLANs as being port of a "virtual" port and hence = map=20 these to a single VPLS instance. This is sort of a hybrid mode between = qual. and=20 unqual. learning which is not describe in the draft.

Note that this would require = specific=20 processing of STP BPDUs in such cases. STP BPDUs would have to be sent = across=20 the various VPLS instances. This could be dealt with in a similar way as = described in the last paragraph of section 8.1.1.

If the tag = will be=20 stripped at ingress there will be no way of restoring it back at the = egress?=20 All the frames related to the same VPLS instance will always be added = with the=20 same tag at the egress.

Is that = the way it should=20 work? Does this draft intend to support such application where several = VLANs=20 are mapped to the same VPLS instance?

No, see above.

2. At the = egress a packet=20 may be tagged or untagged,

To my = understanding a VPLS=20 instance must be configured with that property to tag or not a frame = before=20 transmitting it to the user, is that correct? =

Correct, it is a local decision of = the egress=20 PE to add (or translate) VLAN tags. This needs to be configured=20 explicitly.

3. In the = same section it=20 is written:

   Contrariwise,=20 if a customer packet arrives at a customer-facing port
   = with a=20 VLAN tag that identifies a VLAN domain in the customer = L2
  =20 network, then the tag is not modified or stripped, as it=20 belongs
   with the rest of the customer = frame.

To my = understanding a VPLS=20 device working in unqualified mode, which receive a VLAN, tagged frame = match=20 this description.

My answer above should clarify this = point.

Thanks,

Marc

Are their = any other=20 applications?

Thanks

Keren

----------------------------------------------------------------= ----------------------------------

Keren Zik=20 Meirom

R&D Team=20 Leader

RAD Data=20 Communication

Tel: =20 03-7657025

Fax:=20 06-6440899

----------------------------------------------------------------= ----------------------------------



= ------=_NextPart_000_00CD_01C3BE41.4307EB50-- From exim@www1.ietf.org Tue Dec 9 14:26:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09017 for ; Tue, 9 Dec 2003 14:26:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATnUm-0003um-8U for l2vpn-archive@odin.ietf.org; Tue, 09 Dec 2003 14:26:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9JQ89f015044 for l2vpn-archive@odin.ietf.org; Tue, 9 Dec 2003 14:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATnUm-0003uZ-33 for l2vpn-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 14:26:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09008 for ; Tue, 9 Dec 2003 14:25:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATnUj-0005mS-00 for l2vpn-web-archive@ietf.org; Tue, 09 Dec 2003 14:26:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATnUj-0005mP-00 for l2vpn-web-archive@ietf.org; Tue, 09 Dec 2003 14:26:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATnUf-0003to-HG; Tue, 09 Dec 2003 14:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATnUJ-0003tP-58 for l2vpn@optimus.ietf.org; Tue, 09 Dec 2003 14:25:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08988 for ; Tue, 9 Dec 2003 14:25:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATnUG-0005m9-00 for l2vpn@ietf.org; Tue, 09 Dec 2003 14:25:36 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1ATnUG-0005m6-00 for l2vpn@ietf.org; Tue, 09 Dec 2003 14:25:36 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hB9JPT031937; Tue, 9 Dec 2003 14:25:30 -0500 Message-ID: <3FD621A8.8060103@txc.com> Date: Tue, 09 Dec 2003 14:25:28 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vach.kompella@alcatel.com, rick@rhwilder.net, loa@pi.se CC: l2vpn@ietf.org Subject: 58th IETF minutes? References: <01b701c3aaed$f1483c40$0101010a@eng.timetra.com> In-Reply-To: <01b701c3aaed$f1483c40$0101010a@eng.timetra.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060704060402010303030808" Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a cryptographically signed message in MIME format. --------------ms060704060402010303030808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Are the 58th IETF minutes available somewhere? Thanks, Alex Conta --------------ms060704060402010303030808 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIwOTE5MjUyOFowIwYJKoZIhvcNAQkEMRYEFC7kqsq9vii8S+YU 8mJxbbWw1ayvMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBADnYn6c1Mk01N2Yxh1CYt4xK8DYn8FSrpfURuv/4UyxXRQp1rpZtXkopNDHE fGTV2pnX4Fo2cKFpEo0nTLQClYamdYxM8OD7daTARDqHRkMUv81K1ZREscUZFxgZObrFkNYv SQIwVZoZ/3nGkUTAumiksXdbpxWpQ6l693EkMpdvbDMNgmiQ1j9wLMD3M9XWggNRSkibbu06 s6NPUBREx2ugnhcnlPNA7+uLjAJ5h5ehe6qbp31T6qvC08/nBKFoVgjNP/BmGHvV3To4g1M1 MTbylZ6RN5+qQ5PhYaMl8FBsXEStC4bN/M17CMkurnyrL4ybCzJL21U2qvJMjf9mILgAAAAA AAA= --------------ms060704060402010303030808-- From exim@www1.ietf.org Wed Dec 17 16:36:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06868 for ; Wed, 17 Dec 2003 16:36:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjL7-0008UI-FX for l2vpn-archive@odin.ietf.org; Wed, 17 Dec 2003 16:36:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLaHtQ032620 for l2vpn-archive@odin.ietf.org; Wed, 17 Dec 2003 16:36:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjL7-0008U3-9e for l2vpn-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:36:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06791 for ; Wed, 17 Dec 2003 16:36:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjL5-0003JW-00 for l2vpn-web-archive@ietf.org; Wed, 17 Dec 2003 16:36:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjL3-0003JM-00 for l2vpn-web-archive@ietf.org; Wed, 17 Dec 2003 16:36:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjL3-0003JJ-00 for l2vpn-web-archive@ietf.org; Wed, 17 Dec 2003 16:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjKs-0008Rq-Fe; Wed, 17 Dec 2003 16:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjKE-0008Qf-NI for l2vpn@optimus.ietf.org; Wed, 17 Dec 2003 16:35:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06698 for ; Wed, 17 Dec 2003 16:35:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjKA-0003G7-00 for l2vpn@ietf.org; Wed, 17 Dec 2003 16:35:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjK9-0003G0-00 for l2vpn@ietf.org; Wed, 17 Dec 2003 16:35:18 -0500 Received: from [64.47.48.7] (helo=exchange.timetra.com) by ietf-mx with esmtp (Exim 4.12) id 1AWjK8-0003FW-00 for l2vpn@ietf.org; Wed, 17 Dec 2003 16:35:17 -0500 Received: from vkompellaxp ([192.168.5.178] unverified) by exchange.timetra.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Dec 2003 13:34:45 -0800 Reply-To: From: "Vach Kompella" To: Cc: "'Rick Wilder'" , "'Loa Andersson'" , "'Thomas Narten'" , , "'Russ Housley'" Subject: IETF 58 - L2VPN minutes Date: Wed, 17 Dec 2003 13:36:55 -0800 Organization: Alcatel USA Message-ID: <005101c3c4e5$e5929690$0101010a@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.1165 Importance: Normal X-OriginalArrivalTime: 17 Dec 2003 21:34:45.0519 (UTC) FILETIME=[96ED39F0:01C3C4E5] Content-Transfer-Encoding: quoted-printable Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Folks, Here are the minutes from the L2VPN session at IETF 58. Sorry for the delay. Thanks to Alia and Ken for taking notes. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Minutes L2VPN WG November 12, 1530-1730 Scribe: Kenneth Sundell Scribe: Alia Atlas L2VPN wg agenda IETF58 - Minneapolis 1. Agenda bashing Loa: There is a custom in the IETF not to use two chairs from same company Rick to stay until next meeting (Rick and Vach at the same company). No objections. =20 Loa went through the agenda No changes to agenda 2. WG Status, Vach Kompella Milestones: At risk: Aug 03 Submit an I-D describing MIB for VPLS=20 Aug 03 Submit an I-D describing MIB for VPWS=20 Vach: Submit Enterprise MIBs as jump start Aug 03 Submit an I-D on OAM for VPLS=20 Aug 03 Submit an I-D on OAM for VPWS=20 Need to follow the OaM development happening in the MPLS WG closely before persuing the work Need more participation Oct 03 Submit L2 requirements to IESG for publication as Informational RFC Into last call soon (some security considerations issues) Oct 03 Submit L2 framework to IESG for publication as Informational RFC Ready to go too Completed or threreabouts Done Identify VPLS and VPWS solutions for the WG=20 Dec 03 Submit VPLS solution documents to IESG=20 Dec 03 Submit VPWS solution documents to IESG=20 A last call warning is issued to find traction.=20 Andy Malis: Send it to the list Looking good: Jan 04 Submit IP-only L2VPN solution documents to IESG=20 Seems Achievable Feb 04 Submit MIB for VPLS to IESG=20 Feb 04 Submit MIB for VPWS to IESG=20 Achievable? Working group documents a: draft-ietf-l2vpn-signaling-00.txt To be presented. b: draft-ietf-l2vpn-requirements-00.txt Waiting for Russ Housley's comments (sec advisor) otherwise ready to go c: draft-ietf-l2vpn-l2-framework-03.txt Eric Rosen d: draft-ietf-l2vpn-vpls-bgp-00.txt Kireeti Kompella e: draft-ietf-ppvpn-vpls-ldp-01.txt Need to rename draft from *ppvpn* to *l2vpn* f: draft-shah-ppvpn-ipls-02.txt=20 Will be published as a wg doc g: draft-heinanen-radius-l2tp-vpls-00.txt (will be published as a wg doc) Mark Townsley picked up the work after Juha Heinanen, the document was already approved as a working group document (not issued as that this time). Mark Townsley: Will resend the document with wg status, but solicits comments on the list before doing do. h: draft-heinanen-radius-pe-discovery-04.txt (will be published as a wg doc) Should have wg status. Greg Weber wasn't present, but Mark said that the same procedure will be applied for this work as well. 3. Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS draft-rosen-l2vpn-mesh-failure-00.txt Eric Rosen Assuming that full mesh of PW's is present, if assuption fails,=20 blackholes can occur. Failure modes: - data plane connectivity - PW state at edge - auto-discovery failure or configuration mismatch Bad ideas for detecting failures - local information (detection only) - mismatch between operational PWs and discovered endpoints - PW operational status changes - global information (resilience) - PWs as overlay network, Spanning tree - PWs as overlay network, run routing - but don't really want to run a routing protocol or spanning tree - overhead costs Not so quite bad idea - global information (detection only) - each edge tells every other edge "here are the PW endpoints i can talk to" - get global info, from each edge, set of other edges that can be seen - any edge not universally seen is removed from the mesh What is the reaction after constructing this information? - log the failure - or fix the failure through re-routing - most important is to get the detection part Is this worth pursuing? Yakov: Does it need to be new protocol to existing ones or done by nms (mibs) Vach: The approach is to detect, fixing things is another question Eric: By NMS do you mean some mgmt station or from each PE Yakov: From mgmt station Vach: Not necessarily need protocol, but we don't want SNMP gets between PEs Eric: In practice, using NMS to detect dynamic problems hasn't historically worked well. Yakov: Have traps when PW goes up and when goes down, so can check adjacency. Vach: If just wanting to detect, then MIB could be enough. If more than that. Eric: Be careful. One could build a tool to look at the MIB info to determine this. How happy are people with depending on NMS yet? Yakov: If all the protocol is to do is detection, then need operator action using nms to fix problem Vach: we haven't determined the scope of the problem yet, so maybe detection is sufficient Liam Casey: The detection time has to be fast, comparable to control plane. Agree to pursuing the work. Propose to do it in the control plane as opposed to the management plane for default border repair. Suggest that failure mode is "if one router can't be reached by another, then no router should be allowed to reach." Jack Lukaski/Lewkowski: Do not reinvent the weel. use existing protocols done elsewhere in this domain (SONET, ATM F4/F5 AIS). Separate in-band from out-of-band. Vach: Asking the WG if this is an important problem to solve? Yes: a fair number of hands Opposed: None Vach: The consensus to be verified on the list Eric: Had already raised on mailing list, said wasn't important and was beaten up. But dead silence now. 4. The "generalized FEC ID" in the PWE3 control messages, as discussed in draft-ietf-pwe3-control-protocol-04.txt draft-ietf-l2vpn-signaling-00.txt Eric Rosen PWE3 control protocol draft (in lc) define it Superset of signaling paradigm in VPLS-LDP spec (L2VPN WG draft) Eric: Can we all agree to use it? It has been sparsely discussed on the mailing list by a few persons. There do not seem to be any substantive technical issues with it Vach: Think we can close on this but want to hear others opinions. Naming of a VPLS is going to change substantially. Not many are involved in the discussion (even if people seem to go off and implement it) Have a couple of issues: most important is to drop the distributed VPLS part, since nobody is doing that. Eric: Some people in WG are interested in distributed VPLS. Inter-provider case may need it. Friends from Nortel should jump up. (Aside from Vach: Hamid from Nortel did come to chairs and ask that it should be retained). Rick: Input from VPLS implementers? No response Eric: We got so tired doing the framework and requirements that at this point nobody cares..? Loa: Hmmm no responses. This is how we handle it, three weeks on the mailing list, no comments and we go with the solution. End of session =20 From exim@www1.ietf.org Wed Dec 17 17:23:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09362 for ; Wed, 17 Dec 2003 17:23:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWk4O-0002Yn-7h for l2vpn-archive@odin.ietf.org; Wed, 17 Dec 2003 17:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHMN4GR009835 for l2vpn-archive@odin.ietf.org; Wed, 17 Dec 2003 17:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWk4O-0002YY-0M for l2vpn-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 17:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09341 for ; Wed, 17 Dec 2003 17:23:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWk4L-0005TH-00 for l2vpn-web-archive@ietf.org; Wed, 17 Dec 2003 17:23:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWk4K-0005T7-00 for l2vpn-web-archive@ietf.org; Wed, 17 Dec 2003 17:23:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWk4K-0005T1-00 for l2vpn-web-archive@ietf.org; Wed, 17 Dec 2003 17:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWk4L-0002XX-3j; Wed, 17 Dec 2003 17:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWk3W-0002WO-5L for l2vpn@optimus.ietf.org; Wed, 17 Dec 2003 17:22:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09289 for ; Wed, 17 Dec 2003 17:22:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWk3T-0005OJ-00 for l2vpn@ietf.org; Wed, 17 Dec 2003 17:22:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWk3S-0005O9-00 for l2vpn@ietf.org; Wed, 17 Dec 2003 17:22:07 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AWk3S-0005N9-00 for l2vpn@ietf.org; Wed, 17 Dec 2003 17:22:06 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHMLRA12663; Wed, 17 Dec 2003 17:21:27 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 17:21:26 -0500 Message-ID: From: "Hamid Ould-Brahim" To: vach.kompella@alcatel.com, l2vpn@ietf.org Cc: "'Rick Wilder'" , "'Loa Andersson'" , "'Thomas Narten'" , margaret.wasserman@nokia.com, "'Russ Housley'" Subject: RE: IETF 58 - L2VPN minutes Date: Wed, 17 Dec 2003 17:21:26 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Vach, From the minutes... > > (Aside from Vach: Hamid from Nortel did come to chairs and > ask that it should be retained).> I'll suggest rewriting the above to: > (Aside from Vach: Hamid did come to chairs and > ask that it should be retained). Hamid. From exim@www1.ietf.org Thu Dec 18 14:24:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09906 for ; Thu, 18 Dec 2003 14:24:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3kj-0002r1-Fh for l2vpn-archive@odin.ietf.org; Thu, 18 Dec 2003 14:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIJO5SZ010965 for l2vpn-archive@odin.ietf.org; Thu, 18 Dec 2003 14:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3kj-0002qm-7z for l2vpn-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 14:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09886 for ; Thu, 18 Dec 2003 14:24:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3kg-0002my-00 for l2vpn-web-archive@ietf.org; Thu, 18 Dec 2003 14:24:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3kf-0002mq-00 for l2vpn-web-archive@ietf.org; Thu, 18 Dec 2003 14:24:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX3kf-0002mn-00 for l2vpn-web-archive@ietf.org; Thu, 18 Dec 2003 14:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3kf-0002q2-1c; Thu, 18 Dec 2003 14:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3kW-0002pl-5E for l2vpn@optimus.ietf.org; Thu, 18 Dec 2003 14:23:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09876 for ; Thu, 18 Dec 2003 14:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3kT-0002mR-00 for l2vpn@ietf.org; Thu, 18 Dec 2003 14:23:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3kR-0002mK-00 for l2vpn@ietf.org; Thu, 18 Dec 2003 14:23:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AX3kR-0002mE-00 for l2vpn@ietf.org; Thu, 18 Dec 2003 14:23:47 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2003 11:27:02 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBIJNCAt017508; Thu, 18 Dec 2003 11:23:12 -0800 (PST) Received: from tnadeauw2k02 (che-vpn-cluster-1-62.cisco.com [10.86.240.62]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AET70648; Thu, 18 Dec 2003 14:23:11 -0500 (EST) Reply-To: From: "Thomas D. Nadeau" To: , Cc: "'Rick Wilder'" , "'Loa Andersson'" , "'Thomas Narten'" , , "'Russ Housley'" , "'David Zelig'" Subject: RE: IETF 58 - L2VPN minutes Date: Thu, 18 Dec 2003 14:22:01 -0500 Organization: Cisco Systems, inc. Message-ID: <002201c3c59c$471b7e20$6701a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <005101c3c4e5$e5929690$0101010a@eng.timetra.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I didn't attend the meeting as I had to leave early due to having the flu, so a few comments In line. -----Original Message----- From: l2vpn-admin@ietf.org [mailto:l2vpn-admin@ietf.org] On Behalf Of Vach Kompella Sent: Wednesday, December 17, 2003 4:37 PM To: l2vpn@ietf.org Cc: 'Rick Wilder'; 'Loa Andersson'; 'Thomas Narten'; margaret.wasserman@nokia.com; 'Russ Housley' Subject: IETF 58 - L2VPN minutes Folks, Here are the minutes from the L2VPN session at IETF 58. Sorry for the delay. Thanks to Alia and Ken for taking notes. ======================================================================== ========== Minutes L2VPN WG November 12, 1530-1730 Scribe: Kenneth Sundell Scribe: Alia Atlas L2VPN wg agenda IETF58 - Minneapolis 1. Agenda bashing Loa: There is a custom in the IETF not to use two chairs from same company Rick to stay until next meeting (Rick and Vach at the same company). No objections. Loa went through the agenda No changes to agenda 2. WG Status, Vach Kompella Milestones: At risk: Aug 03 Submit an I-D describing MIB for VPLS Aug 03 Submit an I-D describing MIB for VPWS Vach: Submit Enterprise MIBs as jump start If an enterprise MIB(s) is/are suggested, it/they must work with the existing PWE3 MIBs, which were designed with VPLS in mind. I mentioned this during he summer meeting. There is a small diff between what exists today and what is needed to facililtate VPLS, so lets not reinvent the wheel. I was supposed to write up a draft with Dave Zelig on this, but due to lots of other commitments, we did not get to it. I will talk with Dave today about trying to put something together for early January (I have CC:ed him above too incase he is not on this list). Aug 03 Submit an I-D on OAM for VPLS Aug 03 Submit an I-D on OAM for VPWS Need to follow the OaM development happening in the MPLS WG closely before persuing the work Need more participation In addition, need to be aligned with that work, as well as work happening in IEEE related to Ethernet OAM which directly applies. --Tom Oct 03 Submit L2 requirements to IESG for publication as Informational RFC Into last call soon (some security considerations issues) Oct 03 Submit L2 framework to IESG for publication as Informational RFC Ready to go too Completed or threreabouts Done Identify VPLS and VPWS solutions for the WG Dec 03 Submit VPLS solution documents to IESG Dec 03 Submit VPWS solution documents to IESG A last call warning is issued to find traction. Andy Malis: Send it to the list Looking good: Jan 04 Submit IP-only L2VPN solution documents to IESG Seems Achievable Feb 04 Submit MIB for VPLS to IESG Feb 04 Submit MIB for VPWS to IESG Achievable? Working group documents a: draft-ietf-l2vpn-signaling-00.txt To be presented. b: draft-ietf-l2vpn-requirements-00.txt Waiting for Russ Housley's comments (sec advisor) otherwise ready to go c: draft-ietf-l2vpn-l2-framework-03.txt Eric Rosen d: draft-ietf-l2vpn-vpls-bgp-00.txt Kireeti Kompella e: draft-ietf-ppvpn-vpls-ldp-01.txt Need to rename draft from *ppvpn* to *l2vpn* f: draft-shah-ppvpn-ipls-02.txt Will be published as a wg doc g: draft-heinanen-radius-l2tp-vpls-00.txt (will be published as a wg doc) Mark Townsley picked up the work after Juha Heinanen, the document was already approved as a working group document (not issued as that this time). Mark Townsley: Will resend the document with wg status, but solicits comments on the list before doing do. h: draft-heinanen-radius-pe-discovery-04.txt (will be published as a wg doc) Should have wg status. Greg Weber wasn't present, but Mark said that the same procedure will be applied for this work as well. 3. Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS draft-rosen-l2vpn-mesh-failure-00.txt Eric Rosen Assuming that full mesh of PW's is present, if assuption fails, blackholes can occur. Failure modes: - data plane connectivity - PW state at edge - auto-discovery failure or configuration mismatch Bad ideas for detecting failures - local information (detection only) - mismatch between operational PWs and discovered endpoints - PW operational status changes - global information (resilience) - PWs as overlay network, Spanning tree - PWs as overlay network, run routing - but don't really want to run a routing protocol or spanning tree - overhead costs Not so quite bad idea - global information (detection only) - each edge tells every other edge "here are the PW endpoints i can talk to" - get global info, from each edge, set of other edges that can be seen - any edge not universally seen is removed from the mesh What is the reaction after constructing this information? - log the failure - or fix the failure through re-routing - most important is to get the detection part Is this worth pursuing? Yakov: Does it need to be new protocol to existing ones or done by nms (mibs) Vach: The approach is to detect, fixing things is another question Eric: By NMS do you mean some mgmt station or from each PE Yakov: From mgmt station Vach: Not necessarily need protocol, but we don't want SNMP gets between PEs Eric: In practice, using NMS to detect dynamic problems hasn't historically worked well. Yakov: Have traps when PW goes up and when goes down, so can check adjacency. Vach: If just wanting to detect, then MIB could be enough. If more than that. Eric: Be careful. One could build a tool to look at the MIB info to determine this. How happy are people with depending on NMS yet? Yakov: If all the protocol is to do is detection, then need operator action using nms to fix problem Vach: we haven't determined the scope of the problem yet, so maybe detection is sufficient Liam Casey: The detection time has to be fast, comparable to control plane. Agree to pursuing the work. Propose to do it in the control plane as opposed to the management plane for default border repair. Suggest that failure mode is "if one router can't be reached by another, then no router should be allowed to reach." Jack Lukaski/Lewkowski: Do not reinvent the weel. use existing protocols done elsewhere in this domain (SONET, ATM F4/F5 AIS). Separate in-band from out-of-band. Vach: Asking the WG if this is an important problem to solve? Yes: a fair number of hands Opposed: None Vach: The consensus to be verified on the list Eric: Had already raised on mailing list, said wasn't important and was beaten up. But dead silence now. 4. The "generalized FEC ID" in the PWE3 control messages, as discussed in draft-ietf-pwe3-control-protocol-04.txt draft-ietf-l2vpn-signaling-00.txt Eric Rosen PWE3 control protocol draft (in lc) define it Superset of signaling paradigm in VPLS-LDP spec (L2VPN WG draft) Eric: Can we all agree to use it? It has been sparsely discussed on the mailing list by a few persons. There do not seem to be any substantive technical issues with it Vach: Think we can close on this but want to hear others opinions. Naming of a VPLS is going to change substantially. Not many are involved in the discussion (even if people seem to go off and implement it) Have a couple of issues: most important is to drop the distributed VPLS part, since nobody is doing that. Eric: Some people in WG are interested in distributed VPLS. Inter-provider case may need it. Friends from Nortel should jump up. (Aside from Vach: Hamid from Nortel did come to chairs and ask that it should be retained). Rick: Input from VPLS implementers? No response Eric: We got so tired doing the framework and requirements that at this point nobody cares..? Loa: Hmmm no responses. This is how we handle it, three weeks on the mailing list, no comments and we go with the solution. End of session From exim@www1.ietf.org Thu Dec 18 19:02:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00020 for ; Thu, 18 Dec 2003 19:02:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX85s-0001Ea-B8 for l2vpn-archive@odin.ietf.org; Thu, 18 Dec 2003 19:02:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ02CJQ004738 for l2vpn-archive@odin.ietf.org; Thu, 18 Dec 2003 19:02:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX85s-0001EL-5K for l2vpn-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 19:02:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29998 for ; Thu, 18 Dec 2003 19:02:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX85o-0001bL-00 for l2vpn-web-archive@ietf.org; Thu, 18 Dec 2003 19:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX85n-0001bD-00 for l2vpn-web-archive@ietf.org; Thu, 18 Dec 2003 19:02:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX85n-0001bA-00 for l2vpn-web-archive@ietf.org; Thu, 18 Dec 2003 19:02:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX85h-0001DY-0P; Thu, 18 Dec 2003 19:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX852-00013C-3t for l2vpn@optimus.ietf.org; Thu, 18 Dec 2003 19:01:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29945 for ; Thu, 18 Dec 2003 19:01:15 -0500 (EST) From: Gijsbert.Van_Kersen@alcatel.be Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX84y-0001Yp-00 for l2vpn@ietf.org; Thu, 18 Dec 2003 19:01:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX84y-0001Yi-00 for l2vpn@ietf.org; Thu, 18 Dec 2003 19:01:16 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AX84x-0001YU-00 for l2vpn@ietf.org; Thu, 18 Dec 2003 19:01:15 -0500 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id hBJ00Xa0014547 for ; Fri, 19 Dec 2003 01:01:05 +0100 Subject: Gijsbert VAN KERSEN/BE/ALCATEL is out of the office. To: l2vpn@ietf.org Message-ID: Date: Fri, 19 Dec 2003 01:00:43 +0100 X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 12/19/2003 01:01:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 I will be out of the office starting 18/12/2003 and will not return until 05/01/2004. I hope you have have a great Xmas and am looking forward to working with you again next year. From exim@www1.ietf.org Fri Dec 19 08:18:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08281 for ; Fri, 19 Dec 2003 08:18:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKW5-0008Lr-RU for l2vpn-archive@odin.ietf.org; Fri, 19 Dec 2003 08:18:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJDI5b3032097 for l2vpn-archive@odin.ietf.org; Fri, 19 Dec 2003 08:18:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKW5-0008Lc-MR for l2vpn-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 08:18:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08273 for ; Fri, 19 Dec 2003 08:18:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXKW4-0002oY-00 for l2vpn-web-archive@ietf.org; Fri, 19 Dec 2003 08:18:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXKW3-0002oQ-00 for l2vpn-web-archive@ietf.org; Fri, 19 Dec 2003 08:18:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXKW3-0002oN-00 for l2vpn-web-archive@ietf.org; Fri, 19 Dec 2003 08:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKW1-0008L2-L0; Fri, 19 Dec 2003 08:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXKVJ-0008KR-0c for l2vpn@optimus.ietf.org; Fri, 19 Dec 2003 08:17:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08258 for ; Fri, 19 Dec 2003 08:17:15 -0500 (EST) From: richard.spencer@bt.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXKVH-0002ng-00 for l2vpn@ietf.org; Fri, 19 Dec 2003 08:17:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXKVG-0002nR-00 for l2vpn@ietf.org; Fri, 19 Dec 2003 08:17:15 -0500 Received: from smtp4.smtp.bt.com ([217.32.164.151] helo=i2kc04-ukbr.domain1.systemhost.net) by ietf-mx with esmtp (Exim 4.12) id 1AXKVF-0002kR-00 for l2vpn@ietf.org; Fri, 19 Dec 2003 08:17:14 -0500 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by i2kc04-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Dec 2003 13:16:43 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Dec 2003 13:16:41 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: Discovery and full mesh failure Date: Fri, 19 Dec 2003 13:16:41 -0000 Message-ID: Thread-Index: AcPGJ8Kc/fDR8lmkTQqcp8bOPr2a7QAATQ7A To: X-OriginalArrivalTime: 19 Dec 2003 13:16:41.0685 (UTC) FILETIME=[57998850:01C3C632] Content-Transfer-Encoding: base64 Sender: l2vpn-admin@ietf.org Errors-To: l2vpn-admin@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYXZlIGEgY291cGxlIG9mIG9ic2VydmF0aW9ucy9xdWVyaWVzIHJlZ2FyZGluZyBkcmFmdC1y b3Nlbi1sMnZwbi1tZXNoLWZhaWx1cmUtMDAudHh0Lg0KIA0KVGhlIGRyYWZ0IGxpc3RzICJGYWls dXJlIG9mIHRoZSBhdXRvLWRpc2NvdmVyeSBwcm9jZXNzIiBhcyBiZWluZyBvbmUgb2YgdGhlIHJl YXNvbnMgYSBnaXZlbiBMUyBpbnN0YW5jZSBtYXkgbm90IGJlIGZ1bGx5IG1lc2hlZC4gSU1PIHRo aXMgaXMgZGVwZW5kYW50IG9uIHRoZSB0eXBlIG9mIGRpc2NvdmVyeSBtZWNoYW5pc20gdXNlZC4g SWYgYSBjZW50cmFsaXNlZCBtZWNoYW5pc20gaXMgdXNlZCwgYWxsIFBFcyB3aWxsIHJlY2VpdmUg ZXhhY3RseSB0aGUgc2FtZSBtZW1iZXJzaGlwIGluZm9ybWF0aW9uIGFuZCB0aGVyZWZvcmUgYSBm dWxsIG1lc2ggd2lsbCBhbHdheXMgYmUgZXN0YWJsaXNoZWQgKHByb3ZpZGluZyB0aGVyZSBhcmUg bm8gc2lnbmFsbGluZyBlcnJvcnMpLiBUaGUgc2FtZSBjb3VsZCBiZSBzYWlkIG9mIGEgZGlzdHJp YnV0ZWQgZGlzY292ZXJ5IG1lY2hhbmlzbSB0aGF0IG1haW50YWlucyBhIGNvbW1vbi9nbG9iYWwg TFMgRUUgbWVtYmVyc2hpcCB0YWJsZS9kYXRhYmFzZSwgYXMgb3Bwb3NlZCB0byBhIGRpc3RyaWJ1 dGVkIG1lY2hhbmlzbSBpbiB3aGljaCBQRXMgbWFpbnRhaW5zIHRoZWlyIG93biBpbmRlcGVuZGVu dC9sb2NhbCB0YWJsZXMuIA0KIA0KVGhlcmUgaXMgdGhlIHBvc3NpYmlsaXR5IHRoYXQgZGlzY292 ZXJ5IHBhY2tldHMgY29udGFpbmluZyBtZW1iZXJzaGlwIGluZm9ybWF0aW9uIHNlbnQgdG8gYSBw YXJ0aWN1bGFyIFBFIGNvdWxkIGJlY29tZSBjb3JydXB0ZWQgaW4gc29tZSB3YXkgYW5kIG9ubHkg YSBzdWJzZXQgb2YgdGhlIGZ1bGwgbGlzdCBvZiBQRSBtZW1iZXJzIGZvciBhIGdpdmVuIExTIG1h eSBiZSByZWNlaXZlZC4gSG93ZXZlciwgaWYgdGhpcyB3ZXJlIHRvIGhhcHBlbiB0aGVuIGVzdGFi bGlzaG1lbnQgb2Ygc29tZSBvZiB0aGUgUFdzIHRvIHRoZSBQRSB0aGF0IGhhcyBvbmx5IHJlY2Vp dmVkIGEgc3Vic2V0IG9mIHRoZSBmdWxsIGxpc3Qgb2YgUEVzIHdvdWxkIGZhaWwuIEZvbGxvd2lu ZyB0aGlzLCB0aGUgUEVzIChpbmNsdWRpbmcgdGhlIFBFIHdpdGggb25seSBhIHN1YnNldCBvZiB0 aGUgZnVsbCBsaXN0KSB3b3VsZCByZXF1ZXN0IGEgcmVzZW5kIG9mIHRoZSBMUyBFRSBkYXRhYmFz ZSBhbmQgdGhlIHByb2JsZW0gd291bGQgYmUgcmVjdGlmaWVkICh1bmxlc3MgcGFja2V0cyBjb250 aW51ZSB0byBiZSBjb3JydXB0ZWQgb2YgY291cnNlLCBpbiB3aGljaCBjYXNlIGFuIGVycm9yIHdv dWxkIGJlIGZsYWdnZWQgYW5kIHN1YnNlcXVlbnQgYWN0aW9ucyB3b3VsZCBiZSByZXF1aXJlZC4p DQogDQpUaGUgZHJhZnQgc3RhdGVzICJUaGVyZSBtdXN0IGJlIGEgc3RhdHVzIG1lc3NhZ2UsIHdo aWNoIHdlIGNhbGwgdGhlICJNZXNoIFN0YXR1cyIgbWVzc2FnZSwgd2hpY2ggYSBQRSBzZW5kcyB0 byBlYWNoIG9mIHRoZSBvdGhlciBQRXMgaW4gdGhlIHNhbWUgTFMgaW5zdGFuY2UiLCB3aGljaCAi bGlzdHMgdGhlIHNldCBvZiBFRSBwYWlycyBmb3Igd2hpY2ggdGhlIG9yaWdpbmF0aW5nIFBFIGhh cyBvcGVyYXRpb25hbCBQV3MiLiBJZiBhIGNvbW1vbiBMUyBFRSBtZW1iZXJzaGlwIGRhdGFiYXNl IGlzIG1haW50YWluZWQgdGhlbiB3aHkgaXMgdGhpcyBsaXN0IG5lZWRlZD8gRWFjaCBQRSByZWNl aXZlcyBhIGxpc3Qgb2YgRUVzIGluIHRoZSBzYW1lIExTIGZyb20gdGhlIGNvbW1vbiBMUyBFRSBk YXRhYmFzZSwgYW5kIHRoZSBQV3MgYmV0d2VlbiB0aG9zZSBFRXMgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgdG8gYmUgb3BlcmF0aW9uYWwgKGFsbG93aW5nIGFkZXF1YXRlIHRpbWUgZm9yIHRoZSBwcm92 aXNpb25pbmcgcHJvY2VzcyB0byBjb21wbGV0ZSkgdW5sZXNzIGluZm9ybWVkIG90aGVyd2lzZS4g DQogDQpJbiB0aGUgZXZlbnQgb2YgYSBQVyBzaWduYWxsaW5nL2ZvcndhcmRpbmcgZmFpbHVyZSwg dGhlIGZhaWx1cmUgc2hvdWxkIGJlIGZsYWdnZWQgdG8gdGhlIGRpc2NvdmVyeSBtZWNoYW5pc20g YnkgdGhlIHNpZ25hbGxpbmcvT0FNIG1lY2hhbmlzbSB0aGF0IGRldGVjdHMgdGhlIGZhaWx1cmUu IFRoaXMgYWxsb3dzIHRoZSBkaXNjb3ZlcnkgbWVjaGFuaXNtIHRvIGluZm9ybSBQRXMgYmVsb25n aW5nIHRvIHRoZSBMUyB0aGF0IHRoZXkgc2hvdWxkIHN0b3AgZm9yd2FyZGluZyBwYWNrZXRzIHRv IHRoZSBFRXMgdGhhdCBhcmUgb25seSBwYXJ0aWFsbHkgY29ubmVjdGVkIChsb2NhbGx5IGF0dGFj aGVkIEVFcyBzaG91bGQgYmUgZGlzYWJsZWQgYXMgcGVyIHRoZSBkcmFmdCkuIFRvIGFsbG93IFBX cyB0byBwYXJ0aWFsbHkgY29ubmVjdGVkIEVFcyB0byByZW1haW4gZXN0YWJsaXNoZWQgZGVzcGl0 ZSBmb3J3YXJkaW5nIGJlaW5nIGRpc2FibGVkLCBhbGwgdGhhdCB3b3VsZCBiZSByZXF1aXJlZCB3 b3VsZCBiZSBhIGZpZWxkIGluIHRoZSBtZW1iZXJzaGlwIGluZm9ybWF0aW9uIGRhdGFiYXNlIHRo YXQgaW5kaWNhdGVzIHdoZXRoZXIgYW4gRUUgaXMgb3BlcmF0aW9uYWwgb3Igbm90Lg0KIA0KSU1P IHRoZSBmdW5jdGlvbmFsaXR5IGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0IHNob3VsZCBiZSBpbmNv cnBvcmF0ZWQgaW50byBleGlzdGluZyBjZW50cmFsaXNlZCBkaXNjb3ZlcnkgbWVjaGFuaXNtcyAo ZS5nLiB0aGUgUkFESVVTIGRpc2NvdmVyeSBkcmFmdCksIEkgZG9uJ3QgdGhpbmsgYSBuZXcgbWVj aGFuaXNtIG5lZWRzIHRvIGJlIGRlZmluZWQuIEl0IHNob3VsZCBiZSB0aGUgcmVzcG9uc2liaWxp dHkgb2YgdGhlIGRpc2NvdmVyeSBtZWNoYW5pc20gdG8gZGV0ZXJtaW5lIHdoaWNoIEVFcyBzaG91 bGQgYmUgY29uc2lkZXJlZCBvcGVyYXRpb25hbCBiYXNlZCBvbiBpbmZvcm1hdGlvbiBpdCByZWNl aXZlcyBhYm91dCBmYWlsdXJlcyBmcm9tIHNpZ25hbGxpbmcvT0FNIG1lY2hhbmlzbXMuIE1haW50 ZW5hbmNlIG9mIGluZm9ybWF0aW9uIGFib3V0IHdoaWNoIEVFcyBhcmUgb3BlcmF0aW9uYWwgaXMg aW1wb3J0YW50IGZvciBhbGwgVlBOIHRlY2hub2xvZ2llcywgbm90IGp1c3QgVlBMUy9JUExTLCBz byB3aHkgbm90IHVzZSB0aGUgY2FwYWJpbGl0aWVzIG9mIGV4aXN0aW5nIG1lY2hhbmlzbXMgcmF0 aGVyIHRoYW4gZGVmaW5lIG5ldyBvbmVzIHNwZWNpZmljYWxseSBmb3IgVlBMUy9JUExTLg0KIA0K SW4gdGhlIGNhc2Ugb2YgZGlzdHJpYnV0ZWQgbWVjaGFuaXNtcyBpbiB3aGljaCBQRXMgbWFpbnRh aW4gdGhlaXIgb3duIGluZGVwZW5kZW50IExTIEVFIHRhYmxlcy9kYXRhYmFzZXMgKGUuZy4gQkdQ IGRpc2NvdmVyeSBkcmFmdCksIHRoZW4gSSBjYW4gc2VlIHdoeSBhbiBhZGRpdGlvbmFsIG1lY2hh bmlzbSBzdWNoIGFzIHRoZSB1c2Ugb2YgIk1lc2ggU3RhdHVzIiBtZXNzYWdlcyBpcyByZXF1aXJl ZC4gVG8gYWRkcmVzcyB0aGlzIG5lZWQgSSB0aGluayB0aGlzIGRyYWZ0IGFsc28gbmVlZHMgdG8g dGFrZSBhY2NvdW50aW5nIGludG8gY29uc2lkZXJhdGlvbi4gSWYgUEVzIGFyZSB0b2xkIHRvIHN0 b3AgZm9yd2FyZGluZyB0cmFmZmljIHRvIHBhcnRpYWxseSBjb25uZWN0ZWQgRUVzIChldmVuIHRo b3VnaCB0aGUgUFdzIHRvIHRob3NlIEVFcyBhcmUgc3RpbGwgZXN0YWJsaXNoZWQpIHRoZW4gYSBt YW5hZ2VtZW50IHN5c3RlbSBhbHNvIG5lZWRzIHRvIGJlIGluZm9ybWVkIG90aGVyd2lzZSB0aGUg Y3VzdG9tZXIgd2lsbCBjb250aW51ZSB0byBiZSBjaGFyZ2VkIGZvciBFRXMgdGhhdCBhcmUgbm90 IGZvcndhcmRpbmcgYW55IHBhY2tldHMgKHVubGVzcyB0aGV5IGFyZSBiZWluZyBjaGFyZ2VkIGJh c2VkIG9uIHVzYWdlIG9ubHkpLiBJbiB0aGUgY2FzZSBvZiBSQURJVVMsIHRoaXMgaXNzdWUgY2Fu IGJlIHNvbHZlZCBieSBzaW1wbHkgaXNzdWluZyBhIHN0b3AgYWNjb3VudGluZyByZXF1ZXN0IGZv ciB0aGUgRUVzIHRoYXQgYXJlIG5vIGxvbmdlciBvcGVyYXRpb25hbC4NCiANCklNTywgdGhpcyBk cmFmdCBoaWdobGlnaHRzIG9uZSBvZiB0aGUgcmVhc29ucyB3aHkgYSBjZW50cmFsaXNlZCBkaXNj b3ZlcnkgbWVjaGFuaXNtIGlzIG1vcmUgc3VpdGFibGUgKGkuZS4gYSBzZXBhcmF0ZSBtZWNoYW5p c20gaXNuJ3QgcmVxdWlyZWQgdG8gbWFpbnRhaW4gaW5mb3JtYXRpb24gYWJvdXQgd2hpY2ggRUVz IGFyZSBvcGVyYXRpb25hbCkgdGhhbiBvbmUgaW4gd2hpY2ggZWFjaCBQRSBtYWludGFpbnMgaXRz IG93biBpbmRlcGVuZGVudCBFRSBtZW1iZXJzaGlwIGluZm9ybWF0aW9uIGRhdGFiYXNlLg0KIA0K UmljaGFyZA0K