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

"Fedyk, Don" <don.fedyk@hp.com> Tue, 20 May 2014 14:37 UTC

Return-Path: <don.fedyk@hp.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032E71A06F4 for <rtg-dir@ietfa.amsl.com>; Tue, 20 May 2014 07:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.383
X-Spam-Level:
X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, MANGLED_LIPS=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, T_HTML_ATTACH=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YErISFOsWtNl for <rtg-dir@ietfa.amsl.com>; Tue, 20 May 2014 07:37:35 -0700 (PDT)
Received: from g5t1626.atlanta.hp.com (g5t1626.atlanta.hp.com [15.192.137.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE5B1A034A for <rtg-dir@ietf.org>; Tue, 20 May 2014 07:37:34 -0700 (PDT)
Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t1626.atlanta.hp.com (Postfix) with ESMTPS id 3D1AF1DA; Tue, 20 May 2014 14:37:32 +0000 (UTC)
Received: from G6W3996.americas.hpqcorp.net (16.205.80.211) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Tue, 20 May 2014 14:36:43 +0000
Received: from G6W2492.americas.hpqcorp.net ([169.254.8.28]) by G6W3996.americas.hpqcorp.net ([16.205.80.211]) with mapi id 14.03.0169.001; Tue, 20 May 2014 14:36:43 +0000
From: "Fedyk, Don" <don.fedyk@hp.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Susan Hares' <shares@ndzh.com>
Thread-Topic: OPS-DIR review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
Thread-Index: Ac90OCcUgmzadK70R0OX2oLAx34tEw==
Date: Tue, 20 May 2014 14:36:43 +0000
Message-ID: <A46D9C092EA46F489F135060986AD9FF07EB6246@G6W2492.americas.hpqcorp.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [16.201.12.30]
Content-Type: multipart/mixed; boundary="_003_A46D9C092EA46F489F135060986AD9FF07EB6246G6W2492americas_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ns0XBSk5ZIi7r92M7XbnWPZuN1A
X-Mailman-Approved-At: Tue, 20 May 2014 16:28:32 -0700
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "Robert Sparks (rjsparks@nostrum.com)" <rjsparks@nostrum.com>, "draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.org" <draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.org>, "Ben Niven-Jenkins (ben@niven-jenkins.co.uk)" <ben@niven-jenkins.co.uk>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: Re: [RTG-DIR] OPS-DIR review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 May 2014 14:37:46 -0000

Hi Sue

Here is a draft to address your comments.   I tried to clarify the procedures as you requested since the details of PBB may not be understood by some.   I've been the main editor on this on what was supposed to be a simple cleanup of the document to publication (OK no such thing).  Note I add myself to the front page since I was listed in the document only and this has caused confusion  (like me missing your comments.) 

I would appreciate if you can tell me if my text addresses your concerns.  

Inline [Don]

Thanks,
Don 

-------Original 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. 

[Don] I have not addressed this comment which would require a protocol change.  We had discussion on capabilities negotiation and there is a yet unaddressed issue to provide a more general procedure for negotiation. The result was we agreed to document the procedures without a negotiation.  

      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. 
[Don]  Hopefully my changes have addressed this comment.

     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. 

[Don] This section was updated as part of other comments.  Please check the updates address your point. 

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@ndzh.com