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

[Ben Niven-Jenkins <[e-mail]>]

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 <[e-mail]>
> Date: 1 April 2014 15:02:25 GMT+01:00
> To: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail]
> 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
>