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

["Fedyk, Don" <[e-mail]>]

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:[e-mail]] On Behalf Of Ben Niven-Jenkins
Sent: Tuesday, April 01, 2014 10:07 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Fwd: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt

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).
[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.

>
>
> 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.

[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 using the primary spoke PW to the backup spoke PW.

[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.
>
> 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.

[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 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).
[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.
>
> 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").
[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 RFC4627 mechanisms.
[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.
>
>
> 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?
[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 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.
[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.
>
> 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?).
[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.
>
> 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.
[Don] Your text is better.  This is the recommendation for backward compatibility since there is no capabilities exchange.
>
> 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.
[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.

>
> 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?

[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.
>
> 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.

[Don] Yes s/2/3/
> 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.
[Don] Sure.
>
> 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?
>
[Don] I believe you are correct is accurate.  Section 3 and section 4 are roughly parallel a holdover from before I took over editing.
> 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.
[Don] I like your suggestion.
>
> 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.
[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.
>
> Regards
> Ben
>