From exim@www1.ietf.org Tue May 4 10:25:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04128 for ; Tue, 4 May 2004 10:25:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0pX-0002op-PI for l2vpn-archive@odin.ietf.org; Tue, 04 May 2004 10:23:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44ENVRH010836 for l2vpn-archive@odin.ietf.org; Tue, 4 May 2004 10:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0mh-0001zm-L1 for l2vpn-web-archive@optimus.ietf.org; Tue, 04 May 2004 10:20:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03952 for ; Tue, 4 May 2004 10:20:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0mf-0005GR-IR for l2vpn-web-archive@ietf.org; Tue, 04 May 2004 10:20:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0lg-0005DL-00 for l2vpn-web-archive@ietf.org; Tue, 04 May 2004 10:19:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL0kk-0005A4-00 for l2vpn-web-archive@ietf.org; Tue, 04 May 2004 10:18:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0fQ-00076q-6H; Tue, 04 May 2004 10:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL0dz-0006Qe-CG for l2vpn@optimus.ietf.org; Tue, 04 May 2004 10:11:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03144 for ; Tue, 4 May 2004 10:11:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL0dx-0004jT-6M for l2vpn@ietf.org; Tue, 04 May 2004 10:11:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL0d4-0004gN-00 for l2vpn@ietf.org; Tue, 04 May 2004 10:10:39 -0400 Received: from [62.90.130.2] (helo=ilmail1.atrica.com) by ietf-mx with esmtp (Exim 4.12) id 1BL0cK-0004dq-00 for l2vpn@ietf.org; Tue, 04 May 2004 10:09:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C431E1.75FAEABC" Subject: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Date: Tue, 4 May 2004 17:09:48 +0300 Message-ID: Thread-Topic: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Thread-Index: AcQx4XXxP+62gTp4QKGfMwzikAKWxg== From: "Dror Caspi" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C431E1.75FAEABC Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, =20 Having read section 11.3 on multi-domain VPLS service, I see a problem = with loop avoidance.=20 =20 To explain this, suppose we have 3 domains: A, B and C. In domain A, = border PE-rs named Ab connects to border PE-rs named Ba in domain B. = Likewise, we have PE-rs pairs Ac-Ca and Bc-Cb. =20 In the above example, it is easy to see that there is a potential loop. = What is not clear is how the split horizon forwarding rules in section 3 = avoid those loops. =20 Suppose border PE-rs Ab received a frame from PE-rs Ac. How would it = tell whether this frame originated in domain A (from one of the CEs = connected to Ac) or in domain C? =20 Or maybe I am mistaken and a border PE-rs is not allowed to serve CEs = directly? This is not stated in the draft. =20 Any comments are welcome =20 Dror =20 =20 =20 ------_=_NextPart_001_01C431E1.75FAEABC Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,=

 

Having = read section 11.3 on multi-domain VPLS service, I see a problem with loop avoidance. =

 

To = explain this, suppose we have 3 domains: A, B and C.   In domain A, border PE-rs named Ab connects to border PE-rs named = Ba in domain B.  Likewise, we = have PE-rs pairs Ac-Ca and Bc-Cb.

 

In the = above example, it is easy to see that there is a potential loop.  What is not clear is how the = split horizon forwarding rules in section 3 avoid those = loops.

 

Suppose = border PE-rs Ab received a frame from PE-rs Ac.  How would it tell whether this frame originated in domain A (from = one of the CEs connected to Ac) or in domain = C?

 

Or maybe = I am mistaken and a border PE-rs is not allowed to serve CEs directly?  This is not stated in the = draft.

 

Any = comments are welcome

 

Dror

 

 

 

------_=_NextPart_001_01C431E1.75FAEABC-- From exim@www1.ietf.org Tue May 4 11:55:05 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09778 for ; Tue, 4 May 2004 11:55:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2Eq-00020j-7i for l2vpn-archive@odin.ietf.org; Tue, 04 May 2004 11:53:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i44Fri8p007723 for l2vpn-archive@odin.ietf.org; Tue, 4 May 2004 11:53:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL2D2-0001ir-Ut for l2vpn-web-archive@optimus.ietf.org; Tue, 04 May 2004 11:51:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09574 for ; Tue, 4 May 2004 11:51:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL2D1-00052M-Px for l2vpn-web-archive@ietf.org; Tue, 04 May 2004 11:51:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL2C6-0004xa-00 for l2vpn-web-archive@ietf.org; Tue, 04 May 2004 11:50:55 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BL2Bj-0004sG-00 for l2vpn-web-archive@ietf.org; Tue, 04 May 2004 11:50:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL28L-0000NB-Cx; Tue, 04 May 2004 11:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BL23C-0007o7-5E for l2vpn@optimus.ietf.org; Tue, 04 May 2004 11:41:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09147 for ; Tue, 4 May 2004 11:41:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BL23A-0004KB-Tq for l2vpn@ietf.org; Tue, 04 May 2004 11:41:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BL22G-0004Ge-00 for l2vpn@ietf.org; Tue, 04 May 2004 11:40:45 -0400 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1BL21r-0004Cd-00 for l2vpn@ietf.org; Tue, 04 May 2004 11:40:19 -0400 Received: from MARCLL2K by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id IAA22885; Tue, 4 May 2004 08:39:44 -0700 (PDT) Message-ID: <012301c431ee$06aac990$6401a8c0@rs.riverstonenet.com> From: "Marc Lasserre" To: "Dror Caspi" , References: Subject: Re: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Date: Tue, 4 May 2004 17:39:43 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0120_01C431FE.C90B1F20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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.2 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0120_01C431FE.C90B1F20 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Dror, A full mesh of inter-domain spokes must be created between border = PE-rs's, not between domains as implied in your example. Hence, within each domain = one=20 border PE-rs is selected, and a full mesh of spokes is created per VPLS = instance between these PE-rs's. Note that different border PE-rs's can be used = for different=20 VPLS instances. Marc ----- Original Message -----=20 From: Dror Caspi=20 To: l2vpn@ietf.org=20 Sent: May 04, 2004 16:09 Subject: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Hi, =20 Having read section 11.3 on multi-domain VPLS service, I see a problem = with loop avoidance.=20 =20 To explain this, suppose we have 3 domains: A, B and C. In domain A, = border PE-rs named Ab connects to border PE-rs named Ba in domain B. = Likewise, we have PE-rs pairs Ac-Ca and Bc-Cb. =20 In the above example, it is easy to see that there is a potential = loop. What is not clear is how the split horizon forwarding rules in = section 3 avoid those loops. =20 Suppose border PE-rs Ab received a frame from PE-rs Ac. How would it = tell whether this frame originated in domain A (from one of the CEs = connected to Ac) or in domain C? =20 Or maybe I am mistaken and a border PE-rs is not allowed to serve CEs = directly? This is not stated in the draft. =20 Any comments are welcome =20 Dror =20 =20 =20 ------=_NextPart_000_0120_01C431FE.C90B1F20 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Dror,
 
A full mesh of inter-domain spokes must be created = between=20 border PE-rs's, not
between domains as implied in your example. Hence,=20 within each domain one =
border PE-rs is selected, and a full mesh of spokes is=20 created per VPLS instance
between these PE-rs's. Note = that different=20 border PE-rs's can be used for different =
VPLS instances.
 
Marc
----- Original Message -----
From:=20 Dror=20 Caspi
Sent: May 04, 2004 16:09
Subject: multi-domain VPLS = question=20 (draft-ietf-l2vpn-vpls-ldp-03)

Hi,

 

Having = read section=20 11.3 on multi-domain VPLS service, I see a problem with loop = avoidance.=20

 

To = explain this,=20 suppose we have 3 domains: A, B and C.   In domain A, border = PE-rs named=20 Ab connects to border PE-rs named Ba in domain B.  Likewise, we have PE-rs = pairs Ac-Ca=20 and Bc-Cb.

 

In the = above example,=20 it is easy to see that there is a potential loop.  What is not clear is how the = split=20 horizon forwarding rules in section 3 avoid those=20 loops.

 

Suppose = border PE-rs=20 Ab received a frame from PE-rs Ac. =20 How would it tell whether this frame originated in domain A = (from one=20 of the CEs connected to Ac) or in domain=20 C?

 

Or maybe = I am=20 mistaken and a border PE-rs is not allowed to serve CEs directly?  This is not stated in the=20 draft.

 

Any = comments are=20 welcome

 

Dror

 

 

 

<= /DIV>
------=_NextPart_000_0120_01C431FE.C90B1F20-- From exim@www1.ietf.org Wed May 5 05:33:58 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02578 for ; Wed, 5 May 2004 05:33:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIk0-0003wj-LZ for l2vpn-archive@odin.ietf.org; Wed, 05 May 2004 05:31:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i459V0eR015138 for l2vpn-archive@odin.ietf.org; Wed, 5 May 2004 05:31:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIZm-0001Yw-5H for l2vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 05:20:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01775 for ; Wed, 5 May 2004 05:20:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLIZi-0001YL-AD for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 05:20:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLIYn-0001MA-00 for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 05:19:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLIXv-0001Ar-00 for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 05:18:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIQf-0007Ia-Ra; Wed, 05 May 2004 05:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLILC-0005RC-K5 for l2vpn@optimus.ietf.org; Wed, 05 May 2004 05:05:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01174 for ; Wed, 5 May 2004 05:05:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLIL9-0006Qr-8z for l2vpn@ietf.org; Wed, 05 May 2004 05:05:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLIKA-0006Ej-00 for l2vpn@ietf.org; Wed, 05 May 2004 05:04:19 -0400 Received: from [62.90.130.2] (helo=ilmail1.atrica.com) by ietf-mx with esmtp (Exim 4.12) id 1BLIJA-0005te-00 for l2vpn@ietf.org; Wed, 05 May 2004 05:03:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4327F.CCDF89B6" Subject: RE: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Date: Wed, 5 May 2004 12:03:15 +0300 Message-ID: Thread-Topic: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Thread-Index: AcQx7rWK970zWTkrT2+zgu5XQE+AOAAkExpg From: "Dror Caspi" To: "Marc Lasserre" , 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.1 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4327F.CCDF89B6 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Thanks Marc. =20 To avoid confusion, section 11.3 should clearly state that there must be = one and only one border PE-rs per domain per VPLS instance. =20 Dror =20 -----Original Message----- From: Marc Lasserre [mailto:marc@riverstonenet.com] Sent: Tuesday, May 04, 2004 6:40 PM To: Dror Caspi; l2vpn@ietf.org Subject: Re: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) =20 Dror, =20 A full mesh of inter-domain spokes must be created between border = PE-rs's, not between domains as implied in your example. Hence, within each domain = one=20 border PE-rs is selected, and a full mesh of spokes is created per VPLS = instance between these PE-rs's. Note that different border PE-rs's can be used = for different=20 VPLS instances. =20 Marc ----- Original Message -----=20 From: Dror Caspi =20 To: l2vpn@ietf.org=20 Sent: May 04, 2004 16:09 Subject: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) =20 Hi, =20 Having read section 11.3 on multi-domain VPLS service, I see a problem = with loop avoidance.=20 =20 To explain this, suppose we have 3 domains: A, B and C. In domain A, = border PE-rs named Ab connects to border PE-rs named Ba in domain B. = Likewise, we have PE-rs pairs Ac-Ca and Bc-Cb. =20 In the above example, it is easy to see that there is a potential loop. = What is not clear is how the split horizon forwarding rules in section 3 = avoid those loops. =20 Suppose border PE-rs Ab received a frame from PE-rs Ac. How would it = tell whether this frame originated in domain A (from one of the CEs = connected to Ac) or in domain C? =20 Or maybe I am mistaken and a border PE-rs is not allowed to serve CEs = directly? This is not stated in the draft. =20 Any comments are welcome =20 Dror =20 =20 =20 ------_=_NextPart_001_01C4327F.CCDF89B6 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Thanks = Marc.

 

To avoid confusion, section = 11.3 should clearly state that there must be one and only one border PE-rs = per domain per VPLS instance.

 

Dror

 

-----Original Message-----
From: Marc Lasserre [mailto:marc@riverstonenet.com]
Sent: Tuesday, May 04, = 2004 6:40 PM
To: Dror Caspi; = l2vpn@ietf.org
Subject: Re: multi-domain = VPLS question (draft-ietf-l2vpn-vpls-ldp-03)

 

Dror,

 

A full mesh of inter-domain spokes = must be created between border PE-rs's, not

between domains as implied in your example. Hence, within each domain one
border PE-rs is selected, and a full mesh of spokes is created per = VPLS instance

between these PE-rs's. Note that different border PE-rs's can be used for different

VPLS instances.

 

Marc

----- Original = Message -----

From: Dror Caspi

=

To: l2vpn@ietf.org

Sent: May 04, 2004 16:09

Subject: multi-domain VPLS question = (draft-ietf-l2vpn-vpls-ldp-03)

 

Hi,

 

Having read section 11.3 on multi-domain VPLS service, I see a problem with loop avoidance. =

 

To explain this, suppose we have 3 domains: A, = B and C.   In domain A, = border PE-rs named Ab connects to border PE-rs named Ba in domain B.  Likewise, we have PE-rs pairs = Ac-Ca and Bc-Cb.

 

In the above example, it is easy to see that = there is a potential loop.  What is = not clear is how the split horizon forwarding rules in section 3 avoid those = loops.

 

Suppose border PE-rs Ab received a frame from = PE-rs Ac.  How would it tell = whether this frame originated in domain A (from one of the CEs connected to Ac) or in = domain C?

 

Or maybe I am mistaken and a border PE-rs is = not allowed to serve CEs directly?  This is not stated in the = draft.

 

Any comments are = welcome

 

Dror

 

 

 

------_=_NextPart_001_01C4327F.CCDF89B6-- From exim@www1.ietf.org Wed May 5 06:02:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03846 for ; Wed, 5 May 2004 06:02:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJCQ-0004hw-D9 for l2vpn-archive@odin.ietf.org; Wed, 05 May 2004 06:00:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45A0MUq018097 for l2vpn-archive@odin.ietf.org; Wed, 5 May 2004 06:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLJBj-0004N6-Kp for l2vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 05:59:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03457 for ; Wed, 5 May 2004 05:59:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLJBg-0001Zf-1N for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 05:59:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLJ7a-0000uB-00 for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 05:55:24 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BLJ5b-0000KC-01 for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 05:53:19 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BLIt2-0007Ea-2t for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 05:40:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIm1-0004uV-Pf; Wed, 05 May 2004 05:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLIee-0002zy-FY for l2vpn@optimus.ietf.org; Wed, 05 May 2004 05:25:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02033 for ; Wed, 5 May 2004 05:25:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLIeb-0002iM-0x for l2vpn@ietf.org; Wed, 05 May 2004 05:25:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLIcz-0002Hf-00 for l2vpn@ietf.org; Wed, 05 May 2004 05:23:48 -0400 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1BLIbQ-0001nU-00 for l2vpn@ietf.org; Wed, 05 May 2004 05:22:08 -0400 Received: from MARCLL2K by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA15224; Wed, 5 May 2004 02:21:29 -0700 (PDT) Message-ID: <01cd01c43282$59d9f4d0$6401a8c0@rs.riverstonenet.com> From: "Marc Lasserre" To: "Dror Caspi" , References: Subject: Re: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Date: Wed, 5 May 2004 11:21:28 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CA_01C43293.1C4FA720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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.2 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_01CA_01C43293.1C4FA720 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Dror, Thanks, I will clarify section 11.3 in the next rev. of the draft. Marc ----- Original Message -----=20 From: Dror Caspi=20 To: Marc Lasserre ; l2vpn@ietf.org=20 Sent: May 05, 2004 11:03 Subject: RE: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Thanks Marc. =20 To avoid confusion, section 11.3 should clearly state that there must = be one and only one border PE-rs per domain per VPLS instance. =20 Dror =20 -----Original Message----- From: Marc Lasserre [mailto:marc@riverstonenet.com] Sent: Tuesday, May 04, 2004 6:40 PM To: Dror Caspi; l2vpn@ietf.org Subject: Re: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) =20 Dror, =20 A full mesh of inter-domain spokes must be created between border = PE-rs's, not between domains as implied in your example. Hence, within each domain = one=20 border PE-rs is selected, and a full mesh of spokes is created per = VPLS instance between these PE-rs's. Note that different border PE-rs's can be used = for different=20 VPLS instances. =20 Marc ----- Original Message -----=20 From: Dror Caspi=20 To: l2vpn@ietf.org=20 Sent: May 04, 2004 16:09 Subject: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) =20 Hi, =20 Having read section 11.3 on multi-domain VPLS service, I see a problem = with loop avoidance.=20 =20 To explain this, suppose we have 3 domains: A, B and C. In domain A, = border PE-rs named Ab connects to border PE-rs named Ba in domain B. = Likewise, we have PE-rs pairs Ac-Ca and Bc-Cb. =20 In the above example, it is easy to see that there is a potential = loop. What is not clear is how the split horizon forwarding rules in = section 3 avoid those loops. =20 Suppose border PE-rs Ab received a frame from PE-rs Ac. How would it = tell whether this frame originated in domain A (from one of the CEs = connected to Ac) or in domain C? =20 Or maybe I am mistaken and a border PE-rs is not allowed to serve CEs = directly? This is not stated in the draft. =20 Any comments are welcome =20 Dror =20 =20 =20 ------=_NextPart_000_01CA_01C43293.1C4FA720 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Dror,
 
Thanks, I will clarify section 11.3 in the next rev. = of the=20 draft.
 
Marc
----- Original Message -----
From:=20 Dror=20 Caspi
To: Marc Lasserre ; l2vpn@ietf.org
Sent: May 05, 2004 11:03
Subject: RE: multi-domain VPLS = question=20 (draft-ietf-l2vpn-vpls-ldp-03)

Thanks=20 Marc.

 

To avoid = confusion,=20 section 11.3 should clearly state that there must be one and only one = border=20 PE-rs per domain per VPLS = instance.

 

Dror

 

-----Original=20 Message-----
From: = Marc=20 Lasserre [mailto:marc@riverstonenet.com]
Sent: Tuesday, May 04, 2004 = 6:40=20 PM
To: Dror Caspi; = l2vpn@ietf.org
Subject: Re: multi-domain VPLS = question=20 (draft-ietf-l2vpn-vpls-ldp-03)

 

Dror,

 

A full = mesh of=20 inter-domain spokes must be created between border PE-rs's,=20 not

between = domains as=20 implied in your example. Hence, within each domain one =
border PE-rs=20 is selected, and a full mesh of spokes is created per VPLS=20 instance

between = these=20 PE-rs's. Note that different border PE-rs's can be used for different=20

VPLS=20 instances.

 

Marc

----- = Original=20 Message -----

From: Dror Caspi=20

To: l2vpn@ietf.org=20

Sent: May 04, = 2004=20 16:09

Subject: = multi-domain VPLS=20 question (draft-ietf-l2vpn-vpls-ldp-03)

 

Hi,

 

Having read section 11.3 = on=20 multi-domain VPLS service, I see a problem with loop avoidance.=20

 

To explain this, suppose = we have 3=20 domains: A, B and C.   = In=20 domain A, border PE-rs named Ab connects to border PE-rs named Ba in = domain=20 B.  Likewise, we have = PE-rs pairs=20 Ac-Ca and Bc-Cb.

 

In the above example, it = is easy=20 to see that there is a potential loop. =20 What is not clear is how the split horizon forwarding rules in = section=20 3 avoid those loops.

 

Suppose border PE-rs Ab = received a=20 frame from PE-rs Ac.  = How would it=20 tell whether this frame originated in domain A (from one of the CEs = connected=20 to Ac) or in domain C?

 

Or maybe I am mistaken = and a=20 border PE-rs is not allowed to serve CEs directly?  This is not stated in the=20 draft.

 

Any comments are=20 welcome

 

Dror

 

 

 

------=_NextPart_000_01CA_01C43293.1C4FA720-- From exim@www1.ietf.org Wed May 5 11:23:29 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20547 for ; Wed, 5 May 2004 11:23:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLO4Y-0006qX-Pb for l2vpn-archive@odin.ietf.org; Wed, 05 May 2004 11:12:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45FCYQj026310 for l2vpn-archive@odin.ietf.org; Wed, 5 May 2004 11:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNwD-00014E-RQ for l2vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:03:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18724 for ; Wed, 5 May 2004 11:03:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNwB-0001Tm-AE for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 11:03:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNvQ-0001DA-00 for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 11:03:10 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLNuV-0000vL-00 for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 11:02:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNfu-0002Q3-Hy; Wed, 05 May 2004 10:47:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLNWr-0007c5-5w for l2vpn@optimus.ietf.org; Wed, 05 May 2004 10:37:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16707 for ; Wed, 5 May 2004 10:37:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLNWo-0001ss-P5 for l2vpn@ietf.org; Wed, 05 May 2004 10:37:42 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLNW0-0001dt-00 for l2vpn@ietf.org; Wed, 05 May 2004 10:36:54 -0400 Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx with esmtp (Exim 4.12) id 1BLNV5-00019Z-00 for l2vpn@ietf.org; Wed, 05 May 2004 10:35:55 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i45EZOl10968; Wed, 5 May 2004 07:35:24 -0700 (PDT) (envelope-from yakov@juniper.net) Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i45EZJJ13828; Wed, 5 May 2004 07:35:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200405051435.i45EZJJ13828@merlot.juniper.net> To: "Marc Lasserre" cc: "Dror Caspi" , l2vpn@ietf.org Subject: Re: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) In-Reply-To: Your message of "Tue, 04 May 2004 17:39:43 +0200." <012301c431ee$06aac990$6401a8c0@rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <90150.1083767719.1@juniper.net> Date: Wed, 05 May 2004 07:35:19 -0700 From: Yakov Rekhter 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.1 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Marc, > Dror, > > A full mesh of inter-domain spokes must be created between border = > PE-rs's, not between domains as implied in your example. Hence, within > each domain one border PE-rs is selected, and a full mesh of spokes > is created per VPLS instance between these PE-rs's. Couple of questions: 1. If a particular VPLS is present in 5 domains, and each domain elects a border PE-rs for that VPLS, does the above mean that these 5 PE-rs' have to have a full mesh of LDP sessions ? 2. What happens when the selected PE-rs crashes ? Yakov. > Note that different border PE-rs's can be used = > for different=20 > VPLS instances. > > Marc > ----- Original Message -----=20 > From: Dror Caspi=20 > To: l2vpn@ietf.org=20 > Sent: May 04, 2004 16:09 > Subject: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) > > > Hi, > > =20 > > Having read section 11.3 on multi-domain VPLS service, I see a problem = > with loop avoidance.=20 > > =20 > > To explain this, suppose we have 3 domains: A, B and C. In domain A, = > border PE-rs named Ab connects to border PE-rs named Ba in domain B. = > Likewise, we have PE-rs pairs Ac-Ca and Bc-Cb. > > =20 > > In the above example, it is easy to see that there is a potential = > loop. What is not clear is how the split horizon forwarding rules in = > section 3 avoid those loops. > > =20 > > Suppose border PE-rs Ab received a frame from PE-rs Ac. How would it = > tell whether this frame originated in domain A (from one of the CEs = > connected to Ac) or in domain C? > > =20 > > Or maybe I am mistaken and a border PE-rs is not allowed to serve CEs = > directly? This is not stated in the draft. > > =20 > > Any comments are welcome > > =20 > > Dror > > =20 > > =20 > > =20 > > ------=_NextPart_000_0120_01C431FE.C90B1F20 > Content-Type: text/html; > charset="windows-1255" > Content-Transfer-Encoding: quoted-printable > > > "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 > "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 > "urn:schemas-microsoft-com:office:word"> > charset=3Dwindows-1255"> > > > href=3D"cid:filelist.xml@01C431FA.9AF0E4C0" rel=3DFile-List> > > > >
Dror,
>
 
>
A full mesh of inter-domain spokes must be created = > between=20 > border PE-rs's, not
>
between domains as implied in your example. Hence,=20 > within each domain one = >
border  size=3D2>PE-rs is selected, and a full mesh of spokes size=3D2>is=20 > created per VPLS instance
>
between these PE-rs's. Note = > that different=20 > border PE-rs's can be used for different = >
>
VPLS instances.
>
 
>
Marc
>
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = > BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> >
----- Original Message -----
> style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = > black">From:=20 > href=3D"mailto:dror_caspi@atrica.com">Dror=20 > Caspi > >
Sent: May 04, 2004 16:09
>
Subject: multi-domain VPLS = > question=20 > (draft-ietf-l2vpn-vpls-ldp-03)
>

>
>

color=3Dblack=20 > size=3D2> style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = > Arial">Hi,

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 > size=3D2>Having = > read section=20 > 11.3 on multi-domain VPLS service, I see a problem with loop = > avoidance.=20 >

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 > size=3D2>To = > explain this,=20 suppose we have 3 domains: A, B and C. style=3D"mso-spacerun: yes">   In domain A, border = > PE-rs named=20 > Ab connects to border PE-rs named Ba in domain B. style=3D"mso-spacerun: yes">  Likewise, we have PE-rs = > pairs Ac-Ca=20 > and Bc-Cb.

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 > size=3D2>In the = > above example,=20 > it is easy to see that there is a potential loop. style=3D"mso-spacerun: yes">  What is not clear is how the = > split=20 > horizon forwarding rules in section 3 avoid those=20 > loops.

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 > size=3D2>Suppose = > border PE-rs=20 > Ab received a frame from PE-rs Ac. yes"> =20 > How would it tell whether this frame originated in domain A = > (from one=20 > of the CEs connected to Ac) or in domain=20 > C?

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 > size=3D2>Or maybe = > I am=20 > mistaken and a border PE-rs is not allowed to serve CEs directly? > style=3D"mso-spacerun: yes">  This is not stated in the=20 > draft.

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 size=3D2>Any = > comments are=20 > welcome

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 > size=3D2> style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = > Arial">Dror

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

>

color=3Dblack=20 > size=3D2> !supportEmptyParas]> 

<= > /DIV>
> > ------=_NextPart_000_0120_01C431FE.C90B1F20-- > > From exim@www1.ietf.org Wed May 5 12:23:32 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23401 for ; Wed, 5 May 2004 12:23:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOpl-0007lN-Uv for l2vpn-archive@odin.ietf.org; Wed, 05 May 2004 12:01:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i45G1Lu2029831 for l2vpn-archive@odin.ietf.org; Wed, 5 May 2004 12:01:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOga-0004lT-An for l2vpn-web-archive@optimus.ietf.org; Wed, 05 May 2004 11:51:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22255 for ; Wed, 5 May 2004 11:51:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLOgZ-0006cF-6d for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 11:51:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOff-0006Ll-00 for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 11:50:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLOeo-000667-00 for l2vpn-web-archive@ietf.org; Wed, 05 May 2004 11:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOX4-0001Wn-V0; Wed, 05 May 2004 11:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLOJB-0004PZ-0r for l2vpn@optimus.ietf.org; Wed, 05 May 2004 11:27:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20819 for ; Wed, 5 May 2004 11:27:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLOJA-0000JM-2f for l2vpn@ietf.org; Wed, 05 May 2004 11:27:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLOIC-00002O-00 for l2vpn@ietf.org; Wed, 05 May 2004 11:26:41 -0400 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1BLOHD-0007LF-00 for l2vpn@ietf.org; Wed, 05 May 2004 11:25:39 -0400 Received: from MARCLL2K by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id IAA24777; Wed, 5 May 2004 08:25:00 -0700 (PDT) Message-ID: <00fc01c432b5$21f94470$6401a8c0@rs.riverstonenet.com> From: "Marc Lasserre" To: "Yakov Rekhter" Cc: "Dror Caspi" , References: <200405051435.i45EZJJ13828@merlot.juniper.net> Subject: Re: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) Date: Wed, 5 May 2004 17:24:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Marc, > > > Dror, > > > > A full mesh of inter-domain spokes must be created between border = > > PE-rs's, not between domains as implied in your example. Hence, within > > each domain one border PE-rs is selected, and a full mesh of spokes > > is created per VPLS instance between these PE-rs's. > > Couple of questions: > > 1. If a particular VPLS is present in 5 domains, and each domain elects > a border PE-rs for that VPLS, does the above mean that these 5 PE-rs' > have to have a full mesh of LDP sessions ? Yes, it does. > > 2. What happens when the selected PE-rs crashes ? This would result in LDP adjacencies within the corresponding domain and between domains to be dropped, and hence would trigger an alarm indicating loss of connectivity for the corresponding VPLS instances. As I replied in a previous email, "A future draft could specify how redundant inter-domain connectivity is achieved (election of border PE, and protocol between PEs within one domain to indicate loss of connectivity)." Marc > > Yakov. > > > Note that different border PE-rs's can be used = > > for different=20 > > VPLS instances. > > > > Marc > > ----- Original Message -----=20 > > From: Dror Caspi=20 > > To: l2vpn@ietf.org=20 > > Sent: May 04, 2004 16:09 > > Subject: multi-domain VPLS question (draft-ietf-l2vpn-vpls-ldp-03) > > > > > > Hi, > > > > =20 > > > > Having read section 11.3 on multi-domain VPLS service, I see a problem = > > with loop avoidance.=20 > > > > =20 > > > > To explain this, suppose we have 3 domains: A, B and C. In domain A, = > > border PE-rs named Ab connects to border PE-rs named Ba in domain B. = > > Likewise, we have PE-rs pairs Ac-Ca and Bc-Cb. > > > > =20 > > > > In the above example, it is easy to see that there is a potential = > > loop. What is not clear is how the split horizon forwarding rules in = > > section 3 avoid those loops. > > > > =20 > > > > Suppose border PE-rs Ab received a frame from PE-rs Ac. How would it = > > tell whether this frame originated in domain A (from one of the CEs = > > connected to Ac) or in domain C? > > > > =20 > > > > Or maybe I am mistaken and a border PE-rs is not allowed to serve CEs = > > directly? This is not stated in the draft. > > > > =20 > > > > Any comments are welcome > > > > =20 > > > > Dror > > > > =20 > > > > =20 > > > > =20 > > > > ------=_NextPart_000_0120_01C431FE.C90B1F20 > > Content-Type: text/html; > > charset="windows-1255" > > Content-Transfer-Encoding: quoted-printable > > > > > > > "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 > > "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 > > "urn:schemas-microsoft-com:office:word"> > > > charset=3Dwindows-1255"> > > > > > > > href=3D"cid:filelist.xml@01C431FA.9AF0E4C0" rel=3DFile-List> > > > > > > > >
Dror,
> >
 
> >
A full mesh of inter-domain spokes must be created = > > between=20 > > border PE-rs's, not
> >
between domains as implied in your example. Hence,=20 > > within each domain one = > >
border  > size=3D2>PE-rs is selected, and a full mesh of spokes > size=3D2>is=20 > > created per VPLS instance
> >
between these PE-rs's. Note = > > that different=20 > > border PE-rs's can be used for different = > >
> >
VPLS instances.
> >
 
> >
Marc
> >
> style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = > > BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> > >
----- Original Message -----
> > > style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = > > black">From:=20 > > > href=3D"mailto:dror_caspi@atrica.com">Dror=20 > > Caspi > > > >
Sent: May 04, 2004 16:09
> >
Subject: multi-domain VPLS = > > question=20 > > (draft-ietf-l2vpn-vpls-ldp-03)
> >

> >
> >

> color=3Dblack=20 > > size=3D2> > style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = > > Arial">Hi,

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > > size=3D2>Having = > > read section=20 > > 11.3 on multi-domain VPLS service, I see a problem with loop = > > avoidance.=20 > >

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > > size=3D2>To = > > explain this,=20 > suppose we have 3 domains: A, B and C. > style=3D"mso-spacerun: yes">   In domain A, border = > > PE-rs named=20 > > Ab connects to border PE-rs named Ba in domain B. > style=3D"mso-spacerun: yes">  Likewise, we have PE-rs = > > pairs Ac-Ca=20 > > and Bc-Cb.

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > > size=3D2>In the = > > above example,=20 > > it is easy to see that there is a potential loop. > style=3D"mso-spacerun: yes">  What is not clear is how the = > > split=20 > > horizon forwarding rules in section 3 avoid those=20 > > loops.

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > > size=3D2>Suppose = > > border PE-rs=20 > > Ab received a frame from PE-rs Ac. > yes"> =20 > > How would it tell whether this frame originated in domain A = > > (from one=20 > > of the CEs connected to Ac) or in domain=20 > > C?

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > > size=3D2>Or maybe = > > I am=20 > > mistaken and a border PE-rs is not allowed to serve CEs directly? > > > style=3D"mso-spacerun: yes">  This is not stated in the=20 > > draft.

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > size=3D2>Any = > > comments are=20 > > welcome

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > > size=3D2> > style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = > > Arial">Dror

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

> >

> color=3Dblack=20 > > size=3D2> > !supportEmptyParas]> 

<= > > /DIV>
> > > > ------=_NextPart_000_0120_01C431FE.C90B1F20-- > > > > > From exim@www1.ietf.org Mon May 10 04:32:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17207 for ; Mon, 10 May 2004 04:32:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN68a-000843-45 for l2vpn-archive@odin.ietf.org; Mon, 10 May 2004 04:27:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4A8Rmkg031000 for l2vpn-archive@odin.ietf.org; Mon, 10 May 2004 04:27:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN62V-0006zE-V0 for l2vpn-web-archive@optimus.ietf.org; Mon, 10 May 2004 04:21:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16492 for ; Mon, 10 May 2004 04:21:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN62T-0005K7-7A for l2vpn-web-archive@ietf.org; Mon, 10 May 2004 04:21:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN61S-00052T-00 for l2vpn-web-archive@ietf.org; Mon, 10 May 2004 04:20:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BN60X-0004lA-00 for l2vpn-web-archive@ietf.org; Mon, 10 May 2004 04:19:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN5wE-0006DC-Up; Mon, 10 May 2004 04:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BN4gI-0006uO-T9 for l2vpn@optimus.ietf.org; Mon, 10 May 2004 02:54:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13544 for ; Mon, 10 May 2004 02:54:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BN4gF-0002tJ-0W for l2vpn@ietf.org; Mon, 10 May 2004 02:54:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BN4fF-0002bK-00 for l2vpn@ietf.org; Mon, 10 May 2004 02:53:26 -0400 Received: from av5-1-sn4.m-sp.skanova.net ([81.228.10.112]) by ietf-mx with esmtp (Exim 4.12) id 1BN4e7-00023M-00 for l2vpn@ietf.org; Mon, 10 May 2004 02:52:15 -0400 Received: by av5-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 0985D37E51; Mon, 10 May 2004 08:51:46 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av5-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id F0F2337E46 for ; Mon, 10 May 2004 08:51:45 +0200 (CEST) Received: from pi.se (h178n2fls307o1033.telia.com [81.226.61.178]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id D289937E4B for ; Mon, 10 May 2004 08:51:45 +0200 (CEST) Message-ID: <409F2676.5090600@pi.se> Date: Mon, 10 May 2004 08:51:34 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org Subject: MPLS2004 Conference CFP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The MPLS2004 Conference will be held in Washington DC, from October 17 to October 19, 2004. This year's conference will include, but will not be limited, to the following topics: - Network Consolidation and Service Convergence - Traffic engineering and QoS - MPLS network operation, administration, and maintenance - OSS Systems for MPLS-based networks - MPLS Multicast - Service Provisioning - MPLS in multi-AS networks - L2VPNs (pseudo-wire emulation, VPWS, VPLS, and others) - L3VPNs (BGP/MPLS, IPSec interworking, virtual routers, and others) - Voice, video, and real-time services over MPLS networks - Scalability and performance of MPLS protocols and networks - Network processor architectures for next generation MPLS networks - MPLS certification, verification, and conformance testing - MPLS network security - MPLS reliability and survivability (fast reroute, graceful restart, and restoration techniques) - IP Optical Integration - Multilayer control, management, and optimization - MPLS deployment case studies: Service Provider operational experience The Program Committee for MPLS2004 is soliciting presentation proposals for this conference. If you wish to propose a particular topic for consideration, please send a one page summary, including speaker's name, affiliation, and contact information to the Technical Program Committee at: MPLS2004-CFP@isocore.com All proposals must be received by June 18, 2004. See http://www.mpls2004.com for more details. The program committee is looking for original and unpublished work to continue the tradition of addressing cutting-edge topics that was initiated by this conference in 1998. Presentations from the vendor, service provider, research, and user communities covering technology evolution and operational experience are solicited. -- Loa Andersson mobile +46 739 81 21 64 From exim@www1.ietf.org Mon May 10 18:44:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13612 for ; Mon, 10 May 2004 18:44:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJPq-0006XN-Vv for l2vpn-archive@odin.ietf.org; Mon, 10 May 2004 18:38:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4AMcUgd025121 for l2vpn-archive@odin.ietf.org; Mon, 10 May 2004 18:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJC8-0003Ca-6l for l2vpn-web-archive@optimus.ietf.org; Mon, 10 May 2004 18:24:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12156 for ; Mon, 10 May 2004 18:24:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNJC5-0002MB-CB for l2vpn-web-archive@ietf.org; Mon, 10 May 2004 18:24:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNJBA-0001yx-00 for l2vpn-web-archive@ietf.org; Mon, 10 May 2004 18:23:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNJAI-0001dJ-00 for l2vpn-web-archive@ietf.org; Mon, 10 May 2004 18:22:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNJ37-0006uk-76; Mon, 10 May 2004 18:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNEXO-0001Yn-CO for l2vpn@optimus.ietf.org; Mon, 10 May 2004 13:25:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18486 for ; Mon, 10 May 2004 13:25:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNEXM-0005ic-13 for l2vpn@ietf.org; Mon, 10 May 2004 13:25:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNEWQ-0005On-00 for l2vpn@ietf.org; Mon, 10 May 2004 13:24:58 -0400 Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx with esmtp (Exim 4.12) id 1BNEVk-0004nT-00 for l2vpn@ietf.org; Mon, 10 May 2004 13:24:16 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Questions on LDP Date: Mon, 10 May 2004 20:25:26 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A52848775D@wombat.seabridge.co.il> Thread-Topic: Questions on LDP Thread-Index: AcQ2u+NMD7zmlClzQ1mG1f4b17zsGAAADpbg From: "Nurit Sprecher" To: Cc: "Nurit Sprecher" 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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I have some questions on LDP for establishing Tunnel-LSPs, as follows: 1. What is the common distribution mode in LDP: DoD or DU? 2. Is that true that in order to use DU in order distribution mode, the = LSRs should be merging capable? Otherwise, what is a trigger for a P = router to issue a more than label-mapping message for each neighbor? 3. When DU and conservative retention mode are supported, a downstream = node should periodically re-advertise the label binding for a re-routing = case. Is that true? 4. Is LDP a popular method for establishing Tunnel-LSPs? Thanks, Nurit. From exim@www1.ietf.org Tue May 11 01:03:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01757 for ; Tue, 11 May 2004 01:03:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNPLj-00078S-Up for l2vpn-archive@odin.ietf.org; Tue, 11 May 2004 00:58:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4B4wdi2027428 for l2vpn-archive@odin.ietf.org; Tue, 11 May 2004 00:58:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNPAu-0005HQ-MB for l2vpn-web-archive@optimus.ietf.org; Tue, 11 May 2004 00:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01174 for ; Tue, 11 May 2004 00:47:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNPAs-00038S-2F for l2vpn-web-archive@ietf.org; Tue, 11 May 2004 00:47:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNP9t-0002mg-00 for l2vpn-web-archive@ietf.org; Tue, 11 May 2004 00:46:25 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNP8x-0002RV-00 for l2vpn-web-archive@ietf.org; Tue, 11 May 2004 00:45:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNP4j-0003yw-By; Tue, 11 May 2004 00:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNP1E-0003Cv-5c for l2vpn@optimus.ietf.org; Tue, 11 May 2004 00:37:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00871 for ; Tue, 11 May 2004 00:37:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNP1B-0007Nn-JH for l2vpn@ietf.org; Tue, 11 May 2004 00:37:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNP0H-000732-00 for l2vpn@ietf.org; Tue, 11 May 2004 00:36:29 -0400 Received: from [212.25.127.226] (helo=wombat.seabridge.co.il) by ietf-mx with esmtp (Exim 4.12) id 1BNOzf-0006fM-00 for l2vpn@ietf.org; Tue, 11 May 2004 00:35:51 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Questions on LDP Date: Tue, 11 May 2004 07:37:03 +0200 Message-ID: <6FAB860EC6AE3C4EB327204DEC33A528487765@wombat.seabridge.co.il> Thread-Topic: Questions on LDP Thread-Index: AcQ2u+NMD7zmlClzQ1mG1f4b17zsGAAADpbg From: "Nurit Sprecher" To: Cc: "Nurit Sprecher" 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I have some questions on LDP for establishing Tunnel-LSPs, as follows: 1. What is the common distribution mode in LDP: DoD or DU? 2. Is that true that in order to use DU in order distribution mode, the = LSRs should be merging capable? Otherwise, what is a trigger for a P = router to issue a more than label-mapping message for each neighbor? 3. When DU and conservative retention mode are supported, a downstream = node should periodically re-advertise the label binding for a re-routing = case. Is that true? 4. Is LDP a popular method for establishing Tunnel-LSPs? Thanks, Nurit. From exim@www1.ietf.org Wed May 12 13:08:01 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27192 for ; Wed, 12 May 2004 13:08:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNxAh-0003SM-DB for l2vpn-archive@odin.ietf.org; Wed, 12 May 2004 13:05:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CH5VFF013287 for l2vpn-archive@odin.ietf.org; Wed, 12 May 2004 13:05:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNx33-0008Rk-38 for l2vpn-web-archive@optimus.ietf.org; Wed, 12 May 2004 12:57:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26284 for ; Wed, 12 May 2004 12:57:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNx31-0002v2-Bl for l2vpn-web-archive@ietf.org; Wed, 12 May 2004 12:57:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNx1y-0002OB-00 for l2vpn-web-archive@ietf.org; Wed, 12 May 2004 12:56:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNx0p-0001a6-00 for l2vpn-web-archive@ietf.org; Wed, 12 May 2004 12:55:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwov-0004Se-0a; Wed, 12 May 2004 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNwcf-0007dI-HY for l2vpn@optimus.ietf.org; Wed, 12 May 2004 12:30:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23616 for ; Wed, 12 May 2004 12:30:18 -0400 (EDT) From: Moshe.Aharon@ecitele.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNwce-00059G-0g for l2vpn@ietf.org; Wed, 12 May 2004 12:30:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNwbH-0004X1-00 for l2vpn@ietf.org; Wed, 12 May 2004 12:28:56 -0400 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx with esmtp (Exim 4.12) id 1BNwaT-00040L-00 for l2vpn@ietf.org; Wed, 12 May 2004 12:28:05 -0400 Subject: Re: Questions on LDP To: "Nurit Sprecher" Cc: l2vpn@ietf.org X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Wed, 12 May 2004 19:27:56 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5|September 18, 2003) at 05/12/2004 19:30:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII 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.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 "Nurit Sprecher" tworks.com> cc: "Nurit Sprecher" Sent by: Subject: Questions on LDP l2vpn-admin@ietf.org 10/05/2004 21:25 Hi Nurit, Please find some (I'm still thinking about number Question 2 ;-)) answers in-line. Hope this helps. Regards, /Moshe >> Hi, >> I have some questions on LDP for establishing Tunnel-LSPs, as follows: >> 1. What is the common distribution mode in LDP: DoD or DU? See ftp://ftp.rfc-editor.org/in-notes/rfc3037.txt (LDP Applicability) for discussion on this issue. IMHO DoD is used more (it saves memory, and is more conservative/secure), but there are scenarios suited for each method. >> 2. Is that true that in order to use DU in order distribution mode, the LSRs should be merging capable? >> Otherwise, what is a trigger for a P router to issue a more than label-mapping message for each neighbor? >> 3. When DU and conservative retention mode are supported, a downstream node should periodically re-advertise the >> label binding for a re-routing case. Is that true? I quote from RFC3036 (wrt the combination of Downstream Unsolicited mode and conservative label retention clause 3.5.7.1.4.): "In situations where Ru [upstream LSR] may not know that it needs the label, Rd [downstream LSR] is responsible for periodically readvertising the label to Ru. For this version of LDP, the only situation where Ru knows it needs a label for a FEC from Rd is when Rd is its next hop for the FEC, Ru does not have a label from Rd, and the LSP for the FEC is one that can be established with TLVs defined in this document." So I guess the answer is yes. >> 4. Is LDP a popular method for establishing Tunnel-LSPs? RSVP is clearly the more popular method for establishing Tunnel-LSPs. Moreover, RSVP-TE is the only one currently supporting explicit routes (CR-LDP is dead-meat see RFC3468), so whenever TE is required, RSVP-TE is there. Of course that means you have to support both RSVP-TE and LDP for a TE capable VPLS... (search l2vpn list's archive for my question on the need for both LDP and RSVP-TE). >> Thanks, >> Nurit From exim@www1.ietf.org Wed May 12 15:43:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06366 for ; Wed, 12 May 2004 15:43:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzXj-0003QZ-2t for l2vpn-archive@odin.ietf.org; Wed, 12 May 2004 15:37:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4CJbR1k013176 for l2vpn-archive@odin.ietf.org; Wed, 12 May 2004 15:37:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzLR-0007gt-1k for l2vpn-web-archive@optimus.ietf.org; Wed, 12 May 2004 15:24:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05159 for ; Wed, 12 May 2004 15:24:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNzLP-0007Ut-QD for l2vpn-web-archive@ietf.org; Wed, 12 May 2004 15:24:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNzKP-0006zC-00 for l2vpn-web-archive@ietf.org; Wed, 12 May 2004 15:23:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNzJU-0006Tu-00 for l2vpn-web-archive@ietf.org; Wed, 12 May 2004 15:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNzFu-0005CL-Hf; Wed, 12 May 2004 15:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNyxM-0008Jw-UN for l2vpn@optimus.ietf.org; Wed, 12 May 2004 14:59:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03121 for ; Wed, 12 May 2004 14:59:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNyxK-0002si-0o for l2vpn@ietf.org; Wed, 12 May 2004 14:59:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNywU-0002Nl-00 for l2vpn@ietf.org; Wed, 12 May 2004 14:58:59 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BNyvW-0001Zw-00 for l2vpn@ietf.org; Wed, 12 May 2004 14:57:58 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i4CIvSPg082237; Wed, 12 May 2004 11:57:28 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i4CIvQ5r082234; Wed, 12 May 2004 11:57:28 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Wed, 12 May 2004 11:57:26 -0700 (PDT) From: Kireeti Kompella To: Nurit Sprecher cc: l2vpn@ietf.org Subject: Re: Questions on LDP In-Reply-To: <6FAB860EC6AE3C4EB327204DEC33A52848775D@wombat.seabridge.co.il> Message-ID: <20040512112923.F81290@kummer.juniper.net> References: <6FAB860EC6AE3C4EB327204DEC33A52848775D@wombat.seabridge.co.il> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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=AWL autolearn=no version=2.60 Hi Nurit, On Mon, 10 May 2004, Nurit Sprecher wrote: > I have some questions on LDP for establishing Tunnel-LSPs, as follows: > 1. What is the common distribution mode in LDP: DoD or DU? DU for packet-based MPLS, DoD for cell-based MPLS. > 2. Is that true that in order to use DU in order distribution mode, > the LSRs should be merging capable? Yes. > 3. When DU and conservative retention mode are supported, a > downstream node should periodically re-advertise the label binding > for a re-routing case. Is that true? I'm not sure I get your question. > 4. Is LDP a popular method for establishing Tunnel-LSPs? Quite so. [These questions really belong in the MPLS mailing list, not here.] Kireeti. ------- From exim@www1.ietf.org Tue May 18 21:52:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04837 for ; Tue, 18 May 2004 21:52:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQGEC-0006na-W6 for l2vpn-archive@odin.ietf.org; Tue, 18 May 2004 21:50:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J1oefn026129 for l2vpn-archive@odin.ietf.org; Tue, 18 May 2004 21:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQGBy-0005oZ-DQ for l2vpn-web-archive@optimus.ietf.org; Tue, 18 May 2004 21:48:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04499 for ; Tue, 18 May 2004 21:48:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQGBv-00028N-Ex for l2vpn-web-archive@ietf.org; Tue, 18 May 2004 21:48:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQGB1-000227-00 for l2vpn-web-archive@ietf.org; Tue, 18 May 2004 21:47:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQGAJ-0001vN-00 for l2vpn-web-archive@ietf.org; Tue, 18 May 2004 21:46:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQG5r-0004Ww-Fp; Tue, 18 May 2004 21:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQFom-0001SJ-Vn for l2vpn@optimus.ietf.org; Tue, 18 May 2004 21:24:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03358 for ; Tue, 18 May 2004 21:24:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQFok-0007nK-Ab for l2vpn@ietf.org; Tue, 18 May 2004 21:24:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQFnp-0007ic-00 for l2vpn@ietf.org; Tue, 18 May 2004 21:23:26 -0400 Received: from natint2.juniper.net ([207.17.136.150] helo=kummer.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 1BQFn6-0007ZL-00 for l2vpn@ietf.org; Tue, 18 May 2004 21:22:40 -0400 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id i4J1MBPg015125 for ; Tue, 18 May 2004 18:22:11 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id i4J1MBUu015122 for ; Tue, 18 May 2004 18:22:11 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 18 May 2004 18:22:10 -0700 (PDT) From: Kireeti Kompella To: l2vpn@ietf.org Subject: Re: I-D ACTION:draft-ietf-l2vpn-vpls-bgp-02.txt In-Reply-To: <200405181937.PAA09578@ietf.org> Message-ID: <20040518181925.I12921@kummer.juniper.net> References: <200405181937.PAA09578@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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=AWL autolearn=no version=2.60 On Tue, 18 May 2004 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. > > Title : Virtual Private LAN Service > Author(s) : K. Kompella, Y. Rekhter > Filename : draft-ietf-l2vpn-vpls-bgp-02.txt > Pages : 19 > Date : 2004-5-18 This version incorporates most of the comments received during Last Call. The main issue still not addressed is the splitting out of the data plane piece, as there weren't a lot of folks clamouring for it. I'll leave it to the chairs and ADs to decide where to go with that. Kireeti. -------