From l2vpn-bounces@ietf.org Mon Jan 02 03:17:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKsU-0002TF-Nn; Mon, 02 Jan 2006 03:17:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtKsR-0002ST-0Q for l2vpn@megatron.ietf.org; Mon, 02 Jan 2006 03:17:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01128 for ; Mon, 2 Jan 2006 03:15:57 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtKxS-0007mi-NZ for l2vpn@ietf.org; Mon, 02 Jan 2006 03:22:23 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id AAA09043; Mon, 2 Jan 2006 00:16:39 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60F74.DCB2A6DE" Date: Mon, 2 Jan 2006 13:46:41 +0530 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0A From: "Dutta, Pranjal" To: "Shah, Himanshu" , X-Spam-Score: 3.3 (+++) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C60F74.DCB2A6DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, Please see my answers inline =20 Thanks, Pranjal=20 =20 ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal =20 =20 Hope somebody can shed light on the following questions....=20 (1)=20 There are two mechanisms described -=20 MAC address withdraw List TLV and empty MAC Address withdraw List TLV=20 cut-and-paste from draft.=20 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV.=20 To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC=20 addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending=20 a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending=20 explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were=20 associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove=20 none. However, the draft says,=20 In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list.=20 [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. (2)=20 Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)?=20 If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to=20 be described.=20 =20 [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs=20 to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think=20 that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. regards,=20 himanshu=20 Himanshu Shah=20 Ciena Corp=20 ------_=_NextPart_001_01C60F74.DCB2A6DE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable VPLS question on MAC address withdrawal

Hi = Himanshu,

      =             &= nbsp;   Please see my answers inline

 

Thanks,

=

Pranjal =

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu
Sent: Friday, 30 = December, 2005 2:49 AM
To: l2vpn@ietf.org
Subject: VPLS question on = MAC address withdrawal

 

 

Hope somebody can shed light on the following = questions....

(1)
There are two mechanisms described -
MAC address withdraw List TLV and empty MAC Address = withdraw List TLV

cut-and-paste from draft.

6.2.2. Address Withdraw Message Containing MAC List = TLV
  
  The processing for MAC List TLV received in an Address = Withdraw
  Message is:
  
  For each MAC address in the TLV:
     - Remove the association between the MAC = address and the AC or
        PW over which this message is received
  
  For a MAC Address Withdraw message with empty list:
     - Remove all the MAC addresses associated with = the VPLS
        instance  (specified by = the FEC TLV) except the MAC addresses
        learned over the PW = associated with this signaling session
        over which the message was = received
  
  The scope of a MAC List TLV is the VPLS specified in the FEC TLV = in
  the MAC Address Withdraw Message.  The number of MAC = addresses can
  be deduced from the length field in the TLV. =

To simplify the problem, lets assume that for a given = VPLS instance A there are only 5 MAC
addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending
a list of 5 MAC address vs sending an empty list = achieves opposite result. That is, sending
explicit list will cause the receiver to remove all 5 = addresses (lets assume that they all were
associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove
none.  However, the draft says, =

In order to minimize the impact on LDP convergence time, = when the
  MAC list TLV contains a large number of MAC addresses, it may = be
  preferable to send a MAC address withdrawal message with an = empty
  list.

[Pranjal]: What the draft means is that = with empty-list in MAC withdraw TLV means remove “ALL” = MACs.

      &nbs= p;       The processing entity of MAC List TLV (in Address Withdraw Msg) needs to = flush all MACs associated with a VPLS instance when it receives MAC list = TLV

      &nbs= p;         without any MAC address(s) in the list (empty list). In case, of the MAC = List TLV that contains specific MAC addresses then the = receiving

      &nbs= p;         entity needs to remove only those MAC addresses in the list associated = with VPLS instance (identifies by FEC in the address withdraw msg). The = withdrawl with empty list

      &nbs= p;         feature is to make it more scalable. For example, a VPLS instance that = has 1000 MACs learned at a PE need not send

      &nbs= p;         Address withdraw with 1000 MACs list, can send empty list instead. But = again it is optional (means if the MAC withdraw originating PE = wants

      &nbs= p;        It can send Address Withdraw with 1000 MACs list) and implementation = specific. Let’s say for a dual homed MTU in HVPLS, the primary link has 100 = PWs

      &nbs= p;         (1 for each VPLS instance) and the secondary link has the backup = of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back = to the secondary and MTU

      &nbs= p;        needs to send Address Withdraw with MACList TLV, one for each of the 100 = PWs. So, empty list would be preferable for each = message.

(2)
Is MAC-Address-withdraw mechanism ever intended to be = used for U-PW (user facing PW, MTU-S<->PErs)?
If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to
be described.

 

[Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be = processed and forwarded by PE-rs

to other PEs. The draft hasn’t = specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS = (in PErs->MTU direction). I think

that part is implementation specific. = The reason could be the distant end MTUs will still be receiving the traffic = in the primary link and MAC withdrawl may not be = necessary.

regards,
himanshu

Himanshu Shah
Ciena Corp

------_=_NextPart_001_01C60F74.DCB2A6DE-- From l2vpn-bounces@ietf.org Mon Jan 02 10:20:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRTe-0005zC-HC; Mon, 02 Jan 2006 10:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtRTc-0005xH-IR for l2vpn@megatron.ietf.org; Mon, 02 Jan 2006 10:20:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09614 for ; Mon, 2 Jan 2006 10:18:45 -0500 (EST) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtRYg-0003NK-Gh for l2vpn@ietf.org; Mon, 02 Jan 2006 10:25:15 -0500 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jan 2006 10:19:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C60FAF.F4842140" Date: Mon, 2 Jan 2006 10:19:42 -0500 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VE= References: From: "Shah, Himanshu" To: "Dutta, Pranjal" , X-OriginalArrivalTime: 02 Jan 2006 15:19:42.0193 (UTC) FILETIME=[F4796E10:01C60FAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C60FAF.F4842140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pranjal, It seems easy to get confused that=20 mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received.=20 In MAC address TLV list with no MAC addresses,=20 the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. regards, himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Himanshu, Please see my answers inline =20 Thanks, Pranjal=20 =20 ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal =20 =20 Hope somebody can shed light on the following questions....=20 (1)=20 There are two mechanisms described -=20 MAC address withdraw List TLV and empty MAC Address withdraw List TLV=20 cut-and-paste from draft.=20 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV.=20 To simplify the problem, lets assume that for a given VPLS instance A = there are only 5 MAC=20 addresses and one PW. In this case, for TCN-Triggererd = MAC-address-withdrawal, sending=20 a list of 5 MAC address vs sending an empty list achieves opposite = result. That is, sending=20 explicit list will cause the receiver to remove all 5 addresses (lets = assume that they all were=20 associated with sender). But by sending, empty MAC-address-withdrawal = list, it will remove=20 none. However, the draft says,=20 In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list.=20 [Pranjal]: What the draft means is that with empty-list in MAC withdraw = TLV means remove "ALL" MACs. The processing entity of MAC List TLV (in Address Withdraw = Msg) needs to flush all MACs associated with a VPLS instance when it = receives MAC list TLV without any MAC address(s) in the list (empty list). In = case, of the MAC List TLV that contains specific MAC addresses then the = receiving entity needs to remove only those MAC addresses in the = list associated with VPLS instance (identifies by FEC in the address = withdraw msg). The withdrawl with empty list feature is to make it more scalable. For example, a VPLS = instance that has 1000 MACs learned at a PE need not send Address withdraw with 1000 MACs list, can send empty = list instead. But again it is optional (means if the MAC withdraw = originating PE wants It can send Address Withdraw with 1000 MACs list) and = implementation specific. Let's say for a dual homed MTU in HVPLS, the = primary link has 100 PWs (1 for each VPLS instance) and the secondary link has = the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all = will switch back to the secondary and MTU needs to send Address Withdraw with MACList TLV, one for = each of the 100 PWs. So, empty list would be preferable for each = message. (2)=20 Is MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user facing PW, MTU-S<->PErs)?=20 If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc needs to=20 be described.=20 =20 [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in = MTU-PErs direction) needs to be processed and forwarded by PE-rs=20 to other PEs. The draft hasn't specified about propagating MAC withdraw = by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I = think=20 that part is implementation specific. The reason could be the distant = end MTUs will still be receiving the traffic in the primary link and MAC = withdrawl may not be necessary. regards,=20 himanshu=20 Himanshu Shah=20 Ciena Corp=20 ------_=_NextPart_001_01C60FAF.F4842140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: VPLS question on MAC address withdrawal

Hi Pranjal,

It seems easy to get confused that
mac address withdraw list TLV and empty mac address
withdraw list TLV are one and the same and can be used
interchangeably for scalability. But that is
clearly not true.

In MAC address withdraw list TLV with MAC addresses, receiver
removes the association between MAC addresses in
the list and PW over which the signal is received.

In MAC address TLV list with no MAC addresses,
the receiver removes the association between all MAC addresses
EXCEPT the ones over which he receives this signal.

In the second part of the question, empty MAC address
withdraw List TLV receieved by secondary which now is primary
PE-rs also has some issues. Broadcasting the empty MAC
address withdraw List TLV to all other PE-rs would create
broadcasts in the core, as it removes MAC addresses
learned from ALL N-PWs EXCEPT for ones learned on the
PW over which the signal was received.  This needs to be
carefully thought out too.

regards,
himanshu

-----Original Message-----
From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<= /A>]
Sent: Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; l2vpn@ietf.org
Subject: RE: VPLS question on MAC address withdrawal

Hi Himanshu,

            &= nbsp;         Please see my = answers inline



Thanks,

Pranjal



________________________________

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= On Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 2:49 AM
To: l2vpn@ietf.org
Subject: VPLS question on MAC address withdrawal





Hope somebody can shed light on the following questions....

(1)
There are two mechanisms described -
MAC address withdraw List TLV and empty MAC Address withdraw List = TLV

cut-and-paste from draft.

6.2.2. Address Withdraw Message Containing MAC List TLV
 
  The processing for MAC List TLV received in an Address = Withdraw
  Message is:
 
  For each MAC address in the TLV:
     - Remove the association between the MAC = address and the AC or
        PW over which this message is = received
 
  For a MAC Address Withdraw message with empty list:
     - Remove all the MAC addresses associated with = the VPLS
        instance  (specified by = the FEC TLV) except the MAC addresses
        learned over the PW = associated with this signaling session
        over which the message was = received
 
  The scope of a MAC List TLV is the VPLS specified in the FEC TLV = in
  the MAC Address Withdraw Message.  The number of MAC = addresses can
  be deduced from the length field in the TLV.

To simplify the problem, lets assume that for a given VPLS instance A = there are only 5 MAC
addresses and one PW. In this case, for TCN-Triggererd = MAC-address-withdrawal, sending
a list of 5 MAC address vs sending an empty list achieves opposite = result. That is, sending
explicit list will cause the receiver to remove all 5 addresses (lets = assume that they all were
associated with sender). But by sending, empty MAC-address-withdrawal = list, it will remove
none.  However, the draft says,

In order to minimize the impact on LDP convergence time, when the
  MAC list TLV contains a large number of MAC addresses, it may = be
  preferable to send a MAC address withdrawal message with an = empty
  list.

[Pranjal]: What the draft means is that with empty-list in MAC withdraw = TLV means remove "ALL" MACs.

            &= nbsp; The processing entity of MAC List TLV (in Address Withdraw Msg) = needs to flush all MACs associated with a VPLS instance when it receives = MAC list TLV

            &= nbsp;   without any MAC address(s) in the list (empty list). = In case, of the MAC List TLV that contains specific MAC addresses then = the receiving

            &= nbsp;   entity needs to remove only those MAC addresses in the = list associated with VPLS instance (identifies by FEC in the address = withdraw msg). The withdrawl with empty list

            &= nbsp;   feature is to make it more scalable. For example, a = VPLS instance that has 1000 MACs learned at a PE need not send

            &= nbsp;   Address withdraw with 1000 MACs list, can send empty = list instead. But again it is optional (means if the MAC withdraw = originating PE wants

            &= nbsp;  It can send Address Withdraw with 1000 MACs list) and = implementation specific. Let's say for a dual homed MTU in HVPLS, the = primary link has 100 PWs

            &= nbsp;   (1 for each VPLS instance) and the secondary link has = the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all = will switch back to the secondary and MTU

            &= nbsp;  needs to send Address Withdraw with MACList TLV, one for = each of the 100 PWs. So, empty list would be preferable for each = message.

(2)
Is MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user facing PW, MTU-S<->PErs)?
If so, how, when, implication of withdraw msg from N-PW (PE<->PE) = to U-PW, etc needs to
be described.



[Pranjal]: The draft says that the MAC withdraw originated at a MTU (in = MTU-PErs direction) needs to be processed and forwarded by PE-rs

to other PEs. The draft hasn't specified about propagating MAC withdraw = by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I = think

that part is implementation specific. The reason could be the distant = end MTUs will still be receiving the traffic in the primary link and MAC = withdrawl may not be necessary.

regards,
himanshu

Himanshu Shah
Ciena Corp

------_=_NextPart_001_01C60FAF.F4842140-- From l2vpn-bounces@ietf.org Tue Jan 03 03:23:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EthSU-0002S8-Rl; Tue, 03 Jan 2006 03:23:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EthSS-0002S3-UX for l2vpn@megatron.ietf.org; Tue, 03 Jan 2006 03:23:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18486 for ; Tue, 3 Jan 2006 03:22:39 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EthXg-0000zs-Kg for l2vpn@ietf.org; Tue, 03 Jan 2006 03:29:17 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id AAA21494; Tue, 3 Jan 2006 00:22:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6103E.EA4D2C01" Date: Tue, 3 Jan 2006 13:53:09 +0530 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoA== From: "Dutta, Pranjal" To: "Shah, Himanshu" , X-Spam-Score: 3.8 (+++) X-Scan-Signature: 3f4d1621eb481886fab661da14b05487 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6103E.EA4D2C01 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, Reg. the first part again excerpts from the draft as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only. =20 The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific. =20 =20 =20 Regards, Pranjal ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. regards, himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Please see my answers inline Thanks, Pranjal ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal Hope somebody can shed light on the following questions.... (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV cut-and-paste from draft. 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove none. However, the draft says, In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to be described. [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. regards, himanshu Himanshu Shah Ciena Corp ------_=_NextPart_001_01C6103E.EA4D2C01 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: VPLS question on MAC address withdrawal

Hi = Himanshu,

      =             &= nbsp;  Reg. the first part again excerpts from the draft as = below

 = 

For a MAC Address Withdraw message with empty =
list: 
     - Remove all =
the MAC addresses associated with the VPLS =

       inst=
ance(specified by the FEC TLV) except the MAC addresses =

       lear=
ned over the PW associated with this signaling session =

       over=
 which the message was received =

   
  The scope of a MAC List TLV is =
the VPLS specified in the FEC TLV in =

  the MAC Address Withdraw =
Message.  The number of MAC addresses can =




  be deduced from the length field in =
the TLV



 =




 =




 In the first part as per my
understanding goes, empty MAC list TLV means delete the association =
between all
MAC addresses associated with the VPLS =
instance



specified in by the FEC TLV within =
the
address withdraw message. This will not delete the association of MACs =
with the
PW on which the Address Withdraw message with empty MAC list is =
received.



So as specified in draft the scope =
is
limited to the FEC specified only. 



 



The second issue you raised is very
interesting and has practical implications. After PW switchover when, =
MTU
originates the Address Withdraw for all N PWs (one msg. for each PW). =
Those will
be forwarded by the “new” PE-rs to all peers thoughout the =
domain. Removal
of all MACs would cause spark of broadcast and considering the traffic =
for all N
FECs are flowing now via secondary PW, so associated MACs will get =
relearned
again across all the PEs. So broadcast will stop once relearning =
completes. In
the absence of MAC withdraw, traffic won’t broadcast, but will =
keep
flowing to wrong ports (till the MACs ages out or till relearning =
happens
again). I think we need to see the time window for the broadcast in a =
specified
scenario/application where MAC withdraw is being used. That could be =
also one
of the reasons why MAC withdraw is an optional feature in VPLS. =
 



 



To address the broadcast issue when
empty-list MAC withdraw is used, we can implement some filtering =
mechanism to
selectively block MAC withdraw msg for some FECs at PE-rs/originating =
MTU (for
PWs where temp. b’cast is not desired due to MAC withdraw). Anyway =
that
is my theoretical idea and could be implementation specific. =
  



 



 



Regards,


Pranjal
=















From: Shah, =
Himanshu
[mailto:hshah@ciena.com] 

Sent: Monday, 02 January, =
2006
8:50 PM

To: Dutta, Pranjal; =
l2vpn@ietf.org

Subject: RE: VPLS =
question on MAC
address withdrawal






 



Hi Pranjal,



It seems easy to get confused that

mac address withdraw list TLV and empty mac address

withdraw list TLV are one and the same and can be used

interchangeably for scalability. But that is

clearly not true.



In MAC address withdraw list TLV with MAC addresses, receiver

removes the association between MAC addresses in

the list and PW over which the signal is received.



In MAC address TLV list with no MAC addresses,

the receiver removes the association between all MAC addresses

EXCEPT the ones over which he receives this signal.



In the second part of the question, empty MAC address

withdraw List TLV receieved by secondary which now is primary

PE-rs also has some issues. Broadcasting the empty MAC

address withdraw List TLV to all other PE-rs would create

broadcasts in the core, as it removes MAC addresses

learned from ALL N-PWs EXCEPT for ones learned on the

PW over which the signal was received.  This needs to be

carefully thought out too.



regards,

himanshu



-----Original Message-----

From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<=
/a>]

Sent: Mon 1/2/2006 3:16 AM

To: Shah, Himanshu; l2vpn@ietf.org

Subject: RE: VPLS question on MAC address withdrawal



Hi Himanshu,



            &=
nbsp;        
Please see my answers inline







Thanks,



Pranjal







________________________________



From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=

On Behalf Of Shah, Himanshu

Sent: Friday, 30 December, 2005 2:49 AM

To: l2vpn@ietf.org

Subject: VPLS question on MAC address withdrawal











Hope somebody can shed light on the following questions....



(1)

There are two mechanisms described -

MAC address withdraw List TLV and empty MAC Address withdraw List =
TLV



cut-and-paste from draft.



6.2.2. Address Withdraw Message Containing MAC List TLV

 

  The processing for MAC List TLV received in an Address =
Withdraw

  Message is:

 

  For each MAC address in the TLV:

     - Remove the association between the MAC =
address and
the AC or

        PW over which this message is
received

 

  For a MAC Address Withdraw message with empty list:

     - Remove all the MAC addresses associated with =
the
VPLS

        instance  (specified by =
the FEC
TLV) except the MAC addresses

        learned over the PW =
associated with
this signaling session

        over which the message was =
received

 

  The scope of a MAC List TLV is the VPLS specified in the FEC TLV =
in

  the MAC Address Withdraw Message.  The number of MAC =
addresses can

  be deduced from the length field in the TLV.



To simplify the problem, lets assume that for a given VPLS instance A =
there are
only 5 MAC

addresses and one PW. In this case, for TCN-Triggererd =
MAC-address-withdrawal,
sending

a list of 5 MAC address vs sending an empty list achieves opposite =
result. That
is, sending

explicit list will cause the receiver to remove all 5 addresses (lets =
assume
that they all were

associated with sender). But by sending, empty MAC-address-withdrawal =
list, it
will remove

none.  However, the draft says,



In order to minimize the impact on LDP convergence time, when the

  MAC list TLV contains a large number of MAC addresses, it may =
be

  preferable to send a MAC address withdrawal message with an =
empty

  list.



[Pranjal]: What the draft means is that with empty-list in MAC withdraw =
TLV
means remove "ALL" MACs.



            &=
nbsp;
The processing entity of MAC List TLV (in Address Withdraw Msg) needs to =
flush
all MACs associated with a VPLS instance when it receives MAC list =
TLV



            &=
nbsp;  
without any MAC address(s) in the list (empty list). In case, of the MAC =
List
TLV that contains specific MAC addresses then the receiving



            &=
nbsp;  
entity needs to remove only those MAC addresses in the list associated =
with
VPLS instance (identifies by FEC in the address withdraw msg). The =
withdrawl
with empty list



            &=
nbsp;  
feature is to make it more scalable. For example, a VPLS instance that =
has 1000
MACs learned at a PE need not send



            &=
nbsp;  
Address withdraw with 1000 MACs list, can send empty list instead. But =
again it
is optional (means if the MAC withdraw originating PE wants



            &=
nbsp; 
It can send Address Withdraw with 1000 MACs list) and implementation =
specific.
Let's say for a dual homed MTU in HVPLS, the primary link has 100 =
PWs



            &=
nbsp;  
(1 for each VPLS instance) and the secondary link has the backup of all =
the 100
PWs. Now if all 100 primary PWs fail then, all will switch back to the
secondary and MTU



            &=
nbsp; 
needs to send Address Withdraw with MACList TLV, one for each of the 100 =
PWs.
So, empty list would be preferable for each message.



(2)

Is MAC-Address-withdraw mechanism ever intended to be used for U-PW =
(user
facing PW, MTU-S<->PErs)?

If so, how, when, implication of withdraw msg from N-PW (PE<->PE) =
to U-PW,
etc needs to

be described.







[Pranjal]: The draft says that the MAC withdraw originated at a MTU (in
MTU-PErs direction) needs to be processed and forwarded by PE-rs



to other PEs. The draft hasn't specified about propagating MAC withdraw =
by PEs
to the distant-end MTUs in HVPLS (in PErs->MTU direction). I =
think



that part is implementation specific. The reason could be the distant =
end MTUs
will still be receiving the traffic in the primary link and MAC =
withdrawl may
not be necessary.



regards,

himanshu



Himanshu Shah

Ciena Corp
------_=_NextPart_001_01C6103E.EA4D2C01-- From l2vpn-bounces@ietf.org Tue Jan 03 09:24:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etn5a-0001yF-R0; Tue, 03 Jan 2006 09:24:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etn5T-0001xq-HV for l2vpn@megatron.ietf.org; Tue, 03 Jan 2006 09:24:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29133 for ; Tue, 3 Jan 2006 09:23:16 -0500 (EST) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtnAh-0004gq-0a for l2vpn@ietf.org; Tue, 03 Jan 2006 09:29:57 -0500 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 09:24:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61071.5E18B046" Date: Tue, 3 Jan 2006 09:24:12 -0500 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0ag From: "Shah, Himanshu" To: "Dutta, Pranjal" , X-OriginalArrivalTime: 03 Jan 2006 14:24:12.0601 (UTC) FILETIME=[5E4BC290:01C61071] X-Spam-Score: 1.0 (+) X-Scan-Signature: 5bf916ef84139eb2787672b9fb107b6e Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61071.5E18B046 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such = circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other = than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Reg. the first part again excerpts from the draft = as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV = means delete the association between all MAC addresses associated with = the VPLS instance specified in by the FEC TLV within the address withdraw message. This = will not delete the association of MACs with the PW on which the Address = Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only. = =20 The second issue you raised is very interesting and has practical = implications. After PW switchover when, MTU originates the Address = Withdraw for all N PWs (one msg. for each PW). Those will be forwarded = by the "new" PE-rs to all peers thoughout the domain. Removal of all = MACs would cause spark of broadcast and considering the traffic for all = N FECs are flowing now via secondary PW, so associated MACs will get = relearned again across all the PEs. So broadcast will stop once = relearning completes. In the absence of MAC withdraw, traffic won't = broadcast, but will keep flowing to wrong ports (till the MACs ages out = or till relearning happens again). I think we need to see the time = window for the broadcast in a specified scenario/application where MAC = withdraw is being used. That could be also one of the reasons why MAC = withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, we = can implement some filtering mechanism to selectively block MAC withdraw = msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast = is not desired due to MAC withdraw). Anyway that is my theoretical idea = and could be implementation specific. =20 =20 =20 Regards, Pranjal _____ =20 From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. regards, himanshu -----Original Message----- From: Dutta, Pranjal [ mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Please see my answers inline Thanks, Pranjal ________________________________ From: l2vpn-bounces@ietf.org [ mailto:l2vpn-bounces@ietf.org] On Behalf = Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal Hope somebody can shed light on the following questions.... (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV cut-and-paste from draft. 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. To simplify the problem, lets assume that for a given VPLS instance A = there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd = MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite = result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets = assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal = list, it will remove none. However, the draft says, In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. [Pranjal]: What the draft means is that with empty-list in MAC withdraw = TLV means remove "ALL" MACs. The processing entity of MAC List TLV (in Address Withdraw = Msg) needs to flush all MACs associated with a VPLS instance when it = receives MAC list TLV without any MAC address(s) in the list (empty list). In = case, of the MAC List TLV that contains specific MAC addresses then the = receiving entity needs to remove only those MAC addresses in the = list associated with VPLS instance (identifies by FEC in the address = withdraw msg). The withdrawl with empty list feature is to make it more scalable. For example, a VPLS = instance that has 1000 MACs learned at a PE need not send Address withdraw with 1000 MACs list, can send empty = list instead. But again it is optional (means if the MAC withdraw = originating PE wants It can send Address Withdraw with 1000 MACs list) and = implementation specific. Let's say for a dual homed MTU in HVPLS, the = primary link has 100 PWs (1 for each VPLS instance) and the secondary link has = the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all = will switch back to the secondary and MTU needs to send Address Withdraw with MACList TLV, one for = each of the 100 PWs. So, empty list would be preferable for each = message. (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc needs to be described. [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in = MTU-PErs direction) needs to be processed and forwarded by PE-rs to other PEs. The draft hasn't specified about propagating MAC withdraw = by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I = think that part is implementation specific. The reason could be the distant = end MTUs will still be receiving the traffic in the primary link and MAC = withdrawl may not be necessary. regards, himanshu Himanshu Shah Ciena Corp ------_=_NextPart_001_01C61071.5E18B046 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: VPLS question on MAC address withdrawal
Hi=20 Pranjal,
 
I think=20 there is a disconnect. You are failing to understand the=20 point
I am=20 raising.
 
I=20 perfectly understand what empty MAC address withdraw list does.=20
 
Please go=20 through the example I gave. The example clearly shows = that
MAC=20 address withdraw list and empty MAC address withdraw list=20 can
NOT be=20 used interchangeably (for scalability or for other = reasons).
 
As for the=20 second part, the failover causes MAC switchover at = the
expense of=20 disturbance to other MAC conversations that had=20 nothing
to do with=20 the failover. It would almost seem that under such=20 circumstances
MAC=20 Withdraw list with switchover MAC addresses from original=20 primary
PE-rs to=20 other PE-rs would make more sense than having to  make all the
PE-rs to=20 remove all the MAC addresses (for a given VPLS instances) other=20 than
the ones=20 switched over. Seems too expensive.
 
/himanshu
-----Original Message-----
From: Dutta, Pranjal=20 [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, January 03, = 2006=20 3:23 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address withdrawal

Hi=20 Himanshu,

           =          =20 Reg. the first part again excerpts from the draft as=20 below

 

For a MAC Address Withdraw =
message with empty list: 
     - Remove all the MAC addresses =
associated with the VPLS 
       instance(specified by =
the FEC TLV) except the MAC addresses =

       learned over the PW =
associated with this signaling session =

       over which the message =
was received 
   
  The scope of a MAC List TLV is the VPLS specified in =
the FEC TLV in 
  the MAC =
Address Withdraw Message.  The number of MAC addresses can =

  be deduced from the = length field=20 in the TLV

 

 

 In = the first=20 part as per my understanding goes, empty MAC list TLV means delete the = association between all MAC addresses associated with the VPLS=20 instance

specified = in by the=20 FEC TLV within the address withdraw message. This will not delete the=20 association of MACs with the PW on which the Address Withdraw message = with=20 empty MAC list is received.

So as = specified in=20 draft the scope is limited to the FEC specified only.=20

 

The second = issue you=20 raised is very interesting and has practical implications. After PW = switchover=20 when, MTU originates the Address Withdraw for all N PWs (one msg. for = each=20 PW). Those will be forwarded by the “new” PE-rs to all = peers thoughout the=20 domain. Removal of all MACs would cause spark of broadcast and = considering the=20 traffic for all N FECs are flowing now via secondary PW, so associated = MACs=20 will get relearned again across all the PEs. So broadcast will stop = once=20 relearning completes. In the absence of MAC withdraw, traffic = won’t broadcast,=20 but will keep flowing to wrong ports (till the MACs ages out or till=20 relearning happens again). I think we need to see the time window for = the=20 broadcast in a specified scenario/application where MAC withdraw is = being=20 used. That could be also one of the reasons why MAC withdraw is an = optional=20 feature in VPLS.  

 

To address = the=20 broadcast issue when empty-list MAC withdraw is used, we can implement = some=20 filtering mechanism to selectively block MAC withdraw msg for some = FECs at=20 PE-rs/originating MTU (for PWs where temp. b’cast is not desired = due to MAC=20 withdraw). Anyway that is my theoretical idea and could be = implementation=20 specific.   

 

 

Regards,

Pranjal

From: Shah,=20 Himanshu [mailto:hshah@ciena.com]
Sent: Monday, 02 January, 2006 = 8:50=20 PM
To: Dutta, = Pranjal;=20 l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address = withdrawal

 

Hi Pranjal,

It seems easy to get = confused=20 that
mac address withdraw list TLV and empty mac = address
withdraw list=20 TLV are one and the same and can be used
interchangeably for = scalability.=20 But that is
clearly not true.

In MAC address withdraw list = TLV with=20 MAC addresses, receiver
removes the association between MAC = addresses=20 in
the list and PW over which the signal is received.

In MAC = address=20 TLV list with no MAC addresses,
the receiver removes the = association=20 between all MAC addresses
EXCEPT the ones over which he receives = this=20 signal.

In the second part of the question, empty MAC=20 address
withdraw List TLV receieved by secondary which now is=20 primary
PE-rs also has some issues. Broadcasting the empty = MAC
address=20 withdraw List TLV to all other PE-rs would create
broadcasts in the = core,=20 as it removes MAC addresses
learned from ALL N-PWs EXCEPT for ones = learned=20 on the
PW over which the signal was received.  This needs to=20 be
carefully thought out=20 too.

regards,
himanshu

-----Original = Message-----
From:=20 Dutta, Pranjal [mailto:pdutta@riverstonenet.com<= /A>]
Sent:=20 Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; l2vpn@ietf.org
Subject: = RE:=20 VPLS question on MAC address withdrawal

Hi=20 = Himanshu,

         &n= bsp;           =20 Please see my answers=20 = inline



Thanks,

Pranjal



_____________= ___________________

From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= On=20 Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 2:49 = AM
To:=20 l2vpn@ietf.org
Subject: VPLS question on MAC address=20 withdrawal





Hope somebody can shed light on the=20 following questions....

(1)
There are two mechanisms = described=20 -
MAC address withdraw List TLV and empty MAC Address withdraw List = TLV

cut-and-paste from draft.

6.2.2. Address Withdraw = Message=20 Containing MAC List TLV
 
  The processing for MAC = List TLV=20 received in an Address Withdraw
  Message = is:
 
  For=20 each MAC address in the TLV:
     - Remove the=20 association between the MAC address and the AC=20 or
        PW over which this = message is=20 received
 
  For a MAC Address Withdraw message with = empty=20 list:
     - Remove all the MAC addresses = associated=20 with the VPLS
        = instance =20 (specified by the FEC TLV) except the MAC=20 addresses
        learned over = the PW=20 associated with this signaling=20 session
        over which the = message=20 was received
 
  The scope of a MAC List TLV is the = VPLS=20 specified in the FEC TLV in
  the MAC Address Withdraw = Message. =20 The number of MAC addresses can
  be deduced from the length = field in=20 the TLV.

To simplify the problem, lets assume that for a given = VPLS=20 instance A there are only 5 MAC
addresses and one PW. In this case, = for=20 TCN-Triggererd MAC-address-withdrawal, sending
a list of 5 MAC = address vs=20 sending an empty list achieves opposite result. That is, = sending
explicit=20 list will cause the receiver to remove all 5 addresses (lets assume = that they=20 all were
associated with sender). But by sending, empty=20 MAC-address-withdrawal list, it will remove
none.  However, = the draft=20 says,

In order to minimize the impact on LDP convergence time, = when=20 the
  MAC list TLV contains a large number of MAC addresses, = it may=20 be
  preferable to send a MAC address withdrawal message with = an=20 empty
  list.

[Pranjal]: What the draft means is that = with=20 empty-list in MAC withdraw TLV means remove "ALL"=20 = MACs.

          =    =20 The processing entity of MAC List TLV (in Address Withdraw Msg) needs = to flush=20 all MACs associated with a VPLS instance when it receives MAC list=20 = TLV

          &n= bsp;    =20 without any MAC address(s) in the list (empty list). In case, of the = MAC List=20 TLV that contains specific MAC addresses then the=20 = receiving

         &n= bsp;     =20 entity needs to remove only those MAC addresses in the list associated = with=20 VPLS instance (identifies by FEC in the address withdraw msg). The = withdrawl=20 with empty=20 = list

          &= nbsp;    =20 feature is to make it more scalable. For example, a VPLS instance that = has=20 1000 MACs learned at a PE need not=20 = send

          &= nbsp;    =20 Address withdraw with 1000 MACs list, can send empty list instead. But = again=20 it is optional (means if the MAC withdraw originating PE=20 = wants

          =     =20 It can send Address Withdraw with 1000 MACs list) and implementation = specific.=20 Let's say for a dual homed MTU in HVPLS, the primary link has 100=20 = PWs

          &n= bsp;    =20 (1 for each VPLS instance) and the secondary link has the backup of = all the=20 100 PWs. Now if all 100 primary PWs fail then, all will switch back to = the=20 secondary and=20 = MTU

          &n= bsp;   =20 needs to send Address Withdraw with MACList TLV, one for each of the = 100 PWs.=20 So, empty list would be preferable for each message.

(2)
Is=20 MAC-Address-withdraw mechanism ever intended to be used for U-PW (user = facing=20 PW, MTU-S<->PErs)?
If so, how, when, implication of withdraw = msg from=20 N-PW (PE<->PE) to U-PW, etc needs to
be=20 described.



[Pranjal]: The draft says that the MAC = withdraw=20 originated at a MTU (in MTU-PErs direction) needs to be processed and=20 forwarded by PE-rs

to other PEs. The draft hasn't specified = about=20 propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in=20 PErs->MTU direction). I think

that part is implementation = specific.=20 The reason could be the distant end MTUs will still be receiving the = traffic=20 in the primary link and MAC withdrawl may not be=20 necessary.

regards,
himanshu

Himanshu Shah
Ciena=20 = Corp

------_=_NextPart_001_01C61071.5E18B046-- From l2vpn-bounces@ietf.org Wed Jan 04 00:51:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu1Yk-0001kD-6p; Wed, 04 Jan 2006 00:51:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu1Yg-0001iw-EH for l2vpn@megatron.ietf.org; Wed, 04 Jan 2006 00:51:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10062 for ; Wed, 4 Jan 2006 00:50:23 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu1e3-0000Fq-Gl for l2vpn@ietf.org; Wed, 04 Jan 2006 00:57:14 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id VAA10204; Tue, 3 Jan 2006 21:51:07 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C610F2.DC79A076" Date: Wed, 4 Jan 2006 11:21:08 +0530 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agACBcEbA= From: "Dutta, Pranjal" To: "Shah, Himanshu" , X-Spam-Score: 3.8 (+++) X-Scan-Signature: b93f0dc9ddba0752e520e7aa9e82b4eb Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C610F2.DC79A076 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, The problem you are referring to seems to be different than the way I perceive it. With reference to your first point, the effect of empty-list MAC withdraw is definitely different than the MAC withdraw with specific MAC addresses. And both can't be used interchangeably (means both will not have the same effect). Rather I would say it's a tradeoff. In the example you provided in first mail where originating MTU has 5 MACs then definitely it makes sense to send a MAC withdraw with those 5 MAC addresses in MAC-list. If the number of MACs learned at the MTU (where PW switchover has taken place) is extremely large (lets say 5000) then sending Address Withdraw with specific MAC list might get expensive and won't be scalable proposition. Now instead when empty-list MAC list is sent it is going to delete the all the "other" MACs (apart from the 5000 in the MTU that are actually switched to secondary) which are learned at PE-rs(s) from "other" MTUs in the VPLS instance. Ideally those MACs shouldn't have been disturbed. So sending empty-list will globally affect all MACs on the VPLS instance. I think as MAC withdraw is an optional feature, so implementations need to take care of such tradeoffs. =20 Regards, Pranjal =20 =20 =20 ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Tuesday, 03 January, 2006 7:54 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Reg. the first part again excerpts from the draft as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only.=20 =20 The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific. =20 =20 =20 Regards, Pranjal =09 ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, =09 It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. =09 In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. =09 In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. =09 In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. =09 regards, himanshu =09 -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 Hi Himanshu, =09 Please see my answers inline =09 =09 =09 Thanks, =09 Pranjal =09 =09 =09 ________________________________ =09 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal =09 =09 =09 =09 =09 Hope somebody can shed light on the following questions.... =09 (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV =09 cut-and-paste from draft. =09 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. =09 To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove none. However, the draft says, =09 In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. =09 [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. =09 The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV =09 without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving =09 entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list =09 feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send =09 Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants =09 It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs =09 (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU =09 needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. =09 (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to be described. =09 =09 =09 [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs =09 to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think =09 that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. =09 regards, himanshu =09 Himanshu Shah Ciena Corp ------_=_NextPart_001_01C610F2.DC79A076 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: VPLS question on MAC address withdrawal

Hi = Himanshu,

      =                 The problem you are referring to seems to be = different than the way I perceive it. With reference to your first point, the = effect of empty-list MAC withdraw is definitely different than the MAC withdraw = with specific MAC addresses. And both can’t be used interchangeably = (means both will not have the same effect). Rather I would say it’s a = tradeoff. In the example you provided in first mail where originating MTU has 5 MACs = then definitely it makes sense to send a MAC withdraw with those 5 MAC addresses in = MAC-list. If the number of MACs learned at the MTU (where PW switchover has taken = place) is extremely large (lets say 5000) then sending Address Withdraw with = specific MAC list might get expensive and won’t be scalable proposition. Now = instead when empty-list MAC list is sent it is going to delete the all the = “other” MACs (apart from the 5000 in the MTU that are actually switched to = secondary) which are learned at PE-rs(s) from “other” MTUs in the VPLS = instance. Ideally those MACs shouldn’t have been disturbed.  So sending = empty-list will globally affect all MACs on the VPLS instance. I think as MAC = withdraw is an optional feature, so implementations need to take care of such = tradeoffs.

 

Regards,

Pranjal =    

 

 

From: Shah, = Himanshu [mailto:hshah@ciena.com]
Sent: Tuesday, 03 = January, 2006 7:54 PM
To: Dutta, Pranjal; = l2vpn@ietf.org
Subject: RE: VPLS = question on MAC address withdrawal

 

Hi = Pranjal,

 

I think there = is a disconnect. You are failing to understand the = point

I am = raising.

 

I perfectly = understand what empty MAC address withdraw list does.

 

Please go = through the example I gave. The example clearly shows = that

MAC address = withdraw list and empty MAC address withdraw list = can

NOT be used interchangeably (for scalability or for other = reasons).

 

As for the = second part, the failover causes MAC switchover at = the

expense of = disturbance to other MAC conversations that had nothing

to do with = the failover. It would almost seem that under such = circumstances

MAC Withdraw = list with switchover MAC addresses from original = primary

PE-rs to = other PE-rs would make more sense than having to  make all = the

PE-rs to = remove all the MAC addresses (for a given VPLS instances) other = than

the ones = switched over. Seems too expensive.

 

/himanshu

-----Original = Message-----
From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, January = 03, 2006 3:23 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE: VPLS = question on MAC address withdrawal

Hi = Himanshu,

      =             &= nbsp;  Reg. the first part again excerpts from the draft as = below

 = 

For a MAC Address Withdraw message with empty =
list: 
     - Remove all =
the MAC addresses associated with the VPLS =

       inst=
ance(specified by the FEC TLV) except the MAC addresses =

       lear=
ned over the PW associated with this signaling session =

       over=
 which the message was received =

   
  The scope of a MAC List TLV is =
the VPLS specified in the FEC TLV in =

  the MAC Address Withdraw =
Message.  The number of MAC addresses can =




  be deduced from the length field in =
the TLV



 =




 =




 In the first part as per my
understanding goes, empty MAC list TLV means delete the association =
between all
MAC addresses associated with the VPLS =
instance



specified in by the FEC TLV within =
the
address withdraw message. This will not delete the association of MACs =
with the
PW on which the Address Withdraw message with empty MAC list is =
received.



So as specified in draft the scope =
is
limited to the FEC specified only. 



 



The second issue you raised is very
interesting and has practical implications. After PW switchover when, =
MTU
originates the Address Withdraw for all N PWs (one msg. for each PW). =
Those
will be forwarded by the “new” PE-rs to all peers thoughout =
the
domain. Removal of all MACs would cause spark of broadcast and =
considering the
traffic for all N FECs are flowing now via secondary PW, so associated =
MACs
will get relearned again across all the PEs. So broadcast will stop once
relearning completes. In the absence of MAC withdraw, traffic =
won’t
broadcast, but will keep flowing to wrong ports (till the MACs ages out =
or till
relearning happens again). I think we need to see the time window for =
the
broadcast in a specified scenario/application where MAC withdraw is =
being used.
That could be also one of the reasons why MAC withdraw is an optional =
feature
in VPLS.  



 



To address the broadcast issue when
empty-list MAC withdraw is used, we can implement some filtering =
mechanism to
selectively block MAC withdraw msg for some FECs at PE-rs/originating =
MTU (for
PWs where temp. b’cast is not desired due to MAC withdraw). Anyway =
that
is my theoretical idea and could be implementation specific. =
  



 



 



Regards,


Pranjal
=















From: Shah, =
Himanshu
[mailto:hshah@ciena.com] 

Sent: Monday, 02 January, =
2006
8:50 PM

To: Dutta, Pranjal; =
l2vpn@ietf.org

Subject: RE: VPLS =
question on MAC
address withdrawal






 



Hi Pranjal,



It seems easy to get confused that

mac address withdraw list TLV and empty mac address

withdraw list TLV are one and the same and can be used

interchangeably for scalability. But that is

clearly not true.



In MAC address withdraw list TLV with MAC addresses, receiver

removes the association between MAC addresses in

the list and PW over which the signal is received.



In MAC address TLV list with no MAC addresses,

the receiver removes the association between all MAC addresses

EXCEPT the ones over which he receives this signal.



In the second part of the question, empty MAC address

withdraw List TLV receieved by secondary which now is primary

PE-rs also has some issues. Broadcasting the empty MAC

address withdraw List TLV to all other PE-rs would create

broadcasts in the core, as it removes MAC addresses

learned from ALL N-PWs EXCEPT for ones learned on the

PW over which the signal was received.  This needs to be

carefully thought out too.



regards,

himanshu



-----Original Message-----

From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<=
/a>]

Sent: Mon 1/2/2006 3:16 AM

To: Shah, Himanshu; l2vpn@ietf.org

Subject: RE: VPLS question on MAC address withdrawal



Hi Himanshu,



            &=
nbsp;        
Please see my answers inline







Thanks,



Pranjal







________________________________



From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=

On Behalf Of Shah, Himanshu

Sent: Friday, 30 December, 2005 2:49 AM

To: l2vpn@ietf.org

Subject: VPLS question on MAC address withdrawal











Hope somebody can shed light on the following questions....



(1)

There are two mechanisms described -

MAC address withdraw List TLV and empty MAC Address withdraw List =
TLV



cut-and-paste from draft.



6.2.2. Address Withdraw Message Containing MAC List TLV

 

  The processing for MAC List TLV received in an Address =
Withdraw

  Message is:

 

  For each MAC address in the TLV:

     - Remove the association between the MAC =
address and
the AC or

        PW over which this message is
received

 

  For a MAC Address Withdraw message with empty list:

     - Remove all the MAC addresses associated with =
the
VPLS

        instance  (specified by =
the FEC
TLV) except the MAC addresses

        learned over the PW =
associated with
this signaling session

        over which the message was =
received

 

  The scope of a MAC List TLV is the VPLS specified in the FEC TLV =
in

  the MAC Address Withdraw Message.  The number of MAC =
addresses can

  be deduced from the length field in the TLV.



To simplify the problem, lets assume that for a given VPLS instance A =
there are
only 5 MAC

addresses and one PW. In this case, for TCN-Triggererd =
MAC-address-withdrawal,
sending

a list of 5 MAC address vs sending an empty list achieves opposite =
result. That
is, sending

explicit list will cause the receiver to remove all 5 addresses (lets =
assume
that they all were

associated with sender). But by sending, empty MAC-address-withdrawal =
list, it
will remove

none.  However, the draft says,



In order to minimize the impact on LDP convergence time, when the

  MAC list TLV contains a large number of MAC addresses, it may =
be

  preferable to send a MAC address withdrawal message with an =
empty

  list.



[Pranjal]: What the draft means is that with empty-list in MAC withdraw =
TLV
means remove "ALL" MACs.



            &=
nbsp;
The processing entity of MAC List TLV (in Address Withdraw Msg) needs to =
flush
all MACs associated with a VPLS instance when it receives MAC list =
TLV



            &=
nbsp;  
without any MAC address(s) in the list (empty list). In case, of the MAC =
List
TLV that contains specific MAC addresses then the receiving



            &=
nbsp;  
entity needs to remove only those MAC addresses in the list associated =
with
VPLS instance (identifies by FEC in the address withdraw msg). The =
withdrawl
with empty list



            &=
nbsp;  
feature is to make it more scalable. For example, a VPLS instance that =
has 1000
MACs learned at a PE need not send



            &=
nbsp;  
Address withdraw with 1000 MACs list, can send empty list instead. But =
again it
is optional (means if the MAC withdraw originating PE wants



            &=
nbsp; 
It can send Address Withdraw with 1000 MACs list) and implementation =
specific.
Let's say for a dual homed MTU in HVPLS, the primary link has 100 =
PWs



            &=
nbsp;  
(1 for each VPLS instance) and the secondary link has the backup of all =
the 100
PWs. Now if all 100 primary PWs fail then, all will switch back to the
secondary and MTU



            &=
nbsp; 
needs to send Address Withdraw with MACList TLV, one for each of the 100 =
PWs.
So, empty list would be preferable for each message.



(2)

Is MAC-Address-withdraw mechanism ever intended to be used for U-PW =
(user
facing PW, MTU-S<->PErs)?

If so, how, when, implication of withdraw msg from N-PW (PE<->PE) =
to
U-PW, etc needs to

be described.







[Pranjal]: The draft says that the MAC withdraw originated at a MTU (in
MTU-PErs direction) needs to be processed and forwarded by PE-rs



to other PEs. The draft hasn't specified about propagating MAC withdraw =
by PEs
to the distant-end MTUs in HVPLS (in PErs->MTU direction). I =
think



that part is implementation specific. The reason could be the distant =
end MTUs
will still be receiving the traffic in the primary link and MAC =
withdrawl may
not be necessary.



regards,

himanshu



Himanshu Shah

Ciena Corp
------_=_NextPart_001_01C610F2.DC79A076-- From l2vpn-bounces@ietf.org Wed Jan 04 03:03:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu3ck-00038J-6n; Wed, 04 Jan 2006 03:03:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu3ci-00038E-EK for l2vpn@megatron.ietf.org; Wed, 04 Jan 2006 03:03:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24070 for ; Wed, 4 Jan 2006 03:02:39 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu3i7-00052P-5G for l2vpn@ietf.org; Wed, 04 Jan 2006 03:09:32 -0500 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id AAA27460; Wed, 4 Jan 2006 00:03:28 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61105.5B05FE55" Date: Wed, 4 Jan 2006 13:33:31 +0530 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agACNSe1A= From: "Dutta, Pranjal" To: "Shah, Himanshu" , X-Spam-Score: 3.8 (+++) X-Scan-Signature: 983a1a9d2ed58a5b530ecfdbd65e0918 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61105.5B05FE55 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, I think I am getting the point you are referring to. In the first example, when we send Address Withdraw with 5 MAC list, it is going to delete the association of the 5MACs from the PW on which it is received. So, when the address withdraw is received at secondary PE-rs over the secondary PW (after MTU switched over to secondary), it might delete even the switched MACs if learnt already on the secondary PW (Because for non-empty MAC list the draft doesn't put the rider on deletion the MACs EXCEPT receiving PW). Propagation of the message to other PE-rs(s) in the full mesh will delete the 5 MACs learned at the respective PEs earlier (on the PW(s) from primary PE-rs).On that part I don't see any problem. In case of Address Withdraw with empty MAC list, the newly learned MACs on the secondary PW won't get deleted in case if learnt already (as draft says EXCEPT on the receiving PW). But when it is propagated by the secondary PE-rs to other PE-rs(s) , the receiver will do two things. First, It will delete all the 5 MACs in respective PE-rs(s) which were learnt earlier on PW(s) from primary PE-rs (The PW on which the message is received, that is between secondary PE-rs is now is different than the PW to primary PE-rs, so the EXCEPT condition prevails here and newly learned MACs won't get deleted). Secondly, it will also delete the "other MACs" learnt from "other" MTUs in the VPLS instance which are not actually affected by the switchover on the MTU in discussion. Again global deletion doesn't include the "other" MACs on the PW on which the address withdraw is received and associated with this signaling session (secondary PE-rs to other PE-rs(s) only). But I am failing to understand the point that you mentioned "But by sending, empty MAC-address-withdrawal list, it will remove none". =20 Regards, Pranjal =20 =20 ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Tuesday, 03 January, 2006 7:54 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Reg. the first part again excerpts from the draft as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only.=20 =20 The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific. =20 =20 =20 Regards, Pranjal =09 ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, =09 It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. =09 In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. =09 In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. =09 In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. =09 regards, himanshu =09 -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 Hi Himanshu, =09 Please see my answers inline =09 =09 =09 Thanks, =09 Pranjal =09 =09 =09 ________________________________ =09 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal =09 =09 =09 =09 =09 Hope somebody can shed light on the following questions.... =09 (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV =09 cut-and-paste from draft. =09 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. =09 To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove none. However, the draft says, =09 In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. =09 [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. =09 The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV =09 without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving =09 entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list =09 feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send =09 Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants =09 It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs =09 (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU =09 needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. =09 (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to be described. =09 =09 =09 [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs =09 to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think =09 that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. =09 regards, himanshu =09 Himanshu Shah Ciena Corp ------_=_NextPart_001_01C61105.5B05FE55 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: VPLS question on MAC address withdrawal

Hi = Himanshu,

      =             &= nbsp;   I think I am getting the point you are referring to. In the = first example, when we send Address Withdraw with 5 MAC list, it is going to delete the association of the 5MACs from the PW on which it is received. So, when = the address withdraw is received at secondary PE-rs over the secondary PW (after MTU = switched over to secondary), it might delete even the switched MACs if learnt = already on the secondary PW (Because for non-empty MAC list the draft doesn’t = put the rider on deletion the MACs EXCEPT receiving PW). Propagation of the = message to other PE-rs(s) in the full mesh will delete the 5 MACs learned at the respective PEs earlier (on the PW(s) from primary PE-rs).On that part I = don’t see any problem. In case of Address Withdraw with empty MAC list, the = newly learned MACs on the secondary PW won’t get deleted in case if = learnt already (as draft says EXCEPT on the receiving PW). But when it is = propagated by the secondary PE-rs to other PE-rs(s) , the receiver will do two = things. First, It will delete all the 5 MACs in respective PE-rs(s) which were learnt = earlier on PW(s) from primary PE-rs (The PW on which the message is received, that = is between secondary PE-rs is now is different than the PW to primary = PE-rs, so the EXCEPT condition prevails here and newly learned MACs won’t = get deleted). Secondly, it will also delete the “other MACs” = learnt from “other” MTUs in the VPLS instance which are not = actually affected by the switchover on the MTU in discussion. Again global = deletion doesn’t include the “other” MACs on the PW on which the address = withdraw is received and associated with this signaling session (secondary PE-rs to = other PE-rs(s) only). But I am failing to understand the point that you = mentioned “But by sending, empty MAC-address-withdrawal list, it will remove = none”.

 

Regards,
Pranjal

      =             &= nbsp; 

 

From: Shah, = Himanshu [mailto:hshah@ciena.com]
Sent: Tuesday, 03 = January, 2006 7:54 PM
To: Dutta, Pranjal; = l2vpn@ietf.org
Subject: RE: VPLS = question on MAC address withdrawal

 

Hi = Pranjal,

 

I think there = is a disconnect. You are failing to understand the = point

I am = raising.

 

I perfectly = understand what empty MAC address withdraw list does.

 

Please go = through the example I gave. The example clearly shows = that

MAC address = withdraw list and empty MAC address withdraw list = can

NOT be used interchangeably (for scalability or for other = reasons).

 

As for the = second part, the failover causes MAC switchover at = the

expense of = disturbance to other MAC conversations that had nothing

to do with = the failover. It would almost seem that under such = circumstances

MAC Withdraw = list with switchover MAC addresses from original = primary

PE-rs to = other PE-rs would make more sense than having to  make all = the

PE-rs to = remove all the MAC addresses (for a given VPLS instances) other = than

the ones = switched over. Seems too expensive.

 

/himanshu

-----Original = Message-----
From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, January = 03, 2006 3:23 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE: VPLS = question on MAC address withdrawal

Hi = Himanshu,

      =             &= nbsp;  Reg. the first part again excerpts from the draft as = below

 = 

For a MAC Address Withdraw message with empty =
list: 
     - Remove all =
the MAC addresses associated with the VPLS =

       inst=
ance(specified by the FEC TLV) except the MAC addresses =

       lear=
ned over the PW associated with this signaling session =

       over=
 which the message was received =

   
  The scope of a MAC List TLV is =
the VPLS specified in the FEC TLV in =

  the MAC Address Withdraw =
Message.  The number of MAC addresses can =




  be deduced from the length field in =
the TLV



 =




 =




 In the first part as per my
understanding goes, empty MAC list TLV means delete the association =
between all
MAC addresses associated with the VPLS =
instance



specified in by the FEC TLV within =
the
address withdraw message. This will not delete the association of MACs =
with the
PW on which the Address Withdraw message with empty MAC list is =
received.



So as specified in draft the scope =
is
limited to the FEC specified only. 



 



The second issue you raised is very
interesting and has practical implications. After PW switchover when, =
MTU
originates the Address Withdraw for all N PWs (one msg. for each PW). =
Those
will be forwarded by the “new” PE-rs to all peers thoughout =
the
domain. Removal of all MACs would cause spark of broadcast and =
considering the
traffic for all N FECs are flowing now via secondary PW, so associated =
MACs
will get relearned again across all the PEs. So broadcast will stop once
relearning completes. In the absence of MAC withdraw, traffic =
won’t
broadcast, but will keep flowing to wrong ports (till the MACs ages out =
or till
relearning happens again). I think we need to see the time window for =
the
broadcast in a specified scenario/application where MAC withdraw is =
being used.
That could be also one of the reasons why MAC withdraw is an optional =
feature
in VPLS.  



 



To address the broadcast issue when
empty-list MAC withdraw is used, we can implement some filtering =
mechanism to
selectively block MAC withdraw msg for some FECs at PE-rs/originating =
MTU (for
PWs where temp. b’cast is not desired due to MAC withdraw). Anyway =
that
is my theoretical idea and could be implementation specific. =
  



 



 



Regards,


Pranjal
=















From: Shah, =
Himanshu
[mailto:hshah@ciena.com] 

Sent: Monday, 02 January, =
2006
8:50 PM

To: Dutta, Pranjal; =
l2vpn@ietf.org

Subject: RE: VPLS =
question on MAC
address withdrawal






 



Hi Pranjal,



It seems easy to get confused that

mac address withdraw list TLV and empty mac address

withdraw list TLV are one and the same and can be used

interchangeably for scalability. But that is

clearly not true.



In MAC address withdraw list TLV with MAC addresses, receiver

removes the association between MAC addresses in

the list and PW over which the signal is received.



In MAC address TLV list with no MAC addresses,

the receiver removes the association between all MAC addresses

EXCEPT the ones over which he receives this signal.



In the second part of the question, empty MAC address

withdraw List TLV receieved by secondary which now is primary

PE-rs also has some issues. Broadcasting the empty MAC

address withdraw List TLV to all other PE-rs would create

broadcasts in the core, as it removes MAC addresses

learned from ALL N-PWs EXCEPT for ones learned on the

PW over which the signal was received.  This needs to be

carefully thought out too.



regards,

himanshu



-----Original Message-----

From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<=
/a>]

Sent: Mon 1/2/2006 3:16 AM

To: Shah, Himanshu; l2vpn@ietf.org

Subject: RE: VPLS question on MAC address withdrawal



Hi Himanshu,



            &=
nbsp;        
Please see my answers inline







Thanks,



Pranjal







________________________________



From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=

On Behalf Of Shah, Himanshu

Sent: Friday, 30 December, 2005 2:49 AM

To: l2vpn@ietf.org

Subject: VPLS question on MAC address withdrawal











Hope somebody can shed light on the following questions....



(1)

There are two mechanisms described -

MAC address withdraw List TLV and empty MAC Address withdraw List =
TLV



cut-and-paste from draft.



6.2.2. Address Withdraw Message Containing MAC List TLV

 

  The processing for MAC List TLV received in an Address =
Withdraw

  Message is:

 

  For each MAC address in the TLV:

     - Remove the association between the MAC =
address and
the AC or

        PW over which this message is
received

 

  For a MAC Address Withdraw message with empty list:

     - Remove all the MAC addresses associated with =
the
VPLS

        instance  (specified by =
the FEC
TLV) except the MAC addresses

        learned over the PW =
associated with
this signaling session

        over which the message was =
received

 

  The scope of a MAC List TLV is the VPLS specified in the FEC TLV =
in

  the MAC Address Withdraw Message.  The number of MAC =
addresses can

  be deduced from the length field in the TLV.



To simplify the problem, lets assume that for a given VPLS instance A =
there are
only 5 MAC

addresses and one PW. In this case, for TCN-Triggererd =
MAC-address-withdrawal,
sending

a list of 5 MAC address vs sending an empty list achieves opposite =
result. That
is, sending

explicit list will cause the receiver to remove all 5 addresses (lets =
assume
that they all were

associated with sender). But by sending, empty MAC-address-withdrawal =
list, it
will remove

none.  However, the draft says,



In order to minimize the impact on LDP convergence time, when the

  MAC list TLV contains a large number of MAC addresses, it may =
be

  preferable to send a MAC address withdrawal message with an =
empty

  list.



[Pranjal]: What the draft means is that with empty-list in MAC withdraw =
TLV
means remove "ALL" MACs.



            &=
nbsp;
The processing entity of MAC List TLV (in Address Withdraw Msg) needs to =
flush
all MACs associated with a VPLS instance when it receives MAC list =
TLV



            &=
nbsp;  
without any MAC address(s) in the list (empty list). In case, of the MAC =
List
TLV that contains specific MAC addresses then the receiving



            &=
nbsp;  
entity needs to remove only those MAC addresses in the list associated =
with
VPLS instance (identifies by FEC in the address withdraw msg). The =
withdrawl
with empty list



            &=
nbsp;  
feature is to make it more scalable. For example, a VPLS instance that =
has 1000
MACs learned at a PE need not send



            &=
nbsp;  
Address withdraw with 1000 MACs list, can send empty list instead. But =
again it
is optional (means if the MAC withdraw originating PE wants



            &=
nbsp; 
It can send Address Withdraw with 1000 MACs list) and implementation =
specific.
Let's say for a dual homed MTU in HVPLS, the primary link has 100 =
PWs



            &=
nbsp;  
(1 for each VPLS instance) and the secondary link has the backup of all =
the 100
PWs. Now if all 100 primary PWs fail then, all will switch back to the
secondary and MTU



            &=
nbsp; 
needs to send Address Withdraw with MACList TLV, one for each of the 100 =
PWs.
So, empty list would be preferable for each message.



(2)

Is MAC-Address-withdraw mechanism ever intended to be used for U-PW =
(user
facing PW, MTU-S<->PErs)?

If so, how, when, implication of withdraw msg from N-PW (PE<->PE) =
to
U-PW, etc needs to

be described.







[Pranjal]: The draft says that the MAC withdraw originated at a MTU (in
MTU-PErs direction) needs to be processed and forwarded by PE-rs



to other PEs. The draft hasn't specified about propagating MAC withdraw =
by PEs
to the distant-end MTUs in HVPLS (in PErs->MTU direction). I =
think



that part is implementation specific. The reason could be the distant =
end MTUs
will still be receiving the traffic in the primary link and MAC =
withdrawl may
not be necessary.



regards,

himanshu



Himanshu Shah

Ciena Corp
------_=_NextPart_001_01C61105.5B05FE55-- From l2vpn-bounces@ietf.org Wed Jan 04 06:22:59 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6jL-00038f-5x; Wed, 04 Jan 2006 06:22:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6jG-00038Q-Jm for l2vpn@megatron.ietf.org; Wed, 04 Jan 2006 06:22:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15069 for ; Wed, 4 Jan 2006 06:21:39 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu6oh-0003XO-IE for l2vpn@ietf.org; Wed, 04 Jan 2006 06:28:34 -0500 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id DAA19815; Wed, 4 Jan 2006 03:22:20 -0800 (PST) Message-ID: <024f01c61121$1e120c10$6801a8c0@IBMT41ML> From: "Marc Lasserre" To: "Shah, Himanshu" , References: Date: Wed, 4 Jan 2006 12:22:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_024C_01C61129.7EBBB540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: Subject: Re: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_024C_01C61129.7EBBB540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VPLS question on MAC address withdrawalHimanshu, Sorry to jump a bit late in this discussion. See my answers below. Cheers, Marc ----- Original Message -----=20 From: Shah, Himanshu=20 To: l2vpn@ietf.org=20 Sent: Thursday, December 29, 2005 10:19 PM Subject: VPLS question on MAC address withdrawal Hope somebody can shed light on the following questions....=20 (1)=20 There are two mechanisms described -=20 MAC address withdraw List TLV and empty MAC Address withdraw List TLV=20 cut-and-paste from draft.=20 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV.=20 To simplify the problem, lets assume that for a given VPLS instance A = there are only 5 MAC=20 addresses and one PW. In this case, for TCN-Triggererd = MAC-address-withdrawal, sending=20 a list of 5 MAC address vs sending an empty list achieves opposite = result. That is, sending=20 explicit list will cause the receiver to remove all 5 addresses (lets = assume that they all were=20 associated with sender). But by sending, empty MAC-address-withdrawal = list, it will remove=20 none. However, the draft says,=20 Sending an empty MAC withdraw message will trigger all MACs to be = unlearned (the 5 MACs in your examples). Only MACs behing the newly active PE-rs would be = preserved. In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list.=20 (2)=20 Is MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user facing PW, MTU-S<->PErs)?=20 If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc needs to=20 be described.=20 The main intent is for an MTU-s to trigger MAC withdrawal to its = directly attached PE-rs. The PE-rs will propagate MAC withdrawal messages to its peer PEs. There is no = withdrawal event to be performed by egress MTUs. The triggering events for sending MAC withdrawals can be based on = different failure detection mechanisms (eg STP based TCNs, BFD, etc). regards,=20 himanshu=20 Himanshu Shah=20 Ciena Corp=20 ------=_NextPart_000_024C_01C61129.7EBBB540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VPLS question on MAC address withdrawal
Himanshu,
 
Sorry to jump a bit late in this=20 discussion.
See my answers below.
 
Cheers,
Marc
----- Original Message -----
From:=20 Shah, = Himanshu=20
Sent: Thursday, December 29, = 2005 10:19=20 PM
Subject: VPLS question on MAC = address=20 withdrawal


Hope somebody can shed light = on the=20 following questions....

(1)
There are two mechanisms described -
MAC address withdraw List TLV and empty = MAC Address=20 withdraw List TLV

cut-and-paste from = draft.

6.2.2. Address Withdraw Message = Containing=20 MAC List TLV
  
  The processing for MAC List TLV = received in an Address Withdraw
  Message=20 is:
  
  For each MAC address in the=20 TLV:
     - Remove the association between the = MAC=20 address and the AC or
        PW = over=20 which this message is received
  
  For a MAC = Address=20 Withdraw message with empty list:
     - Remove = all the=20 MAC addresses associated with the=20 VPLS
        instance  = (specified=20 by the FEC TLV) except the MAC=20 addresses
        learned over = the PW=20 associated with this signaling=20 session
        over which the = message=20 was received
  
  The scope of a MAC List TLV is = the VPLS=20 specified in the FEC TLV in
  the MAC Address Withdraw = Message. =20 The number of MAC addresses can
  be deduced from the length = field in=20 the TLV.

To simplify the problem, lets = assume that=20 for a given VPLS instance A there are only 5 MAC
addresses and one PW. In this case, for = TCN-Triggererd MAC-address-withdrawal, sending
a list of 5 MAC address vs sending an = empty list=20 achieves opposite result. That is, sending
explicit list will cause the receiver = to remove all=20 5 addresses (lets assume that they all were
associated with sender). But by = sending, empty=20 MAC-address-withdrawal list, it will remove
none.  However, the draft = says,=20

Sending an empty MAC = withdraw=20 message will trigger all MACs to be unlearned (the 5 MACs

in your examples). = Only MACs behing=20 the newly active PE-rs would be preserved.

In order to minimize the impact = on LDP=20 convergence time, when the
  MAC list TLV contains a large = number of=20 MAC addresses, it may be
  preferable to send a MAC address = withdrawal=20 message with an empty
  list.

(2)
Is MAC-Address-withdraw mechanism ever intended to be used = for U-PW=20 (user facing PW, MTU-S<->PErs)?
If so, how, when, implication of withdraw msg from N-PW = (PE<->PE)=20 to U-PW, etc needs to
be=20 described.

The main intent is for = an MTU-s to=20 trigger MAC withdrawal to its directly attached PE-rs. The PE-rs = will

propagate MAC = withdrawal messages to=20 its peer PEs. There is no withdrawal event to be performed by = egress

MTUs. The triggering = events for=20 sending MAC withdrawals can be based on different failure = detection

mechanisms (eg STP = based TCNs, BFD,=20 etc).

regards,
himanshu

Himanshu Shah
Ciena Corp

------=_NextPart_000_024C_01C61129.7EBBB540-- From l2vpn-bounces@ietf.org Wed Jan 04 06:34:51 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6up-0005le-O7; Wed, 04 Jan 2006 06:34:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6un-0005lX-MR for l2vpn@megatron.ietf.org; Wed, 04 Jan 2006 06:34:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16249 for ; Wed, 4 Jan 2006 06:33:34 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eu70F-0003v6-Kj for l2vpn@ietf.org; Wed, 04 Jan 2006 06:40:28 -0500 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id DAA20968; Wed, 4 Jan 2006 03:34:27 -0800 (PST) Message-ID: <025a01c61122$cf4dcae0$6801a8c0@IBMT41ML> From: "Marc Lasserre" To: "Shah, Himanshu" , "Dutta, Pranjal" , References: Date: Wed, 4 Jan 2006 12:34:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0257_01C6112B.30083CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 4c84a8aa52bdf533e792c08a691dbd02 Cc: Subject: Re: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0257_01C6112B.30083CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: VPLS question on MAC address withdrawalThanks Pranjal for your = previous replies. See my replies below. Marc ----- Original Message -----=20 From: Shah, Himanshu=20 To: Dutta, Pranjal ; l2vpn@ietf.org=20 Sent: Tuesday, January 03, 2006 3:24 PM Subject: RE: VPLS question on MAC address withdrawal Hi Pranjal, I think there is a disconnect. You are failing to understand the point I am raising. I perfectly understand what empty MAC address withdraw list does.=20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). Himanshu, It is true that empty withdrawals lead to a different behaviour than = withdrawals with a MAC list, and hence one could say that they can not be used = interchangeably. However, both message types result in handling topology changes by = unlearning MACs that are no longer behind the proper circuits/devices. An empty = withdrawal does lead to unlearning MACs that were not affected. The reasoning is = that there might cases where the newly active ingress PE-rs might not know the = specific list of MACs that need to be unlearned. As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such = circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all = the PE-rs to remove all the MAC addresses (for a given VPLS instances) = other than the ones switched over. Seems too expensive. In cases where such a list is available or when such a list if small = enough, the draft does not prevent such a capability (i.e. having the newly = active ingress PE-rs send a list of the MACs to be switched) from being implemented. /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Reg. the first part again excerpts from the = draft as below =20 For a MAC Address Withdraw message with empty list: - Remove all = the MAC addresses associated with the VPLS instance(specified by = the FEC TLV) except the MAC addresses learned over the PW = associated with this signaling session over which the message was = received The scope of a MAC List TLV is the VPLS specified in the = FEC TLV in the MAC Address Withdraw Message. The number of MAC = addresses can be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV = means delete the association between all MAC addresses associated with = the VPLS instance specified in by the FEC TLV within the address withdraw message. = This will not delete the association of MACs with the PW on which the = Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified = only.=20 =20 The second issue you raised is very interesting and has practical = implications. After PW switchover when, MTU originates the Address = Withdraw for all N PWs (one msg. for each PW). Those will be forwarded = by the "new" PE-rs to all peers thoughout the domain. Removal of all = MACs would cause spark of broadcast and considering the traffic for all = N FECs are flowing now via secondary PW, so associated MACs will get = relearned again across all the PEs. So broadcast will stop once = relearning completes. In the absence of MAC withdraw, traffic won't = broadcast, but will keep flowing to wrong ports (till the MACs ages out = or till relearning happens again). I think we need to see the time = window for the broadcast in a specified scenario/application where MAC = withdraw is being used. That could be also one of the reasons why MAC = withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, = we can implement some filtering mechanism to selectively block MAC = withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. = b'cast is not desired due to MAC withdraw). Anyway that is my = theoretical idea and could be implementation specific. =20 =20 =20 Regards, Pranjal -------------------------------------------------------------------------= --- From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. regards, himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Please see my answers inline Thanks, Pranjal ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal Hope somebody can shed light on the following questions.... (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List = TLV cut-and-paste from draft. 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC = addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV = in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. To simplify the problem, lets assume that for a given VPLS instance = A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd = MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite = result. That is, sending explicit list will cause the receiver to remove all 5 addresses = (lets assume that they all were associated with sender). But by sending, empty = MAC-address-withdrawal list, it will remove none. However, the draft says, In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. [Pranjal]: What the draft means is that with empty-list in MAC = withdraw TLV means remove "ALL" MACs. The processing entity of MAC List TLV (in Address = Withdraw Msg) needs to flush all MACs associated with a VPLS instance = when it receives MAC list TLV without any MAC address(s) in the list (empty list). = In case, of the MAC List TLV that contains specific MAC addresses then = the receiving entity needs to remove only those MAC addresses in = the list associated with VPLS instance (identifies by FEC in the address = withdraw msg). The withdrawl with empty list feature is to make it more scalable. For example, a = VPLS instance that has 1000 MACs learned at a PE need not send Address withdraw with 1000 MACs list, can send empty = list instead. But again it is optional (means if the MAC withdraw = originating PE wants It can send Address Withdraw with 1000 MACs list) and = implementation specific. Let's say for a dual homed MTU in HVPLS, the = primary link has 100 PWs (1 for each VPLS instance) and the secondary link = has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, = all will switch back to the secondary and MTU needs to send Address Withdraw with MACList TLV, one = for each of the 100 PWs. So, empty list would be preferable for each = message. (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc needs to be described. [Pranjal]: The draft says that the MAC withdraw originated at a MTU = (in MTU-PErs direction) needs to be processed and forwarded by PE-rs to other PEs. The draft hasn't specified about propagating MAC = withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU = direction). I think that part is implementation specific. The reason could be the = distant end MTUs will still be receiving the traffic in the primary link = and MAC withdrawl may not be necessary. regards, himanshu Himanshu Shah Ciena Corp ------=_NextPart_000_0257_01C6112B.30083CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: VPLS question = on MAC address withdrawal
Thanks Pranjal for your previous=20 replies.
See my replies below.
 
Marc
----- Original Message -----
From:=20 Shah, = Himanshu=20
To: Dutta, Pranjal ; l2vpn@ietf.org
Sent: Tuesday, January 03, 2006 = 3:24=20 PM
Subject: RE: VPLS question on = MAC address=20 withdrawal

Hi=20 Pranjal,
 
I think=20 there is a disconnect. You are failing to understand the=20 point
I am=20 raising.
 
I=20 perfectly understand what empty MAC address withdraw list does.=20
 
Please=20 go through the example I gave. The example clearly shows=20 that
MAC=20 address withdraw list and empty MAC address withdraw list=20 can
NOT be=20 used interchangeably (for scalability or for other=20 reasons).
 
Himanshu,
 
It=20 is true that empty withdrawals lead to a different behaviour than=20 withdrawals
with a MAC list, and hence one could say that they can = not be used=20 interchangeably.
However, both message types result in handling topology = changes by=20 unlearning
MACs that are no longer behind the proper = circuits/devices. An=20 empty withdrawal
does lead to unlearning MACs that were not affected. The = reasoning=20 is that there
might cases where the newly active ingress PE-rs might = not know=20 the specific list of
MACs that need to be unlearned.
 
As for=20 the second part, the failover causes MAC switchover at = the
expense=20 of disturbance to other MAC conversations that had=20 nothing
to do=20 with the failover. It would almost seem that under such=20 circumstances
MAC=20 Withdraw list with switchover MAC addresses from original=20 primary
PE-rs to=20 other PE-rs would make more sense than having to  make all the
PE-rs to=20 remove all the MAC addresses (for a given VPLS instances) other=20 than
the ones=20 switched over. Seems too expensive.
In=20 cases where such a list is available or when such a list if small=20 enough,
the draft does not prevent such a capability (i.e. = having the=20 newly active ingress PE-rs
send a list of the MACs to be switched)=20 from being implemented.
 
/himanshu
-----Original Message-----
From: Dutta, Pranjal=20 [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, January = 03, 2006=20 3:23 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address withdrawal

Hi=20 Himanshu,

           =          =20 Reg. the first part again excerpts from the draft as=20 below

 

For a MAC Address Withdraw =
message with empty list: 
     - Remove all the MAC addresses =
associated with the VPLS 
       instance(specified by =
the FEC TLV) except the MAC addresses =

       learned over the PW =
associated with this signaling session =

       over which the message =
was received 
   
  The scope of a MAC List TLV is the VPLS specified in =
the FEC TLV in 
  the MAC =
Address Withdraw Message.  The number of MAC addresses can =

  be deduced from the = length field=20 in the TLV

 

 

 In = the first=20 part as per my understanding goes, empty MAC list TLV means delete = the=20 association between all MAC addresses associated with the VPLS=20 instance

specified = in by the=20 FEC TLV within the address withdraw message. This will not delete = the=20 association of MACs with the PW on which the Address Withdraw = message with=20 empty MAC list is received.

So as = specified in=20 draft the scope is limited to the FEC specified only.=20

 

The = second issue=20 you raised is very interesting and has practical implications. After = PW=20 switchover when, MTU originates the Address Withdraw for all N PWs = (one msg.=20 for each PW). Those will be forwarded by the =93new=94 PE-rs to all = peers=20 thoughout the domain. Removal of all MACs would cause spark of = broadcast and=20 considering the traffic for all N FECs are flowing now via secondary = PW, so=20 associated MACs will get relearned again across all the PEs. So = broadcast=20 will stop once relearning completes. In the absence of MAC withdraw, = traffic=20 won=92t broadcast, but will keep flowing to wrong ports (till the = MACs ages=20 out or till relearning happens again). I think we need to see the = time=20 window for the broadcast in a specified scenario/application where = MAC=20 withdraw is being used. That could be also one of the reasons why = MAC=20 withdraw is an optional feature in VPLS. =  

 

To = address the=20 broadcast issue when empty-list MAC withdraw is used, we can = implement some=20 filtering mechanism to selectively block MAC withdraw msg for some = FECs at=20 PE-rs/originating MTU (for PWs where temp. b=92cast is not desired = due to MAC=20 withdraw). Anyway that is my theoretical idea and could be = implementation=20 specific.   

 

 

Regards,

Pranjal

From: Shah,=20 Himanshu [mailto:hshah@ciena.com]
Sent: Monday, 02 January, = 2006 8:50=20 PM
To: Dutta, = Pranjal;=20 l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address = withdrawal

 

Hi Pranjal,

It seems easy to get = confused=20 that
mac address withdraw list TLV and empty mac = address
withdraw list=20 TLV are one and the same and can be used
interchangeably for = scalability.=20 But that is
clearly not true.

In MAC address withdraw list = TLV=20 with MAC addresses, receiver
removes the association between MAC=20 addresses in
the list and PW over which the signal is = received.

In=20 MAC address TLV list with no MAC addresses,
the receiver removes = the=20 association between all MAC addresses
EXCEPT the ones over which = he=20 receives this signal.

In the second part of the question, = empty MAC=20 address
withdraw List TLV receieved by secondary which now is=20 primary
PE-rs also has some issues. Broadcasting the empty = MAC
address=20 withdraw List TLV to all other PE-rs would create
broadcasts in = the core,=20 as it removes MAC addresses
learned from ALL N-PWs EXCEPT for = ones=20 learned on the
PW over which the signal was received.  This = needs to=20 be
carefully thought out=20 too.

regards,
himanshu

-----Original = Message-----
From:=20 Dutta, Pranjal [mailto:pdutta@riverstonenet.com<= /A>]
Sent:=20 Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address withdrawal

Hi=20 = Himanshu,

         &n= bsp;           =20 Please see my answers=20 = inline



Thanks,

Pranjal



_____________= ___________________

From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= On=20 Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 2:49 = AM
To:=20 l2vpn@ietf.org
Subject: VPLS question on MAC address=20 withdrawal





Hope somebody can shed light on = the=20 following questions....

(1)
There are two mechanisms = described=20 -
MAC address withdraw List TLV and empty MAC Address withdraw = List=20 TLV

cut-and-paste from draft.

6.2.2. Address Withdraw = Message=20 Containing MAC List TLV
 
  The processing for MAC = List TLV=20 received in an Address Withdraw
  Message = is:
 
 =20 For each MAC address in the TLV:
     - = Remove the=20 association between the MAC address and the AC=20 or
        PW over which this = message=20 is received
 
  For a MAC Address Withdraw message = with=20 empty list:
     - Remove all the MAC = addresses=20 associated with the = VPLS
       =20 instance  (specified by the FEC TLV) except the MAC=20 addresses
        learned over = the PW=20 associated with this signaling=20 session
        over which the = message=20 was received
 
  The scope of a MAC List TLV is the = VPLS=20 specified in the FEC TLV in
  the MAC Address Withdraw=20 Message.  The number of MAC addresses can
  be deduced = from the=20 length field in the TLV.

To simplify the problem, lets assume = that=20 for a given VPLS instance A there are only 5 MAC
addresses and = one PW. In=20 this case, for TCN-Triggererd MAC-address-withdrawal, sending
a = list of 5=20 MAC address vs sending an empty list achieves opposite result. That = is,=20 sending
explicit list will cause the receiver to remove all 5 = addresses=20 (lets assume that they all were
associated with sender). But by = sending,=20 empty MAC-address-withdrawal list, it will remove
none.  = However,=20 the draft says,

In order to minimize the impact on LDP = convergence=20 time, when the
  MAC list TLV contains a large number of MAC = addresses, it may be
  preferable to send a MAC address = withdrawal=20 message with an empty
  list.

[Pranjal]: What the = draft means=20 is that with empty-list in MAC withdraw TLV means remove "ALL"=20 = MACs.

          =    =20 The processing entity of MAC List TLV (in Address Withdraw Msg) = needs to=20 flush all MACs associated with a VPLS instance when it receives MAC = list=20 = TLV

          &n= bsp;    =20 without any MAC address(s) in the list (empty list). In case, of the = MAC=20 List TLV that contains specific MAC addresses then the=20 = receiving

         &n= bsp;     =20 entity needs to remove only those MAC addresses in the list = associated with=20 VPLS instance (identifies by FEC in the address withdraw msg). The = withdrawl=20 with empty=20 = list

          &= nbsp;    =20 feature is to make it more scalable. For example, a VPLS instance = that has=20 1000 MACs learned at a PE need not=20 = send

          &= nbsp;    =20 Address withdraw with 1000 MACs list, can send empty list instead. = But again=20 it is optional (means if the MAC withdraw originating PE=20 = wants

          =     =20 It can send Address Withdraw with 1000 MACs list) and implementation = specific. Let's say for a dual homed MTU in HVPLS, the primary link = has 100=20 = PWs

          &n= bsp;    =20 (1 for each VPLS instance) and the secondary link has the backup of = all the=20 100 PWs. Now if all 100 primary PWs fail then, all will switch back = to the=20 secondary and=20 = MTU

          &n= bsp;   =20 needs to send Address Withdraw with MACList TLV, one for each of the = 100=20 PWs. So, empty list would be preferable for each = message.

(2)
Is=20 MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user=20 facing PW, MTU-S<->PErs)?
If so, how, when, implication of = withdraw=20 msg from N-PW (PE<->PE) to U-PW, etc needs to
be=20 described.



[Pranjal]: The draft says that the MAC = withdraw=20 originated at a MTU (in MTU-PErs direction) needs to be processed = and=20 forwarded by PE-rs

to other PEs. The draft hasn't specified = about=20 propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in = PErs->MTU direction). I think

that part is implementation=20 specific. The reason could be the distant end MTUs will still be = receiving=20 the traffic in the primary link and MAC withdrawl may not be=20 necessary.

regards,
himanshu

Himanshu Shah
Ciena = = Corp

= ------=_NextPart_000_0257_01C6112B.30083CF0-- From l2vpn-bounces@ietf.org Wed Jan 04 13:11:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuD6V-0006uk-3l; Wed, 04 Jan 2006 13:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuD6P-0006uW-Sp for l2vpn@megatron.ietf.org; Wed, 04 Jan 2006 13:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08356 for ; Wed, 4 Jan 2006 13:09:58 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuDBv-0002tf-DB for l2vpn@ietf.org; Wed, 04 Jan 2006 13:16:56 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 04 Jan 2006 10:04:05 -0800 X-IronPort-AV: i="3.99,330,1131350400"; d="scan'208,217"; a="387344822:sNHT1524146820" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k04I42YW015090; Wed, 4 Jan 2006 10:04:03 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 10:04:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61159.3FAB9B28" Date: Wed, 4 Jan 2006 10:04:04 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EBF42C67@xmb-sjc-21e.amer.cisco.com> Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agABvac6A= From: "Ali Sajassi \(sajassi\)" To: "Shah, Himanshu" , "Dutta, Pranjal" , X-OriginalArrivalTime: 04 Jan 2006 18:04:04.0723 (UTC) FILETIME=[3FD39430:01C61159] X-Spam-Score: 1.0 (+) X-Scan-Signature: 292db305ba6b0ffa7431a7a1bb4c4970 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61159.3FAB9B28 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Himanshu, =20 When this section was first written, the MAC address withdraw message was generated by the PE detecting the failed link or PW. This was incorrect because the backup link might not have come up yet and this message would have resulted in deleting MAC addresses without having any place to sent the traffic to and thus causing broadcast storms in the provider network.=20 =20 When I edited this section of the draft several years ago, I corrected this issue by modeling it after IEEE TCN operation. The version 4 of this draft based on my edit (which I happened to have) is as follow: =20 "The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the interface/pseudowire over which this message is received - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over this link (over the pseudowire associated with the signaling link over which the message is received)=20 - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV." =20 =20 As you can see, for the case of MAC address withdraw message with non-empty list, the message is sent over the newly activated link (just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT deleted as specified currently in the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that these MAC addresses are affected and now needs to be re-learned over this newly activated link, then this message can be used. =20 It seems like someone has changed the correct text based on my edit into the existing incorrect text but given that Vach and Marc are now the primary editors (and not me), they can take the credit for this :-) =20 -Ali ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Tuesday, January 03, 2006 6:24 AM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Himanshu, Reg. the first part again excerpts from the draft as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only.=20 =20 The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific. =20 =20 Regards, Pranjal =09 ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, =09 It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. =09 In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. =09 In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. =09 In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. =09 regards, himanshu =09 -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 Hi Himanshu, =09 Please see my answers inline =09 =09 =09 Thanks, =09 Pranjal =09 =09 =09 ________________________________ =09 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal =09 =09 =09 =09 =09 Hope somebody can shed light on the following questions.... =09 (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV =09 cut-and-paste from draft. =09 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. =09 To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove none. However, the draft says, =09 In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. =09 [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. =09 The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV =09 without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving =09 entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list =09 feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send =09 Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants =09 It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs =09 (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU =09 needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. =09 (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to be described. =09 =09 =09 [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs =09 to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think =09 that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. =09 regards, himanshu =09 Himanshu Shah Ciena Corp =09 =09 ------_=_NextPart_001_01C61159.3FAB9B28 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: VPLS question = on MAC address withdrawal
Hi Himanshu,
 
When this section was first written, the MAC = address=20 withdraw message was generated by the PE detecting the failed link or = PW. This=20 was incorrect because the backup link might not have come up yet = and this=20 message would have resulted in deleting MAC addresses without = having any=20 place to sent the traffic to and thus causing broadcast storms in = the=20 provider network.
 
When I edited this section of the draft = several years=20 ago, I corrected this issue by modeling it after IEEE TCN = operation. The=20 version 4 of this draft based on my edit (which I happened to have) is = as=20 follow:
 

"The processing for MAC TLVs received = in an=20 Address Withdraw Message is:

 =20 For each MAC address in the TLV:

-      =20 Relearn the association = between=20 the MAC address and the interface/pseudowire over which this message is=20 received

-      =20 Send the same message to = all other=20 PEs over the corresponding directed LDP = sessions.

 

 =20 For an Address Withdraw message with empty=20 list:

-      =20 Remove all the MAC = addresses=20 associated with the VPLS instance (specified by the FEC TLV) except the = MAC=20 addresses learned over this link (over the pseudowire associated with = the=20 signaling link over which the message is received) =

-      =20 Send the same message to = all other=20 PEs over the corresponding directed LDP = sessions.

 

The scope of a MAC TLV is the = VPLS=20 specified in the FEC TLV in the Address Withdraw Message.  The number of MAC addresses = can be=20 deduced from the length field in the TLV." =20

 
As you can see, for the case of MAC = address=20 withdraw message with non-empty list, the message is sent over the = newly=20 activated link (just like TCN) but with as list of MAC addresses to be=20 "RE-LEARNED" and NOT deleted as specified currently in the draft. = In other=20 words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the = PE know=20 that these MAC addresses are affected and now needs to be re-learned = over this=20 newly activated link, then this message can be used.
 
It seems like someone has changed the correct = text=20 based on my edit into the existing incorrect text but given = that Vach=20 and Marc are now the primary editors (and not me), they can take the = credit=20 for this :-)
 
-Ali

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah,=20 Himanshu
Sent: Tuesday, January 03, 2006 6:24 = AM
To:=20 Dutta, Pranjal; l2vpn@ietf.org
Subject: RE: VPLS question on = MAC=20 address withdrawal

Hi=20 Pranjal,
 
I think=20 there is a disconnect. You are failing to understand the=20 point
I am=20 raising.
 
I=20 perfectly understand what empty MAC address withdraw list does.=20
 
Please=20 go through the example I gave. The example clearly shows=20 that
MAC=20 address withdraw list and empty MAC address withdraw list=20 can
NOT be=20 used interchangeably (for scalability or for other=20 reasons).
 
As for=20 the second part, the failover causes MAC switchover at = the
expense=20 of disturbance to other MAC conversations that had=20 nothing
to do=20 with the failover. It would almost seem that under such=20 circumstances
MAC=20 Withdraw list with switchover MAC addresses from original=20 primary
PE-rs to=20 other PE-rs would make more sense than having to  make all the
PE-rs to=20 remove all the MAC addresses (for a given VPLS instances) other=20 than
the ones=20 switched over. Seems too expensive.
 
/himanshu
-----Original Message-----
From: Dutta, Pranjal=20 [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, January = 03, 2006=20 3:23 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address withdrawal

Hi=20 Himanshu,

           =          =20 Reg. the first part again excerpts from the draft as=20 below

 

For a MAC Address Withdraw =
message with empty list: 
     - Remove all the MAC addresses =
associated with the VPLS 
       instance(specified by =
the FEC TLV) except the MAC addresses =

       learned over the PW =
associated with this signaling session =

       over which the message =
was received 
   
  The scope of a MAC List TLV is the VPLS specified in =
the FEC TLV in 
  the MAC =
Address Withdraw Message.  The number of MAC addresses can =

  be deduced from the = length field=20 in the TLV

 

 

 In = the first=20 part as per my understanding goes, empty MAC list TLV means delete = the=20 association between all MAC addresses associated with the VPLS=20 instance

specified = in by the=20 FEC TLV within the address withdraw message. This will not delete = the=20 association of MACs with the PW on which the Address Withdraw = message with=20 empty MAC list is received.

So as = specified in=20 draft the scope is limited to the FEC specified only.=20

 

The = second issue=20 you raised is very interesting and has practical implications. After = PW=20 switchover when, MTU originates the Address Withdraw for all N PWs = (one msg.=20 for each PW). Those will be forwarded by the “new” PE-rs = to all peers=20 thoughout the domain. Removal of all MACs would cause spark of = broadcast and=20 considering the traffic for all N FECs are flowing now via secondary = PW, so=20 associated MACs will get relearned again across all the PEs. So = broadcast=20 will stop once relearning completes. In the absence of MAC withdraw, = traffic=20 won’t broadcast, but will keep flowing to wrong ports (till = the MACs ages=20 out or till relearning happens again). I think we need to see the = time=20 window for the broadcast in a specified scenario/application where = MAC=20 withdraw is being used. That could be also one of the reasons why = MAC=20 withdraw is an optional feature in VPLS. =  

 

To = address the=20 broadcast issue when empty-list MAC withdraw is used, we can = implement some=20 filtering mechanism to selectively block MAC withdraw msg for some = FECs at=20 PE-rs/originating MTU (for PWs where temp. b’cast is not = desired due to MAC=20 withdraw). Anyway that is my theoretical idea and could be = implementation=20 specific.   

 

 

Regards,

Pranjal

From: Shah,=20 Himanshu [mailto:hshah@ciena.com]
Sent: Monday, 02 January, = 2006 8:50=20 PM
To: Dutta, = Pranjal;=20 l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address = withdrawal

 

Hi Pranjal,

It seems easy to get = confused=20 that
mac address withdraw list TLV and empty mac = address
withdraw list=20 TLV are one and the same and can be used
interchangeably for = scalability.=20 But that is
clearly not true.

In MAC address withdraw list = TLV=20 with MAC addresses, receiver
removes the association between MAC=20 addresses in
the list and PW over which the signal is = received.

In=20 MAC address TLV list with no MAC addresses,
the receiver removes = the=20 association between all MAC addresses
EXCEPT the ones over which = he=20 receives this signal.

In the second part of the question, = empty MAC=20 address
withdraw List TLV receieved by secondary which now is=20 primary
PE-rs also has some issues. Broadcasting the empty = MAC
address=20 withdraw List TLV to all other PE-rs would create
broadcasts in = the core,=20 as it removes MAC addresses
learned from ALL N-PWs EXCEPT for = ones=20 learned on the
PW over which the signal was received.  This = needs to=20 be
carefully thought out=20 too.

regards,
himanshu

-----Original = Message-----
From:=20 Dutta, Pranjal [mailto:pdutta@riverstonenet.com<= /A>]
Sent:=20 Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address withdrawal

Hi=20 = Himanshu,

         &n= bsp;           =20 Please see my answers=20 = inline



Thanks,

Pranjal



_____________= ___________________

From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= On=20 Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 2:49 = AM
To:=20 l2vpn@ietf.org
Subject: VPLS question on MAC address=20 withdrawal





Hope somebody can shed light on = the=20 following questions....

(1)
There are two mechanisms = described=20 -
MAC address withdraw List TLV and empty MAC Address withdraw = List=20 TLV

cut-and-paste from draft.

6.2.2. Address Withdraw = Message=20 Containing MAC List TLV
 
  The processing for MAC = List TLV=20 received in an Address Withdraw
  Message = is:
 
 =20 For each MAC address in the TLV:
     - = Remove the=20 association between the MAC address and the AC=20 or
        PW over which this = message=20 is received
 
  For a MAC Address Withdraw message = with=20 empty list:
     - Remove all the MAC = addresses=20 associated with the = VPLS
       =20 instance  (specified by the FEC TLV) except the MAC=20 addresses
        learned over = the PW=20 associated with this signaling=20 session
        over which the = message=20 was received
 
  The scope of a MAC List TLV is the = VPLS=20 specified in the FEC TLV in
  the MAC Address Withdraw=20 Message.  The number of MAC addresses can
  be deduced = from the=20 length field in the TLV.

To simplify the problem, lets assume = that=20 for a given VPLS instance A there are only 5 MAC
addresses and = one PW. In=20 this case, for TCN-Triggererd MAC-address-withdrawal, sending
a = list of 5=20 MAC address vs sending an empty list achieves opposite result. That = is,=20 sending
explicit list will cause the receiver to remove all 5 = addresses=20 (lets assume that they all were
associated with sender). But by = sending,=20 empty MAC-address-withdrawal list, it will remove
none.  = However,=20 the draft says,

In order to minimize the impact on LDP = convergence=20 time, when the
  MAC list TLV contains a large number of MAC = addresses, it may be
  preferable to send a MAC address = withdrawal=20 message with an empty
  list.

[Pranjal]: What the = draft means=20 is that with empty-list in MAC withdraw TLV means remove "ALL"=20 = MACs.

          =    =20 The processing entity of MAC List TLV (in Address Withdraw Msg) = needs to=20 flush all MACs associated with a VPLS instance when it receives MAC = list=20 = TLV

          &n= bsp;    =20 without any MAC address(s) in the list (empty list). In case, of the = MAC=20 List TLV that contains specific MAC addresses then the=20 = receiving

         &n= bsp;     =20 entity needs to remove only those MAC addresses in the list = associated with=20 VPLS instance (identifies by FEC in the address withdraw msg). The = withdrawl=20 with empty=20 = list

          &= nbsp;    =20 feature is to make it more scalable. For example, a VPLS instance = that has=20 1000 MACs learned at a PE need not=20 = send

          &= nbsp;    =20 Address withdraw with 1000 MACs list, can send empty list instead. = But again=20 it is optional (means if the MAC withdraw originating PE=20 = wants

          =     =20 It can send Address Withdraw with 1000 MACs list) and implementation = specific. Let's say for a dual homed MTU in HVPLS, the primary link = has 100=20 = PWs

          &n= bsp;    =20 (1 for each VPLS instance) and the secondary link has the backup of = all the=20 100 PWs. Now if all 100 primary PWs fail then, all will switch back = to the=20 secondary and=20 = MTU

          &n= bsp;   =20 needs to send Address Withdraw with MACList TLV, one for each of the = 100=20 PWs. So, empty list would be preferable for each = message.

(2)
Is=20 MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user=20 facing PW, MTU-S<->PErs)?
If so, how, when, implication of = withdraw=20 msg from N-PW (PE<->PE) to U-PW, etc needs to
be=20 described.



[Pranjal]: The draft says that the MAC = withdraw=20 originated at a MTU (in MTU-PErs direction) needs to be processed = and=20 forwarded by PE-rs

to other PEs. The draft hasn't specified = about=20 propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in = PErs->MTU direction). I think

that part is implementation=20 specific. The reason could be the distant end MTUs will still be = receiving=20 the traffic in the primary link and MAC withdrawl may not be=20 necessary.

regards,
himanshu

Himanshu Shah
Ciena = = Corp

= ------_=_NextPart_001_01C61159.3FAB9B28-- From l2vpn-bounces@ietf.org Wed Jan 04 14:07:28 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuDyq-0004WY-Ln; Wed, 04 Jan 2006 14:07:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En17o-0000fJ-Gs; Thu, 15 Dec 2005 16:58:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21485; Thu, 15 Dec 2005 16:57:57 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En19H-0007ws-6C; Thu, 15 Dec 2005 17:00:28 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2005 13:58:45 -0800 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBFLwiQg002769; Thu, 15 Dec 2005 13:58:44 -0800 (PST) Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id NAA13760; Thu, 15 Dec 2005 13:58:44 -0800 (PST) Date: Thu, 15 Dec 2005 13:58:44 -0800 From: Toerless Eckert To: Suresh Boddapati Message-ID: <20051215135844.J25829@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Wed, 04 Jan 2006 14:07:18 -0500 Cc: l2vpn@ietf.org, 'Yakov Rekhter' , pim@ietf.org, 'Shane Amante' Subject: Re: [pim] RE: PIM Snooping X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org What i still don't understand is how IGMP Snoping or PIM Snooping are considered to be acceptable within the scope of L2VPNs. I quite frankly think that it is important to point out that using these two mechanisms very much breaks the transparency expectation that traditionally has been the primary reason of a customer to buy into an L2VPN service instead of let's say an L3VPN service. In my opinion, L2VPN is perfectly fine as long as the service required for multicast works well without snooping on PE nodes (aka: broadcast type multicast traffic), but once you need to have traffic constrainment only achievale with snooping, you should seriously consider an L3VPN service, because effectively you are running exactly the same tree building mechanisms now, just that in L3VPN you are making it based on explicit, standardized protocol interactions, and in L2VPN you would need to trust and pray for vendor specific PIM Snooping functionality to be compatible with the particular set of functions in PIM / IGMP that you as the customer are relying on - like Bidir, DR/DF priorities, any extensions like Proxies for InterAS, or for Dino's membership counting, different address families (IPv4, IPv6),... I don't understand why the base requirements of L2VPN services don't have a very strong statement about this basic principle - transparency of the service, and independence of protocol properties used on CE from what the SP is using. Surely each of the vendors will implement as much PIM, IGMP and foobar snooping as they can make money with, and that certainly includes Cisco, but that doesn't make it really a good thing to pursue that type of approach in the IETF. For example, we also have two drafts on IGMP out: one for IGMP snooping, the oher one for IGMP proxy routing. The proxy-routing is tageted for standards track, the snoping one just informational. That's i think as far as any other technology that depends on or describes snooping should go in the IETF. Cheers Toerless From l2vpn-bounces@ietf.org Wed Jan 04 14:07:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuDyr-0004X1-Cz; Wed, 04 Jan 2006 14:07:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuDfu-0006un-Ow for l2vpn@megatron.ietf.org; Wed, 04 Jan 2006 13:47:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12241 for ; Wed, 4 Jan 2006 13:46:38 -0500 (EST) Received: from zcars04e.nortel.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuDlM-00042B-AB for l2vpn@ietf.org; Wed, 04 Jan 2006 13:53:34 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k04Ihoj01021; Wed, 4 Jan 2006 13:43:50 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6115F.4BF9B08B" Date: Wed, 4 Jan 2006 13:47:19 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB646507B39AAE@zcarhxm1.corp.nortel.com> Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agABvac6AAH7pmQA== From: "Florin Balus" To: "Ali Sajassi \(sajassi\)" , "Shah, Himanshu" , "Dutta, Pranjal" , X-Spam-Score: 1.0 (+) X-Scan-Signature: 92abeebc7b3c56bc274d8238a52368c9 X-Mailman-Approved-At: Wed, 04 Jan 2006 14:07:18 -0500 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6115F.4BF9B08B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ali,=20 So what you are saying is that is better for the MTU-s that moved to a new PE-rs and subsequently the new PE-rs to readvertise the MAC addresses he knows about to avoid flooding. I assume that on reception of a non-empty MAC Address withdraw, the receiving PE-rs will remove the old entries pointing to the old PE-rs to avoid blackholing.=20 =20 This seems like a better alternative although if flooding is a concern, we should note that the second option (empty list) may generate much more flooding. =20 Nevertheless we should make sure there are interoperable implementations out there as it seems there are at least 2 versions... =20 =20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Wednesday, January 04, 2006 1:04 PM To: Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, =20 When this section was first written, the MAC address withdraw message was generated by the PE detecting the failed link or PW. This was incorrect because the backup link might not have come up yet and this message would have resulted in deleting MAC addresses without having any place to sent the traffic to and thus causing broadcast storms in the provider network.=20 =20 When I edited this section of the draft several years ago, I corrected this issue by modeling it after IEEE TCN operation. The version 4 of this draft based on my edit (which I happened to have) is as follow: =20 "The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the interface/pseudowire over which this message is received - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over this link (over the pseudowire associated with the signaling link over which the message is received)=20 - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV." =20 =20 As you can see, for the case of MAC address withdraw message with non-empty list, the message is sent over the newly activated link (just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT deleted as specified currently in the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that these MAC addresses are affected and now needs to be re-learned over this newly activated link, then this message can be used. =20 It seems like someone has changed the correct text based on my edit into the existing incorrect text but given that Vach and Marc are now the primary editors (and not me), they can take the credit for this :-) =20 -Ali _____ =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Tuesday, January 03, 2006 6:24 AM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Reg. the first part again excerpts from the draft as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only. =20 The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific. =20 =20 =20 Regards, Pranjal _____ =20 From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. regards, himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Please see my answers inline Thanks, Pranjal ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal Hope somebody can shed light on the following questions.... (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV cut-and-paste from draft. 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove none. However, the draft says, In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to be described. [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. regards, himanshu Himanshu Shah Ciena Corp ------_=_NextPart_001_01C6115F.4BF9B08B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Ali,
So=20 what you are saying is that is better for the MTU-s that moved to a new = PE-rs=20 and subsequently the new PE-rs to readvertise the MAC addresses he = knows=20 about to avoid flooding. I assume that on reception of = a = non-empty MAC=20 Address withdraw, the receiving PE-rs will remove the old entries = pointing=20 to the old PE-rs to avoid blackholing.
 
This=20 seems like a better alternative although if flooding is a concern, we = should=20 note that the second option (empty list) may generate much=20 more flooding.
 
Nevertheless we should make sure there are interoperable = implementations=20 out there as it seems there are at least 2=20 versions...  
 
-----Original = Message-----
From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Ali=20 Sajassi (sajassi)
Sent: Wednesday, January 04, 2006 1:04=20 PM
To: Shah, Himanshu; Dutta, Pranjal;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi Himanshu,
 
When this section was first written, the = MAC address=20 withdraw message was generated by the PE detecting the failed link or = PW. This=20 was incorrect because the backup link might not have come up yet = and this=20 message would have resulted in deleting MAC addresses without = having any=20 place to sent the traffic to and thus causing broadcast storms in = the=20 provider network.
 
When I edited this section of the draft = several years=20 ago, I corrected this issue by modeling it after IEEE TCN = operation. The=20 version 4 of this draft based on my edit (which I happened to have) is = as=20 follow:
 

"The processing for MAC TLVs = received in an=20 Address Withdraw Message is:

 =20 For each MAC address in the TLV:

-      =20 Relearn the = association between=20 the MAC address and the interface/pseudowire over which this message = is=20 received

-      =20 Send the same message = to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

 =20 For an Address Withdraw message with empty=20 list:

-      =20 Remove all the MAC = addresses=20 associated with the VPLS instance (specified by the FEC TLV) except = the MAC=20 addresses learned over this link (over the pseudowire associated with = the=20 signaling link over which the message is received)=20

-      =20 Send the same message = to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

The scope of a MAC TLV is = the VPLS=20 specified in the FEC TLV in the Address Withdraw Message.  The number of MAC addresses = can be=20 deduced from the length field in the TLV." =20

 
As you can see, for the case of MAC = address=20 withdraw message with non-empty list, the message is sent over = the newly=20 activated link (just like TCN) but with as list of MAC addresses to be = "RE-LEARNED" and NOT deleted as specified currently in the draft. = In=20 other words, if a VPLS has a few MAC addresses and a MTU-rs wants to = let the=20 PE know that these MAC addresses are affected and now needs to be = re-learned=20 over this newly activated link, then this message can be=20 used.
 
It seems like someone has changed the = correct text=20 based on my edit into the existing incorrect text but given = that=20 Vach and Marc are now the primary editors (and not me), they can take = the=20 credit for this :-)
 
-Ali

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah,=20 Himanshu
Sent: Tuesday, January 03, 2006 6:24 = AM
To:=20 Dutta, Pranjal; l2vpn@ietf.org
Subject: RE: VPLS question = on MAC=20 address withdrawal

Hi=20 Pranjal,
 
I=20 think there is a disconnect. You are failing to understand the=20 point
I am=20 raising.
 
I=20 perfectly understand what empty MAC address withdraw list does.=20
 
Please=20 go through the example I gave. The example clearly shows=20 that
MAC=20 address withdraw list and empty MAC address withdraw list=20 can
NOT be=20 used interchangeably (for scalability or for other=20 reasons).
 
As for=20 the second part, the failover causes MAC switchover at=20 the
expense of disturbance to other MAC = conversations=20 that had nothing
to do=20 with the failover. It would almost seem that under such=20 circumstances
MAC=20 Withdraw list with switchover MAC addresses from original=20 primary
PE-rs=20 to other PE-rs would make more sense than having to =  make all the
PE-rs=20 to remove all the MAC addresses (for a given VPLS instances) other=20 than
the=20 ones switched over. Seems too expensive.
 
/himanshu
-----Original Message-----
From: Dutta, Pranjal = [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, January = 03,=20 2006 3:23 AM
To: Shah, Himanshu;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address = withdrawal

Hi=20 Himanshu,

           =          =20 Reg. the first part again excerpts from the draft as=20 below

 

For a MAC Address Withdraw =
message with empty list: 
     - Remove all the MAC addresses =
associated with the VPLS 
       instance(specified by =
the FEC TLV) except the MAC addresses =

       learned over the PW =
associated with this signaling session =

       over which the message =
was received 
   
  The scope of a MAC List TLV is the VPLS specified in =
the FEC TLV in 
  the MAC =
Address Withdraw Message.  The number of MAC addresses can =

  be deduced from = the length=20 field in the TLV

 

 

 In the=20 first part as per my understanding goes, empty MAC list TLV means = delete=20 the association between all MAC addresses associated with the VPLS = instance

specified in by=20 the FEC TLV within the address withdraw message. This will not = delete the=20 association of MACs with the PW on which the Address Withdraw = message with=20 empty MAC list is received.

So as = specified=20 in draft the scope is limited to the FEC specified only.=20

 

The = second issue=20 you raised is very interesting and has practical implications. = After PW=20 switchover when, MTU originates the Address Withdraw for all N PWs = (one=20 msg. for each PW). Those will be forwarded by the = “new” PE-rs to all peers=20 thoughout the domain. Removal of all MACs would cause spark of = broadcast=20 and considering the traffic for all N FECs are flowing now via = secondary=20 PW, so associated MACs will get relearned again across all the = PEs. So=20 broadcast will stop once relearning completes. In the absence of = MAC=20 withdraw, traffic won’t broadcast, but will keep flowing to = wrong ports=20 (till the MACs ages out or till relearning happens again). I think = we need=20 to see the time window for the broadcast in a specified=20 scenario/application where MAC withdraw is being used. That could = be also=20 one of the reasons why MAC withdraw is an optional feature in = VPLS.=20  

 

To = address the=20 broadcast issue when empty-list MAC withdraw is used, we can = implement=20 some filtering mechanism to selectively block MAC withdraw msg for = some=20 FECs at PE-rs/originating MTU (for PWs where temp. b’cast is = not desired=20 due to MAC withdraw). Anyway that is my theoretical idea and could = be=20 implementation specific.   

 

 

Regards,

Pranjal

From:=20 Shah, Himanshu [mailto:hshah@ciena.com]
Sent: Monday, 02 January, = 2006 8:50=20 PM
To: Dutta, = Pranjal;=20 l2vpn@ietf.org
Subject:=20 RE: VPLS question on MAC address=20 withdrawal

 

Hi Pranjal,

It seems easy to get = confused=20 that
mac address withdraw list TLV and empty mac = address
withdraw=20 list TLV are one and the same and can be used
interchangeably = for=20 scalability. But that is
clearly not true.

In MAC = address=20 withdraw list TLV with MAC addresses, receiver
removes the = association=20 between MAC addresses in
the list and PW over which the signal = is=20 received.

In MAC address TLV list with no MAC = addresses,
the=20 receiver removes the association between all MAC = addresses
EXCEPT the=20 ones over which he receives this signal.

In the second part = of the=20 question, empty MAC address
withdraw List TLV receieved by = secondary=20 which now is primary
PE-rs also has some issues. Broadcasting = the empty=20 MAC
address withdraw List TLV to all other PE-rs would=20 create
broadcasts in the core, as it removes MAC = addresses
learned=20 from ALL N-PWs EXCEPT for ones learned on the
PW over which the = signal=20 was received.  This needs to be
carefully thought out=20 too.

regards,
himanshu

-----Original=20 Message-----
From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<= /A>]
Sent:=20 Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address withdrawal

Hi=20 = Himanshu,

         &n= bsp;           =20 Please see my answers=20 = inline



Thanks,

Pranjal



_____________= ___________________

From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= On=20 Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 2:49 = AM
To:=20 l2vpn@ietf.org
Subject: VPLS question on MAC address=20 withdrawal





Hope somebody can shed light on = the=20 following questions....

(1)
There are two mechanisms = described=20 -
MAC address withdraw List TLV and empty MAC Address withdraw = List=20 TLV

cut-and-paste from draft.

6.2.2. Address = Withdraw=20 Message Containing MAC List TLV
 
  The processing = for MAC=20 List TLV received in an Address Withdraw
  Message=20 is:
 
  For each MAC address in the=20 TLV:
     - Remove the association between = the MAC=20 address and the AC = or
        PW=20 over which this message is received
 
  For a MAC = Address=20 Withdraw message with empty list:
     - = Remove all=20 the MAC addresses associated with the=20 VPLS
        instance =20 (specified by the FEC TLV) except the MAC=20 addresses
        learned = over the=20 PW associated with this signaling=20 session
        over which = the=20 message was received
 
  The scope of a MAC List = TLV is=20 the VPLS specified in the FEC TLV in
  the MAC Address = Withdraw=20 Message.  The number of MAC addresses can
  be = deduced from=20 the length field in the TLV.

To simplify the problem, lets = assume=20 that for a given VPLS instance A there are only 5 MAC
addresses = and one=20 PW. In this case, for TCN-Triggererd MAC-address-withdrawal, = sending
a=20 list of 5 MAC address vs sending an empty list achieves opposite = result.=20 That is, sending
explicit list will cause the receiver to = remove all 5=20 addresses (lets assume that they all were
associated with = sender). But=20 by sending, empty MAC-address-withdrawal list, it will=20 remove
none.  However, the draft says,

In order to = minimize=20 the impact on LDP convergence time, when the
  MAC list = TLV=20 contains a large number of MAC addresses, it may be
  = preferable=20 to send a MAC address withdrawal message with an empty
 =20 list.

[Pranjal]: What the draft means is that with = empty-list in=20 MAC withdraw TLV means remove "ALL"=20 = MACs.

          =    =20 The processing entity of MAC List TLV (in Address Withdraw Msg) = needs to=20 flush all MACs associated with a VPLS instance when it receives = MAC list=20 = TLV

          &n= bsp;    =20 without any MAC address(s) in the list (empty list). In case, of = the MAC=20 List TLV that contains specific MAC addresses then the=20 = receiving

         &n= bsp;     =20 entity needs to remove only those MAC addresses in the list = associated=20 with VPLS instance (identifies by FEC in the address withdraw = msg). The=20 withdrawl with empty=20 = list

          &= nbsp;    =20 feature is to make it more scalable. For example, a VPLS instance = that has=20 1000 MACs learned at a PE need not=20 = send

          &= nbsp;    =20 Address withdraw with 1000 MACs list, can send empty list instead. = But=20 again it is optional (means if the MAC withdraw originating PE=20 = wants

          =     =20 It can send Address Withdraw with 1000 MACs list) and = implementation=20 specific. Let's say for a dual homed MTU in HVPLS, the primary = link has=20 100=20 = PWs

          &n= bsp;    =20 (1 for each VPLS instance) and the secondary link has the backup = of all=20 the 100 PWs. Now if all 100 primary PWs fail then, all will switch = back to=20 the secondary and=20 = MTU

          &n= bsp;   =20 needs to send Address Withdraw with MACList TLV, one for each of = the 100=20 PWs. So, empty list would be preferable for each = message.

(2)
Is=20 MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user=20 facing PW, MTU-S<->PErs)?
If so, how, when, implication = of=20 withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to
be = described.



[Pranjal]: The draft says that the MAC = withdraw=20 originated at a MTU (in MTU-PErs direction) needs to be processed = and=20 forwarded by PE-rs

to other PEs. The draft hasn't specified = about=20 propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS = (in=20 PErs->MTU direction). I think

that part is = implementation=20 specific. The reason could be the distant end MTUs will still be = receiving=20 the traffic in the primary link and MAC withdrawl may not be=20 necessary.

regards,
himanshu

Himanshu = Shah
Ciena=20 = Corp

=
------_=_NextPart_001_01C6115F.4BF9B08B-- From l2vpn-bounces@ietf.org Wed Jan 04 16:31:11 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGDu-0002M5-VW; Wed, 04 Jan 2006 16:31:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFnW-000078-TU for l2vpn@megatron.ietf.org; Wed, 04 Jan 2006 16:03:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29259 for ; Wed, 4 Jan 2006 16:02:38 -0500 (EST) Received: from howler.tri.sbc.com ([205.173.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuFt3-0001ck-Ec for l2vpn@ietf.org; Wed, 04 Jan 2006 16:09:39 -0500 Received: from sbctri.tri.sbc.com (J-144-60-9-139.tri.sbc.com [144.60.9.139]) by howler.tri.sbc.com (8.12.10/8.12.10) with ESMTP id k04L3RNc027284; Wed, 4 Jan 2006 15:03:29 -0600 (CST) Received: from TSMAIL.ad.tri.sbc.com (tsmail.ad.tri.sbc.com [144.60.55.228]) by sbctri.tri.sbc.com (8.12.10/8.12.10) with ESMTP id k04L3JEB011644; Wed, 4 Jan 2006 15:03:19 -0600 (CST) Received: from TSMAIL2.ad.tri.sbc.com ([144.60.55.226]) by TSMAIL.ad.tri.sbc.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 4 Jan 2006 15:03:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61172.49CA93FF" Date: Wed, 4 Jan 2006 15:03:18 -0600 Message-ID: <0CED449E95A92A42991EB71B778C17BF0226E38D@TSMAIL2.ad.tri.sbc.com> Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agABvac6AAH7pmQAAFUhNA From: "Serbest, Yetik" To: "Florin Balus" , "Ali Sajassi \(sajassi\)" , "Shah, Himanshu" , "Dutta, Pranjal" , X-OriginalArrivalTime: 04 Jan 2006 21:03:19.0159 (UTC) FILETIME=[49F84870:01C61172] X-Scanned-By: MIMEDefang 2.38 X-Spam-Score: 0.6 (/) X-Scan-Signature: 0c570d268ad236c74712319b5faffc41 X-Mailman-Approved-At: Wed, 04 Jan 2006 16:31:08 -0500 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61172.49CA93FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I remember Norm Finn explained this case and reasoning very clearly in his draft (see the following link). =20 http://www.watersprings.org/pub/id/draft-finn-ppvpn-bridging-vpls-00.txt =20 thanks, yetik =20 ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Florin Balus Sent: Wednesday, January 04, 2006 12:47 PM To: Ali Sajassi (sajassi); Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Ali,=20 So what you are saying is that is better for the MTU-s that moved to a new PE-rs and subsequently the new PE-rs to readvertise the MAC addresses he knows about to avoid flooding. I assume that on reception of a non-empty MAC Address withdraw, the receiving PE-rs will remove the old entries pointing to the old PE-rs to avoid blackholing.=20 =20 This seems like a better alternative although if flooding is a concern, we should note that the second option (empty list) may generate much more flooding. =20 Nevertheless we should make sure there are interoperable implementations out there as it seems there are at least 2 versions... =20 =20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Wednesday, January 04, 2006 1:04 PM To: Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, =20 When this section was first written, the MAC address withdraw message was generated by the PE detecting the failed link or PW. This was incorrect because the backup link might not have come up yet and this message would have resulted in deleting MAC addresses without having any place to sent the traffic to and thus causing broadcast storms in the provider network.=20 =20 When I edited this section of the draft several years ago, I corrected this issue by modeling it after IEEE TCN operation. The version 4 of this draft based on my edit (which I happened to have) is as follow: =20 "The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the interface/pseudowire over which this message is received - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over this link (over the pseudowire associated with the signaling link over which the message is received)=20 - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV." =20 =20 As you can see, for the case of MAC address withdraw message with non-empty list, the message is sent over the newly activated link (just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT deleted as specified currently in the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that these MAC addresses are affected and now needs to be re-learned over this newly activated link, then this message can be used. =20 It seems like someone has changed the correct text based on my edit into the existing incorrect text but given that Vach and Marc are now the primary editors (and not me), they can take the credit for this :-) =20 -Ali =20 =09 ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Tuesday, January 03, 2006 6:24 AM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Reg. the first part again excerpts from the draft as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only.=20 =20 The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific. =20 =20 Regards, Pranjal =09 ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, =09 It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. =09 In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. =09 In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. =09 In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. =09 regards, himanshu =09 -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 Hi Himanshu, =09 Please see my answers inline =09 =09 =09 Thanks, =09 Pranjal =09 =09 =09 ________________________________ =09 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal =09 =09 =09 =09 =09 Hope somebody can shed light on the following questions.... =09 (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV =09 cut-and-paste from draft. =09 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. =09 To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove none. However, the draft says, =09 In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. =09 [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. =09 The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV =09 without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving =09 entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list =09 feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send =09 Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants =09 It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs =09 (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU =09 needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. =09 (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to be described. =09 =09 =09 [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs =09 to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think =09 that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. =09 regards, himanshu =09 Himanshu Shah Ciena Corp ------_=_NextPart_001_01C61172.49CA93FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

As I remember Norm Finn explained = this case and reasoning very clearly in his draft (see the following = link).

 

http://www.watersprings.org/pub/id/draft-finn-ppvpn-bridging-vpl= s-00.txt

 

thanks,

=

yetik

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Florin Balus
Sent: Wednesday, January = 04, 2006 12:47 PM
To: Ali Sajassi = (sajassi); Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org
Subject: RE: VPLS = question on MAC address withdrawal

 

Hi Ali, =

So what you are saying is that is = better for the MTU-s that moved to a new PE-rs and subsequently the new PE-rs to readvertise the MAC addresses he knows about to avoid flooding. = I assume that on reception of a non-empty MAC Address withdraw, the = receiving PE-rs will remove the old entries pointing to the old PE-rs to = avoid blackholing.

 

This seems like a better = alternative although if flooding is a concern, we should note that the second = option (empty list) may generate much = more flooding.

 

Nevertheless we should make sure = there are interoperable implementations out there as it seems there are at least 2 versions...  

 

-----Original = Message-----
From: = l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On = Behalf Of Ali Sajassi (sajassi)
Sent: Wednesday, January = 04, 2006 1:04 PM
To: Shah, Himanshu; = Dutta, Pranjal; l2vpn@ietf.org
Subject: RE: VPLS = question on MAC address withdrawal

Hi = Himanshu,

 

When this section was first = written, the MAC address withdraw message was generated by the PE detecting the = failed link or PW. This was incorrect because the backup link might not = have come up yet and this message would have resulted in deleting MAC addresses = without having any place to sent the traffic to and thus causing broadcast = storms in the provider network.

 

When I edited this section of the = draft several years ago, I corrected this issue by modeling it after IEEE = TCN operation. The version 4 of this draft based on my edit (which I = happened to have) is as follow:

 

"The processing for MAC TLVs received in an Address = Withdraw Message is:

  For each MAC address in the = TLV:

-       = Relearn the association between the MAC address and the interface/pseudowire over which this message is = received

-       = Send the same message to all other PEs over the = corresponding directed LDP sessions.

 

=

  For an Address Withdraw message with empty = list:

-       = Remove all the MAC addresses associated with the VPLS = instance (specified by the FEC TLV) except the MAC addresses learned over this = link (over the pseudowire associated with the signaling link over which the = message is received)

-       = Send the same message to all other PEs over the = corresponding directed LDP sessions.

 

=

The scope of a MAC TLV is the VPLS specified in the FEC TLV = in the Address Withdraw Message.  The number of MAC addresses can be = deduced from the length field in the TLV." 

 

As you can see, for the case = of MAC address withdraw message with non-empty list, the message is sent = over the newly activated link (just like TCN) but with as list of MAC addresses = to be "RE-LEARNED" and NOT deleted as specified currently in = the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs = wants to let the PE know that these MAC addresses are affected and now needs to = be re-learned over this newly activated link, then this message can be = used.

 

It seems like someone has changed = the correct text based on my edit into the existing incorrect text = but given that Vach and Marc are now the primary editors (and not me), they = can take the credit for this :-)

 

-Ali

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu
Sent: Tuesday, January = 03, 2006 6:24 AM
To: Dutta, Pranjal; = l2vpn@ietf.org
Subject: RE: VPLS = question on MAC address withdrawal

Hi = Pranjal,

 

I think there = is a disconnect. You are failing to understand the = point

I am = raising.

 

I perfectly = understand what empty MAC address withdraw list does.

 

Please go = through the example I gave. The example clearly shows = that

MAC address = withdraw list and empty MAC address withdraw list = can

NOT be used interchangeably (for scalability or for other = reasons).

 

As for the = second part, the failover causes MAC switchover at = the

expense of = disturbance to other MAC conversations that had nothing

to do with = the failover. It would almost seem that under such = circumstances

MAC Withdraw = list with switchover MAC addresses from original = primary

PE-rs to = other PE-rs would make more sense than having to  make all = the

PE-rs to = remove all the MAC addresses (for a given VPLS instances) other = than

the ones = switched over. Seems too expensive.

 

/himanshu

-----Original = Message-----
From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, January = 03, 2006 3:23 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE: VPLS = question on MAC address withdrawal

Hi = Himanshu,

      =             &= nbsp;  Reg. the first part again excerpts from the draft as = below

 = 

For a MAC Address Withdraw message with empty =
list: 
     - Remove all =
the MAC addresses associated with the VPLS =

       inst=
ance(specified by the FEC TLV) except the MAC addresses =

       lear=
ned over the PW associated with this signaling session =

       over=
 which the message was received =

   
  The scope of a MAC List TLV is =
the VPLS specified in the FEC TLV in =

  the MAC Address Withdraw =
Message.  The number of MAC addresses can =




  be deduced from the length field in =
the TLV



 =




 =




 In the first part as per my
understanding goes, empty MAC list TLV means delete the association =
between all
MAC addresses associated with the VPLS =
instance



specified in by the FEC TLV within =
the
address withdraw message. This will not delete the association of MACs =
with the
PW on which the Address Withdraw message with empty MAC list is =
received.



So as specified in draft the scope =
is
limited to the FEC specified only. 



 



The second issue you raised is very
interesting and has practical implications. After PW switchover when, =
MTU
originates the Address Withdraw for all N PWs (one msg. for each PW). =
Those
will be forwarded by the “new” PE-rs to all peers thoughout =
the
domain. Removal of all MACs would cause spark of broadcast and =
considering the
traffic for all N FECs are flowing now via secondary PW, so associated =
MACs
will get relearned again across all the PEs. So broadcast will stop once
relearning completes. In the absence of MAC withdraw, traffic =
won’t broadcast,
but will keep flowing to wrong ports (till the MACs ages out or till =
relearning
happens again). I think we need to see the time window for the broadcast =
in a
specified scenario/application where MAC withdraw is being used. That =
could be
also one of the reasons why MAC withdraw is an optional feature in VPLS. =
 



 



To address the broadcast issue when
empty-list MAC withdraw is used, we can implement some filtering =
mechanism to
selectively block MAC withdraw msg for some FECs at PE-rs/originating =
MTU (for
PWs where temp. b’cast is not desired due to MAC withdraw). Anyway =
that
is my theoretical idea and could be implementation specific. =
  



 



 



Regards,


Pranjal
=















From: Shah, =
Himanshu
[mailto:hshah@ciena.com] 

Sent: Monday, 02 January, =
2006
8:50 PM

To: Dutta, Pranjal; =
l2vpn@ietf.org

Subject: RE: VPLS =
question on MAC
address withdrawal






 



Hi Pranjal,



It seems easy to get confused that

mac address withdraw list TLV and empty mac address

withdraw list TLV are one and the same and can be used

interchangeably for scalability. But that is

clearly not true.



In MAC address withdraw list TLV with MAC addresses, receiver

removes the association between MAC addresses in

the list and PW over which the signal is received.



In MAC address TLV list with no MAC addresses,

the receiver removes the association between all MAC addresses

EXCEPT the ones over which he receives this signal.



In the second part of the question, empty MAC address

withdraw List TLV receieved by secondary which now is primary

PE-rs also has some issues. Broadcasting the empty MAC

address withdraw List TLV to all other PE-rs would create

broadcasts in the core, as it removes MAC addresses

learned from ALL N-PWs EXCEPT for ones learned on the

PW over which the signal was received.  This needs to be

carefully thought out too.



regards,

himanshu



-----Original Message-----

From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<=
/a>]

Sent: Mon 1/2/2006 3:16 AM

To: Shah, Himanshu; l2vpn@ietf.org

Subject: RE: VPLS question on MAC address withdrawal



Hi Himanshu,



            &=
nbsp;        
Please see my answers inline







Thanks,



Pranjal







________________________________



From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=

On Behalf Of Shah, Himanshu

Sent: Friday, 30 December, 2005 2:49 AM

To: l2vpn@ietf.org

Subject: VPLS question on MAC address withdrawal











Hope somebody can shed light on the following questions....



(1)

There are two mechanisms described -

MAC address withdraw List TLV and empty MAC Address withdraw List =
TLV



cut-and-paste from draft.



6.2.2. Address Withdraw Message Containing MAC List TLV

 

  The processing for MAC List TLV received in an Address =
Withdraw

  Message is:

 

  For each MAC address in the TLV:

     - Remove the association between the MAC =
address and
the AC or

        PW over which this message is
received

 

  For a MAC Address Withdraw message with empty list:

     - Remove all the MAC addresses associated with =
the
VPLS

        instance  (specified by =
the FEC
TLV) except the MAC addresses

        learned over the PW =
associated with
this signaling session

        over which the message was =
received

 

  The scope of a MAC List TLV is the VPLS specified in the FEC TLV =
in

  the MAC Address Withdraw Message.  The number of MAC =
addresses can

  be deduced from the length field in the TLV.



To simplify the problem, lets assume that for a given VPLS instance A =
there are
only 5 MAC

addresses and one PW. In this case, for TCN-Triggererd =
MAC-address-withdrawal,
sending

a list of 5 MAC address vs sending an empty list achieves opposite =
result. That
is, sending

explicit list will cause the receiver to remove all 5 addresses (lets =
assume
that they all were

associated with sender). But by sending, empty MAC-address-withdrawal =
list, it
will remove

none.  However, the draft says,



In order to minimize the impact on LDP convergence time, when the

  MAC list TLV contains a large number of MAC addresses, it may =
be

  preferable to send a MAC address withdrawal message with an =
empty

  list.



[Pranjal]: What the draft means is that with empty-list in MAC withdraw =
TLV
means remove "ALL" MACs.



            &=
nbsp;
The processing entity of MAC List TLV (in Address Withdraw Msg) needs to =
flush
all MACs associated with a VPLS instance when it receives MAC list =
TLV



            &=
nbsp;  
without any MAC address(s) in the list (empty list). In case, of the MAC =
List
TLV that contains specific MAC addresses then the receiving



            &=
nbsp;  
entity needs to remove only those MAC addresses in the list associated =
with
VPLS instance (identifies by FEC in the address withdraw msg). The =
withdrawl
with empty list



            &=
nbsp;  
feature is to make it more scalable. For example, a VPLS instance that =
has 1000
MACs learned at a PE need not send



            &=
nbsp;  
Address withdraw with 1000 MACs list, can send empty list instead. But =
again it
is optional (means if the MAC withdraw originating PE wants



            &=
nbsp; 
It can send Address Withdraw with 1000 MACs list) and implementation =
specific.
Let's say for a dual homed MTU in HVPLS, the primary link has 100 =
PWs



            &=
nbsp;  
(1 for each VPLS instance) and the secondary link has the backup of all =
the 100
PWs. Now if all 100 primary PWs fail then, all will switch back to the
secondary and MTU



            &=
nbsp; 
needs to send Address Withdraw with MACList TLV, one for each of the 100 =
PWs.
So, empty list would be preferable for each message.



(2)

Is MAC-Address-withdraw mechanism ever intended to be used for U-PW =
(user
facing PW, MTU-S<->PErs)?

If so, how, when, implication of withdraw msg from N-PW (PE<->PE) =
to
U-PW, etc needs to

be described.







[Pranjal]: The draft says that the MAC withdraw originated at a MTU (in
MTU-PErs direction) needs to be processed and forwarded by PE-rs



to other PEs. The draft hasn't specified about propagating MAC withdraw =
by PEs
to the distant-end MTUs in HVPLS (in PErs->MTU direction). I =
think



that part is implementation specific. The reason could be the distant =
end MTUs
will still be receiving the traffic in the primary link and MAC =
withdrawl may
not be necessary.



regards,

himanshu



Himanshu Shah

Ciena Corp
------_=_NextPart_001_01C61172.49CA93FF-- From l2vpn-bounces@ietf.org Thu Jan 05 10:10:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWkm-0004E5-SJ; Thu, 05 Jan 2006 10:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuWkj-0004Du-JO for l2vpn@megatron.ietf.org; Thu, 05 Jan 2006 10:10:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25155 for ; Thu, 5 Jan 2006 10:08:53 -0500 (EST) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuWqR-0005hp-CU for l2vpn@ietf.org; Thu, 05 Jan 2006 10:16:03 -0500 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 10:09:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6120A.157561FA" Date: Thu, 5 Jan 2006 10:09:54 -0500 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYRISd78WdXBCVcSHaeo++D5vBTewAZmeOw From: "Shah, Himanshu" To: "Marc Lasserre" , X-OriginalArrivalTime: 05 Jan 2006 15:09:55.0211 (UTC) FILETIME=[15D855B0:01C6120A] X-Spam-Score: 0.9 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: "Libby, Mark" Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6120A.157561FA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Marc, =20 It seems that you and pranjal are taking narrower view of the use of MAC address withdraw mechanism. This being its use during failovers to backup PE-rs in H-VPLS topology. =20 My concern is for general cases. If a TCN was triggered 5 hops deep in C-STP land and is being propagated from root to leaves. If PE-rs or MTU-s is monitoring such TCN and triggers MAC address withdraw then empty and non-empty MAC address withdraw is going to achieve different results at receiving PE-rs (as was described in my previous emails). =20 If MAC address withdraw is strictly used for H-VPLS topology for failover from primary to secondary PE-rs, then you should=20 state this restriction in the draft. If not, then may be you need another qualifier (i.e. flag) for empty MAC address withdraw list which states for a given VPLS instance, 1) age out all MAC except ones learned on PW receiving this signal ( = current ) 2) age out all MAC that are learned on PW receiving this signal (new) 3) age out all MAC (new) =20 regards, himanshu -----Original Message----- From: Marc Lasserre [mailto:marc@riverstonenet.com] Sent: Wednesday, January 04, 2006 6:22 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: Re: VPLS question on MAC address withdrawal Himanshu, =20 Sorry to jump a bit late in this discussion. See my answers below. =20 Cheers, Marc ----- Original Message -----=20 From: Shah, Himanshu =20 To: l2vpn@ietf.org=20 Sent: Thursday, December 29, 2005 10:19 PM Subject: VPLS question on MAC address withdrawal Hope somebody can shed light on the following questions....=20 (1)=20 There are two mechanisms described -=20 MAC address withdraw List TLV and empty MAC Address withdraw List TLV=20 cut-and-paste from draft.=20 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV.=20 To simplify the problem, lets assume that for a given VPLS instance A = there are only 5 MAC=20 addresses and one PW. In this case, for TCN-Triggererd = MAC-address-withdrawal, sending=20 a list of 5 MAC address vs sending an empty list achieves opposite = result. That is, sending=20 explicit list will cause the receiver to remove all 5 addresses (lets = assume that they all were=20 associated with sender). But by sending, empty MAC-address-withdrawal = list, it will remove=20 none. However, the draft says,=20 Sending an empty MAC withdraw message will trigger all MACs to be = unlearned (the 5 MACs in your examples). Only MACs behing the newly active PE-rs would be = preserved. In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list.=20 (2)=20 Is MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user facing PW, MTU-S<->PErs)?=20 If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc needs to=20 be described.=20 The main intent is for an MTU-s to trigger MAC withdrawal to its = directly attached PE-rs. The PE-rs will propagate MAC withdrawal messages to its peer PEs. There is no = withdrawal event to be performed by egress MTUs. The triggering events for sending MAC withdrawals can be based on = different failure detection mechanisms (eg STP based TCNs, BFD, etc). regards,=20 himanshu=20 Himanshu Shah=20 Ciena Corp=20 ------_=_NextPart_001_01C6120A.157561FA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VPLS question on MAC address withdrawal
Hi=20 Marc,
 
It seems=20 that you and pranjal are taking narrower view of the use = of
MAC=20 address withdraw mechanism. This being its use = during
failovers=20 to backup PE-rs in H-VPLS topology.
 
My concern=20 is for general cases. If a TCN was triggered 5 hops
deep in=20 C-STP land and is being propagated from root to = leaves.
If PE-rs=20 or MTU-s is monitoring such TCN and triggers MAC
address=20 withdraw then empty and non-empty MAC address
withdraw=20 is going to achieve different results at receiving = PE-rs
(as was=20 described in my previous emails).
 
If MAC=20 address withdraw is strictly used for H-VPLS = topology
for=20 failover from primary to secondary PE-rs, then you should =
state this=20 restriction in the draft. If not, then may be you = need
another=20 qualifier (i.e. flag) for empty MAC address withdraw list=20 which
states for=20 a given VPLS instance,
1) age out=20 all MAC except ones learned on PW receiving this signal ( current=20 )
2) age out=20 all MAC that are learned on PW receiving this signal = (new)
3) age out=20 all MAC (new)
 
regards,
himanshu
-----Original Message-----
From: Marc Lasserre=20 [mailto:marc@riverstonenet.com]
Sent: Wednesday, January 04, = 2006=20 6:22 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: Re:=20 VPLS question on MAC address withdrawal

Himanshu,
 
Sorry to jump a bit late in this=20 discussion.
See my answers below.
 
Cheers,
Marc
----- Original Message -----
From:=20 Shah, = Himanshu=20
Sent: Thursday, December 29, = 2005 10:19=20 PM
Subject: VPLS question on MAC = address=20 withdrawal


Hope somebody can shed light = on the=20 following questions....

(1)
There are two mechanisms described -
MAC address withdraw List TLV and = empty MAC=20 Address withdraw List TLV

cut-and-paste from = draft.

6.2.2. Address Withdraw = Message=20 Containing MAC List TLV
  
  The processing for = MAC=20 List TLV received in an Address Withdraw
  Message=20 is:
  
  For each MAC address in the=20 TLV:
     - Remove the association between = the MAC=20 address and the AC or
        = PW over=20 which this message is received
  
  For a MAC = Address=20 Withdraw message with empty list:
     - = Remove all=20 the MAC addresses associated with the=20 VPLS
        instance  = (specified=20 by the FEC TLV) except the MAC=20 addresses
        learned over = the PW=20 associated with this signaling=20 session
        over which the = message=20 was received
  
  The scope of a MAC List TLV = is the=20 VPLS specified in the FEC TLV in
  the MAC Address Withdraw=20 Message.  The number of MAC addresses can
  be deduced = from the=20 length field in the TLV.

To simplify the problem, = lets assume=20 that for a given VPLS instance A there are only 5 MAC =
addresses and one PW. In this case, = for=20 TCN-Triggererd MAC-address-withdrawal, sending
a list of 5 MAC address vs sending an = empty list=20 achieves opposite result. That is, sending
explicit list will cause the receiver = to remove=20 all 5 addresses (lets assume that they all were
associated with sender). But by = sending, empty=20 MAC-address-withdrawal list, it will remove
none.  However, the draft = says,=20

Sending an empty MAC = withdraw=20 message will trigger all MACs to be unlearned (the 5 MACs

in your examples). = Only MACs=20 behing the newly active PE-rs would be preserved.

In order to minimize the = impact on LDP=20 convergence time, when the
  MAC list TLV contains a large = number of=20 MAC addresses, it may be
  preferable to send a MAC address=20 withdrawal message with an empty
  list.

(2)
Is MAC-Address-withdraw mechanism ever intended to be used = for U-PW=20 (user facing PW, MTU-S<->PErs)?
If so, how, when, implication of withdraw msg from N-PW=20 (PE<->PE) to U-PW, etc needs to
be described.

The main intent is = for an MTU-s to=20 trigger MAC withdrawal to its directly attached PE-rs. The PE-rs=20 will

propagate MAC = withdrawal messages=20 to its peer PEs. There is no withdrawal event to be performed by=20 egress

MTUs. The triggering = events for=20 sending MAC withdrawals can be based on different failure = detection

mechanisms (eg STP = based TCNs,=20 BFD, etc).

regards,
himanshu

Himanshu Shah
Ciena Corp =

------_=_NextPart_001_01C6120A.157561FA-- From l2vpn-bounces@ietf.org Thu Jan 05 11:56:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYPr-0005jw-1I; Thu, 05 Jan 2006 11:56:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYPp-0005j5-0I for l2vpn@megatron.ietf.org; Thu, 05 Jan 2006 11:56:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09292 for ; Thu, 5 Jan 2006 11:55:25 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYVW-0001ez-KU for l2vpn@ietf.org; Thu, 05 Jan 2006 12:02:35 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 05 Jan 2006 08:56:25 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05GuOjt010804; Thu, 5 Jan 2006 08:56:24 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 08:56:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61218.F329BFC5" Date: Thu, 5 Jan 2006 08:56:18 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EBF43006@xmb-sjc-21e.amer.cisco.com> Thread-Topic: RE: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agABvac6AAH7pmQAAugongAACbmYA= From: "Ali Sajassi \(sajassi\)" To: "Florin Balus" , "Shah, Himanshu" , "Dutta, Pranjal" , X-OriginalArrivalTime: 05 Jan 2006 16:56:20.0006 (UTC) FILETIME=[F37ABC60:01C61218] X-Spam-Score: 0.7 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61218.F329BFC5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Florin, Please see my reply in line ... =20 ________________________________ From: Florin Balus [mailto:balus@nortel.com]=20 Sent: Wednesday, January 04, 2006 10:47 AM To: Ali Sajassi (sajassi); Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Ali,=20 So what you are saying is that is better for the MTU-s that moved to a new PE-rs and subsequently the new PE-rs to readvertise the MAC addresses he knows about to avoid flooding. I assume that on reception of a non-empty MAC Address withdraw, the receiving PE-rs will remove the old entries pointing to the old PE-rs to avoid blackholing.=20 [AS] Yes, MTU-s will notify the PE-rs via its newly activated PW and subsequently PE-rs will notify other PE-rs to take the same action. =20 This seems like a better alternative although if flooding is a concern, we should note that the second option (empty list) may generate much more flooding. [AS] The main point of sending both messages (MAC withdraw message with empty-list and MAC withdraw message with non-empty list) over newly activated link is to avoid BLACKHOLING and unnecessary flooding. The fact that the message with empty-list creates more flooding is the price we pay for its simplicity but it is consistent with the operation of current IEEE bridges.=20 =20 Nevertheless we should make sure there are interoperable implementations out there as it seems there are at least 2 versions... =20 [AS] Yes, we need to correct the current rev. of the draft.=20 =20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Wednesday, January 04, 2006 1:04 PM To: Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Himanshu, =20 When this section was first written, the MAC address withdraw message was generated by the PE detecting the failed link or PW. This was incorrect because the backup link might not have come up yet and this message would have resulted in deleting MAC addresses without having any place to sent the traffic to and thus causing broadcast storms in the provider network.=20 =20 When I edited this section of the draft several years ago, I corrected this issue by modeling it after IEEE TCN operation. The version 4 of this draft based on my edit (which I happened to have) is as follow: =20 "The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the interface/pseudowire over which this message is received - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over this link (over the pseudowire associated with the signaling link over which the message is received)=20 - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV." =20 =20 As you can see, for the case of MAC address withdraw message with non-empty list, the message is sent over the newly activated link (just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT deleted as specified currently in the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that these MAC addresses are affected and now needs to be re-learned over this newly activated link, then this message can be used. =20 It seems like someone has changed the correct text based on my edit into the existing incorrect text but given that Vach and Marc are now the primary editors (and not me), they can take the credit for this :-) =20 -Ali ------_=_NextPart_001_01C61218.F329BFC5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Florin,
Please see my reply in line = ...
 

From: Florin Balus = [mailto:balus@nortel.com]=20
Sent: Wednesday, January 04, 2006 10:47 AM
To: = Ali=20 Sajassi (sajassi); Shah, Himanshu; Dutta, Pranjal;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi=20 Ali,
So=20 what you are saying is that is better for the MTU-s that moved to a = new PE-rs=20 and subsequently the new PE-rs to readvertise the MAC addresses = he knows=20 about to avoid flooding. I assume that on reception of = a=20 non-empty MAC Address withdraw, the receiving PE-rs will remove = the old=20 entries pointing to the old PE-rs to avoid blackholing.
[AS] Yes, MTU-s = will notify=20 the PE-rs via its newly activated PW and subsequently PE-rs = will=20 notify other PE-rs to take the same=20 action.
 
This seems like a better alternative although if flooding is = a concern,=20 we should note that the second option (empty list) may generate = much=20 more flooding.
[AS] The main point of sending both = messages (MAC=20 withdraw message with empty-list and MAC withdraw message with = non-empty list)=20 over newly activated link is to avoid BLACKHOLING and unnecessary = flooding. The fact that the message with empty-list creates = more=20 flooding is the price we pay for its simplicity but it is = consistent with=20 the operation of current IEEE=20 bridges. 
 
Nevertheless we should make sure there are interoperable=20 implementations out there as it seems there are at least 2=20 versions...  
[AS] Yes, we need to correct the  current = rev. of=20 the draft. 
 
-----Original = Message-----
From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Ali=20 Sajassi (sajassi)
Sent: Wednesday, January 04, 2006 1:04=20 PM
To: Shah, Himanshu; Dutta, Pranjal;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi Himanshu,
 
When this section was first written, the = MAC=20 address withdraw message was generated by the PE detecting the = failed link=20 or PW. This was incorrect because the backup link might not = have come=20 up yet and this message would have resulted in deleting MAC = addresses=20 without having any place to sent the traffic to and = thus causing=20 broadcast storms in the provider network.
 
When I edited this section of the draft = several=20 years ago, I corrected this issue by modeling it after IEEE TCN = operation. The version 4 of this draft based on my edit (which I = happened to=20 have) is as follow:
 

"The processing for MAC TLVs = received in an=20 Address Withdraw Message is:

  For each MAC address in = the=20 TLV:

-      =20 Relearn the = association=20 between the MAC address and the interface/pseudowire over which this = message=20 is received

-      =20 Send the same = message to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

  For an Address Withdraw = message with=20 empty list:

-      =20 Remove all the MAC = addresses=20 associated with the VPLS instance (specified by the FEC TLV) except = the MAC=20 addresses learned over this link (over the pseudowire associated = with the=20 signaling link over which the message is received)=20

-      =20 Send the same = message to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

The scope of a MAC TLV is = the VPLS=20 specified in the FEC TLV in the Address Withdraw Message.  The number of MAC = addresses can be=20 deduced from the length field in the TLV." =20

 
As you can see, for the case of MAC = address=20 withdraw message with non-empty list, the message is sent over = the=20 newly activated link (just like TCN) but with as list of MAC = addresses to be=20 "RE-LEARNED" and NOT deleted as specified currently in the = draft. In=20 other words, if a VPLS has a few MAC addresses and a MTU-rs wants to = let the=20 PE know that these MAC addresses are affected and now needs to be = re-learned=20 over this newly activated link, then this message can be=20 used.
 
It seems like someone has changed the = correct text=20 based on my edit into the existing incorrect text but = given that=20 Vach and Marc are now the primary editors (and not me), they can = take the=20 credit for this :-)
 
-Ali
------_=_NextPart_001_01C61218.F329BFC5-- From l2vpn-bounces@ietf.org Thu Jan 05 14:01:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaMn-00080z-BK; Thu, 05 Jan 2006 14:01:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaMk-00080L-T4 for l2vpn@megatron.ietf.org; Thu, 05 Jan 2006 14:01:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27483 for ; Thu, 5 Jan 2006 14:00:22 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaSU-0006uv-2f for l2vpn@ietf.org; Thu, 05 Jan 2006 14:07:34 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 05 Jan 2006 11:01:28 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k05J1Sc1018645; Thu, 5 Jan 2006 11:01:28 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 11:01:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6122A.6E94F8B9" Date: Thu, 5 Jan 2006 11:01:27 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EBF430A5@xmb-sjc-21e.amer.cisco.com> Thread-Topic: RE: VPLS question on MAC address withdrawal Thread-Index: AcYSKm42f+QHLxQeQ5a/Rx86pQbmyQ== From: "Ali Sajassi \(sajassi\)" To: "Shah, Himanshu" , "Dutta, Pranjal" , X-OriginalArrivalTime: 05 Jan 2006 19:01:28.0329 (UTC) FILETIME=[6EC9E790:01C6122A] X-Spam-Score: 0.6 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: "Libby, Mark" Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6122A.6E94F8B9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I agree. If there is no objection to this proposal, lets include it in the next rev. of the document. =20 -Ali ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Thursday, January 05, 2006 7:28 AM To: Ali Sajassi (sajassi); Dutta, Pranjal; l2vpn@ietf.org Cc: Libby, Mark Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Ali, =20 It is a good suggestion and it would help in broadcast dampening, as you suggest. May be a qualifier can be added in the MAC address withdraw list TLV to=20 1) delete the MAC addresses in the list (current) 2) re-learn the MAC addresses in the list to the PW over which this signal is received (new - your suggestion) =20 I also suggested an additional qualifier for empty MAC address withdraw list to make operations for empty and non-empty list consistent. =20 /himanshu =20 -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Wednesday, January 04, 2006 1:04 PM To: Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Himanshu, =20 When this section was first written, the MAC address withdraw message was generated by the PE detecting the failed link or PW. This was incorrect because the backup link might not have come up yet and this message would have resulted in deleting MAC addresses without having any place to sent the traffic to and thus causing broadcast storms in the provider network.=20 =20 When I edited this section of the draft several years ago, I corrected this issue by modeling it after IEEE TCN operation. The version 4 of this draft based on my edit (which I happened to have) is as follow: =20 "The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the interface/pseudowire over which this message is received - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over this link (over the pseudowire associated with the signaling link over which the message is received)=20 - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV." =20 =20 As you can see, for the case of MAC address withdraw message with non-empty list, the message is sent over the newly activated link (just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT deleted as specified currently in the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that these MAC addresses are affected and now needs to be re-learned over this newly activated link, then this message can be used. =20 It seems like someone has changed the correct text based on my edit into the existing incorrect text but given that Vach and Marc are now the primary editors (and not me), they can take the credit for this :-) =20 -Ali ------_=_NextPart_001_01C6122A.6E94F8B9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes, I agree. If there is no objection to this = proposal,=20 lets include it in the next rev. of the document.
 
-Ali

From: Shah, Himanshu = [mailto:hshah@ciena.com]=20
Sent: Thursday, January 05, 2006 7:28 AM
To: Ali = Sajassi=20 (sajassi); Dutta, Pranjal; l2vpn@ietf.org
Cc: Libby,=20 Mark
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi=20 Ali,
 
It is a=20 good suggestion and it would help in broadcast
dampening, as you suggest. May be a qualifier can=20 be
added in=20 the MAC address withdraw list TLV to
1)=20 delete the MAC addresses in the list (current)
2)=20 re-learn the MAC addresses in the list to the PW = over
    which this signal is received = (new -=20 your suggestion)
 
I also=20 suggested an additional qualifier for empty MAC = address
withdraw=20 list to make operations for empty and non-empty list=20 consistent.
 
/himanshu
 
-----Original Message-----
From: Ali Sajassi = (sajassi)=20 [mailto:sajassi@cisco.com]
Sent: Wednesday, January 04, = 2006 1:04=20 PM
To: Shah, Himanshu; Dutta, Pranjal;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi Himanshu,
 
When this section was first written, the = MAC=20 address withdraw message was generated by the PE detecting the = failed link=20 or PW. This was incorrect because the backup link might not = have come=20 up yet and this message would have resulted in deleting MAC = addresses=20 without having any place to sent the traffic to and = thus causing=20 broadcast storms in the provider network.
 
When I edited this section of the draft = several=20 years ago, I corrected this issue by modeling it after IEEE TCN = operation. The version 4 of this draft based on my edit (which I = happened to=20 have) is as follow:
 

"The processing for MAC TLVs = received in an=20 Address Withdraw Message is:

  For each MAC address in = the=20 TLV:

-      =20 Relearn the = association=20 between the MAC address and the interface/pseudowire over which this = message=20 is received

-      =20 Send the same = message to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

  For an Address Withdraw = message with=20 empty list:

-      =20 Remove all the MAC = addresses=20 associated with the VPLS instance (specified by the FEC TLV) except = the MAC=20 addresses learned over this link (over the pseudowire associated = with the=20 signaling link over which the message is received)=20

-      =20 Send the same = message to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

The scope of a MAC TLV is = the VPLS=20 specified in the FEC TLV in the Address Withdraw Message.  The number of MAC = addresses can be=20 deduced from the length field in the TLV." =20

 
As you can see, for the case of MAC = address=20 withdraw message with non-empty list, the message is sent over = the=20 newly activated link (just like TCN) but with as list of MAC = addresses to be=20 "RE-LEARNED" and NOT deleted as specified currently in the = draft. In=20 other words, if a VPLS has a few MAC addresses and a MTU-rs wants to = let the=20 PE know that these MAC addresses are affected and now needs to be = re-learned=20 over this newly activated link, then this message can be=20 used.
 
It seems like someone has changed the = correct text=20 based on my edit into the existing incorrect text but = given that=20 Vach and Marc are now the primary editors (and not me), they can = take the=20 credit for this :-)
 
-Ali
------_=_NextPart_001_01C6122A.6E94F8B9-- From l2vpn-bounces@ietf.org Thu Jan 05 14:20:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuafA-0001qz-Va; Thu, 05 Jan 2006 14:20:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuYKQ-0003Hj-Ij for l2vpn@megatron.ietf.org; Thu, 05 Jan 2006 11:51:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08387 for ; Thu, 5 Jan 2006 11:49:51 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuYQ5-0001P2-Rg for l2vpn@ietf.org; Thu, 05 Jan 2006 11:57:01 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 05 Jan 2006 08:50:54 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k05GomcH019954; Thu, 5 Jan 2006 08:50:53 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 08:50:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61218.2FC1B92B" Date: Thu, 5 Jan 2006 08:50:50 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EBF42FF9@xmb-sjc-21e.amer.cisco.com> Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agABvac6AAH7pmQAAugong From: "Ali Sajassi \(sajassi\)" To: "Florin Balus" , "Shah, Himanshu" , "Dutta, Pranjal" , X-OriginalArrivalTime: 05 Jan 2006 16:50:51.0990 (UTC) FILETIME=[2FF77760:01C61218] X-Spam-Score: 1.1 (+) X-Scan-Signature: 55feac791c210a7b8ad24a8d0de373fe X-Mailman-Approved-At: Thu, 05 Jan 2006 14:20:39 -0500 Cc: Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61218.2FC1B92B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Florin, Please see my reply in line ... =20 ________________________________ From: Florin Balus [mailto:balus@nortel.com]=20 Sent: Wednesday, January 04, 2006 10:47 AM To: Ali Sajassi (sajassi); Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Ali,=20 So what you are saying is that is better for the MTU-s that moved to a new PE-rs and subsequently the new PE-rs to readvertise the MAC addresses he knows about to avoid flooding. I assume that on reception of a non-empty MAC Address withdraw, the receiving PE-rs will remove the old entries pointing to the old PE-rs to avoid blackholing.=20 [AS] Yes, MTU-s will notify the PE-rs via its newly activated PW and subsequently PE-rs will notify other PE-rs to take the same action. =20 This seems like a better alternative although if flooding is a concern, we should note that the second option (empty list) may generate much more flooding. [AS] The main point of sending both messages (MAC withdraw message with empty-list and MAC withdraw message with non-empty list) over newly activated link is to avoid BLACKHOLING and unnecessary flooding. The fact that the message with empty-list creates more flooding is the price we pay for its simplicity but it is consistent with the operation of current IEEE bridges.=20 =20 Nevertheless we should make sure there are interoperable implementations out there as it seems there are at least 2 versions... =20 [AS] Yes, we need to correct the current rev. of the draft.=20 =20 -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi) Sent: Wednesday, January 04, 2006 1:04 PM To: Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Himanshu, =20 When this section was first written, the MAC address withdraw message was generated by the PE detecting the failed link or PW. This was incorrect because the backup link might not have come up yet and this message would have resulted in deleting MAC addresses without having any place to sent the traffic to and thus causing broadcast storms in the provider network.=20 =20 When I edited this section of the draft several years ago, I corrected this issue by modeling it after IEEE TCN operation. The version 4 of this draft based on my edit (which I happened to have) is as follow: =20 "The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the interface/pseudowire over which this message is received - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over this link (over the pseudowire associated with the signaling link over which the message is received)=20 - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV." =20 =20 As you can see, for the case of MAC address withdraw message with non-empty list, the message is sent over the newly activated link (just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT deleted as specified currently in the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that these MAC addresses are affected and now needs to be re-learned over this newly activated link, then this message can be used. =20 It seems like someone has changed the correct text based on my edit into the existing incorrect text but given that Vach and Marc are now the primary editors (and not me), they can take the credit for this :-) =20 -Ali ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Tuesday, January 03, 2006 6:24 AM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Himanshu, Reg. the first part again excerpts from the draft as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only.=20 =20 The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS. =20 To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific. =20 =20 =20 Regards, Pranjal =09 ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, =09 It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. =09 In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. =09 In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. =09 In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. =09 regards, himanshu =09 -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 Hi Himanshu, =09 Please see my answers inline =09 =09 =09 Thanks, =09 Pranjal =09 =09 =09 ________________________________ =09 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal =09 =09 =09 =09 =09 Hope somebody can shed light on the following questions.... =09 (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV =09 cut-and-paste from draft. =09 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. =09 To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove none. However, the draft says, =09 In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. =09 [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. =09 The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV =09 without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving =09 entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list =09 feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send =09 Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants =09 It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs =09 (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU =09 needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. =09 (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to be described. =09 =09 =09 [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs =09 to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think =09 that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. =09 regards, himanshu =09 Himanshu Shah Ciena Corp =09 =09 ------_=_NextPart_001_01C61218.2FC1B92B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Florin,
Please see my reply in line = ...
 

From: Florin Balus = [mailto:balus@nortel.com]=20
Sent: Wednesday, January 04, 2006 10:47 AM
To: = Ali=20 Sajassi (sajassi); Shah, Himanshu; Dutta, Pranjal;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi=20 Ali,
So=20 what you are saying is that is better for the MTU-s that moved to a = new PE-rs=20 and subsequently the new PE-rs to readvertise the MAC addresses = he knows=20 about to avoid flooding. I assume that on reception of = a=20 non-empty MAC Address withdraw, the receiving PE-rs will remove = the old=20 entries pointing to the old PE-rs to avoid blackholing.
[AS] Yes, MTU-s = will notify=20 the PE-rs via its newly activated PW and subsequently PE-rs = will=20 notify other PE-rs to take the same=20 action.
 
This seems like a better alternative although if flooding is = a concern,=20 we should note that the second option (empty list) may generate = much=20 more flooding.
[AS] The main point of sending both = messages (MAC=20 withdraw message with empty-list and MAC withdraw message with = non-empty list)=20 over newly activated link is to avoid BLACKHOLING and unnecessary = flooding. The fact that the message with empty-list creates = more=20 flooding is the price we pay for its simplicity but it is = consistent with=20 the operation of current IEEE=20 bridges. 
 
Nevertheless we should make sure there are interoperable=20 implementations out there as it seems there are at least 2=20 versions...  
[AS] Yes, we need to correct the  current = rev. of=20 the draft. 
 
-----Original = Message-----
From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Ali=20 Sajassi (sajassi)
Sent: Wednesday, January 04, 2006 1:04=20 PM
To: Shah, Himanshu; Dutta, Pranjal;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi Himanshu,
 
When this section was first written, the = MAC=20 address withdraw message was generated by the PE detecting the = failed link=20 or PW. This was incorrect because the backup link might not = have come=20 up yet and this message would have resulted in deleting MAC = addresses=20 without having any place to sent the traffic to and = thus causing=20 broadcast storms in the provider network.
 
When I edited this section of the draft = several=20 years ago, I corrected this issue by modeling it after IEEE TCN = operation. The version 4 of this draft based on my edit (which I = happened to=20 have) is as follow:
 

"The processing for MAC TLVs = received in an=20 Address Withdraw Message is:

  For each MAC address in = the=20 TLV:

-      =20 Relearn the = association=20 between the MAC address and the interface/pseudowire over which this = message=20 is received

-      =20 Send the same = message to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

  For an Address Withdraw = message with=20 empty list:

-      =20 Remove all the MAC = addresses=20 associated with the VPLS instance (specified by the FEC TLV) except = the MAC=20 addresses learned over this link (over the pseudowire associated = with the=20 signaling link over which the message is received)=20

-      =20 Send the same = message to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

The scope of a MAC TLV is = the VPLS=20 specified in the FEC TLV in the Address Withdraw Message.  The number of MAC = addresses can be=20 deduced from the length field in the TLV." =20

 
As you can see, for the case of MAC = address=20 withdraw message with non-empty list, the message is sent over = the=20 newly activated link (just like TCN) but with as list of MAC = addresses to be=20 "RE-LEARNED" and NOT deleted as specified currently in the = draft. In=20 other words, if a VPLS has a few MAC addresses and a MTU-rs wants to = let the=20 PE know that these MAC addresses are affected and now needs to be = re-learned=20 over this newly activated link, then this message can be=20 used.
 
It seems like someone has changed the = correct text=20 based on my edit into the existing incorrect text but = given that=20 Vach and Marc are now the primary editors (and not me), they can = take the=20 credit for this :-)
 
-Ali

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah,=20 Himanshu
Sent: Tuesday, January 03, 2006 6:24 = AM
To:=20 Dutta, Pranjal; l2vpn@ietf.org
Subject: RE: VPLS = question on MAC=20 address withdrawal

Hi=20 Pranjal,
 
I=20 think there is a disconnect. You are failing to understand the=20 point
I am=20 raising.
 
I=20 perfectly understand what empty MAC address withdraw list does.=20
 
Please go through the example I gave. The example = clearly=20 shows that
MAC=20 address withdraw list and empty MAC address withdraw list=20 can
NOT=20 be used interchangeably (for scalability or for other=20 reasons).
 
As=20 for the second part, the failover causes MAC switchover at=20 the
expense of disturbance to other = MAC=20 conversations that had nothing
to=20 do with the failover. It would almost seem that under such=20 circumstances
MAC=20 Withdraw list with switchover MAC addresses from original=20 primary
PE-rs to other PE-rs would make more sense than = having to=20  make all=20 the
PE-rs to remove all the MAC addresses (for a given = VPLS=20 instances) other than
the=20 ones switched over. Seems too expensive.
 
/himanshu
-----Original Message-----
From: Dutta, = Pranjal=20 [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, = January 03,=20 2006 3:23 AM
To: Shah, Himanshu;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC = address=20 withdrawal

Hi=20 Himanshu,

           =          =20 Reg. the first part again excerpts from the draft as=20 below

 

For a MAC Address Withdraw =
message with empty list: 
     - Remove all the MAC addresses =
associated with the VPLS 
       instance(specified by =
the FEC TLV) except the MAC addresses =

       learned over the PW =
associated with this signaling session =

       over which the message =
was received 
   
  The scope of a MAC List TLV is the VPLS specified in =
the FEC TLV in 
  the MAC =
Address Withdraw Message.  The number of MAC addresses can =

  be deduced from = the length=20 field in the TLV

 

 

 In the=20 first part as per my understanding goes, empty MAC list TLV = means delete=20 the association between all MAC addresses associated with the = VPLS=20 instance

specified in by=20 the FEC TLV within the address withdraw message. This will not = delete=20 the association of MACs with the PW on which the Address = Withdraw=20 message with empty MAC list is = received.

So as = specified=20 in draft the scope is limited to the FEC specified only.=20

 

The = second=20 issue you raised is very interesting and has practical = implications.=20 After PW switchover when, MTU originates the Address Withdraw = for all N=20 PWs (one msg. for each PW). Those will be forwarded by the = “new” PE-rs=20 to all peers thoughout the domain. Removal of all MACs would = cause spark=20 of broadcast and considering the traffic for all N FECs are = flowing now=20 via secondary PW, so associated MACs will get relearned again = across all=20 the PEs. So broadcast will stop once relearning completes. In = the=20 absence of MAC withdraw, traffic won’t broadcast, but will = keep flowing=20 to wrong ports (till the MACs ages out or till relearning = happens=20 again). I think we need to see the time window for the broadcast = in a=20 specified scenario/application where MAC withdraw is being used. = That=20 could be also one of the reasons why MAC withdraw is an optional = feature=20 in VPLS.  

 

To = address the=20 broadcast issue when empty-list MAC withdraw is used, we can = implement=20 some filtering mechanism to selectively block MAC withdraw msg = for some=20 FECs at PE-rs/originating MTU (for PWs where temp. b’cast = is not desired=20 due to MAC withdraw). Anyway that is my theoretical idea and = could be=20 implementation specific. =   

 

 

Regards,

Pranjal

From:=20 Shah, Himanshu [mailto:hshah@ciena.com]
Sent: Monday, 02 January, = 2006 8:50=20 PM
To: Dutta, = Pranjal;=20 l2vpn@ietf.org
Subject:=20 RE: VPLS question on MAC address=20 withdrawal

 

Hi Pranjal,

It seems easy to = get confused=20 that
mac address withdraw list TLV and empty mac = address
withdraw=20 list TLV are one and the same and can be used
interchangeably = for=20 scalability. But that is
clearly not true.

In MAC = address=20 withdraw list TLV with MAC addresses, receiver
removes the=20 association between MAC addresses in
the list and PW over = which the=20 signal is received.

In MAC address TLV list with no MAC=20 addresses,
the receiver removes the association between all = MAC=20 addresses
EXCEPT the ones over which he receives this=20 signal.

In the second part of the question, empty MAC=20 address
withdraw List TLV receieved by secondary which now is = primary
PE-rs also has some issues. Broadcasting the empty=20 MAC
address withdraw List TLV to all other PE-rs would=20 create
broadcasts in the core, as it removes MAC = addresses
learned=20 from ALL N-PWs EXCEPT for ones learned on the
PW over which = the=20 signal was received.  This needs to be
carefully thought = out=20 too.

regards,
himanshu

-----Original=20 Message-----
From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<= /A>]
Sent:=20 Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject:=20 RE: VPLS question on MAC address withdrawal

Hi=20 = Himanshu,

         &n= bsp;           =20 Please see my answers=20 = inline



Thanks,

Pranjal



_____________= ___________________

From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= =20 On Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 = 2:49=20 AM
To: l2vpn@ietf.org
Subject: VPLS question on MAC = address=20 withdrawal





Hope somebody can shed light = on the=20 following questions....

(1)
There are two mechanisms = described=20 -
MAC address withdraw List TLV and empty MAC Address = withdraw List=20 TLV

cut-and-paste from draft.

6.2.2. Address = Withdraw=20 Message Containing MAC List TLV
 
  The = processing for=20 MAC List TLV received in an Address Withdraw
  Message=20 is:
 
  For each MAC address in the=20 TLV:
     - Remove the association = between the=20 MAC address and the AC = or
       =20 PW over which this message is received
 
  For a = MAC=20 Address Withdraw message with empty = list:
     -=20 Remove all the MAC addresses associated with the=20 VPLS
        = instance =20 (specified by the FEC TLV) except the MAC=20 addresses
        learned = over the=20 PW associated with this signaling=20 session
        over which = the=20 message was received
 
  The scope of a MAC List = TLV is=20 the VPLS specified in the FEC TLV in
  the MAC Address = Withdraw=20 Message.  The number of MAC addresses can
  be = deduced from=20 the length field in the TLV.

To simplify the problem, = lets assume=20 that for a given VPLS instance A there are only 5 = MAC
addresses and=20 one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, = sending
a list of 5 MAC address vs sending an empty list = achieves=20 opposite result. That is, sending
explicit list will cause = the=20 receiver to remove all 5 addresses (lets assume that they all=20 were
associated with sender). But by sending, empty=20 MAC-address-withdrawal list, it will remove
none.  = However, the=20 draft says,

In order to minimize the impact on LDP = convergence=20 time, when the
  MAC list TLV contains a large number of = MAC=20 addresses, it may be
  preferable to send a MAC address=20 withdrawal message with an empty
  = list.

[Pranjal]: What=20 the draft means is that with empty-list in MAC withdraw TLV = means remove=20 "ALL"=20 = MACs.

          =    =20 The processing entity of MAC List TLV (in Address Withdraw Msg) = needs to=20 flush all MACs associated with a VPLS instance when it receives = MAC list=20 = TLV

          &n= bsp;    =20 without any MAC address(s) in the list (empty list). In case, of = the MAC=20 List TLV that contains specific MAC addresses then the=20 = receiving

         &n= bsp;     =20 entity needs to remove only those MAC addresses in the list = associated=20 with VPLS instance (identifies by FEC in the address withdraw = msg). The=20 withdrawl with empty=20 = list

          &= nbsp;    =20 feature is to make it more scalable. For example, a VPLS = instance that=20 has 1000 MACs learned at a PE need not=20 = send

          &= nbsp;    =20 Address withdraw with 1000 MACs list, can send empty list = instead. But=20 again it is optional (means if the MAC withdraw originating PE=20 = wants

          =     =20 It can send Address Withdraw with 1000 MACs list) and = implementation=20 specific. Let's say for a dual homed MTU in HVPLS, the primary = link has=20 100=20 = PWs

          &n= bsp;    =20 (1 for each VPLS instance) and the secondary link has the backup = of all=20 the 100 PWs. Now if all 100 primary PWs fail then, all will = switch back=20 to the secondary and=20 = MTU

          &n= bsp;   =20 needs to send Address Withdraw with MACList TLV, one for each of = the 100=20 PWs. So, empty list would be preferable for each=20 message.

(2)
Is MAC-Address-withdraw mechanism ever = intended=20 to be used for U-PW (user facing PW, MTU-S<->PErs)?
If = so, how,=20 when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc=20 needs to
be described.



[Pranjal]: The draft = says that=20 the MAC withdraw originated at a MTU (in MTU-PErs direction) = needs to be=20 processed and forwarded by PE-rs

to other PEs. The draft = hasn't=20 specified about propagating MAC withdraw by PEs to the = distant-end MTUs=20 in HVPLS (in PErs->MTU direction). I think

that part = is=20 implementation specific. The reason could be the distant end = MTUs will=20 still be receiving the traffic in the primary link and MAC = withdrawl may=20 not be necessary.

regards,
himanshu

Himanshu=20 Shah
Ciena=20 = Corp

=
------_=_NextPart_001_01C61218.2FC1B92B-- From l2vpn-bounces@ietf.org Thu Jan 05 14:20:42 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuafB-0001rh-Sg; Thu, 05 Jan 2006 14:20:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuX2T-0001iZ-FK for l2vpn@megatron.ietf.org; Thu, 05 Jan 2006 10:28:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26598 for ; Thu, 5 Jan 2006 10:27:12 -0500 (EST) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuX8A-0006EM-DA for l2vpn@ietf.org; Thu, 05 Jan 2006 10:34:23 -0500 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jan 2006 10:28:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6120C.A964C9B2" Date: Thu, 5 Jan 2006 10:28:21 -0500 Message-ID: Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agABvac6AAS1SQgA== From: "Shah, Himanshu" To: "Ali Sajassi \(sajassi\)" , "Dutta, Pranjal" , X-OriginalArrivalTime: 05 Jan 2006 15:28:21.0353 (UTC) FILETIME=[A9283590:01C6120C] X-Spam-Score: 1.0 (+) X-Scan-Signature: 92abeebc7b3c56bc274d8238a52368c9 X-Mailman-Approved-At: Thu, 05 Jan 2006 14:20:39 -0500 Cc: "Libby, Mark" Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6120C.A964C9B2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ali, =20 It is a good suggestion and it would help in broadcast dampening, as you suggest. May be a qualifier can be added in the MAC address withdraw list TLV to=20 1) delete the MAC addresses in the list (current) 2) re-learn the MAC addresses in the list to the PW over which this signal is received (new - your suggestion) =20 I also suggested an additional qualifier for empty MAC address withdraw list to make operations for empty and non-empty list = consistent. =20 /himanshu =20 -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Wednesday, January 04, 2006 1:04 PM To: Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, =20 When this section was first written, the MAC address withdraw message = was generated by the PE detecting the failed link or PW. This was = incorrect because the backup link might not have come up yet and this = message would have resulted in deleting MAC addresses without having any = place to sent the traffic to and thus causing broadcast storms in the = provider network.=20 =20 When I edited this section of the draft several years ago, I corrected = this issue by modeling it after IEEE TCN operation. The version 4 of = this draft based on my edit (which I happened to have) is as follow: =20 "The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the = interface/pseudowire over which this message is received - Send the same message to all other PEs over the corresponding = directed LDP sessions. =20 For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance = (specified by the FEC TLV) except the MAC addresses learned over this = link (over the pseudowire associated with the signaling link over which = the message is received)=20 - Send the same message to all other PEs over the corresponding = directed LDP sessions. =20 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the = Address Withdraw Message. The number of MAC addresses can be deduced = from the length field in the TLV." =20 =20 As you can see, for the case of MAC address withdraw message with = non-empty list, the message is sent over the newly activated link (just = like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT = deleted as specified currently in the draft. In other words, if a VPLS = has a few MAC addresses and a MTU-rs wants to let the PE know that these = MAC addresses are affected and now needs to be re-learned over this = newly activated link, then this message can be used. =20 It seems like someone has changed the correct text based on my edit into = the existing incorrect text but given that Vach and Marc are now the = primary editors (and not me), they can take the credit for this :-) =20 -Ali _____ =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf = Of Shah, Himanshu Sent: Tuesday, January 03, 2006 6:24 AM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such = circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other = than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Reg. the first part again excerpts from the draft = as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV = means delete the association between all MAC addresses associated with = the VPLS instance specified in by the FEC TLV within the address withdraw message. This = will not delete the association of MACs with the PW on which the Address = Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only. = =20 The second issue you raised is very interesting and has practical = implications. After PW switchover when, MTU originates the Address = Withdraw for all N PWs (one msg. for each PW). Those will be forwarded = by the "new" PE-rs to all peers thoughout the domain. Removal of all = MACs would cause spark of broadcast and considering the traffic for all = N FECs are flowing now via secondary PW, so associated MACs will get = relearned again across all the PEs. So broadcast will stop once = relearning completes. In the absence of MAC withdraw, traffic won't = broadcast, but will keep flowing to wrong ports (till the MACs ages out = or till relearning happens again). I think we need to see the time = window for the broadcast in a specified scenario/application where MAC = withdraw is being used. That could be also one of the reasons why MAC = withdraw is an optional feature in VPLS. =20 =20 To address the broadcast issue when empty-list MAC withdraw is used, we = can implement some filtering mechanism to selectively block MAC withdraw = msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast = is not desired due to MAC withdraw). Anyway that is my theoretical idea = and could be implementation specific. =20 =20 =20 Regards, Pranjal _____ =20 From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. regards, himanshu -----Original Message----- From: Dutta, Pranjal [ mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal Hi Himanshu, Please see my answers inline Thanks, Pranjal ________________________________ From: l2vpn-bounces@ietf.org [ mailto:l2vpn-bounces@ietf.org] On Behalf = Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal Hope somebody can shed light on the following questions.... (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV cut-and-paste from draft. 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. To simplify the problem, lets assume that for a given VPLS instance A = there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd = MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite = result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets = assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal = list, it will remove none. However, the draft says, In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. [Pranjal]: What the draft means is that with empty-list in MAC withdraw = TLV means remove "ALL" MACs. The processing entity of MAC List TLV (in Address Withdraw = Msg) needs to flush all MACs associated with a VPLS instance when it = receives MAC list TLV without any MAC address(s) in the list (empty list). In = case, of the MAC List TLV that contains specific MAC addresses then the = receiving entity needs to remove only those MAC addresses in the = list associated with VPLS instance (identifies by FEC in the address = withdraw msg). The withdrawl with empty list feature is to make it more scalable. For example, a VPLS = instance that has 1000 MACs learned at a PE need not send Address withdraw with 1000 MACs list, can send empty = list instead. But again it is optional (means if the MAC withdraw = originating PE wants It can send Address Withdraw with 1000 MACs list) and = implementation specific. Let's say for a dual homed MTU in HVPLS, the = primary link has 100 PWs (1 for each VPLS instance) and the secondary link has = the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all = will switch back to the secondary and MTU needs to send Address Withdraw with MACList TLV, one for = each of the 100 PWs. So, empty list would be preferable for each = message. (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc needs to be described. [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in = MTU-PErs direction) needs to be processed and forwarded by PE-rs to other PEs. The draft hasn't specified about propagating MAC withdraw = by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I = think that part is implementation specific. The reason could be the distant = end MTUs will still be receiving the traffic in the primary link and MAC = withdrawl may not be necessary. regards, himanshu Himanshu Shah Ciena Corp ------_=_NextPart_001_01C6120C.A964C9B2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: VPLS question on MAC address withdrawal
Hi=20 Ali,
 
It is a=20 good suggestion and it would help in broadcast
dampening,=20 as you suggest. May be a qualifier can be
added in=20 the MAC address withdraw list TLV to
1) delete=20 the MAC addresses in the list (current)
2)=20 re-learn the MAC addresses in the list to the PW = over
    which this signal is received = (new - your=20 suggestion)
 
I also=20 suggested an additional qualifier for empty MAC = address
withdraw=20 list to make operations for empty and non-empty list=20 consistent.
 
/himanshu
 
-----Original Message-----
From: Ali Sajassi = (sajassi)=20 [mailto:sajassi@cisco.com]
Sent: Wednesday, January 04, 2006 = 1:04=20 PM
To: Shah, Himanshu; Dutta, Pranjal;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi Himanshu,
 
When this section was first written, the = MAC address=20 withdraw message was generated by the PE detecting the failed link or = PW. This=20 was incorrect because the backup link might not have come up yet = and this=20 message would have resulted in deleting MAC addresses without = having any=20 place to sent the traffic to and thus causing broadcast storms in = the=20 provider network.
 
When I edited this section of the draft = several years=20 ago, I corrected this issue by modeling it after IEEE TCN = operation. The=20 version 4 of this draft based on my edit (which I happened to have) is = as=20 follow:
 

"The processing for MAC TLVs = received in an=20 Address Withdraw Message is:

 =20 For each MAC address in the TLV:

-      =20 Relearn the = association between=20 the MAC address and the interface/pseudowire over which this message = is=20 received

-      =20 Send the same message = to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

 =20 For an Address Withdraw message with empty=20 list:

-      =20 Remove all the MAC = addresses=20 associated with the VPLS instance (specified by the FEC TLV) except = the MAC=20 addresses learned over this link (over the pseudowire associated with = the=20 signaling link over which the message is received)=20

-      =20 Send the same message = to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

The scope of a MAC TLV is = the VPLS=20 specified in the FEC TLV in the Address Withdraw Message.  The number of MAC addresses = can be=20 deduced from the length field in the TLV." =20

 
As you can see, for the case of MAC = address=20 withdraw message with non-empty list, the message is sent over = the newly=20 activated link (just like TCN) but with as list of MAC addresses to be = "RE-LEARNED" and NOT deleted as specified currently in the draft. = In=20 other words, if a VPLS has a few MAC addresses and a MTU-rs wants to = let the=20 PE know that these MAC addresses are affected and now needs to be = re-learned=20 over this newly activated link, then this message can be=20 used.
 
It seems like someone has changed the = correct text=20 based on my edit into the existing incorrect text but given = that=20 Vach and Marc are now the primary editors (and not me), they can take = the=20 credit for this :-)
 
-Ali

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah,=20 Himanshu
Sent: Tuesday, January 03, 2006 6:24 = AM
To:=20 Dutta, Pranjal; l2vpn@ietf.org
Subject: RE: VPLS question = on MAC=20 address withdrawal

Hi=20 Pranjal,
 
I=20 think there is a disconnect. You are failing to understand the=20 point
I am=20 raising.
 
I=20 perfectly understand what empty MAC address withdraw list does.=20
 
Please=20 go through the example I gave. The example clearly shows=20 that
MAC=20 address withdraw list and empty MAC address withdraw list=20 can
NOT be=20 used interchangeably (for scalability or for other=20 reasons).
 
As for=20 the second part, the failover causes MAC switchover at=20 the
expense of disturbance to other MAC = conversations=20 that had nothing
to do=20 with the failover. It would almost seem that under such=20 circumstances
MAC=20 Withdraw list with switchover MAC addresses from original=20 primary
PE-rs=20 to other PE-rs would make more sense than having to =  make all the
PE-rs=20 to remove all the MAC addresses (for a given VPLS instances) other=20 than
the=20 ones switched over. Seems too expensive.
 
/himanshu
-----Original Message-----
From: Dutta, Pranjal = [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, January = 03,=20 2006 3:23 AM
To: Shah, Himanshu;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address = withdrawal

Hi=20 Himanshu,

           =          =20 Reg. the first part again excerpts from the draft as=20 below

 

For a MAC Address Withdraw =
message with empty list: 
     - Remove all the MAC addresses =
associated with the VPLS 
       instance(specified by =
the FEC TLV) except the MAC addresses =

       learned over the PW =
associated with this signaling session =

       over which the message =
was received 
   
  The scope of a MAC List TLV is the VPLS specified in =
the FEC TLV in 
  the MAC =
Address Withdraw Message.  The number of MAC addresses can =

  be deduced from = the length=20 field in the TLV

 

 

 In the=20 first part as per my understanding goes, empty MAC list TLV means = delete=20 the association between all MAC addresses associated with the VPLS = instance

specified in by=20 the FEC TLV within the address withdraw message. This will not = delete the=20 association of MACs with the PW on which the Address Withdraw = message with=20 empty MAC list is received.

So as = specified=20 in draft the scope is limited to the FEC specified only.=20

 

The = second issue=20 you raised is very interesting and has practical implications. = After PW=20 switchover when, MTU originates the Address Withdraw for all N PWs = (one=20 msg. for each PW). Those will be forwarded by the = “new” PE-rs to all peers=20 thoughout the domain. Removal of all MACs would cause spark of = broadcast=20 and considering the traffic for all N FECs are flowing now via = secondary=20 PW, so associated MACs will get relearned again across all the = PEs. So=20 broadcast will stop once relearning completes. In the absence of = MAC=20 withdraw, traffic won’t broadcast, but will keep flowing to = wrong ports=20 (till the MACs ages out or till relearning happens again). I think = we need=20 to see the time window for the broadcast in a specified=20 scenario/application where MAC withdraw is being used. That could = be also=20 one of the reasons why MAC withdraw is an optional feature in = VPLS.=20  

 

To = address the=20 broadcast issue when empty-list MAC withdraw is used, we can = implement=20 some filtering mechanism to selectively block MAC withdraw msg for = some=20 FECs at PE-rs/originating MTU (for PWs where temp. b’cast is = not desired=20 due to MAC withdraw). Anyway that is my theoretical idea and could = be=20 implementation specific.   

 

 

Regards,

Pranjal

From:=20 Shah, Himanshu [mailto:hshah@ciena.com]
Sent: Monday, 02 January, = 2006 8:50=20 PM
To: Dutta, = Pranjal;=20 l2vpn@ietf.org
Subject:=20 RE: VPLS question on MAC address=20 withdrawal

 

Hi Pranjal,

It seems easy to get = confused=20 that
mac address withdraw list TLV and empty mac = address
withdraw=20 list TLV are one and the same and can be used
interchangeably = for=20 scalability. But that is
clearly not true.

In MAC = address=20 withdraw list TLV with MAC addresses, receiver
removes the = association=20 between MAC addresses in
the list and PW over which the signal = is=20 received.

In MAC address TLV list with no MAC = addresses,
the=20 receiver removes the association between all MAC = addresses
EXCEPT the=20 ones over which he receives this signal.

In the second part = of the=20 question, empty MAC address
withdraw List TLV receieved by = secondary=20 which now is primary
PE-rs also has some issues. Broadcasting = the empty=20 MAC
address withdraw List TLV to all other PE-rs would=20 create
broadcasts in the core, as it removes MAC = addresses
learned=20 from ALL N-PWs EXCEPT for ones learned on the
PW over which the = signal=20 was received.  This needs to be
carefully thought out=20 too.

regards,
himanshu

-----Original=20 Message-----
From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<= /A>]
Sent:=20 Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject: RE:=20 VPLS question on MAC address withdrawal

Hi=20 = Himanshu,

         &n= bsp;           =20 Please see my answers=20 = inline



Thanks,

Pranjal



_____________= ___________________

From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= On=20 Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 2:49 = AM
To:=20 l2vpn@ietf.org
Subject: VPLS question on MAC address=20 withdrawal





Hope somebody can shed light on = the=20 following questions....

(1)
There are two mechanisms = described=20 -
MAC address withdraw List TLV and empty MAC Address withdraw = List=20 TLV

cut-and-paste from draft.

6.2.2. Address = Withdraw=20 Message Containing MAC List TLV
 
  The processing = for MAC=20 List TLV received in an Address Withdraw
  Message=20 is:
 
  For each MAC address in the=20 TLV:
     - Remove the association between = the MAC=20 address and the AC = or
        PW=20 over which this message is received
 
  For a MAC = Address=20 Withdraw message with empty list:
     - = Remove all=20 the MAC addresses associated with the=20 VPLS
        instance =20 (specified by the FEC TLV) except the MAC=20 addresses
        learned = over the=20 PW associated with this signaling=20 session
        over which = the=20 message was received
 
  The scope of a MAC List = TLV is=20 the VPLS specified in the FEC TLV in
  the MAC Address = Withdraw=20 Message.  The number of MAC addresses can
  be = deduced from=20 the length field in the TLV.

To simplify the problem, lets = assume=20 that for a given VPLS instance A there are only 5 MAC
addresses = and one=20 PW. In this case, for TCN-Triggererd MAC-address-withdrawal, = sending
a=20 list of 5 MAC address vs sending an empty list achieves opposite = result.=20 That is, sending
explicit list will cause the receiver to = remove all 5=20 addresses (lets assume that they all were
associated with = sender). But=20 by sending, empty MAC-address-withdrawal list, it will=20 remove
none.  However, the draft says,

In order to = minimize=20 the impact on LDP convergence time, when the
  MAC list = TLV=20 contains a large number of MAC addresses, it may be
  = preferable=20 to send a MAC address withdrawal message with an empty
 =20 list.

[Pranjal]: What the draft means is that with = empty-list in=20 MAC withdraw TLV means remove "ALL"=20 = MACs.

          =    =20 The processing entity of MAC List TLV (in Address Withdraw Msg) = needs to=20 flush all MACs associated with a VPLS instance when it receives = MAC list=20 = TLV

          &n= bsp;    =20 without any MAC address(s) in the list (empty list). In case, of = the MAC=20 List TLV that contains specific MAC addresses then the=20 = receiving

         &n= bsp;     =20 entity needs to remove only those MAC addresses in the list = associated=20 with VPLS instance (identifies by FEC in the address withdraw = msg). The=20 withdrawl with empty=20 = list

          &= nbsp;    =20 feature is to make it more scalable. For example, a VPLS instance = that has=20 1000 MACs learned at a PE need not=20 = send

          &= nbsp;    =20 Address withdraw with 1000 MACs list, can send empty list instead. = But=20 again it is optional (means if the MAC withdraw originating PE=20 = wants

          =     =20 It can send Address Withdraw with 1000 MACs list) and = implementation=20 specific. Let's say for a dual homed MTU in HVPLS, the primary = link has=20 100=20 = PWs

          &n= bsp;    =20 (1 for each VPLS instance) and the secondary link has the backup = of all=20 the 100 PWs. Now if all 100 primary PWs fail then, all will switch = back to=20 the secondary and=20 = MTU

          &n= bsp;   =20 needs to send Address Withdraw with MACList TLV, one for each of = the 100=20 PWs. So, empty list would be preferable for each = message.

(2)
Is=20 MAC-Address-withdraw mechanism ever intended to be used for U-PW = (user=20 facing PW, MTU-S<->PErs)?
If so, how, when, implication = of=20 withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to
be = described.



[Pranjal]: The draft says that the MAC = withdraw=20 originated at a MTU (in MTU-PErs direction) needs to be processed = and=20 forwarded by PE-rs

to other PEs. The draft hasn't specified = about=20 propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS = (in=20 PErs->MTU direction). I think

that part is = implementation=20 specific. The reason could be the distant end MTUs will still be = receiving=20 the traffic in the primary link and MAC withdrawl may not be=20 necessary.

regards,
himanshu

Himanshu = Shah
Ciena=20 = Corp

=
------_=_NextPart_001_01C6120C.A964C9B2-- From l2vpn-bounces@ietf.org Thu Jan 05 14:20:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuafC-0001sY-Tb; Thu, 05 Jan 2006 14:20:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuaHB-0005vc-NN for l2vpn@megatron.ietf.org; Thu, 05 Jan 2006 13:55:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26395 for ; Thu, 5 Jan 2006 13:54:37 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EuaMs-0006Vi-9J for l2vpn@ietf.org; Thu, 05 Jan 2006 14:01:49 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 05 Jan 2006 10:55:38 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k05Itbjt005087; Thu, 5 Jan 2006 10:55:37 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 5 Jan 2006 10:55:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61229.9D72B931" Date: Thu, 5 Jan 2006 10:55:36 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EBF4309A@xmb-sjc-21e.amer.cisco.com> Thread-Topic: VPLS question on MAC address withdrawal Thread-Index: AcYMvYeqJnmGFEBySe+6nxp5hzuwCgCsjW0AAA8m8VEAIrWqoAANp0agABvac6AAS1SQgAAHf4Bg From: "Ali Sajassi \(sajassi\)" To: "Shah, Himanshu" , "Dutta, Pranjal" , X-OriginalArrivalTime: 05 Jan 2006 18:55:37.0495 (UTC) FILETIME=[9DACE270:01C61229] X-Spam-Score: 1.0 (+) X-Scan-Signature: 654d8dea790bc7609adc97f133706ab1 X-Mailman-Approved-At: Thu, 05 Jan 2006 14:20:39 -0500 Cc: "Libby, Mark" Subject: RE: VPLS question on MAC address withdrawal X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61229.9D72B931 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I agree. If there is no objection to this proposal, lets include it in the next rev. of the document. =20 -Ali ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Thursday, January 05, 2006 7:28 AM To: Ali Sajassi (sajassi); Dutta, Pranjal; l2vpn@ietf.org Cc: Libby, Mark Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Ali, =20 It is a good suggestion and it would help in broadcast dampening, as you suggest. May be a qualifier can be added in the MAC address withdraw list TLV to=20 1) delete the MAC addresses in the list (current) 2) re-learn the MAC addresses in the list to the PW over which this signal is received (new - your suggestion) =20 I also suggested an additional qualifier for empty MAC address withdraw list to make operations for empty and non-empty list consistent. =20 /himanshu =20 -----Original Message----- From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Wednesday, January 04, 2006 1:04 PM To: Shah, Himanshu; Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Himanshu, =20 When this section was first written, the MAC address withdraw message was generated by the PE detecting the failed link or PW. This was incorrect because the backup link might not have come up yet and this message would have resulted in deleting MAC addresses without having any place to sent the traffic to and thus causing broadcast storms in the provider network.=20 =20 When I edited this section of the draft several years ago, I corrected this issue by modeling it after IEEE TCN operation. The version 4 of this draft based on my edit (which I happened to have) is as follow: =20 "The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the interface/pseudowire over which this message is received - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over this link (over the pseudowire associated with the signaling link over which the message is received)=20 - Send the same message to all other PEs over the corresponding directed LDP sessions. =20 The scope of a MAC TLV is the VPLS specified in the FEC TLV in the Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV." =20 =20 As you can see, for the case of MAC address withdraw message with non-empty list, the message is sent over the newly activated link (just like TCN) but with as list of MAC addresses to be "RE-LEARNED" and NOT deleted as specified currently in the draft. In other words, if a VPLS has a few MAC addresses and a MTU-rs wants to let the PE know that these MAC addresses are affected and now needs to be re-learned over this newly activated link, then this message can be used. =20 It seems like someone has changed the correct text based on my edit into the existing incorrect text but given that Vach and Marc are now the primary editors (and not me), they can take the credit for this :-) =20 -Ali ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Tuesday, January 03, 2006 6:24 AM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Pranjal, =20 I think there is a disconnect. You are failing to understand the point I am raising. =20 I perfectly understand what empty MAC address withdraw list does.=20 =20 Please go through the example I gave. The example clearly shows that MAC address withdraw list and empty MAC address withdraw list can NOT be used interchangeably (for scalability or for other reasons). =20 As for the second part, the failover causes MAC switchover at the expense of disturbance to other MAC conversations that had nothing to do with the failover. It would almost seem that under such circumstances MAC Withdraw list with switchover MAC addresses from original primary PE-rs to other PE-rs would make more sense than having to make all the PE-rs to remove all the MAC addresses (for a given VPLS instances) other than the ones switched over. Seems too expensive. =20 /himanshu -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Tuesday, January 03, 2006 3:23 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 =09 Hi Himanshu, Reg. the first part again excerpts from the draft as below =20 For a MAC Address Withdraw message with empty list:=20 - Remove all the MAC addresses associated with the VPLS=20 instance(specified by the FEC TLV) except the MAC addresses=20 learned over the PW associated with this signaling session=20 over which the message was received=20 =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in=20 the MAC Address Withdraw Message. The number of MAC addresses can=20 be deduced from the length field in the TLV =20 =20 In the first part as per my understanding goes, empty MAC list TLV means delete the association between all MAC addresses associated with the VPLS instance specified in by the FEC TLV within the address withdraw message. This will not delete the association of MACs with the PW on which the Address Withdraw message with empty MAC list is received. So as specified in draft the scope is limited to the FEC specified only.=20 =20 The second issue you raised is very interesting and has practical implications. After PW switchover when, MTU originates the Address Withdraw for all N PWs (one msg. for each PW). Those will be forwarded by the "new" PE-rs to all peers thoughout the domain. Removal of all MACs would cause spark of broadcast and considering the traffic for all N FECs are flowing now via secondary PW, so associated MACs will get relearned again across all the PEs. So broadcast will stop once relearning completes. In the absence of MAC withdraw, traffic won't broadcast, but will keep flowing to wrong ports (till the MACs ages out or till relearning happens again). I think we need to see the time window for the broadcast in a specified scenario/application where MAC withdraw is being used. That could be also one of the reasons why MAC withdraw is an optional feature in VPLS. =20 To address the broadcast issue when empty-list MAC withdraw is used, we can implement some filtering mechanism to selectively block MAC withdraw msg for some FECs at PE-rs/originating MTU (for PWs where temp. b'cast is not desired due to MAC withdraw). Anyway that is my theoretical idea and could be implementation specific. =20 =20 =20 Regards, Pranjal =09 ________________________________ From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, 02 January, 2006 8:50 PM To: Dutta, Pranjal; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =20 Hi Pranjal, =09 It seems easy to get confused that mac address withdraw list TLV and empty mac address withdraw list TLV are one and the same and can be used interchangeably for scalability. But that is clearly not true. =09 In MAC address withdraw list TLV with MAC addresses, receiver removes the association between MAC addresses in the list and PW over which the signal is received. =09 In MAC address TLV list with no MAC addresses, the receiver removes the association between all MAC addresses EXCEPT the ones over which he receives this signal. =09 In the second part of the question, empty MAC address withdraw List TLV receieved by secondary which now is primary PE-rs also has some issues. Broadcasting the empty MAC address withdraw List TLV to all other PE-rs would create broadcasts in the core, as it removes MAC addresses learned from ALL N-PWs EXCEPT for ones learned on the PW over which the signal was received. This needs to be carefully thought out too. =09 regards, himanshu =09 -----Original Message----- From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com] Sent: Mon 1/2/2006 3:16 AM To: Shah, Himanshu; l2vpn@ietf.org Subject: RE: VPLS question on MAC address withdrawal =09 Hi Himanshu, =09 Please see my answers inline =09 =09 =09 Thanks, =09 Pranjal =09 =09 =09 ________________________________ =09 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah, Himanshu Sent: Friday, 30 December, 2005 2:49 AM To: l2vpn@ietf.org Subject: VPLS question on MAC address withdrawal =09 =09 =09 =09 =09 Hope somebody can shed light on the following questions.... =09 (1) There are two mechanisms described - MAC address withdraw List TLV and empty MAC Address withdraw List TLV =09 cut-and-paste from draft. =09 6.2.2. Address Withdraw Message Containing MAC List TLV =20 The processing for MAC List TLV received in an Address Withdraw Message is: =20 For each MAC address in the TLV: - Remove the association between the MAC address and the AC or PW over which this message is received =20 For a MAC Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received =20 The scope of a MAC List TLV is the VPLS specified in the FEC TLV in the MAC Address Withdraw Message. The number of MAC addresses can be deduced from the length field in the TLV. =09 To simplify the problem, lets assume that for a given VPLS instance A there are only 5 MAC addresses and one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, sending a list of 5 MAC address vs sending an empty list achieves opposite result. That is, sending explicit list will cause the receiver to remove all 5 addresses (lets assume that they all were associated with sender). But by sending, empty MAC-address-withdrawal list, it will remove none. However, the draft says, =09 In order to minimize the impact on LDP convergence time, when the MAC list TLV contains a large number of MAC addresses, it may be preferable to send a MAC address withdrawal message with an empty list. =09 [Pranjal]: What the draft means is that with empty-list in MAC withdraw TLV means remove "ALL" MACs. =09 The processing entity of MAC List TLV (in Address Withdraw Msg) needs to flush all MACs associated with a VPLS instance when it receives MAC list TLV =09 without any MAC address(s) in the list (empty list). In case, of the MAC List TLV that contains specific MAC addresses then the receiving =09 entity needs to remove only those MAC addresses in the list associated with VPLS instance (identifies by FEC in the address withdraw msg). The withdrawl with empty list =09 feature is to make it more scalable. For example, a VPLS instance that has 1000 MACs learned at a PE need not send =09 Address withdraw with 1000 MACs list, can send empty list instead. But again it is optional (means if the MAC withdraw originating PE wants =09 It can send Address Withdraw with 1000 MACs list) and implementation specific. Let's say for a dual homed MTU in HVPLS, the primary link has 100 PWs =09 (1 for each VPLS instance) and the secondary link has the backup of all the 100 PWs. Now if all 100 primary PWs fail then, all will switch back to the secondary and MTU =09 needs to send Address Withdraw with MACList TLV, one for each of the 100 PWs. So, empty list would be preferable for each message. =09 (2) Is MAC-Address-withdraw mechanism ever intended to be used for U-PW (user facing PW, MTU-S<->PErs)? If so, how, when, implication of withdraw msg from N-PW (PE<->PE) to U-PW, etc needs to be described. =09 =09 =09 [Pranjal]: The draft says that the MAC withdraw originated at a MTU (in MTU-PErs direction) needs to be processed and forwarded by PE-rs =09 to other PEs. The draft hasn't specified about propagating MAC withdraw by PEs to the distant-end MTUs in HVPLS (in PErs->MTU direction). I think =09 that part is implementation specific. The reason could be the distant end MTUs will still be receiving the traffic in the primary link and MAC withdrawl may not be necessary. =09 regards, himanshu =09 Himanshu Shah Ciena Corp =09 =09 ------_=_NextPart_001_01C61229.9D72B931 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: VPLS question = on MAC address withdrawal
Yes, I agree. If there is no objection to this = proposal,=20 lets include it in the next rev. of the document.
 
-Ali

From: Shah, Himanshu = [mailto:hshah@ciena.com]=20
Sent: Thursday, January 05, 2006 7:28 AM
To: Ali = Sajassi=20 (sajassi); Dutta, Pranjal; l2vpn@ietf.org
Cc: Libby,=20 Mark
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi=20 Ali,
 
It is a=20 good suggestion and it would help in broadcast
dampening, as you suggest. May be a qualifier can=20 be
added in=20 the MAC address withdraw list TLV to
1)=20 delete the MAC addresses in the list (current)
2)=20 re-learn the MAC addresses in the list to the PW = over
    which this signal is received = (new -=20 your suggestion)
 
I also=20 suggested an additional qualifier for empty MAC = address
withdraw=20 list to make operations for empty and non-empty list=20 consistent.
 
/himanshu
 
-----Original Message-----
From: Ali Sajassi = (sajassi)=20 [mailto:sajassi@cisco.com]
Sent: Wednesday, January 04, = 2006 1:04=20 PM
To: Shah, Himanshu; Dutta, Pranjal;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC address=20 withdrawal

Hi Himanshu,
 
When this section was first written, the = MAC=20 address withdraw message was generated by the PE detecting the = failed link=20 or PW. This was incorrect because the backup link might not = have come=20 up yet and this message would have resulted in deleting MAC = addresses=20 without having any place to sent the traffic to and = thus causing=20 broadcast storms in the provider network.
 
When I edited this section of the draft = several=20 years ago, I corrected this issue by modeling it after IEEE TCN = operation. The version 4 of this draft based on my edit (which I = happened to=20 have) is as follow:
 

"The processing for MAC TLVs = received in an=20 Address Withdraw Message is:

  For each MAC address in = the=20 TLV:

-      =20 Relearn the = association=20 between the MAC address and the interface/pseudowire over which this = message=20 is received

-      =20 Send the same = message to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

  For an Address Withdraw = message with=20 empty list:

-      =20 Remove all the MAC = addresses=20 associated with the VPLS instance (specified by the FEC TLV) except = the MAC=20 addresses learned over this link (over the pseudowire associated = with the=20 signaling link over which the message is received)=20

-      =20 Send the same = message to all=20 other PEs over the corresponding directed LDP=20 sessions.

 

The scope of a MAC TLV is = the VPLS=20 specified in the FEC TLV in the Address Withdraw Message.  The number of MAC = addresses can be=20 deduced from the length field in the TLV." =20

 
As you can see, for the case of MAC = address=20 withdraw message with non-empty list, the message is sent over = the=20 newly activated link (just like TCN) but with as list of MAC = addresses to be=20 "RE-LEARNED" and NOT deleted as specified currently in the = draft. In=20 other words, if a VPLS has a few MAC addresses and a MTU-rs wants to = let the=20 PE know that these MAC addresses are affected and now needs to be = re-learned=20 over this newly activated link, then this message can be=20 used.
 
It seems like someone has changed the = correct text=20 based on my edit into the existing incorrect text but = given that=20 Vach and Marc are now the primary editors (and not me), they can = take the=20 credit for this :-)
 
-Ali

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of Shah,=20 Himanshu
Sent: Tuesday, January 03, 2006 6:24 = AM
To:=20 Dutta, Pranjal; l2vpn@ietf.org
Subject: RE: VPLS = question on MAC=20 address withdrawal

Hi=20 Pranjal,
 
I=20 think there is a disconnect. You are failing to understand the=20 point
I am=20 raising.
 
I=20 perfectly understand what empty MAC address withdraw list does.=20
 
Please go through the example I gave. The example = clearly=20 shows that
MAC=20 address withdraw list and empty MAC address withdraw list=20 can
NOT=20 be used interchangeably (for scalability or for other=20 reasons).
 
As=20 for the second part, the failover causes MAC switchover at=20 the
expense of disturbance to other = MAC=20 conversations that had nothing
to=20 do with the failover. It would almost seem that under such=20 circumstances
MAC=20 Withdraw list with switchover MAC addresses from original=20 primary
PE-rs to other PE-rs would make more sense than = having to=20  make all=20 the
PE-rs to remove all the MAC addresses (for a given = VPLS=20 instances) other than
the=20 ones switched over. Seems too expensive.
 
/himanshu
-----Original Message-----
From: Dutta, = Pranjal=20 [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, = January 03,=20 2006 3:23 AM
To: Shah, Himanshu;=20 l2vpn@ietf.org
Subject: RE: VPLS question on MAC = address=20 withdrawal

Hi=20 Himanshu,

           =          =20 Reg. the first part again excerpts from the draft as=20 below

 

For a MAC Address Withdraw =
message with empty list: 
     - Remove all the MAC addresses =
associated with the VPLS 
       instance(specified by =
the FEC TLV) except the MAC addresses =

       learned over the PW =
associated with this signaling session =

       over which the message =
was received 
   
  The scope of a MAC List TLV is the VPLS specified in =
the FEC TLV in 
  the MAC =
Address Withdraw Message.  The number of MAC addresses can =

  be deduced from = the length=20 field in the TLV

 

 

 In the=20 first part as per my understanding goes, empty MAC list TLV = means delete=20 the association between all MAC addresses associated with the = VPLS=20 instance

specified in by=20 the FEC TLV within the address withdraw message. This will not = delete=20 the association of MACs with the PW on which the Address = Withdraw=20 message with empty MAC list is = received.

So as = specified=20 in draft the scope is limited to the FEC specified only.=20

 

The = second=20 issue you raised is very interesting and has practical = implications.=20 After PW switchover when, MTU originates the Address Withdraw = for all N=20 PWs (one msg. for each PW). Those will be forwarded by the = “new” PE-rs=20 to all peers thoughout the domain. Removal of all MACs would = cause spark=20 of broadcast and considering the traffic for all N FECs are = flowing now=20 via secondary PW, so associated MACs will get relearned again = across all=20 the PEs. So broadcast will stop once relearning completes. In = the=20 absence of MAC withdraw, traffic won’t broadcast, but will = keep flowing=20 to wrong ports (till the MACs ages out or till relearning = happens=20 again). I think we need to see the time window for the broadcast = in a=20 specified scenario/application where MAC withdraw is being used. = That=20 could be also one of the reasons why MAC withdraw is an optional = feature=20 in VPLS.  

 

To = address the=20 broadcast issue when empty-list MAC withdraw is used, we can = implement=20 some filtering mechanism to selectively block MAC withdraw msg = for some=20 FECs at PE-rs/originating MTU (for PWs where temp. b’cast = is not desired=20 due to MAC withdraw). Anyway that is my theoretical idea and = could be=20 implementation specific. =   

 

 

Regards,

Pranjal

From:=20 Shah, Himanshu [mailto:hshah@ciena.com]
Sent: Monday, 02 January, = 2006 8:50=20 PM
To: Dutta, = Pranjal;=20 l2vpn@ietf.org
Subject:=20 RE: VPLS question on MAC address=20 withdrawal

 

Hi Pranjal,

It seems easy to = get confused=20 that
mac address withdraw list TLV and empty mac = address
withdraw=20 list TLV are one and the same and can be used
interchangeably = for=20 scalability. But that is
clearly not true.

In MAC = address=20 withdraw list TLV with MAC addresses, receiver
removes the=20 association between MAC addresses in
the list and PW over = which the=20 signal is received.

In MAC address TLV list with no MAC=20 addresses,
the receiver removes the association between all = MAC=20 addresses
EXCEPT the ones over which he receives this=20 signal.

In the second part of the question, empty MAC=20 address
withdraw List TLV receieved by secondary which now is = primary
PE-rs also has some issues. Broadcasting the empty=20 MAC
address withdraw List TLV to all other PE-rs would=20 create
broadcasts in the core, as it removes MAC = addresses
learned=20 from ALL N-PWs EXCEPT for ones learned on the
PW over which = the=20 signal was received.  This needs to be
carefully thought = out=20 too.

regards,
himanshu

-----Original=20 Message-----
From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com<= /A>]
Sent:=20 Mon 1/2/2006 3:16 AM
To: Shah, Himanshu; = l2vpn@ietf.org
Subject:=20 RE: VPLS question on MAC address withdrawal

Hi=20 = Himanshu,

         &n= bsp;           =20 Please see my answers=20 = inline



Thanks,

Pranjal



_____________= ___________________

From:=20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]= =20 On Behalf Of Shah, Himanshu
Sent: Friday, 30 December, 2005 = 2:49=20 AM
To: l2vpn@ietf.org
Subject: VPLS question on MAC = address=20 withdrawal





Hope somebody can shed light = on the=20 following questions....

(1)
There are two mechanisms = described=20 -
MAC address withdraw List TLV and empty MAC Address = withdraw List=20 TLV

cut-and-paste from draft.

6.2.2. Address = Withdraw=20 Message Containing MAC List TLV
 
  The = processing for=20 MAC List TLV received in an Address Withdraw
  Message=20 is:
 
  For each MAC address in the=20 TLV:
     - Remove the association = between the=20 MAC address and the AC = or
       =20 PW over which this message is received
 
  For a = MAC=20 Address Withdraw message with empty = list:
     -=20 Remove all the MAC addresses associated with the=20 VPLS
        = instance =20 (specified by the FEC TLV) except the MAC=20 addresses
        learned = over the=20 PW associated with this signaling=20 session
        over which = the=20 message was received
 
  The scope of a MAC List = TLV is=20 the VPLS specified in the FEC TLV in
  the MAC Address = Withdraw=20 Message.  The number of MAC addresses can
  be = deduced from=20 the length field in the TLV.

To simplify the problem, = lets assume=20 that for a given VPLS instance A there are only 5 = MAC
addresses and=20 one PW. In this case, for TCN-Triggererd MAC-address-withdrawal, = sending
a list of 5 MAC address vs sending an empty list = achieves=20 opposite result. That is, sending
explicit list will cause = the=20 receiver to remove all 5 addresses (lets assume that they all=20 were
associated with sender). But by sending, empty=20 MAC-address-withdrawal list, it will remove
none.  = However, the=20 draft says,

In order to minimize the impact on LDP = convergence=20 time, when the
  MAC list TLV contains a large number of = MAC=20 addresses, it may be
  preferable to send a MAC address=20 withdrawal message with an empty
  = list.

[Pranjal]: What=20 the draft means is that with empty-list in MAC withdraw TLV = means remove=20 "ALL"=20 = MACs.

          =    =20 The processing entity of MAC List TLV (in Address Withdraw Msg) = needs to=20 flush all MACs associated with a VPLS instance when it receives = MAC list=20 = TLV

          &n= bsp;    =20 without any MAC address(s) in the list (empty list). In case, of = the MAC=20 List TLV that contains specific MAC addresses then the=20 = receiving

         &n= bsp;     =20 entity needs to remove only those MAC addresses in the list = associated=20 with VPLS instance (identifies by FEC in the address withdraw = msg). The=20 withdrawl with empty=20 = list

          &= nbsp;    =20 feature is to make it more scalable. For example, a VPLS = instance that=20 has 1000 MACs learned at a PE need not=20 = send

          &= nbsp;    =20 Address withdraw with 1000 MACs list, can send empty list = instead. But=20 again it is optional (means if the MAC withdraw originating PE=20 = wants

          =     =20 It can send Address Withdraw with 1000 MACs list) and = implementation=20 specific. Let's say for a dual homed MTU in HVPLS, the primary = link has=20 100=20 = PWs

          &n= bsp;    =20 (1 for each VPLS instance) and the secondary link has the backup = of all=20 the 100 PWs. Now if all 100 primary PWs fail then, all will = switch back=20 to the secondary and=20 = MTU

          &n= bsp;   =20 needs to send Address Withdraw with MACList TLV, one for each of = the 100=20 PWs. So, empty list would be preferable for each=20 message.

(2)
Is MAC-Address-withdraw mechanism ever = intended=20 to be used for U-PW (user facing PW, MTU-S<->PErs)?
If = so, how,=20 when, implication of withdraw msg from N-PW (PE<->PE) to = U-PW, etc=20 needs to
be described.



[Pranjal]: The draft = says that=20 the MAC withdraw originated at a MTU (in MTU-PErs direction) = needs to be=20 processed and forwarded by PE-rs

to other PEs. The draft = hasn't=20 specified about propagating MAC withdraw by PEs to the = distant-end MTUs=20 in HVPLS (in PErs->MTU direction). I think

that part = is=20 implementation specific. The reason could be the distant end = MTUs will=20 still be receiving the traffic in the primary link and MAC = withdrawl may=20 not be necessary.

regards,
himanshu

Himanshu=20 Shah
Ciena=20 = Corp

=
------_=_NextPart_001_01C61229.9D72B931-- From l2vpn-bounces@ietf.org Mon Jan 09 22:28:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwABn-00033E-TO; Mon, 09 Jan 2006 22:28:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwABl-0002ys-57 for l2vpn@megatron.ietf.org; Mon, 09 Jan 2006 22:28:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27026 for ; Mon, 9 Jan 2006 22:27:30 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwAIM-0001MW-Tu for l2vpn@ietf.org; Mon, 09 Jan 2006 22:35:40 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id A2111642E4 for ; Mon, 9 Jan 2006 20:28:22 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D8CA952-613C-4B35-9241-5C73D6163D33@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Date: Mon, 9 Jan 2006 20:28:26 -0700 To: l2vpn@ietf.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Subject: Fwd: Last Call: 'L2VPN Extensions for L2TP' to Proposed Standard X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Folks, If you have the time, could you take a look at the following I-D, which is on its way to Proposed Standard? Thanks, -shane Begin forwarded message: > From: The IESG > Date: January 9, 2006 3:37:50 PM MST > To: IETF-Announce > Cc: l2tpext@ietf.org > Subject: Last Call: 'L2VPN Extensions for L2TP' to Proposed Standard > Reply-To: iesg@ietf.org > > The IESG has received a request from the Layer Two Tunneling Protocol > Extensions WG to consider the following document: > > - 'L2VPN Extensions for L2TP ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-23. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2vpn-06.txt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce From l2vpn-bounces@ietf.org Tue Jan 10 15:50:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQRU-00013e-KD; Tue, 10 Jan 2006 15:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwQRP-000126-3o; Tue, 10 Jan 2006 15:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06924; Tue, 10 Jan 2006 15:48:41 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwQYA-0007SV-G4; Tue, 10 Jan 2006 15:57:02 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EwQRN-0004Yu-Mm; Tue, 10 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jan 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: l2vpn@ietf.org Subject: I-D ACTION:draft-ietf-l2vpn-requirements-06.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org --NextPart 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 : Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks Author(s) : W. Augustyn, Y. Serbest Filename : draft-ietf-l2vpn-requirements-06.txt Pages : 25 Date : 2006-1-10 This document provides requirements for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs referred to as Virtual Private Wire Service (VPWS), as well as multipoint-to-multipoint VPNs also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from a customer as well as a service provider perspective. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-l2vpn-requirements-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-l2vpn-requirements-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-10145321.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-l2vpn-requirements-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-l2vpn-requirements-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-10145321.I-D@ietf.org> --OtherAccess-- --NextPart-- From l2vpn-bounces@ietf.org Tue Jan 10 20:37:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwUw1-0006gi-OR; Tue, 10 Jan 2006 20:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwUw0-0006gQ-RH for l2vpn@megatron.ietf.org; Tue, 10 Jan 2006 20:37:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29481 for ; Tue, 10 Jan 2006 20:36:36 -0500 (EST) Message-Id: <200601110136.UAA29481@ietf.org> Received: from [218.104.33.231] (helo=centecnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwV2o-0000IF-Ne for l2vpn@ietf.org; Tue, 10 Jan 2006 20:44:59 -0500 Received: from fengger ([218.104.33.229]) (envelope-sender ) by 192.168.25.7 with ESMTP for ; Wed, 11 Jan 2006 09:37:41 +0800 From: "Fengger" To: Date: Wed, 11 Jan 2006 09:37:45 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C61692.AD1C30E0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcYWT56seABWNILYS9i4j8cq2umNsg== X-Spam-Score: 0.1 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Subject: Is mac learning on AC side required or optional or forbidden for VPWS? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C61692.AD1C30E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit WG, For VPLS, the draft has explicitly specified that mac learning/bridging must be supported on AC side. But it doesn't how to do for VPWS on the AC side. I have read some vendor's implementation document, whose understandings are different. Some of them treat VPWS as absolute P2P connection, on each PE, one PW only corresponds to one port or Only corresponds one vlan on one port. So there is no learning/bridging on the AC side. But some of them understand it differently, on each PE, there are more than one ports can map to one PW or One vlan which includes more than one customer-facing ports can map to one PW. In this case, learning/bridging on AC side Is necessary. So, I think the requirement for VPWS should explicitly outline this point. Should specify if learning/bridging for VPWS on the AC side is required , optional or forbidden. Thanks and BR Fengger ------=_NextPart_000_000B_01C61692.AD1C30E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG,

 

For VPLS, the draft has explicitly specified = that mac learning/bridging must be supported on AC = side.

But it doesn’t how to do for VPWS on the = AC side.

I have read some vendor’s implementation document, whose understandings are = different.

Some of them treat VPWS as absolute P2P = connection, on each PE, one PW only corresponds to one port = or

Only corresponds one vlan on one port. So there = is no learning/bridging on the AC side.

But some of them understand it differently, on = each PE, there are more than one ports can map to one PW = or

One vlan which includes more than one = customer-facing ports can map to one PW. In this case, learning/bridging on AC = side

Is necessary.

 

So, I think the requirement for VPWS should = explicitly outline this point. Should specify if learning/bridging for VPWS on the = AC side is required

, optional or = forbidden.

 

Thanks and BR

 

Fengger

 

------=_NextPart_000_000B_01C61692.AD1C30E0-- From l2vpn-bounces@ietf.org Wed Jan 11 05:14:34 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewczy-0001um-GN; Wed, 11 Jan 2006 05:14:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewczx-0001uh-Ey for l2vpn@megatron.ietf.org; Wed, 11 Jan 2006 05:14:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29507 for ; Wed, 11 Jan 2006 05:13:13 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewd6n-0005fr-VT for l2vpn@ietf.org; Wed, 11 Jan 2006 05:21:40 -0500 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id CAA16214; Wed, 11 Jan 2006 02:13:44 -0800 (PST) Message-ID: <01ec01c61697$b0bae930$6401a8c0@IBMT41ML> From: "Marc Lasserre" To: "Fengger" , References: <200601110136.UAA29481@ietf.org> Date: Wed, 11 Jan 2006 11:08:13 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E5_01C6169F.50700E90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: Subject: Re: Is mac learning on AC side required or optional or forbidden forVPWS? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01E5_01C6169F.50700E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fengger, VPWS is defined as a p2p service and hence no learning is required. This = point is clearly specified in both the l2vpn charter and RFC4026. Not = being a requirement does not prevent specific implementations from = supporting add'l capabilities such as the ability to learn MACs when = multiple ports are mapped to a VPWS. Marc ----- Original Message -----=20 From: Fengger=20 To: l2vpn@ietf.org=20 Sent: Wednesday, January 11, 2006 2:37 AM Subject: Is mac learning on AC side required or optional or forbidden = forVPWS? WG, =20 For VPLS, the draft has explicitly specified that mac = learning/bridging must be supported on AC side. But it doesn't how to do for VPWS on the AC side. I have read some vendor's implementation document, whose = understandings are different. Some of them treat VPWS as absolute P2P connection, on each PE, one PW = only corresponds to one port or Only corresponds one vlan on one port. So there is no = learning/bridging on the AC side. But some of them understand it differently, on each PE, there are more = than one ports can map to one PW or One vlan which includes more than one customer-facing ports can map to = one PW. In this case, learning/bridging on AC side Is necessary. =20 So, I think the requirement for VPWS should explicitly outline this = point. Should specify if learning/bridging for VPWS on the AC side is = required , optional or forbidden. =20 Thanks and BR =20 Fengger =20 ------=_NextPart_000_01E5_01C6169F.50700E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Fengger,
 
VPWS is defined as a p2p service and = hence no=20 learning is required. This point is clearly specified in both the l2vpn charter and RFC4026. Not being a requirement = does not=20 prevent specific implementations from supporting add'l capabilities such = as the=20 ability to learn MACs when multiple ports are mapped to a = VPWS.
 
Marc
----- Original Message -----
From:=20 Fengger
Sent: Wednesday, January 11, = 2006 2:37=20 AM
Subject: Is mac learning on AC = side=20 required or optional or forbidden forVPWS?

WG,

 

For VPLS, the draft has = explicitly=20 specified that mac learning/bridging must be supported on AC=20 side.

But it doesn=92t how to = do for VPWS=20 on the AC side.

I have read some = vendor=92s=20 implementation document, whose understandings are=20 different.

Some of them treat VPWS = as absolute=20 P2P connection, on each PE, one PW only corresponds to one port=20 or

Only corresponds one vlan = on one=20 port. So there is no learning/bridging on the AC=20 side.

But some of them = understand it=20 differently, on each PE, there are more than one ports can map to one = PW=20 or

One vlan which includes = more than=20 one customer-facing ports can map to one PW. In this case, = learning/bridging=20 on AC side

Is=20 necessary.

 

So, I think the = requirement for=20 VPWS should explicitly outline this point. Should specify if = learning/bridging=20 for VPWS on the AC side is required

, optional or=20 forbidden.

 

Thanks and BR

 

Fengger

 

------=_NextPart_000_01E5_01C6169F.50700E90-- From l2vpn-bounces@ietf.org Wed Jan 11 06:21:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewe2K-0004I5-VF; Wed, 11 Jan 2006 06:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewe2J-0004Hr-8a for l2vpn@megatron.ietf.org; Wed, 11 Jan 2006 06:21:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03287 for ; Wed, 11 Jan 2006 06:19:43 -0500 (EST) Received: from mail.greenfieldnetworks.com ([64.220.152.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewe9B-0007N5-MD for l2vpn@ietf.org; Wed, 11 Jan 2006 06:28:11 -0500 Received: from [127.0.0.1] ([10.20.20.142]) by mail.greenfieldnetworks.com (8.13.1/8.13.1) with ESMTP id k0BBKa2v003185 for ; Wed, 11 Jan 2006 03:20:52 -0800 Message-ID: <43C4EBC7.4010306@greenfieldnetworks.com> Date: Wed, 11 Jan 2006 16:58:07 +0530 From: Ravindra Rathi User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: Question on RSTP/MSTP between CE and PE X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is regarding following text in draft-sajassi-l2vpn-vpls-bridge-interop-01.txt. For example, when an Attachment Circuit is port-based, then the bridge module of the PE can operate transparently with respect to the CEs RSTP/MSTP protocols (and thus no C-VLAN component is required for that customer UNI). However, when an Attachment Circuit is VLAN-based (either VLAN mapping or VLAN bundling), then the bridge module of the PE needs to peer with the RSTP/MSTP protocols running on the CE (and thus the C-VLAN bridge component is required). Can anyone explain clearly why PE need not participate in CE's RSTP/MSTP protocols if attachment circuit(AC) is port based and why it should participate if AC is vlan based..? Thanks, Rathi From l2vpn-bounces@ietf.org Wed Jan 11 08:03:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfdD-0000is-LS; Wed, 11 Jan 2006 08:03:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfdB-0000iU-Mf for l2vpn@megatron.ietf.org; Wed, 11 Jan 2006 08:03:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10062 for ; Wed, 11 Jan 2006 08:01:50 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewfk1-00020V-51 for l2vpn@ietf.org; Wed, 11 Jan 2006 08:10:19 -0500 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id FAA05913; Wed, 11 Jan 2006 05:02:41 -0800 (PST) Message-ID: <023901c616af$4a9e3d10$6401a8c0@IBMT41ML> From: "Marc Lasserre" To: "Fengger" , References: <200601111245.k0BCj641008063@mgate2.riverstonenet.com> Date: Wed, 11 Jan 2006 14:02:33 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0236_01C616B7.AB607750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.3 (+++) X-Scan-Signature: d9951f061208886fc6ada4b24aa6f98d Cc: Subject: Re: Is mac learning on AC side required or optional or forbidden forVPWS? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0236_01C616B7.AB607750 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Fengger=20 To: 'Marc Lasserre' ; l2vpn@ietf.org=20 Sent: Wednesday, January 11, 2006 1:44 PM Subject: =B4=F0=B8=B4: Is mac learning on AC side required or optional = or forbidden forVPWS? Thank Marc. =20 Then I want to discuss another related case. Can I deduce so: If the PW is vlan based, the vlan shouldn=A1=AFt = include more than one customer-facing port on the PE? Because once the vlan includes more then one customer-facing port, = then learning is needed in the AC side. Certainly, as what you have said, it doesn=A1=AFt prevent specific = implementations from supporting such case. Fengger, =20 Your understanding is correct. If my above understanding is wrong, then the below questions may be = ignored. Otherwise, I=A1=AFd like to continue another related=20 question. : ) If the draft proposes that one vlan only includes one customer-facing = port on the PE, then why doesn=A1=AFt the draft introduces = =A1=B0port+vlan=A1=B1 based PW but only the vlan-base PW? I think =A1=B0port+vlan=A1=B1 based PW = is more scalable than vlan-based PW because the latter can support up to = 4K customers while the former can support much more. In other words, I = think in this case, the vlan 100 on port 1 should be mapped to a VC = label differently from the vlan 100 on port 2. This is also implementation dependent. Such capabilities (port/VLAN = combinations) can be supported. Maybe my question is too naive, but please fix me. Thanks! =20 - Fengger=20 =20 =20 -------------------------------------------------------------------------= ----- =B7=A2=BC=FE=C8=CB: Marc Lasserre [mailto:marc@riverstonenet.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA1=D4=C211=C8=D5 18:08 =CA=D5=BC=FE=C8=CB: Fengger; l2vpn@ietf.org =D6=F7=CC=E2: Re: Is mac learning on AC side required or optional or = forbidden forVPWS? =20 Fengger, =20 VPWS is defined as a p2p service and hence no learning is required. = This point is clearly specified in both the l2vpn charter and RFC4026. = Not being a requirement does not prevent specific implementations from = supporting add'l capabilities such as the ability to learn MACs when = multiple ports are mapped to a VPWS. =20 Marc ----- Original Message -----=20 From: Fengger=20 To: l2vpn@ietf.org=20 Sent: Wednesday, January 11, 2006 2:37 AM Subject: Is mac learning on AC side required or optional or = forbidden forVPWS? =20 WG, =20 For VPLS, the draft has explicitly specified that mac = learning/bridging must be supported on AC side. But it doesn=A1=AFt how to do for VPWS on the AC side. I have read some vendor=A1=AFs implementation document, whose = understandings are different. Some of them treat VPWS as absolute P2P connection, on each PE, one = PW only corresponds to one port or Only corresponds one vlan on one port. So there is no = learning/bridging on the AC side. But some of them understand it differently, on each PE, there are = more than one ports can map to one PW or One vlan which includes more than one customer-facing ports can map = to one PW. In this case, learning/bridging on AC side Is necessary. =20 So, I think the requirement for VPWS should explicitly outline this = point. Should specify if learning/bridging for VPWS on the AC side is = required , optional or forbidden. =20 Thanks and BR =20 Fengger =20 ------=_NextPart_000_0236_01C616B7.AB607750 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From:=20 Fengger
To: 'Marc Lasserre' ; l2vpn@ietf.org
Sent: Wednesday, January 11, = 2006 1:44=20 PM
Subject: =B4=F0=B8=B4: Is mac = learning on AC side=20 required or optional or forbidden forVPWS?

Thank=20 Marc.

 

Then I want = to discuss=20 another related case.

Can I deduce = so: If=20 the PW is vlan based, the vlan shouldn=A1=AFt include more than one = customer-facing=20 port on the PE?

Because once = the vlan=20 includes more then one customer-facing port, then learning is needed = in the AC=20 side.

Certainly, = as what you=20 have said, it doesn=A1=AFt prevent specific implementations from = supporting such=20 case.

Fengger,

 

Your understanding is correct.

If my above=20 understanding is wrong, then the below questions may be ignored. = Otherwise,=20 I=A1=AFd like to continue another related =

question. :=20 )

If the draft = proposes=20 that one vlan only includes one customer-facing port on the PE, then = why=20 doesn=A1=AFt the draft introduces =A1=B0port+vlan=A1=B1 = based

PW but only = the=20 vlan-base PW? I think =A1=B0port+vlan=A1=B1 based PW is more scalable = than vlan-based PW=20 because the latter can support up to 4K

customers = while the=20 former can support much more. In other words, I think in this case, = the vlan=20 100 on port 1 should be mapped to a VC label=20 differently

from the = vlan 100 on=20 port 2.

This is also=20 implementation dependent. Such capabilities (port/VLAN combinations) can = be=20 supported.

Maybe my = question is=20 too naive, but please fix me.

Thanks!

 

- Fengger=20

 

 

=B7=A2=BC=FE=C8=CB: Marc Lasserre=20 [mailto:marc@riverstonenet.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2006=C4=EA1=D4=C211=C8=D5 = 18:08
=CA=D5=BC=FE=C8=CB: Fengger;=20 l2vpn@ietf.org
=D6=F7=CC=E2: Re: Is mac = learning on AC side=20 required or optional or forbidden forVPWS?

 

Fengger,

 

VPWS is=20 defined as a p2p service and hence no learning is required. This point = is=20 clearly specified in both the l2vpn charter and RFC4026. Not being a=20 requirement does not prevent specific implementations from supporting = add'l=20 capabilities such as the ability to learn MACs when multiple ports are = mapped=20 to a VPWS.

 

Marc

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

From: Fengger=20

Sent: Wednesday, January = 11, 2006 2:37 = AM

Subject: Is mac learning on AC = side=20 required or optional or forbidden=20 forVPWS?

 

WG,

 

For VPLS,=20 the draft has explicitly specified that mac learning/bridging must = be=20 supported on AC side.

But it=20 doesn=A1=AFt how to do for VPWS on the AC = side.

I have=20 read some vendor=A1=AFs implementation document, whose = understandings are=20 different.

Some of=20 them treat VPWS as absolute P2P connection, on each PE, one PW only=20 corresponds to one port or

Only=20 corresponds one vlan on one port. So there is no learning/bridging = on the AC=20 side.

But some=20 of them understand it differently, on each PE, there are more than = one ports=20 can map to one PW or

One vlan=20 which includes more than one customer-facing ports can map to one = PW. In=20 this case, learning/bridging on AC side

Is=20 necessary.

 

So, I=20 think the requirement for VPWS should explicitly outline this point. = Should=20 specify if learning/bridging for VPWS on the AC side is=20 required

,=20 optional or forbidden.

 

Thanks and BR

 

Fengger

 

------=_NextPart_000_0236_01C616B7.AB607750-- From l2vpn-bounces@ietf.org Wed Jan 11 11:47:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewj7w-0003L2-CR; Wed, 11 Jan 2006 11:47:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwZW5-00037F-NH for l2vpn@megatron.ietf.org; Wed, 11 Jan 2006 01:31:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17944 for ; Wed, 11 Jan 2006 01:30:09 -0500 (EST) Received: from [218.104.33.231] (helo=centecnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwZcv-0008Vi-In for l2vpn@ietf.org; Wed, 11 Jan 2006 01:38:35 -0500 Received: from [192.168.0.152] ([218.104.33.229]) (envelope-sender ) by 192.168.25.7 with ESMTP for ; Wed, 11 Jan 2006 14:30:55 +0800 Message-ID: <43C4A64F.1010406@centecnetworks.com> Date: Wed, 11 Jan 2006 14:31:43 +0800 From: Tao Gu User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Jan 2006 11:47:11 -0500 Subject: difference between VPLS and PWE3 encapsulation X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gu@centecnetworks.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi folks, According to section 7&8 in draft-ietf-l2vpn-vpls-ldp-08.txt, the VPLS encapsulation is "similar" to PWE3 but has some differences in VLAN tag processing, can anyone explain in detail what these differences are? It would be great if some examples are provided in both cases to help the understanding. Thanks a lot. Best Regards, Tao Gu 7. Data Forwarding on an Ethernet PW This section describes the data plane behavior on an Ethernet PW used in a VPLS. While the encapsulation is similar to that described in [PWE3-ETHERNET], the functions of stripping the service-delimiting tag and using a "normalized" Ethernet frame are described. .... 8. Data Forwarding on an Ethernet VLAN PW This section describes the data plane behavior on an Ethernet VLAN PW in a VPLS. While the encapsulation is similar to that described in [PWE3-ETHERNET], the functions of imposing tags and using a "normalized" Ethernet frame are described. The learning behavior is the same as for Ethernet PWs. From l2vpn-bounces@ietf.org Wed Jan 11 11:47:12 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewj7w-0003LS-RB; Wed, 11 Jan 2006 11:47:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewa8e-0006KL-BL for l2vpn@megatron.ietf.org; Wed, 11 Jan 2006 02:11:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19911 for ; Wed, 11 Jan 2006 02:09:59 -0500 (EST) Received: from [218.104.33.231] (helo=centecnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EwaFV-00010U-EF for l2vpn@ietf.org; Wed, 11 Jan 2006 02:18:25 -0500 Received: from [192.168.0.152] ([218.104.33.229]) (envelope-sender ) by 192.168.25.7 with ESMTP for ; Wed, 11 Jan 2006 15:11:01 +0800 Message-ID: <43C4AFB6.1080807@centecnetworks.com> Date: Wed, 11 Jan 2006 15:11:50 +0800 From: Tao Gu User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 11 Jan 2006 11:47:11 -0500 Subject: supporting both Ethernet PW and Ethernet VLAN PW on the same VSI on the same PE X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gu@centecnetworks.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi folks, According to section 8 in draft-ietf-l2vpn-vpls-ldp-08.txt, A VPLS MAY have both Ethernet and Ethernet VLAN PWs. However, if a PE is not able to support both PWs simultaneously, it SHOULD send a Label Release on the PW messages that it cannot support with a status code "Unknown FEC" as given in [RFC3036]. My understanding is that a VSI on the same PE (say PE1) can support both types of PWs, i.e., using a Ethernet PW to connect to PE2 while using a Ethernet VLAN PW to connect to PE3. Can anyone confirm this? Thanks a lot in advance. Best regards, Tao Gu -- Tao Gu Centec Networks Inc. www.centecnetworks.com tgu@centecnetworks.com Tel (0512) 62885358 ext 815 Fax (0512) 62885870 Cell 136-4621-3957 From l2vpn-bounces@ietf.org Wed Jan 11 12:04:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjOK-0001vO-NN; Wed, 11 Jan 2006 12:04:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwjOJ-0001ur-1f for l2vpn@megatron.ietf.org; Wed, 11 Jan 2006 12:04:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26895 for ; Wed, 11 Jan 2006 12:02:46 -0500 (EST) Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwjVE-0000vf-Ad for l2vpn@ietf.org; Wed, 11 Jan 2006 12:11:17 -0500 Received: from IBMT41ML by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA03909; Wed, 11 Jan 2006 09:03:39 -0800 (PST) Message-ID: <02b901c616d0$f41a22c0$6401a8c0@IBMT41ML> From: "Marc Lasserre" To: , References: <43C4AFB6.1080807@centecnetworks.com> Date: Wed, 11 Jan 2006 18:03:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.9 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Subject: Re: supporting both Ethernet PW and Ethernet VLAN PW on the same VSI on the same PE X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org ----- Original Message ----- From: "Tao Gu" To: Sent: Wednesday, January 11, 2006 8:11 AM Subject: supporting both Ethernet PW and Ethernet VLAN PW on the same VSI on the same PE > Hi folks, > > According to section 8 in draft-ietf-l2vpn-vpls-ldp-08.txt, > > A VPLS MAY have both Ethernet and Ethernet VLAN PWs. However, if a PE is > not able to support both PWs simultaneously, it SHOULD send a Label > Release on the PW messages that it cannot support with a status code > "Unknown FEC" as given in [RFC3036]. > My understanding is that a VSI on the same PE (say PE1) can support both > types of PWs, i.e., using a Ethernet PW to connect to PE2 while using a > Ethernet VLAN PW to connect to PE3. Can anyone confirm this? Tao, This is correct as long as peer PEs support the corresponding PW types. Marc > > Thanks a lot in advance. > > Best regards, > > Tao Gu > > -- > Tao Gu > > > Centec Networks Inc. > www.centecnetworks.com > > tgu@centecnetworks.com > Tel (0512) 62885358 ext 815 > Fax (0512) 62885870 > Cell 136-4621-3957 > > > > > From l2vpn-bounces@ietf.org Wed Jan 11 23:19:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewtvj-0006rT-Uy; Wed, 11 Jan 2006 23:19:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewtvi-0006qw-0M for l2vpn@megatron.ietf.org; Wed, 11 Jan 2006 23:19:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18532 for ; Wed, 11 Jan 2006 23:17:58 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ewu2j-0006Ub-K8 for l2vpn@ietf.org; Wed, 11 Jan 2006 23:26:34 -0500 Received: from [172.16.15.25] (dsl081-098-224.den1.dsl.speakeasy.net [64.81.98.224]) by dog.tcb.net (Postfix) with ESMTP id 655DB64392 for ; Wed, 11 Jan 2006 21:18:53 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <08C63A4D-69A8-48A8-80DC-9945AB95CF84@castlepoint.net> References: <08C63A4D-69A8-48A8-80DC-9945AB95CF84@castlepoint.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A7978BE-8022-4F7C-8B12-D45C60CDBF9A@castlepoint.net> Content-Transfer-Encoding: 7bit From: Shane Amante Date: Wed, 11 Jan 2006 21:18:57 -0700 To: l2vpn@ietf.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Folks, FYI. Last Call on IPLS ends this Friday, 1/13. So far, we haven't seen any comments, or anyone respond with either an affirmation or objection to forward this I-D on to the IESG. Please speak up by Friday. Thanks, -shane & Vach On Dec 18, 2005, at 6:08 PM, Shane Amante wrote: > Folks, > > This note starts a WG Last Call for comments on: draft-ietf-l2vpn- > ipls-05.txt, "IP-Only LAN Service (IPLS)". It can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-ipls-05.txt > > Please thoroughly review the document and send any comments to the > list. Also, please indicate whether you do or do not believe this > document is ready to go to the IESG. > > Due to the holidays, the WG Last Call will end on 13 Jan 2006 at > 1700 MST (UTC/GMT -7). > > -shane > From l2vpn-bounces@ietf.org Thu Jan 12 00:53:01 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwvOP-0003hX-Pn; Thu, 12 Jan 2006 00:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwvON-0003hP-KM for l2vpn@megatron.ietf.org; Thu, 12 Jan 2006 00:52:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22581 for ; Thu, 12 Jan 2006 00:51:39 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwvVQ-0000EL-9H for l2vpn@ietf.org; Thu, 12 Jan 2006 01:00:16 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 11 Jan 2006 21:52:49 -0800 X-IronPort-AV: i="3.99,358,1131350400"; d="scan'208,217"; a="390769304:sNHT57510544" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0C5qmjt000268; Wed, 11 Jan 2006 21:52:48 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 21:52:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6173C.6ADAAE7D" Date: Wed, 11 Jan 2006 21:52:49 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB01015B4B@xmb-sjc-21e.amer.cisco.com> Thread-Topic: Is mac learning on AC side required or optional or forbiddenforVPWS? Thread-Index: AcYWmDrm7E/Cr9ezQxOZqkphRFsPAAAowunQ From: "Ali Sajassi \(sajassi\)" To: "Marc Lasserre" , "Fengger" , X-OriginalArrivalTime: 12 Jan 2006 05:52:48.0825 (UTC) FILETIME=[6B0EDA90:01C6173C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: Subject: RE: Is mac learning on AC side required or optional or forbiddenforVPWS? X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6173C.6ADAAE7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Marc, =20 I don't want to be too picky here but the we should not confuse the terminologies that are clearly defined in the l2vpn drafts/charters. If anything, the functionality that you are talking about falls under degenerate case of VPLS (e.g., VPLS with two sites), rather than calling it VPWS with additional functionality. =20 -Ali=20 ________________________________ From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Marc Lasserre Sent: Wednesday, January 11, 2006 2:08 AM To: Fengger; l2vpn@ietf.org Subject: Re: Is mac learning on AC side required or optional or forbiddenforVPWS? =09 =09 Fengger, =20 VPWS is defined as a p2p service and hence no learning is required. This point is clearly specified in both the l2vpn charter and RFC4026. Not being a requirement does not prevent specific implementations from supporting add'l capabilities such as the ability to learn MACs when multiple ports are mapped to a VPWS. =20 Marc ----- Original Message -----=20 From: Fengger =20 To: l2vpn@ietf.org=20 Sent: Wednesday, January 11, 2006 2:37 AM Subject: Is mac learning on AC side required or optional or forbidden forVPWS? WG, =20 For VPLS, the draft has explicitly specified that mac learning/bridging must be supported on AC side. But it doesn't how to do for VPWS on the AC side. I have read some vendor's implementation document, whose understandings are different. Some of them treat VPWS as absolute P2P connection, on each PE, one PW only corresponds to one port or Only corresponds one vlan on one port. So there is no learning/bridging on the AC side. But some of them understand it differently, on each PE, there are more than one ports can map to one PW or One vlan which includes more than one customer-facing ports can map to one PW. In this case, learning/bridging on AC side Is necessary. =20 So, I think the requirement for VPWS should explicitly outline this point. Should specify if learning/bridging for VPWS on the AC side is required , optional or forbidden. =20 Thanks and BR =20 Fengger =20 ------_=_NextPart_001_01C6173C.6ADAAE7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Marc,
 
I don't want to be too picky here but the we = should=20 not confuse the terminologies that are clearly defined in the l2vpn = drafts/charters. If anything, the functionality that you are = talking about=20 falls under degenerate case of VPLS (e.g., VPLS with two sites), rather = than=20 calling it VPWS with additional functionality.
 
-Ali 

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of Marc=20 Lasserre
Sent: Wednesday, January 11, 2006 2:08 = AM
To:=20 Fengger; l2vpn@ietf.org
Subject: Re: Is mac learning on AC = side=20 required or optional or forbiddenforVPWS?

Fengger,
 
VPWS is defined as a p2p service and = hence no=20 learning is required. This point is clearly specified in both the l2vpn charter and RFC4026. Not being a = requirement does not=20 prevent specific implementations from supporting add'l capabilities = such as=20 the ability to learn MACs when multiple ports are mapped to a=20 VPWS.
 
Marc
----- Original Message -----
From:=20 Fengger
Sent: Wednesday, January 11, = 2006 2:37=20 AM
Subject: Is mac learning on = AC side=20 required or optional or forbidden forVPWS?

WG,

 

For VPLS, the draft has = explicitly specified that mac learning/bridging must be supported on = AC=20 side.

But it doesn’t = how to do for VPWS=20 on the AC side.

I have read some = vendor’s=20 implementation document, whose understandings are=20 different.

Some of them treat VPWS = as=20 absolute P2P connection, on each PE, one PW only corresponds to one = port=20 or

Only corresponds one = vlan on one=20 port. So there is no learning/bridging on the AC=20 side.

But some of them = understand it=20 differently, on each PE, there are more than one ports can map to = one PW=20 or

One vlan which includes = more than=20 one customer-facing ports can map to one PW. In this case, = learning/bridging=20 on AC side

Is=20 necessary.

 

So, I think the = requirement for=20 VPWS should explicitly outline this point. Should specify if=20 learning/bridging for VPWS on the AC side is=20 required

, optional or=20 forbidden.

 

Thanks and BR

 

Fengger

 

------_=_NextPart_001_01C6173C.6ADAAE7D-- From l2vpn-bounces@ietf.org Thu Jan 12 07:37:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex1i8-0000RP-C7; Thu, 12 Jan 2006 07:37:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex1i6-0000RJ-Pg for l2vpn@megatron.ietf.org; Thu, 12 Jan 2006 07:37:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14246 for ; Thu, 12 Jan 2006 07:36:26 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ex1pD-0002KE-LV for l2vpn@ietf.org; Thu, 12 Jan 2006 07:45:08 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Jan 2006 13:37:37 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0CCbYgT011734; Thu, 12 Jan 2006 13:37:35 +0100 (MET) Received: from [10.61.80.215] (ams-clip-vpn-dhcp4312.cisco.com [10.61.80.215]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA18324; Thu, 12 Jan 2006 12:37:33 GMT Message-ID: <43C64D8D.7050307@cisco.com> Date: Thu, 12 Jan 2006 12:37:33 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shane Amante References: <08C63A4D-69A8-48A8-80DC-9945AB95CF84@castlepoint.net> <9A7978BE-8022-4F7C-8B12-D45C60CDBF9A@castlepoint.net> In-Reply-To: <9A7978BE-8022-4F7C-8B12-D45C60CDBF9A@castlepoint.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org 3. Pseudowires for Multicast Traffic: In addition, every PE supporting a given IPLS instance will set up a special "broadcast pseudowire" to every other PE in that IPLS instance. SB> Is there any intention to use PSN multicast techniques here (either SB> now or in the future? 4. Signaling: The necessary pseudowires can be set up and maintained using the LDP-based signaling procedures described in [PWE3-CONTROL]. SB> The only control protocol that gets referenced is PWE3-Control, SB> but the draft (quite rightly) talks about L2TP as an alternate SB> tunnel technology. I think that we need to be able to run this SB> over any PSN type and use the PWs defined by both PWE3 and L2TPext SB> WGs. 3.0 Topology The Customer Edge (CE) devices are IP nodes (hosts or routers) that are connected to PE devices either directly, or via an Ethernet network. We assume that the PE/CE connection may be regarded by the PE as an "interface" to which one or more CEs are attached. This interface may be a physical LAN interface or a VLAN. The Provider Edge (PE) routers are MPLS Label Edge Routers (LERs) that serve as pseudowire endpoints. PE1, PE2 and PE3 are shown as connected via an MPLS network; however, other tunneling technologies, such as GRE, L2TPv3, etc., could also be used to carry the pseudowires. SB> This is where you talk about about L2TPv3 6.0 Pseudowire Creation 6.1 Receive Unicast Multipoint-to-point Pseudowire As the PE discovers each locally attached CE, a unicast multipoint- to-point pseudowire (mp2p PW) associated exclusively with that CE is created by distributing the CE's IP address and MAC address along with a PW-Label to all the remote PE peers that participate in the same IPLS instance. Note that the same value of a PW-label SHOULD be distributed to all the remote PE peers for a given CE. The mp2p PW thus created is used by remote PEs to send unicast IP traffic to a specific CE. (The same functionality can be provided by a set of point-to-point PWs, and the PE is not required to send the same PW-label to all the other PEs. For convenience, however, we will use the term mp2p PWs, which may be implemented using a set of point-to-point PWs.) SB> Do we need to start work on mp PWs over in PWE3? 11.0 IP Protocols The solution described in this document offers IPLS service for IPv4 traffic only. SB> Why? For this reason, the MAC Header is not carried over the unicast pseudowire. It is reconstructed by the PE when receiving a packet from a unicast pseudowire and the Ethertype 0x0800 is used in the MAC Header since IPv4 is assumed. However, this solution may be extended to carry other types of important traffic such as ISIS and IPv6 which are not encapsulated in Ethernet with the use of Ethertype 0x0800. SB> Surely these are needed day one? In order to permit the propagation of such packets correctly, one may create a separate set of pseudowires SB> That is a very bad idea! The IGPs assume that there is shared SB> fate between data and routing. If yo do this you break one SB> of the IGP design invariants. , or pass protocol information in the "control word" SB> sort of PW-ACH with 0000 in the first nibble? of a "multiprotocol" pseudowire, or encapsulate the Ethernet MAC Header in the pseudowire. The selection of appropriate multiplexing/demultiplexing scheme is the subject of future study. The current document focuses on IPLS service for IPv4 traffic. SB> What is the IETF policy on standards that only support v4? SB> Surely we really ought to support v6 on day one? [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", February 2005, work in progress. SB> This does not seem to be called up in the body of the draft Stewart From l2vpn-bounces@ietf.org Thu Jan 12 21:18:18 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExEWA-00042F-3d; Thu, 12 Jan 2006 21:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExEW8-00040j-6X; Thu, 12 Jan 2006 21:18:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20368; Thu, 12 Jan 2006 21:16:54 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExEdE-0006ji-7c; Thu, 12 Jan 2006 21:25:41 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IT000GS7EM7H6@szxga02-in.huawei.com>; Fri, 13 Jan 2006 10:22:55 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IT000A99EM7OZ@szxga02-in.huawei.com>; Fri, 13 Jan 2006 10:22:55 +0800 (CST) Received: from d10570a ([10.70.77.239]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IT000AYQERSQ0@szxml01-in.huawei.com>; Fri, 13 Jan 2006 10:26:16 +0800 (CST) Date: Fri, 13 Jan 2006 10:11:30 +0800 From: Jixiong Dong To: Stewart Bryant , Shane Amante Message-id: <00f001c617e6$ab47bc80$ef4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <08C63A4D-69A8-48A8-80DC-9945AB95CF84@castlepoint.net> <9A7978BE-8022-4F7C-8B12-D45C60CDBF9A@castlepoint.net> <43C64D8D.7050307@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7BIT Cc: l2vpn@ietf.org, pwe3 Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Stewart, IMO, As you indicated, it is the time to start the study work on how to transport the multicast traffic over the PW. In PSN network, each layer has its own multicast technology in control plane. In IP, the multicast technology is IGMP. In ethernet, the multicast technology is IGMP snooping/GMRP/native. In MPLS, mpls folks are working hard on multicast LSP. So I think PWE3 folks should consider pw's multicast technology. And L2VPN can use the PW multicast technology.IMO, L2VPN is not very efficient when transporting multicast traffic or broadcast/flooding traffic. Regards, Dong ----- Original Message ----- From: "Stewart Bryant" To: "Shane Amante" Cc: Sent: Thursday, January 12, 2006 8:37 PM Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt > > 3. Pseudowires for Multicast Traffic: In addition, every PE > supporting a given IPLS instance will set up a special > "broadcast pseudowire" to every other PE in that IPLS instance. > > SB> Is there any intention to use PSN multicast techniques here (either > SB> now or in the future? > > > > 6.0 Pseudowire Creation > > 6.1 Receive Unicast Multipoint-to-point Pseudowire > > As the PE discovers each locally attached CE, a unicast multipoint- > to-point pseudowire (mp2p PW) associated exclusively with that CE is > created by distributing the CE's IP address and MAC address along > with a PW-Label to all the remote PE peers that participate in the > same IPLS instance. Note that the same value of a PW-label SHOULD be > distributed to all the remote PE peers for a given CE. The mp2p PW > thus created is used by remote PEs to send unicast IP traffic to a > specific CE. > > (The same functionality can be provided by a set of point-to-point > PWs, and the PE is not required to send the same PW-label to all the > other PEs. For convenience, however, we will use the term mp2p PWs, > which may be implemented using a set of point-to-point PWs.) > > SB> Do we need to start work on mp PWs over in PWE3? > From l2vpn-bounces@ietf.org Fri Jan 13 01:19:48 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExIHr-0004GC-Qc; Fri, 13 Jan 2006 01:19:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExIHp-0004Fl-V9 for l2vpn@megatron.ietf.org; Fri, 13 Jan 2006 01:19:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04454 for ; Fri, 13 Jan 2006 01:18:24 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExIP4-0005Jt-8G for l2vpn@ietf.org; Fri, 13 Jan 2006 01:27:16 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2006 22:19:34 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0D6JVjv008703; Thu, 12 Jan 2006 22:19:34 -0800 (PST) Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 22:19:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2006 22:19:32 -0800 Message-ID: <75B2A84D9323BC4CA3977CF378CE75EB01015F3C@xmb-sjc-21e.amer.cisco.com> Thread-Topic: Question on RSTP/MSTP between CE and PE Thread-Index: AcYWoqGAvKgJ5p8pS7yDZgEMzfI0PQBZcdvA From: "Ali Sajassi \(sajassi\)" To: "Ravindra Rathi" , X-OriginalArrivalTime: 13 Jan 2006 06:19:33.0790 (UTC) FILETIME=[521AD3E0:01C61809] X-Spam-Score: 2.2 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: Question on RSTP/MSTP between CE and PE X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org The short answer is to take a look at clauses 15 and 13 of 802.1ad (rev.D6). -Ali =20 > -----Original Message----- > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 > On Behalf Of Ravindra Rathi > Sent: Wednesday, January 11, 2006 3:28 AM > To: l2vpn@ietf.org > Subject: Question on RSTP/MSTP between CE and PE >=20 > This is regarding following text in=20 > draft-sajassi-l2vpn-vpls-bridge-interop-01.txt. >=20 > > For example, when an Attachment Circuit is port-based, then=20 > the bridge module of the PE can operate transparently with=20 > respect to the CEs RSTP/MSTP protocols (and thus no C-VLAN=20 > component is required for that customer UNI). However, when=20 > an Attachment Circuit is VLAN-based (either VLAN mapping or=20 > VLAN bundling), then the bridge module of the PE needs to=20 > peer with the RSTP/MSTP protocols running on the CE (and thus=20 > the C-VLAN bridge component is required). > >=20 > Can anyone explain clearly why PE need not participate in=20 > CE's RSTP/MSTP protocols if attachment circuit(AC) is port=20 > based and why it should participate if AC is vlan based..? >=20 > Thanks, > Rathi >=20 From l2vpn-bounces@ietf.org Mon Jan 16 06:47:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySq1-0002nD-Py; Mon, 16 Jan 2006 06:47:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EySq0-0002m0-0r; Mon, 16 Jan 2006 06:47:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05796; Mon, 16 Jan 2006 06:46:27 -0500 (EST) Received: from mgw1.noc.ntt.com ([210.163.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EySxs-0005Ri-Fq; Mon, 16 Jan 2006 06:56:03 -0500 Received: from mop3.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id k0GBlKEK003684; Mon, 16 Jan 2006 20:47:20 +0900 (JST) Received: from mip1.noc.ntt.com (mvi2.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0IT600E2YOQWK1@ntt.com>; Mon, 16 Jan 2006 20:47:20 +0900 (JST) Date: Mon, 16 Jan 2006 20:47:19 +0900 From: "Yuji KAMITE" In-reply-to: To: "'Pekka Savola'" , l3vpn@ietf.org Message-id: <0IT600L90OQV14@ntt.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Thread-index: AcYaAuKQoIGwvXeXQeuJaZmJhWBsqQAhWS0g X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org Subject: RE: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Pekka, > >From the external point of view, what's the relation to > draft-ietf-l2vpn-vpls-mcast-reqts-xx? It'd seem to me that > it'd be HIGHLY desirable that at least the bulk of the > solutions used could be the same... Operators shouldn't need > to deploy two completely different solutions for both L2 and L3VPNs. Yes, it is definitely worth considering common viewpoints, which would give us good opportunities to take similar approaches. That's why l2vpn mcast requriment tries to borrow some l3vpn reqt's wording and ideas that has common points (Actually l3vpn work item was preceding l2vpn a little recently). However, that's not enough yet. Most other parts are needed to be considered spearately in detail because they are dealing with different layer protocols. In l3vpn, there are lots of IP routing layer consideration, that is not needed in l2vpn, while l3vpn does not need to MAC address consideration. We should avoid having just too generic and vague requirements. Regards, -Yuji > -----Original Message----- > From: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] > On Behalf Of Pekka Savola > Sent: Saturday, January 14, 2006 11:24 PM > To: l3vpn@ietf.org > Subject: comments on draft-ietf-l3vpn-ppvpn-mcast-reqts-03 > > Hi, > > On MBONED WG, folks were asked to take a look at > draft-ietf-l3vpn-ppvpn-mcast-reqts-03, so here goes. > > >From the external point of view, what's the relation to > draft-ietf-l2vpn-vpls-mcast-reqts-xx? It'd seem to me that > it'd be HIGHLY desirable that at least the bulk of the > solutions used could be the same... Operators shouldn't need > to deploy two completely different solutions for both L2 and L3VPNs. > > > more or less substantial comments > --------------------------------- > > 5.1.2. CE-PE Multicast routing and management protocols > > When IPv6 is supported by a VPN solution, relevant IPv6 > corresponding > protocols MUST also be supported, e.g. Multicast > Listener Discovery > Protocol (MLD) (v1 [RFC2710]], v2 [RFC3810]]). > > ==> The IPv6 part requires wordsmithing. The IETF will *NOT* > allow specification of a standards track solution which does > not support IPv6. This text seems to imply that IPv6 support > could be optional. > > (you might also clarify which IGMP/MLD versions should be > supported and which not.) > > 5.1.3. Quality of Service (QoS) > > .... > > As multicast is often used to deliver high quality > services such as > TV broadcast, the solution should have additional > features to support > high QoS such as bandwidth reservation and admission control. > > ==> are these available for unicast? Seems like you're > asking more of a multicast solution than from unicast. I'd > remove these kind of "nice-to-have" reqs, or rephrase s/should/MAY/ > > > 5.1.11. RP Engineering > > When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer > side, the location of the RP has to be chosen. In some cases this > engineering problem is not trivial: for instance, if sources and > receivers are located in VPN sites that are different than that of > the RP, then traffic may flow twice through the SP network and the > CE-PE link of the RP (from source to RP, and then from RP to > receivers) ; this is obviously not ideal. A multicast > VPN solution > SHOULD propose a way to help on solving this RP engineering issue. > > ==> I'm not sure if this specific problem exists in practice. > If the RP sends Register-Stop, the multicast traffic is > forwarded natively, and the data will short-cut inside the > site without going to the RP and then back. I.e., there > should not be two times traffic once the forwarding is native. > > 5.1.13. Minimum MTU > > ... > > It SHOULD also be compatible with Path MTU discovery > mechanisms, such > as those defined in [RFC1191] or [I-D.mathis-frag-harmful]. > > ==> you may be interested in looking at > draft-savola-mtufrag-network-tunneling-05.txt which was just > recently approved for publication. Depending on the MDT > solution, this may have relevant discussion on MTU handling methods. > > For MDTunnels (multicast distribution tunnels, the means used to > carry VPNs' multicast traffic over the provider's network), a > solution SHOULD be able to use a range of tunneling technologies, > including point-to-point and point-to-multipoint, such as GRE > [RFC2784] (including GRE in multicast IP trees), MPLS [RFC3031] > (including P2P or MP2P tunnels, and multipoint tunnels > signaled with > MPLS P2MP extensions to RSVP [I-D.ietf-mpls-rsvp-te-p2mp] or LDP > [I-D.leroux-mpls-mp-ldp-reqs][I-D.minei-wijnands-mpls-ldp-p2mp]), > L2TP (including L2TP for multicast [RFC4045]), IPsec > [RFC2401], IP- > in-IP [RFC1853], etc. > > ==> you should probably also a) specify, or b) require that > the solution will specify one or two mandatory to implement > tunneling mechanisms, so that there would be ways how > MDTunnels between different vendors, operators, etc. could be > interoperable..? > > 5.2.10. Architectural Considerations > > As far as possible, the design of a solution should carefully > consider the number of protocols within the core network. If any > additional protocols are introduced compared with unicast VPN, the > balance between their advantage and operation burden should be > examined thoroughly. > > ==> these are not "Architectural Considerations", maybe > rather Operational Considerations, IMHO. Let's take an > example: ISP is unicast-only and solution A proposed using > standards-track multicast protocols to offer a service, and > solution B would imply reinventing multicast signalling > inside the unicast protocols. > > In my opinion, solution A is clear architecturally a best > solution. The above paragraph makes this sound like B would > be favorable from the > *architectural* point-of-view. Perhaps this section needs to > be generalized to bring out the different tradeoffs better, > for example: > - the benefits of using existing multicast technologies > - the drawbacks of deploying the existing multicast technologies > - the benefits of shorning multicast protocols into > commonly deployed unicast > protocols > - the drawbacks of reinventing the wheel > - etc. > > editorial > --------- > > ==> you should add a dummy IANA considerations section > > Service management should also include the TMN 'FCAPS' > functionalities, as follows: Fault, Configuration, Accounting, > Provisioning, and Security. > > ==> 'P' stands for Performance, I think. > > Resiliency is also crucial to infrastructure security, thus a > multicast VPN solution SHOULD whether avoid single points > of failures > or propose some technical solution making possible to implement a > fail-over mechanism. > > ==> s/whether/either/ > > All or part of this information SHOULD be made available through > standardized SNMP ([RFC1157]) MIBs (Management Information Base). > > ==> 1157 is no longer standardized, as it has been made > Historic. Refer to the later SNMPv2/SNMPv3 RFCs? > > [RFC1853] Simpson, W., "IP in IP Tunneling", RFC 1853, > October 1995. > > ==> you should probably use RFC2003 instead, as RFC1853 just > informational while 2003 is standards track. > > > [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, > RFC 3978, March 2005. > > [RFC2026] Bradner, S., "The Internet Standards Process > -- Revision > 3", BCP 9, RFC 2026, October 1996. > > [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, > June 1999. > > ==> these are not referred to in the body of the draft (when > the document gets published by the RFC editor), so they can > be removed. > (not sure if there are more of these) > > 8.2. Informative references > > [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, > March 1999. > > [I-D.ietf-l3vpn-rfc2547bis] > Rosen, E., "BGP/MPLS IP VPNs", > draft-ietf-l3vpn-rfc2547bis-03 (work in progress), > October 2004. > > [I-D.ietf-l3vpn-vpn-vr] > Knight, P., Ould-Brahim, H., and B. Gleeson, "Network > based IP VPN Architecture using Virtual Routers", > draft-ietf-l3vpn-vpn-vr-02 (work in progress), > April 2004. > > ==> these and many more are referred to in so many places of > the drafts in a very normative way, and should really be > under the normative references. > Some others as well -- please consider each with the > following question in > mind: > > - is reading this reference required to understand this document? > (rather than providing some optional additional information) > - if the reference changed radically before publication, would this > document need to be reflected as well? > > If either of these is a "yes", then the reference should > likely be normative. > > .... > > Appendix A. Requirements summary > > ==> I'd consider removing this, because these should be > extractable from the body of the document, and these could > get out of date easily if the editors are not really, really > careful. Recent xml2rfc includes support for some degree of > autogeneration of these using xref format=title (see RFC > 3871 appendix A for > example) > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > From l2vpn-bounces@ietf.org Mon Jan 16 10:10:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyW0W-0000kF-Aw; Mon, 16 Jan 2006 10:10:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyW0U-0000k7-RV for l2vpn@megatron.ietf.org; Mon, 16 Jan 2006 10:10:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19378 for ; Mon, 16 Jan 2006 10:09:31 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyW8O-0005ZL-IC for l2vpn@ietf.org; Mon, 16 Jan 2006 10:19:07 -0500 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 44348644B3 for ; Mon, 16 Jan 2006 08:10:18 -0700 (MST) Message-ID: <43CBB75E.4020102@castlepoint.net> Date: Mon, 16 Jan 2006 08:10:22 -0700 From: Shane Amante User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: WG Last Call Ended: draft-ietf-l2vpn-ipls-05.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Folks, This e-mail signals the end of WG Last Call for draft-ietf-l2vpn-ipls-05.txt. Himanshu, et. al need to satisfactorily address comments received by Stewart Bryant before the document can progress to the next stage. -shane & Vach From l2vpn-bounces@ietf.org Tue Jan 17 15:52:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxoR-0002Lf-Nx; Tue, 17 Jan 2006 15:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxoQ-0002LF-Io for l2vpn@megatron.ietf.org; Tue, 17 Jan 2006 15:52:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16945 for ; Tue, 17 Jan 2006 15:50:50 -0500 (EST) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EyxwY-0006CD-HC for l2vpn@ietf.org; Tue, 17 Jan 2006 16:00:44 -0500 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jan 2006 15:52:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jan 2006 15:52:01 -0500 Message-ID: Thread-Topic: WG Last Call: draft-ietf-l2vpn-ipls-05.txt Thread-Index: AcYXdUTbqm8fs21aR4CcZymeHY98EAEMBxtA From: "Shah, Himanshu" To: "Stewart Bryant" , "Shane Amante" X-OriginalArrivalTime: 17 Jan 2006 20:52:00.0123 (UTC) FILETIME=[DC9A5CB0:01C61BA7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-05.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Stewart, Thanks for the review and comments. Response in line. /himanshu > -----Original Message----- > From: l2vpn-bounces@ietf.org=20 > [mailto:l2vpn-bounces@ietf.org]On Behalf Of > Stewart Bryant > Sent: Thursday, January 12, 2006 7:38 AM > To: Shane Amante > Cc: l2vpn@ietf.org > Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt >=20 >=20 > =20 > 3. Pseudowires for Multicast Traffic: In addition, every PE=20 > supporting a given IPLS instance will set up a special=20 > "broadcast pseudowire" to every other PE in that IPLS=20 > instance. >=20 > SB> Is there any intention to use PSN multicast techniques=20 > here (either > SB> now or in the future? HCS> In the future.=20 > =20 >=20 > =20 > 4. Signaling: The necessary pseudowires can be set up and=20 > maintained using the LDP-based signaling procedures described=20 > in [PWE3-CONTROL]. >=20 > SB> The only control protocol that gets referenced is PWE3-Control, > SB> but the draft (quite rightly) talks about L2TP as an alternate > SB> tunnel technology. I think that we need to be able to run this > SB> over any PSN type and use the PWs defined by both PWE3 and L2TPext > SB> WGs.=20 > =20 >=20 HCS> You seem to be recommending adding appropriate text and reference HCS> to L2TP based PW. Will do.=20 > =20 > 3.0 Topology=20 > =20 > The Customer Edge (CE) devices are IP nodes (hosts or=20 > routers) that=20 > are connected to PE devices either directly, or via an Ethernet=20 > network. We assume that the PE/CE connection may be=20 > regarded by the=20 > PE as an "interface" to which one or more CEs are attached. This=20 > interface may be a physical LAN interface or a VLAN. The Provider=20 > Edge (PE) routers are MPLS Label Edge Routers (LERs) that serve as=20 > pseudowire endpoints.=20 > =20 > =20 > =20 > PE1, PE2 and PE3 are shown as connected via an MPLS network;=20 > however, other tunneling technologies, such as GRE, L2TPv3, etc.,=20 > could also be used to carry the pseudowires. =20 >=20 > SB> This is where you talk about about L2TPv3 >=20 >=20 > =20 > 6.0 Pseudowire Creation=20 > =20 > 6.1 Receive Unicast Multipoint-to-point Pseudowire=20 > =20 > As the PE discovers each locally attached CE, a unicast multipoint- > to-point pseudowire (mp2p PW) associated exclusively with=20 > that CE is=20 > created by distributing the CE's IP address and MAC address along=20 > with a PW-Label to all the remote PE peers that participate in the=20 > same IPLS instance. Note that the same value of a PW-label=20 > SHOULD be=20 > distributed to all the remote PE peers for a given CE. The mp2p PW=20 > thus created is used by remote PEs to send unicast IP traffic to a=20 > specific CE. =20 > =20 > (The same functionality can be provided by a set of point-to-point=20 > PWs, and the PE is not required to send the same PW-label=20 > to all the =20 > other PEs. For convenience, however, we will use the term=20 > mp2p PWs,=20 > which may be implemented using a set of point-to-point PWs.)=20 >=20 > SB> Do we need to start work on mp PWs over in PWE3? > =20 > HCS> Yes. =20 > =20 > 11.0 IP Protocols=20 > =20 > The solution described in this document offers IPLS=20 > service for IPv4=20 > traffic only.=20 >=20 > SB> Why? HCS> We discussed this in one of the WG meetings. HCS> It was agreed that IPv6 support can be added as follow on. >=20 > For this reason, the MAC Header is not carried over=20 > the unicast pseudowire. It is reconstructed by the PE when=20 > receiving=20 > a packet from a unicast pseudowire and the Ethertype=20 > 0x0800 is used=20 > in the MAC Header since IPv4 is assumed.=20 > =20 > However, this solution may be extended to carry other types of=20 > important traffic such as ISIS and IPv6 which are not encapsulated=20 > in Ethernet with the use of Ethertype 0x0800. >=20 > SB> Surely these are needed day one? HCS> See above. As for IS-IS which uses 802.3 encap, there needs to be HCS> some mechanism such that egress PE can correctly encapsulate the HCS> Ethernet header. >=20 > In order to permit the=20 > propagation of such packets correctly, one may create a=20 > separate set=20 > of pseudowires >=20 > SB> That is a very bad idea! The IGPs assume that there is shared > SB> fate between data and routing. If yo do this you break one > SB> of the IGP design invariants. HCS> Agreed. It is only presented as one option albeit not a desirable HCS> one. >=20 > , or pass protocol information in the "control word"=20 >=20 > SB> sort of PW-ACH with 0000 in the first nibble? HCS> Yes. This would be a desirable option.=20 >=20 > of a "multiprotocol" pseudowire, or encapsulate the Ethernet MAC=20 > Header in the pseudowire. The selection of appropriate=20 > multiplexing/demultiplexing scheme is the subject of future study.=20 > The current document focuses on IPLS service for IPv4 traffic.=20 >=20 > SB> What is the IETF policy on standards that only support v4? > SB> Surely we really ought to support v6 on day one? HCS> See above. >=20 > [PWE3-IANA] L. Martini et al,. "IANA Allocations for pseudo Wire=20 > Edge to Edge Emulation (PWE3)", February 2005, work in progress.=20 >=20 > SB> This does not seem to be called up in the body of the draft HCS> Thanks for catching this. Will add it at the appropriate place HCS> in the draft. >=20 > Stewart > =20 >=20 >=20 From l2vpn-bounces@ietf.org Wed Jan 18 05:24:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzAU3-00018a-KH; Wed, 18 Jan 2006 05:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzATz-00018Q-Ss for l2vpn@megatron.ietf.org; Wed, 18 Jan 2006 05:24:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25658 for ; Wed, 18 Jan 2006 05:22:37 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzAcH-00030L-5s for l2vpn@ietf.org; Wed, 18 Jan 2006 05:32:39 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 18 Jan 2006 11:23:50 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0IANi5i010481; Wed, 18 Jan 2006 11:23:45 +0100 (MET) Received: from [10.61.64.72] (ams-clip-vpn-dhcp72.cisco.com [10.61.64.72]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA10554; Wed, 18 Jan 2006 10:23:41 GMT Message-ID: <43CE172D.8090108@cisco.com> Date: Wed, 18 Jan 2006 10:23:41 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shah, Himanshu" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, Shane Amante Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Himanshu I think that it would also be a good idea if you asked for a review by the RTGWG or the routing area directorate. I am concerned about breaking shared fate assumptions particularly with regard to the sending of multicast packets down one PW, and various types of unicast packets down other PWs. Now we can unify the the unicast packets and emulated muticast packets over a single PW using a CW and maybe that is what we have to do. However I am having concerns as to the consequence of moving on to the use of a MP PW - which would increase bandwidth efficiency but might have serious consequences for the client layer routing algorithm. - Stewart From l2vpn-bounces@ietf.org Wed Jan 18 17:25:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLkH-0004ss-Oo; Wed, 18 Jan 2006 17:25:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzLkF-0004s0-F0 for l2vpn@megatron.ietf.org; Wed, 18 Jan 2006 17:25:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16043 for ; Wed, 18 Jan 2006 17:24:08 -0500 (EST) Received: from lin1-118-39-26.ciena.com ([63.118.39.26] helo=mdmxm01.ciena.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzLse-0001s6-8a for l2vpn@ietf.org; Wed, 18 Jan 2006 17:34:17 -0500 Received: from mamxm01.ciena.com ([10.172.0.155]) by mdmxm01.ciena.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 17:25:20 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2006 17:25:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: WG Last Call: draft-ietf-l2vpn-ipls-05.txt Thread-Index: AcYcGUr938Vt4GjMQhuTYzNHD9tx5gAYQ1Fg From: "Shah, Himanshu" To: "Stewart Bryant" X-OriginalArrivalTime: 18 Jan 2006 22:25:20.0548 (UTC) FILETIME=[11212640:01C61C7E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: l2vpn@ietf.org, Shane Amante Subject: RE: WG Last Call: draft-ietf-l2vpn-ipls-05.txt X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Some response in line..=20 -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com]=20 Sent: Wednesday, January 18, 2006 5:24 AM To: Shah, Himanshu Cc: Shane Amante; l2vpn@ietf.org Subject: Re: WG Last Call: draft-ietf-l2vpn-ipls-05.txt Himanshu I think that it would also be a good idea if you asked for a review by the RTGWG or the routing area directorate. HCS> I am guessing you are suggesting this as for your concern of lack of support HCS> for Ipv6 at the get-go? The WG is committed to support v6 as follow on and HCS> did not feel that draft be held off for that. It seems that is an acceptable HCS> conclusion.=20 I am concerned about breaking shared fate assumptions particularly with regard to the sending of multicast packets down one PW, and various types of unicast packets down other PWs. Now we can unify the the unicast packets and emulated muticast packets over a single PW using a CW and maybe that is what we have to do. However I am having concerns as to the consequence of moving on to the use of a MP PW - which would increase bandwidth efficiency but might have serious consequences for the client layer routing algorithm. HCS> "multicast" PW is the anchor and works in tandom with associated "unicast" PW for HCS> a given IPLS instance with a PE peer. They are tightly coupled wrt their operational HCS> status. The concept is similar (but not same) to how PW maintains bidirectionality=20 HCS> over two unidirectional transport LSPs. HCS> Not sure about your concern with MP PW. Are you referring to the use of mp2p PW, HCS> the way it is used in IPLS or p2mp LSP that is being designed in MPLS WG and how HCS> we make use of that for "multicast" PW? Regards, himanshu - Stewart From l2vpn-bounces@ietf.org Thu Jan 19 09:54:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbB9-0007vD-2u; Thu, 19 Jan 2006 09:54:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbB7-0007u3-P4 for l2vpn@megatron.ietf.org; Thu, 19 Jan 2006 09:54:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28535 for ; Thu, 19 Jan 2006 09:52:54 -0500 (EST) Received: from cat.tcb.net ([64.78.150.134] helo=dog.tcb.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbJf-0001si-7l for l2vpn@ietf.org; Thu, 19 Jan 2006 10:03:12 -0500 Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by dog.tcb.net (Postfix) with ESMTP id 5375364392 for ; Thu, 19 Jan 2006 07:53:51 -0700 (MST) Message-ID: <43CFA803.4020109@castlepoint.net> Date: Thu, 19 Jan 2006 07:53:55 -0700 From: Shane Amante User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: IETF 65: l2vpn WG Agenda X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Hi Folks, In preparation for IETF 65, please forward to Vach & I any l2vpn WG items that you would like to discuss. Thanks, -shane & Vach From l2vpn-bounces@ietf.org Fri Jan 20 11:11:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyrD-00038C-OQ; Fri, 20 Jan 2006 11:11:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzyrC-00037w-Vj for l2vpn@megatron.ietf.org; Fri, 20 Jan 2006 11:11:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26061 for ; Fri, 20 Jan 2006 11:09:55 -0500 (EST) Received: from mail.greenfieldnetworks.com ([64.220.152.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezyzx-0001Qf-4V for l2vpn@ietf.org; Fri, 20 Jan 2006 11:20:26 -0500 Received: from [127.0.0.1] ([10.20.20.107]) by mail.greenfieldnetworks.com (8.13.1/8.13.1) with ESMTP id k0KGB7Rr011313; Fri, 20 Jan 2006 08:11:10 -0800 Message-ID: <43D10BA3.2070203@greenfieldnetworks.com> Date: Fri, 20 Jan 2006 21:41:15 +0530 From: Ravindra Rathi User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ali Sajassi (sajassi)" References: <75B2A84D9323BC4CA3977CF378CE75EB01015F3C@xmb-sjc-21e.amer.cisco.com> In-Reply-To: <75B2A84D9323BC4CA3977CF378CE75EB01015F3C@xmb-sjc-21e.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org Subject: Re: Question on RSTP/MSTP between CE and PE X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: l2vpn-bounces@ietf.org Errors-To: l2vpn-bounces@ietf.org Ali, Thanks for replying. I took a look at both the clauses of 802.1ad spec. But I am still not able to understand clearly. Spec just says when you need to run MSTP between the CE and PE and it doesn't really explain why (as in why looping can happen if MSTP is not run between CE and PE). It will be really nice if you can answer my questions with following example topology. 1. Why no need to run MSTP/RSTP if AC is port based..? Actually, that I can understand since PEs are acting as a hub with respect to BPDUs and hence looping can't happen. 2. Why MSTP/RSTP needs to be run if AC is vlan based to avoid looping..? +------+ +------+ +------+ +------+ | CE |-----| PE |----........---| PE |------| CE | |dev 1 | |dev A | |dev B | | dev 3| +------+ / +------+ +------+ +------+ | / Back | / door | / link | / +------+ | CE | |dev 2 | +------+ Thanks, Rathi Ali Sajassi (sajassi) wrote: > The short answer is to take a look at clauses 15 and 13 of 802.1ad > (rev.D6). > > -Ali > > >>-----Original Message----- >>From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] >>On Behalf Of Ravindra Rathi >>Sent: Wednesday, January 11, 2006 3:28 AM >>To: l2vpn@ietf.org >>Subject: Question on RSTP/MSTP between CE and PE >> >>This is regarding following text in >>draft-sajassi-l2vpn-vpls-bridge-interop-01.txt. >> >> >>For example, when an Attachment Circuit is port-based, then >>the bridge module of the PE can operate transparently with >>respect to the CEs RSTP/MSTP protocols (and thus no C-VLAN >>component is required for that customer UNI). However, when >>an Attachment Circuit is VLAN-based (either VLAN mapping or >>VLAN bundling), then the bridge module of the PE needs to >>peer with the RSTP/MSTP protocols running on the CE (and thus >>the C-VLAN bridge component is required). >> >> >>Can anyone explain clearly why PE need not participate in >>CE's RSTP/MSTP protocols if attachment circuit(AC) is port >>based and why it should participate if AC is vlan based..? >> >>Thanks, >>Rathi >>