Subject: RE: Questions/suggestions regarding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka)

From: "Paz Pentelka" <[email-masked]>
Date: Wed, 29 Jun 2011 17:52:15 +0300

Hi,

Thanks Ran for your response.

Please see below my comments

Paz.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, June 29, 2011 11:55 AM
To: [email-masked]
Subject: Re: Questions/suggestions regarding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka)

Hi all， 

Please see the comments inline below. 

Regards, 

Ran

[email-masked] 
Sent by: [email-masked] 

2011-06-29 03:00 

Please respond to
[email-masked]

To

[email-masked] 

cc

Subject

L2vpn Digest, Vol 85, Issue 14

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

Message: 1
Date: Mon, 27 Jun 2011 22:00:16 +0300
From: "Paz Pentelka" <[email-masked]>
To: <[email-masked]>
Subject: Questions/suggestions regarding
                "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt"
Message-ID: <44F4E579A764584EA9BDFD07D0CA081306D5FDF9@tlvmail1>
Content-Type: text/plain; charset="us-ascii"

Dear Authors,

Following review of "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt
<http://potaroo.net/ietf/idref/draft-ietf-l2vpn-vpls-ldp-mac-opt/rfcmark
up?repository=/away/ietf&url=/away/ietf/all-ids/draft-ietf-l2vpn-vpls-ld
p-mac-opt-04.txt <http://potaroo.net/ietf/idref/draft-ietf-l2vpn-vpls-ldp-mac-opt/rfcmark%0bup?repository=/away/ietf&url=/away/ietf/all-ids/draft-ietf-l2vpn-vpls-ld%0bp-mac-opt-04.txt> > " I have a couple of questions/suggestions - 

1 - According to 4.1.2

Note that if a MAC Flush TLV is not understood by a receiver then it 

may result in undesired action. For example if a MAC Flush Parameters 

TLV is received with N=1 and receiver does not understand that TLV 

then it would result in flushing of all MACs learned in the VSI 

except the ones learned over the PW. The MAC Flush TLV SHOULD be 

placed after the existing TLVs in MAC Flush message in [RFC4762
<http://potaroo.net/ietf/idref/draft-ietf-l2vpn-vpls-ldp-mac-opt/#ref-RF
C4762 <http://potaroo.net/ietf/idref/draft-ietf-l2vpn-vpls-ldp-mac-opt/#ref-RFC4762> > ].   

I would like to propose a solution to avoid the undesired flushing at
PEs implementing [RFC4762] that are not supporting the new optimization
- if PE-1 (according to the diagram below) can send MAC Flush Parameters
TLV but doesn't send MAC Address TLV, there will not be incorrect
flushing.

[Ran]I think we should carry the MAC address TLV in the MAC Flush Paremeters. 
Actually draft-ietf-l2vpn-vpls-ldp-mac-opt-04 states:The MAC Flush TLV SHOULD be
placed after the existing TLVs in MAC Flush message in [RFC4762 <http://tools.ietf.org/html/rfc4762> ].
Maybe we can use a LDP capability mechnism to slove this probrem. 

[Paz] That appears to be a good solution too. Are you planning to add this support in the next revision? 

2- In a case where the primary spoke PW is down (according to the
diagram below), there can be a case in which there are many other PWs
connected between the 2 PEs that are down (due to physical link down for
instance). In this case, is there a way to send MAC flush for different
PW's/VPLS's with a single LDP MAC message (for better messaging
scalability)? Such option can be defined using sub-TLVs, for example.
[Ran]  IMO, in this case, it can be achived by carring muti-FEC tlv in the MAC flush message.

[Paz] Currently in RFC 4762 there seems to be no support for multiple FEC TLVs in the same MAC address withdrawal message, as follows:

“The MAC Address Withdraw Message contains a FEC TLV (to identify the

   VPLS affected), a MAC Address TLV, and optional parameters.“

I would like to suggest instead using PW grouping capabilities, already defined in RFC 4447, to signal MAC address withdrawal on multiple 

PWs using a single FEC TLV. This has the additional advantage of being more scalable. What do you think?

---

From: [email-masked]
Date: Thu, 30 Jun 2011 12:42:48 +0800

Hi Paz and all,
Please see below.

Regards,
Ran

"Paz Pentelka" <[email-masked]> 
发件人:  [email-masked]
2011-06-29 22:52

收件人
<[email-masked]>
抄送

主题
RE: Questions/suggestions 
regarding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka)

Hi,

 
Paz.

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Wednesday, June 29, 2011 11:55 AM
To: [email-masked]
Subject: Re: Questions/suggestions re 
garding"draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt" (Paz Pentelka)
 
Hi all， 

[email-masked] 

Please respond to
[email-masked]

To
[email-masked] 
cc

Subject

Message: 1

Dear Authors,

Following review of "draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt
<http://potaroo.net/ietf/idref/draft-ietf-l2vpn-vpls-ldp-mac-opt/rfcmark
up?repository=/away/ietf&url=/away/ietf/all-ids/draft-ietf-l2vpn-vpls-ld
p-mac-opt-04.txt> " I have a couple of questions/suggestions - 

1 - According to 4.1.2

C4762> ].   

I would like to propose a solution to avoid the undesired flushing at
PEs implementing [RFC4762] that are not supporting the new optimization
- if PE-1 (according to the diagram below) can send MAC Flush Parameters
TLV bu t doesn't send MAC Address TLV, there will not be incorrect
flushing.

[Ran]I think we should carry the MAC address TLV in the MAC Flush 
Paremeters. 
Actually draft-ietf-l2vpn-vpls-ldp-mac-opt-04 states:The MAC Flush TLV 
SHOULD be
placed after the existing TLVs in MAC Flush message in [RFC4762].
Maybe we can use a LDP capability mechnism to slove this probrem. 
[Paz] That appears to be a good solution too. Are you planning to add this 
support in the next revision? 
 [Ran]I am sorry，I am not the author，I just give some coments.  ：）

[Ran]  IMO, in this case, it can be achived by carring muti-FEC tlv in the 
MAC flush message.

[Paz] Currently in RFC 4762 there seems to be no support for multiple FEC 
TLVs in the same MAC address withdrawal message, as follows:
 
“The MAC Address Withdraw Message contains a FEC TLV (to identify the
   VPLS affected), a MAC Address TLV, and optional parameters.“
 [Ran]Yes ，I mean that maybe we can do some extensions.

I would like to suggest instead using PW grouping capabilities, already 
defined in RFC 4447, to signal MAC address withdrawal on multiple 
PWs using a single FEC TLV. This has the additional advantage of being 
more scalable. What do you think?

 [Ran]Currently, in RFC4762, I do not think the Grouping ID field/PW 
Grouping ID TLV  is carried in MAC withdraw message.
 If the PW grouping capabilities are used , How to divide the group?