Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt

[Robert Sparks <[e-mail]>]

Sorry Don - I skimmed passed this originally since I didn't see an 
update in the tracker - my bad.
I'll reply to my original review so there's context.

RjS

On 5/16/14, 10:20 AM, Fedyk, Don wrote:
> Hi Adrian
>
> Just checking next steps for this  version of the draft (version 12). I Think Ben is good with the updates.  I didn't see an explicit approval from Robert.
>
> Thanks,
> Don
>
>
>
> -----Original Message-----
> From: Fedyk, Don
> Sent: Friday, April 11, 2014 11:23 AM
> To: 'Ben Niven-Jenkins'
> Cc: [e-mail]; [e-mail]; Robert Sparks ([e-mail]); [e-mail]; [e-mail]
> Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
>
> Thanks Ben
>
> Attached is the updated draft, let me know if there are other changes/corrections.
>
> Don
>
> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[e-mail]]
> Sent: Friday, April 11, 2014 7:23 AM
> To: Fedyk, Don
> Cc: [e-mail]; [e-mail]; Robert Sparks ([e-mail]); [e-mail]; [e-mail]
> Subject: Re: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
>
> Hi Don,
>
> The updates look good to me :-)
>
> Some minor things I noticed reading the diff...
>
> Figure 1 is now split across 2 pages making it a bit harder to read.
>
> First sentence under Figure 1 reads a little strange, maybe
> s/An example of usage of the MAC Flush mechanism/An example usage of the MAC Flush mechanism/   [remove the first 'of']
>
> Section 3.1.1 says
>     The scope of this document is not specific to any dual or
>     mulithoming homing protocols
>
> Which reads a little strange (and multihoming is misspelt)
>
> I'd suggest rewording slightly to something like:
>     The scope of this document is not specific to any dual-homing
>     or multihoming protocols
>
> Section 3.2 2nd paragraph:
>     The negative MAC flush typically results is a smaller set of MACs
>
> s/is/in/
>
> Section 5.1.2 3rd paragraph:
>     The MAC withdraw procedures defined in [RFC4762], where either the
>     MTU-s or PE2-rs send the MAC Withdrawl message SHOULD be used
>
> Is it a MAC Withdrawl message or a MAC Withdraw message?
>
>
> Ben
>
> On 10 Apr 2014, at 19:27, Fedyk, Don <[e-mail]> wrote:
>
>> Hi All (note L2VPN WG not CCd)
>>
>> Here is an update of the draft attempting to address concerns and deficiencies pointed out.  Please check the draft changes address the concerns.
>>
>> Thanks for your feedback,
>> Don
>>
>> -----Original Message-----
>> From: Adrian Farrel [mailto:[e-mail]]
>> Sent: Thursday, April 10, 2014 12:03 PM
>> To: Fedyk, Don; 'Ben Niven-Jenkins'; [e-mail]
>> Cc: [e-mail]; [e-mail];
>> [e-mail]
>> Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
>>
>> 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").
>>> [Don] OK I'll ask Adrian if he would like this highlighted.
>> 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]
>>
>>>> 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.
>> 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
>>
>> <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>