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

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

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:[e-mail]] 
Sent: Friday, May 16, 2014 12:03 PM
To: Fedyk, Don; 'Ben Niven-Jenkins'
Cc: [e-mail]; 'Robert Sparks'; [e-mail]; [e-mail]
Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt

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

> -----Original Message-----
> From: Fedyk, Don [mailto:[e-mail]]
> Sent: 16 May 2014 16:21
> To: Ben Niven-Jenkins
> Cc: [e-mail]; [e-mail]; Robert Sparks 
> ([e-mail]); [e-mail]; 
> draft-ietf-l2vpn-vpls-ldp-mac- [e-mail]
> Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
> 
> 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]; 
> draft-ietf-l2vpn-vpls-ldp-mac- [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]; 
> draft-ietf-l2vpn-vpls-ldp-mac- [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>