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

["Adrian Farrel" <[e-mail]>]

Attached

A

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

--- Begin Message ---

Florin, Dutta, Olen and Geraldine:

 

Document ready for publication: Not yet - Technical  and editorial issues need
to be addressed 

 

Technical mechanism:  Good mechanism and needed for internet.  Most technical
issues are due to write-up, but without a clear mechanism interoperability
issues will probably occur. 

 

Resolution: 

1.       Consider technical issue 1 

2.       Fix obvious editorial errors - (section references, MS-PW, ordering of
processing) 

3.       Fix problems 2-4 in the text's clarity and accurate 

4.       Consider strongly rewording document - if you can do this within the WG


(no further comment is made on this point) 

 

Technical errors: 

 

1.       Basic mechanism is good 

a.       N=1 Clear mine, N=0 Clear other than mine

b.      C= Context - PBB-VPLS I-context (1), H-VPLS/BMACS = 0

 

2.       Mechanism to consider for operational issue  

 

         Problem 1: Negotiation is outside your context  (to be considered) 

 

       Negotiation being outside your context does not mean you cannot

       flag that a flush has been part of a negotiated  Flush entity. 

 

      Have all users of MAC flush set a flag bit if the setting is negotiated.

      This may help you debugging of this feature distribution. 

 

      Problem 2 (Technical/Editorial) - Clarity of mechanisms in text 

 

       Due to expert level of the authors, I assume in this write-up that the 

       lack of clarity is a documentation issue. 

 

       Sections 5.1.2 - 5.1.4 do not have a clear step by step processing. 

       It is not "what" you do that is the problem, but the order of the
processing 

      That is not clearly specified.  I cannot tell if there is an ordering of
the process.

       An ordered list (1-n) is useful if it is ordered.  A clearly delineated
set of steps.

       Your references to the operations section should be 6 (5.1.2, 5.1.3)  

 

        I am not suggesting a specific ordering or language just a clean-up.

        Why?  Because I know Florin to be an excellent author.  I suspect

       that this text is the result of editorial hacks from the WG - but 

       the result I cannot tell how to process each section. 

 

       Editorial nit: MS-PW - is not defined (or I missed it). 

 

       Sections 5.2.1 - I could not follow the step by step processing of the 

       Packet until I made notes on the side. 

 

     Problem 3:  Technical/Editorial: I cannot tell the fallback case - must fix


 

      Because sections 5.1.2-5.1.4 and 5.2.1 are not clearly written,

      I cannot tell what the fall-back mechanism is if one side negotiates

      And expects this option, and the other side does not. 

 

       Operational considerations try to address this, but the clarity of the

       Text fails. 

 

     Problem 4:  IANA section - must fix 

 

    I do not believe this section provides the details required by IANA.

    Please have your shepherd check do a pre-check with IANA - it will save you
time. 

 

Next steps: 

1.       Consider problem 1 

2.       Fix problems 2-4 and section errors 

 

OPS-DIR reviewer comment:  I'm glad to help you form text or provide text.  Out
of respect for the authors, I have only pointed the way to allow the authors the
freedom to revise the text to address the issues. 

 

Sue Hares 

[e-mail] 

 

--- End Message ---