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

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

Hi Don,

Some follow-ups inline below

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

> 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
>> From: Ben Niven-Jenkins <[e-mail]>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.

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.

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

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

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.

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

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?

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

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. 

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

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

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

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.

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

WFM.

Ben

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