Benoit:

 

I’m sorry I missed updating this last week when the authors updated to -12.  

 

Status: not ready

Why: Operations issues not 100%.  However, a few rounds of text change discussions should fix.  Will engage with authors to complete the discussion. 

 

What’s good: 3.0 Overview  - nice addition, section 5.1 and 5.2 

Status: Technical issues: 

Problem 1: 

Negotiation is outside your context  (to be considered) 

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

 

Status: Do not see where this was completely or answers.  Answer may be no/yes in the text – but I cannot tell. 

Authors simply need to tell me if looked at it – said not useful or X is wrong with the idea. 

 

Where saw change: Section 3.0 – positive MAC flushes must be always be handled.   Section 3.2 – operator can choose optimized flush.  Section 5.1.2 – States it applies when optimized flush is supported/no-supported.   5.1.3 specifies actions for optimized Flush. 

 

[What’s missing]: Operation section really doesn’t tie together the above changes, and make it easier for the reader to find the solution to problem 1 stated above.    Since the authors are very good at this technology and good authors, I think it is simply an oversight that they will fix.  If the authors wish to engage with a round of text, I’m glad to work toward this with the authors.  

 

Problem 2: fix in 5.2.1 : Very nice work on clear specification.  Kudos to the Authors on careful description. This will really help interoperability.  

Status: fixed

Style: Author used their current form rather than a numbered form.  OK with reviewer.  

Editorial: 

MS-PW – is not defined.  I still think it would be useful.  Style – OK with reviewer. 

 

Problem 3: negotiation – 

Fall Back: if one side negotiates and expects this option, and the other side does not. 

 

Status: Greatly improved.  Still does not tie it together with Section 6, para 1-3.  It is 90% of the way there,  but it still leaves a medium level reader trying to connect the dots.   Really, this is the same comment as problem 1.  I think the authors are 80-90% the way there, but I really cannot tie section back to the appropriate answers in previous sections.  

 Great progress toward this is made all over the document.  An analogy – I can see lines and dots and most of the picture, but it is still fuzzy here and there.  

 

Answer:  I think a few rounds with the authors. 

Note: I will help the authors to resolve this comment quickly.   Please me let me know if the authors sent email and I missed it. 

 

Problem 4: IANA – Looks fixed to me. 

 

Sue Hares 

 

 

From:

 Benoit Claise [mailto:bclaise at cisco.com] 

Sent:

 Thursday, June 12, 2014 9:16 AM

To:

 Susan Hares

Subject:

 Re: OPS-DIR review of draft-ietf-l2vpn-vpls-ldp-mac-opt

 

Hi Sue,

Have you had a chance to review this?

Regards, Benoit

No need to apologize. You sent it to the right place. The authors did not

B.

Benoit: 

 

I apologize for sending it to the wrong place. I will check and update. 

 

Sue 

 

From:

 Benoit Claise [

mailto:bclaise at cisco.com

] 

Sent:

 Tuesday, June 10, 2014 11:38 AM

To:

 

adrian at olddog.co.uk

; 'Susan Hares'; 

draft-ietf-l2vpn-vpls-ldp-mac-opt.all at tools.ietf.org

; 

ops-dir at ietf.org

Cc:

 'Joel Jaeggli'; 'Alia Atlas'

Subject:

 Re: OPS-DIR review of draft-ietf-l2vpn-vpls-ldp-mac-opt

 

Hi Adrian, Sue,

Thanks. Neither OPS-DIR nor I were copied to the email below. That explains.

Sue, can you please let us if your concerns are addressed with the latest version.

Regards, Benoit

Hi Benoit,

 

There were multiple emails from Don Fedyk about this Ops Dir review before the latest version was posted. Don could not get a response so went ahead and posted.

 

Please see attached.

 

Adrian

 

 

From:

 Benoit Claise [

mailto:bclaise at cisco.com

] 

Sent:

 10 June 2014 15:46

To:

 Susan Hares; 

draft-ietf-l2vpn-vpls-ldp-mac-opt.all at tools.ietf.org

; 

ops-dir at ietf.org

Cc:

 Joel Jaeggli; Alia Atlas; 'adrian'

Subject:

 Re: OPS-DIR review of draft-ietf-l2vpn-vpls-ldp-mac-opt

 

Dear authors,

Can you please engage in the discussion.

Note: this draft is on the IESG telechat this Thursday.

Regards, Benoit

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 

shares at ndzh.com