Subject: Fwd: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 1 Apr 2014 15:07:22 +0100

Colleagues,

I am resending my Routing Directorate review below as I messed up the e-mail address for the draft's authors.

Ben

Begin forwarded message:

> From: Ben Niven-Jenkins <[email-masked]>
> Date: 1 April 2014 15:02:25 GMT+01:00
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html
> 
> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
> 
> Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
> Reviewer: Ben Niven-Jenkins
> Review Date: 1st April 2014
> IETF LC End Date: 8th April 2014
> Intended Status: Standards Track
> 
> Summary:
> I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.
> 
> Comments:
> Overall the document is reasonably well written, although many cross-references to different sections in the draft appear to be wrong. Where I've noticed incorrect cross-references I have noted them in the nits section below but I would recommend someone doing a complete pass of the document to ensure all cross-references refer to the correct section(s).
> 
> From reading the document my opinion is that it suitably describes what is required to implement the newly proposed mechanism but it may be hard for someone to read the document and determine what circumstances would motivate using the new optimised MAC flush versus sticking with the original RFC4627 MAC flush mechanism. 
> 
> 
> Major issues:
> 
> I've raised this as a major issue as I think it may require AD input/attention to resolve. It is not a technical issue but a suggestion for including more explanatory text that I think would help improve the document but which the AD may decide is not required.
> 
> The document specifies a solution to solve a problem with the mechanism for MAC address withdrawal specified in RFC4762 but it doesn't provide any indication of when the new optimised MAC flush that is proposed should be used instead of the existing MAC flush mechanism specified in RFC4627.
> 
> The downside of the existing RFC4627 MAC flush mechanism appears to be that PEs can end up having to flush many more MAC addresses than absolutely required when a dual homed CE/MTU switches from using the primary spoke PW to the backup spoke PW.
> 
> The optimised MAC flush specified in the document solves the problem by moving the initiation of the MAC flush message from the 'backup' PE-rs to the 'primary' PE-rs and introducing a new message to allow the primary PE-rs to request other PE-rs in the network flush all MAC addresses learnt via the primary PE-rs.
> 
> While the new message means that the PE-rs in the network will flush and relearn fewer MAC addresses on failure of the primary spoke PW between the MTU-s & primary PE-rs, it is not clear to me whether it is superior in all cases.
> 
> For example, the new optimised MAC flush relies on the primary PE-rs to detect the failure of the spoke PW and initiate the optimised MAC flush but the document doesn't discuss what happens if the failure isn't detected (e.g. if PE-rs doesn't detect the failure or PE-rs itself fails). My assumption is that the network falls back to relying on aging/timeout of MAC entries, which presumably means that traffic is blackholed for up to 5 minutes (using default timers).
> 
> It is also not clear whether this mechanism is designed to replace the mechanism in RFC4627 or to augment it, although I have assumed the former.
> 
> I therefore think that the document would benefit significantly from:
> 
> a) Some clear text/statement of when the new optimised MAC flush mechanism should be used instead of the existing RFC4627 mechanism (e.g. when is a full RFC4627 MAC flush "bad").
> 
> b) Some discussion describing how the new optimised MAC flush mechanism is equivalent to the existing mechanism and highlighting any cases where it may not provide as rapid MAC table updates as the RFC4627 mechanisms.
> 
> 
> Minor issues:
> 
> 1) The first paragraph of section 3 states:
> 
>   When the MTU-s switches over to the backup PW, the requirement is to
>   flush the MAC addresses learned in the corresponding Virtual Switch
>   Instance (VSI) in peer PE devices participating in the full mesh, to
>   avoid black holing of frames to those addresses.  This is
>   accomplished by sending an LDP Address Withdraw Message from the PE
>   that is no longer connected to the MTU-s with the primary PW, with
>   the list of MAC addresses to be removed to all other PEs over the
>   corresponding LDP sessions [RFC4762].
> 
> Comparing this against Figure 1, my understanding is that the "PE that is no longer connected to the MTU-s with the primary PW" is PE1-rs. However section 3.1.1 states:
> 
>   [RFC4762] specifies that on failure of the primary PW, it is the
>   PE3-rs (Figure 1) that initiates MAC flush towards the core.
> 
> Which contradicts the first paragraph of section 3?
> 
> I think that the first paragraph of section 3 is describing the behaviour when using the new mechanism described in the draft, but that wasn't clear to me when I first read the draft, so I would suggest re-wording or adding some text to make it more explicit when you are describing new behaviour specified in the document versus existing behaviour inherited from RFC4762.
> 
> 2) Section 3.2. I'm not sure what the significance of the native ethernet segment is in this sentence "For example, the case of PE1-rs initiated MAC flush on failure may arise when the dual-homing segment is native ethernet as opposed to spoke PWs.". You may want to consider stating what issue it is that the presence of native ethernet causes.
> 
> 3) Section 3.2 goes on to say "In this case the PE-rs devices
>   that receive the MAC flush from PE1-rs are required to flush all the
>   MAC addresses learned over the PW connected to PE1-rs.  This cannot
>   be achieved with the MAC Address Withdraw Message defined in
>   [RFC4762]."
> 
> You may want to consider stating why MAC flush cannot be achieved with the MAC Address Withdraw Message defined in RFC4762 (as the lack of ability for performing MAC flush in this scenario is presumably the motivation for defining the new MAC flush on failure mechanism in the document?).
> 
> 4) Section 5.1.2 states
> 
>   The MAC withdraw procedures defined in [RFC4762], MTU-s or PE2-rs
>   SHOULD be sent in cases where the network is being upgraded and
>   devices are not capable of understanding the optimized MAC flush.
>   This would result in the same flushing action as [RFC4762] at the
>   receiving PE-rs devices.
> 
> Which I am struggling to parse. Do you mean something along these lines?
> 
>   The MAC withdraw procedures defined in [RFC4762], where either
>   MTU-s or PE2-rs send the MAC Withdrawl message SHOULD be used
>   in cases where the network is being upgraded and devices are not
>   capable of understanding the optimized MAC flush.
>   This would result in the same flushing action as [RFC4762] at the
>   receiving PE-rs devices.
> 
> 5) Section 5.1.2 states
> 
>   For the case of B-VPLS devices optimized MAC flush message SHOULD be
>   supported.
> 
> It's not clear to me what the purpose of this sentence is or what it adds to the document.
> 
> 6) Section 5.1.4 states
> 
>   This section explains the optimized MAC flush procedure in the
>   scenario in Figure 2.  When the primary spoke PW transition (failure
>   or standby transition) is detected by PE1-rs, it MAY send MAC flush
>   messages to PE2-rs, PE3-rs and PE4-rs with MAC Flush TLV and N = 1.
> 
> Use of MAY here seems a bit strange to me. I may have misunderstood but it seems to me that the document is proposing replacing the existing MAC withdraw mechanisms with this new mechanism, but when using this new mechanism sending the optimised MAC flush is only a MAY, so what happens when PE1-rs doesn't send the optimised MAC flush? I assume the fallback is aging/timeout of MAC entries, or is it that the previous MAC withdraw mechanism is also being used?
> 
> You may want to consider re-phrasing it along the lines of "When optimised MAC flush is being used then <this is the expected behaviour of PEs/etc>"
> 
> 
> nits:
> 1) Section 4 states:
>   This section describes the problems in detail with respective to
>   various MAC flush actions described in section 2.
> 
> Section 2 is the terminology section and doesn't describe any MAC flush actions, do you mean to reference section 3?
> 
> Also I'm not exactly sure what a MAC flush action is. I think you may mean:
> 
>   This section describes the problems in detail with respect to the
>   various MAC flush scenarios described in section 3.
> 
> And I think you mean to use 'respect' rather than 'respective'.
> 
> 2) Section 4.1.1, penultimate paragraph says "In the example above, only the MAC addresses in set X and Y need to be flushed across the core." Y is not used in the text which confused me for a while until I realised you were referring to Figure 2. You may want to consider making that more explicit, for example:
> 
>   In the example above, only the MAC addresses in set X and Y
>   (shown in Figure 2) need to be flushed across the core.
> 
> 3) Section 4.1.2 starts
> 
>   The analysis in section 3.1.1 applies also to the native Ethernet
>   access into a VPLS.
> 
> I think you may mean to reference section 4.1.1, not 3.1.1?
> 
> 4) Section 5 states
> 
>   This section describes the solution for the requirements described in
>   section 4.
> 
> Section 4 doesn't seem to list any requirements as such. Maybe consider rewording to something like:
> 
>   This section describes a solution for the problem space described in
>   section 4.
> 
> 5) Section 5.1 states
> 
>   The optimization is achieved by
>   initiating MAC Flush on failure as described in section 2.2.
> 
> and
> 
>   The MAC Flush TLV can also
>   be used for [RFC4762] style of MAC Flush as explained in section 2.
> 
> I think you mean section 3.2 and section 3 respectively.
> 
> 6) Section 5.1.1 & 5.1.2 cross-reference section 4.2 for details of its usage in PBB-VPLS but I think you mean to cross-reference section 5.2.
> 
> 7) Section 5.1.2, 5.1.3 & 5.2.2 cross-references section 5 for operational considerations but I think you mean to cross-reference section 6.
> 
> Regards
> Ben
>

---

From: "Fedyk, Don" <[email-masked]>
Date: Mon, 7 Apr 2014 13:04:09 +0000

Hi Ben

Thanks for your review.  Attached are the changes so far. Inline [Don] are my comments.

You raise a couple of points that Adrian/Nabil/Giles, other authors should review before I change anything else.

Don

-----Original Message-----
From: L2vpn [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Tuesday, April 01, 2014 10:07 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Fwd: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt

Colleagues,

Ben

> Overall the document is reasonably well written, although many cross-references to different sections in the draft appear to be wrong. Where I've noticed incorrect cross-references I have noted the…
[Don] Updated cross refs to section3.1.1 should be 4.1.1,  section 2 should be section 3 (refers to paragraph 3) Operation considerations is section  6 .
>
> From reading the document my opinion is that it suitably describes what is required to implement the newly proposed mechanism but it may be hard for someone to read the document and determine what circumstances would motivate using the new optimised MAC flush versus sticking with the original RFC4627 [don] 4762 MAC flush mechanism.

[Don] It is mentioned in section 3 overview that a simplified LDP MAC message while it speeds up LDP can adversely affect the native Ethernet forwarding which reverts to flooding of unknown addresses. This is important in real time Etehrnet networks.

> The document specifies a solution to solve a problem with the mechanism for MAC address withdrawal specified in RFC4762 but it doesn't provide any indication of when the new optimised MAC flush tha…

[Don] One of the debates we had was that for backwards compatibly the worst you get is the RFC4762 behavior.  But if all nodes are updated you can use the new message and get the optimized MAC flush.  However during the course of the draft a more explicit means of specifying the behavior was proposed to signal compatibility that became its own draft.  In order to resolve the MAC flush issues, without dependency on a capabilities draft,  this draft specifies  backwards compatibly by requiring the node that supports the optimized  MAC flush can also support the old MAC flush.
> The downside of the existing RFC4627 MAC flush mechanism appears to be that PEs can end up having to flush many more MAC addresses than absolutely required when a dual homed CE/MTU switches from us…

[Don] Flushing more MACs causes issues with the side effect of traffic that should not be affected being affected by a change.  In order to decouple this effect, the optimization reduces unintentional disruption.
> While the new message means that the PE-rs in the network will flush and relearn fewer MAC addresses on failure of the primary spoke PW between the MTU-s & primary PE-rs, it is not clear to me whet…

[Don] It does solve cases where dual homing aware PE-rs connect to resilient Ethernet networks. This is a case worth solving because those type of network usually have strict SLAs.   The other cases where other dual homing is outside of the of the PE-rs was covered for completeness.

> For example, the new optimised MAC flush relies on the primary PE-rs to detect the failure of the spoke PW and initiate the optimised MAC flush but the document doesn't discuss what happens if the…
[Don] Yes as mentioned this is not the case this was designed for but was described for completeness.
> It is also not clear whether this mechanism is designed to replace the mechanism in RFC4627 or to augment it, although I have assumed the former.
[Don] In a case where all nodes supported the optimized flush RFC4627 would be used but for backwards compatibility the mechanism in RFC4627 is recommended to be retained.
> a) Some clear text/statement of when the new optimised MAC flush mechanism should be used instead of the existing RFC4627 mechanism (e.g. when is a full RFC4627 MAC flush "bad").
[Don] OK I'll ask Adrian if he would like this highlighted.
> b) Some discussion describing how the new optimised MAC flush mechanism is equivalent to the existing mechanism and highlighting any cases where it may not provide as rapid MAC table updates as the…
[Don] I  don't think we should get into operational specifics of timing. I know for a fact that the mechanism has been deployed in dual homing aware networks with tight SLAs.  Flushing traffic that is unaffected is clearly undesirable. It really depends on the network scenario where you are flushing MACs. PBB networks can have 1000s of affected flows.
> Which contradicts the first paragraph of section 3?
[Don] I see your point here, is what is being described.
1) PE-rs dual homing Aware
- Control of dual homing by the PE-RS <- This is 3.1.1
- Control of dual homing by the MTUs <-This is 3.
2) PE-Rs dual homing unaware.

[Don] It is up to you Ads & WG chairs to say if this should be highlighted,  I think it covers the cases and I can try make it clearer as above if that helps.
>
> I think that the first paragraph of section 3 is describing the behaviour when using the new mechanism described in the draft, but that wasn't clear to me when I first read the draft, so I would suggest re-wording or adding some text to make it more explicit when you are describing new behaviour specified in the document versus existing behavior inherited from RFC4762.
[Don] The first part of section 3 is describing an existing RFC 4762 message a positive flush by a MTU-s that is dual homing and in control of the dual homing.  However it is true that a MTU-s using LDP could use the new procedures to propagate a flush to the PE-RS in the case of some downstream Dual homing and that is not excluded.
> 2) Section 3.2. I'm not sure what the significance of the native ethernet segment is in this sentence "For example, the case of PE1-rs initiated MAC flush on failure may arise when the dual-homing…
[Don]  If the connection is MPLS then there are LDP control messages that can propagate MAC status messages and if it is native Ethernet then the PE-RS has to interpret the messages and convert them to the LDP messages.  I think that is all native Ethernet is trying to say but there are multiple ways Ethernet can do that RSTP, G.8031 etc.
> You may want to consider stating why MAC flush cannot be achieved with the MAC Address Withdraw Message defined in RFC4762 (as the lack of ability for performing MAC flush in this scenario is presu…
[Don] Reasons from the document are :
Many implementations use an LDP withdraw message with an empty MAC list. (My interpretation is this is just the way it is.)
Section 3.2 states the rational for the MAC flush on failure. That cannot be achieved with the RFC4762 message and procedures.
>   This would result in the same flushing action as [RFC4762] at the
[Don] Your text is better.  This is the recommendation for backward compatibility since there is no capabilities exchange.
> It's not clear to me what the purpose of this sentence is or what it adds to the document.
[Don] It is historical. RFC 4762 VPLS preceded the deployment of PBB B-VPLS.   But B-VPLS was developed the same time as this draft and the procures help in deployments where there are lots of I-SIDs .  So the recommendation is to use the optimization for PBB deployments.

> Use of MAY here seems a bit strange to me. I may have misunderstood but it seems to me that the document is proposing replacing the existing MAC withdraw mechanisms with this new mechanism, but whe…

[Don] How about:
When Optimized MAC flush is being used a PE-rs that is dual homing aware SHOULD send MAC address messages with MAC Flush TLV and N=1 provided the other PEs understand the new messages.
>   various MAC flush actions described in section 2.

[Don] Yes s/2/3/
>   (shown in Figure 2) need to be flushed across the core.
[Don] Sure.
> I think you may mean to reference section 4.1.1, not 3.1.1?
[Don] I believe you are correct is accurate.  Section 3 and section 4 are roughly parallel a holdover from before I took over editing.
>   This section describes a solution for the problem space described in
[Don] I like your suggestion.
> I think you mean section 3.2 and section 3 respectively.
[Don] Yes I think we switched section 3 and section 2 and forgot the reference.  No smart tags just me.
> 6) Section 5.1.1 & 5.1.2 cross-reference section 4.2 for details of its usage in PBB-VPLS but I think you mean to cross-reference section 5.2.
[Don] Changed 4.2 is not completely wrong but 5.2 gives more usage notes.   I'm tempted to reference both but I've change to 5.2.
> 7) Section 5.1.2, 5.1.3 & 5.2.2 cross-references section 5 for operational considerations but I think you mean to cross-reference section 6.
[Don] Yes.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 8 Apr 2014 09:16:40 +0100

Hi Don,

Some follow-ups inline below

On 7 Apr 2014, at 14:04, Fedyk, Don <[email-masked]> wrote:

>> From: Ben Niven-Jenkins <[email-masked]>From reading the document my opinion is that it suitably describes what is required to implement the newly proposed mechanism but it may be hard for someone to read the document and determine what circumstances would motivate using the new optimised MAC flush versus sticking with the original RFC4627 [don] 4762 MAC flush mechanism.
> 

I saw that in section 3. I can see that you have a new mechanism that solves a problem with an existing mechanism.

My comment above is my observation that the way the document is written seems to me to assume that the reader is already familiar with the proposed optimised MAC flush and any implications it might have and has already decided to use/implement it and is reading the RFC to figure out what code to write to implement it.

The ADs may decide that is fine.

> [Don] One of the debates we had was that for backwards compatibly the worst you get is the RFC4762 behaviour.

>  But if all nodes are updated you can use the new message and get the optimized MAC flush.  However during the course of the draft a more explicit means of specifying the behavior was proposed to signal compatibility that became its own draft.  In order to resolve the MAC flush issues, without dependency on a capabilities draft,  this draft specifies  backwards compatibly by requiring the node that supports the optimized  MAC flush can also support the old MAC flush.

See my comment above. I think the same applies here.

> [Don] Flushing more MACs causes issues with the side effect of traffic that should not be affected being affected by a change.  In order to decouple this effect, the optimization reduces unintentio…

It would IMO be useful if the document stated this sort of thing somewhere. I’m not thinking about specific numbers or anything but some information along these lines that highlights what are the issues & impacts caused by RFC4627 under what circumstances and how the new optimised MAC flush avoids them would be valuable information for a reader to determine if they are likely to face the problems optimised MAC flush addresses and therefore whether optimised MAC flush is something they should consider using/implementing.

> [Don] It does solve cases where dual homing aware PE-rs connect to resilient Ethernet networks. This is a case worth solving because those type of network usually have strict SLAs.   The other case…

I think my sloppy use of “in all cases” may have caused confusion.

If instead I said "it is not clear to me whether optimised MAC flush is superior in all failure scenarios”, does that help clarify?

> [Don] Yes as mentioned this is not the case this was designed for but was described for completeness.

I’m not quite sure what you mean here (specifically what you mean by “case”).

Let me try and expand on my concern.

With RFC4762, failure of the primary spoke PW causes the MTU-s to switch traffic to the backup spoke PW, which results in packets being no longer being forwarded to PE1-rs and instead being forwarded to PE3-rs (using the labelling from Figure 1 of the document).

On seeing packets suddenly arriving, PE3-rs can tell it is now the primary PE-rs, and can initiate a MAC flush message to all other PE-rs.

This doesn’t rely on anything external, PE3-rs can determine just by the appearance of packets on the PW that it is now the primary PE-rs for that traffic. There’s very little further to go wrong, except for the possibility that PE3-rs does not initiate the MAC flush for some reason and then the fallback is to ageing/timeout of MACs.

With the optimised MAC flush, in order for the optimised MAC flush to work, it relies on PE1-rs detecting the failure somehow and initiating the optimised MAC flush. The optimised MAC flush isn’t triggered by PE3-rs suddenly seeing traffic anymore. Now if PE1-rs does’t trigger the optimised MAC flush for whatever reason (it didn’t detect the PW failed, PE1-rs itself fell over, etc) the fallback is to ageing/timeout of MACs.

Therefore my conclusion is that with RFC4762 the chance of having to fallback to ageing MACs is pretty remote (basically just when there is a badly borked implementation on PE3-rs).

With optimised MAC flush there are several scenarios which could result in PE1-rs not initiating the optimised MAC flush message for some reason and so the network has to rely on ageing MACs in those cases.

I think it’s worth saying something about this. 

> [Don] I  don't think we should get into operational specifics of timing. I know for a fact that the mechanism has been deployed in dual homing aware networks with tight SLAs.  Flushing traffic that…

I am not asking for operational specifics of timing. See above.

> [Don] It is historical. RFC 4762 VPLS preceded the deployment of PBB B-VPLS.   But B-VPLS was developed the same time as this draft and the procures help in deployments where there are lots of I-SI…

I’d suggest stating something like that then instead of the current sentence. The current SHOULD does’t contribute to interoperability of your mechanism, instead it is placing a requirement on devices to implement your mechanism. That requirement carries no weight in reality as it in unenforceable so I’d suggest not using the SHOULD and just stating what you want to say, e.g. something like: B-VPLS deployments with lots of I-SIDs can also benefit from using the optimised MAC flush mechanism specified in this document.

> When Optimized MAC flush is being used a PE-rs that is dual homing aware SHOULD send MAC address messages with MAC Flush TLV and N=1 provided the other PEs understand the new messages.

WFM.

Ben

> <draft-ietf-l2vpn-vpls-ldp-mac-opt-12.txt><Diff draft-ietf-l2vpn-vpls-ldp-mac-opt-11_txt - draft-ietf-l2vpn-vpls-ldp-mac-opt-12_txt.htm>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 10 Apr 2014 17:02:33 +0100

Hi Don,

[snip]

> > a) Some clear text/statement of when the new optimised MAC flush
> mechanism should be used instead of the existing RFC4627 mechanism (e.g.
> when is a full RFC4627 MAC flush "bad").

I think that would be valuable to include (and am embarrassed to have not picked
up on it myself). Essentially, you are introducing an option: new flush
mechanism or old flush mechanism. You should help implementers decide which to
use. Might be as simple as "always" or might be some other issues.

[snip]

> > Comparing this against Figure 1, my understanding is that the "PE that is no
> longer connected to the MTU-s with the primary PW" is PE1-rs. However section
> 3.1.1 states:
> >
> [Don] It is up to you Ads & WG chairs to say if this should be highlighted,  I
think it
> covers the cases and I can try make it clearer as above if that helps.

My general rule of thumb is that if a reasonably smart reader has questions
arising from the text, clarifying the text is worthwhile. Maybe that some
pointers as highlighted would cover the case.

[snip]

Thanks,
Adrian

---

From: "Fedyk, Don" <[email-masked]>
Date: Thu, 10 Apr 2014 16:23:32 +0000

Hi Ben 

Inline [Don] (no >)

I'll be providing an update based on your feedback and that of  Robert and Adrian.

Hopefully in short order,
Thanks
Don 

>From: Ben Niven-Jenkins [mailto:[email-masked]] 
>Hi Don,
>
>> [Don] It is mentioned in section 3 overview that a simplified LDP MAC message while it speeds up LDP can adversely affect the native Ethernet forwarding which reverts to flooding of unknown addresses. This is important in real time Ethernet networks.
>

[Don] OK. 
>It would IMO be useful if the document stated this sort of thing somewhere. I'm not thinking about specific numbers or anything but some information along these lines that highlights what are the issues & impacts caused by RFC4627 under what circumstances and how the new optimised MAC flush avoids them would be valuable information for a reader to determine if they are likely to face the problems optimised MAC flush addresses and therefore whether optimised MAC flush is something they should consider using/implementing.
>

[Don] OK I'll try to make this point.  
>I think my sloppy use of "in all cases" may have caused confusion.
>
>If instead I said "it is not clear to me whether optimised MAC flush is superior in all failure scenarios", does that help clarify?
>

[Don] I think the true statement is optimized MAC flush is superior in the case of Dual Homing Aware PE-rs  which is a common and important case.   As you point out there are possible error cases which fall back to less responsive behavior. 

>I'm not quite sure what you mean here (specifically what you mean by "case").
>

[Don]  Section 3.1.1 Points out the cases that PE3-rs is not being able to tell it is a new primary. I.e. PE3-rs  is not dual homing aware or PE3-rs  is not in control of the dual homing (eg BGP-MH). 
>
>This doesn't rely on anything external, PE3-rs can determine just by the appearance of packets on the PW that it is now the primary PE-rs for that traffic. There's very little further to go wrong, except for the possibility that PE3-rs does not initiate the MAC flush for some reason and then the fallback is to ageing/timeout of MACs.
>
>With the optimised MAC flush, in order for the optimised MAC flush to work, it relies on PE1-rs detecting the failure somehow and initiating the optimised MAC flush. The optimised MAC flush isn't triggered by PE3-rs suddenly seeing traffic anymore. Now if PE1-rs does't trigger the optimised MAC flush for whatever reason (it didn't detect the PW failed, PE1-rs itself fell over, etc) the fallback is to ageing/timeout of MACs.
>
[Don] Not just that as pointed out in section 3.1.1.
>With optimised MAC flush there are several scenarios which could result in PE1-rs not initiating the optimised MAC flush message for some reason and so the network has to rely on ageing MACs in thos…
[Don] So we have a case where optimized MAC flush is fast and efficient but if for some reason PE1-rs does not initiate the MAC flush there is some delay.  If PE1-rs fails then LDP will trigger MAC flush on other VPLS on other PE-rs. So we are down to Failure cases where PE1-rs does not notice the MTU-s went away or there is a software error on PE1-rs.  I believe the intent is that is a fairly rare case and as pointed out PE3-rs cannot do better.  If you had both mechanisms you would be initiating 2 flushes.  Also, PE3-rs must initiate a full VPLS flush (empty MAC list) because it does not know in the RFC4762 case how many MAC addresses or the specifics of the MAC addresses.   So the intent of the optimized MAC flush is to use the more targeted flush from PE1-rs. 
>
>I think it's worth saying something about this. 
>
[Don] I will attempt to address this.  

>I am not asking for operational specifics of timing. See above.
[Don] So if we say something about the corner case and point out when optimized MAC Flush operates it is fast and more efficient.  Also we make it clear that it augments RFC4762 by handling cases that were outside of RFC4762. 
Does that cover your points?  
>>> 3) Section 3.2 goes on to say "In this case the PE-rs devices  that 
>>> receive the MAC flush from PE1-rs are required to flush all the  MAC 
>>> addresses learned over the PW connected to PE1-rs.  This cannot  be 
>>> achieved with the MAC Address Withdraw Message defined in  
>>> [RFC4762]."
>>> 
>> Many implementations use an LDP withdraw message with an empty MAC 
>> list. (My interpretation is this is just the way it is.) Section 3.2 states the rational for the MAC flush on failure. That cannot be achieved with the RFC4762 message and procedures.
>>> 
>>> 4) Section 5.1.2 states
>>> 
>>> MTU-s or PE2-rs send the MAC Withdrawl message SHOULD be used  in 
>>> cases where the network is being upgraded and devices are not  
>I'd suggest stating something like that then instead of the current sentence. The current SHOULD does't contribute to interoperability of your mechanism, instead it is placing a requirement on devices to implement your mechanism. That requirement carries no weight in reality as it in unenforceable so I'd suggest not using the SHOULD and just stating what you want to say, e.g. something like: B-VPLS deployments with lots of I-SIDs can also benefit from using the optimised MAC flush mechanism specified in this document.
[Don] Good by me. 
>>>  In the example above, only the MAC addresses in set X and Y  (shown 
>>> in Figure 2) need to be flushed across the core.
>> [Don] Sure.
>>> 
>>> 3) Section 4.1.2 starts
>>> 
>>>  This section describes the solution for the requirements described 
>>> in  section 4.
>>> 
>> <draft-ietf-l2vpn-vpls-ldp-mac-opt-12.txt><Diff 
>> draft-ietf-l2vpn-vpls-ldp-mac-opt-11_txt - 
>> draft-ietf-l2vpn-vpls-ldp-mac-opt-12_txt.htm>
>
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 11 Apr 2014 12:59:07 +0200

Don,

> Does that cover your points?  

Yes I think it will :-)

Ben