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

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 16 May 2014 15:20:51 +0000

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: [email-masked]; [email-masked]; Robert Sparks ([email-masked]); [email-masked]; [email-masked]
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:[email-masked]]
Sent: Friday, April 11, 2014 7:23 AM
To: Fedyk, Don
Cc: [email-masked]; [email-masked]; Robert Sparks ([email-masked]); [email-masked]; [email-masked]
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 <[email-masked]> 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:[email-masked]]
> Sent: Thursday, April 10, 2014 12:03 PM
> To: Fedyk, Don; 'Ben Niven-Jenkins'; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> 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>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 16 May 2014 17:03:01 +0100

Hi don,

Thanks for sticking with it.

There was also an OpsDir review from Sue Hares you need to look at.

Post a revision when you're ready.

Cheers,
Adrian

> From: Fedyk, Don [mailto:[email-masked]]
> Sent: 16 May 2014 16:21
> To: Ben Niven-Jenkins
> Cc: [email-masked]; [email-masked]; Robert Sparks
> ([email-masked]); [email-masked]; draft-ietf-l2vpn-vpls-ldp-mac-
> [email-masked]
> 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
> 
> 
> 
> Cc: [email-masked]; [email-masked]; Robert Sparks
> ([email-masked]); [email-masked]; draft-ietf-l2vpn-vpls-ldp-mac-
> [email-masked]
> Cc: [email-masked]; [email-masked]; Robert Sparks
> ([email-masked]); [email-masked]; draft-ietf-l2vpn-vpls-ldp-mac-
> [email-masked]
> 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
> > Here is an update of the draft attempting to address concerns and
deficiencies
> pointed out.  Please check the draft changes address the concerns.
> >
> > 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]
> >
> > 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: Fri, 16 May 2014 16:08:17 +0000

Hi Adrian

Sorry I' ve missed Sue Hares input completely.  I don't seem to have a copy in my Inbox.  Not sure what went wrong can you forward or show me where to look ? 

Thanks
Don 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, May 16, 2014 12:03 PM
To: Fedyk, Don; 'Ben Niven-Jenkins'
Cc: [email-masked]; 'Robert Sparks'; [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt

Hi don,

Cheers,
Adrian

> ([email-masked]); [email-masked]; 
> draft-ietf-l2vpn-vpls-ldp-mac- [email-masked]
Ben is
> ([email-masked]); [email-masked]; 
> draft-ietf-l2vpn-vpls-ldp-mac- [email-masked]
> ([email-masked]); [email-masked]; 
> draft-ietf-l2vpn-vpls-ldp-mac- [email-masked]
> 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
deficiencies
> 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]
> >
> >>> 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].
> >>>
> >> longer connected to the MTU-s with the primary PW" is PE1-rs. 
> >> However section
> >> 3.1.1 states:
> >>>
pointers

---

From: Robert Sparks <[email-masked]>
Date: Fri, 16 May 2014 15:16:25 -0500

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