Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-df-election-framework-06

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 15 December 2018 09:12 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF7D128CF3; Sat, 15 Dec 2018 01:12:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 pwImgkny6FBY; Sat, 15 Dec 2018 01:12:06 -0800 (PST)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC1512426A; Sat, 15 Dec 2018 01:12:04 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id wBF9Bxb1016429; Sat, 15 Dec 2018 09:12:00 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B012422044; Sat, 15 Dec 2018 09:11:59 +0000 (GMT)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 9A6D222042; Sat, 15 Dec 2018 09:11:59 +0000 (GMT)
Received: from LAPTOPK7AS653V ([84.93.88.219]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id wBF9Bv7X007539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 Dec 2018 09:11:58 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: "'Satya Mohanty (satyamoh)'" <satyamoh@cisco.com>, "'Rabadan, Jorge (Nokia - US/Mountain View)'" <jorge.rabadan@nokia.com>, rtg-dir@ietf.org, draft-ietf-bess-evpn-df-election-framework.all@ietf.org, ietf@ietf.org, bess@ietf.org
References: <154419600663.20319.1134084541639124198@ietfa.amsl.com> <B65E51DB-82EE-42FD-8B51-094C2E55EA01@cisco.com> <E4882881-876F-4291-BBCC-1526D30D6459@nokia.com> <4A14B12F-E33B-436F-A5B3-BD7138C4E8D6@cisco.com>
In-Reply-To: <4A14B12F-E33B-436F-A5B3-BD7138C4E8D6@cisco.com>
Date: Sat, 15 Dec 2018 09:11:56 -0000
Organization: Old Dog Consulting
Message-ID: <008601d49456$3b264890$b172d9b0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEWpEFXgdqUqpDZbgUMsJcHyGssHwI49mZOAcBixzYBn+8G0qbOmS/g
Content-Language: en-gb
X-Originating-IP: 84.93.88.219
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24290.003
X-TM-AS-Result: No--16.793-10.0-31-10
X-imss-scan-details: No--16.793-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24290.003
X-TMASE-Result: 10--16.792700-10.000000
X-TMASE-MatchedRID: IeZYkn8zfFrxIbpQ8BhdbODQCXqvSA0sEtdrY/Wb3fPagsZM0qVv13ik i0zUgl6q3SqeYDfY38upWhL1UZ8ry1UUpkR4hWC1LTHwnYOikQ1mxw9CDZdnHNunfO6Vvq2NOo7 4i8pSTyHhvDeoa30WYKqXbbImsVMS1Vkkxa3vhyBz5CFYokzTgxmyTBaqiJvcnpc4lExoYmofah 0XtuYfoMoL7gNw4ydQmHooW/9INe+7JfBr9Xl5Co0JVVcEm48nX5TqQagR07fyFWy7/IKeM7z4O lLLFRT/MzV5e7Be8i3oIzeGKNm8l9MsGRKm0bkE2OSj4qJA9QaHxi2fvkKUM6wgydzPLF7nZ7KX jwm26qoOcAv3o3ngp/HXT34Eqlvlu+66Sy5jOwL4vYawCsCC2h9fNWA7SFWqut/GVGOoEncWEyC dxNirJDEY7DZx2PFZwbUPQvgaX7rMwsxmsfdd47MsPmSZxbpk+qTrCpYSyMJnnK6mXN72m42KV0 EJ3FKhzunozDNkImgJzcgAAYMWdSTtChVcJtE4SDkh6bW+bcdmoXQjRSqSYbLXgMbd2Te8Y2iR7 K8Wcsxz3i6rL4HbS29FG+Uo0WMmHWFOJL3jV+Slc2LL333VMQmu5ZW+opihVm3hZ7omt1IeTpcy by/54j1lfqwBcvJtYklZyHW6Io+Tp/xbsLF+b8gEzEv7Qy+YVo4lwLFUdivQpokFSTvCgAf7tX3 4v0pR1uxskyNzLJt7qWxPmqWCgGEYnUk3BM1rW7gz/Gbgpl4za2zV+sjx6rVhTD1Udgq82FRtV0 ZQbSWN9b7YNwjpRgeJ2DSv9lS6T5YEU7L8zSWeAiCmPx4NwFkMvWAuahr80rgiRgBhihoMyrfP9 j+C1d934/rDAK3zUc1+O1X9AzE=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/9NQaHRyRXbHr2OXbcjKIIFd6nyY>
Subject: Re: [bess] Rtgdir last call review of draft-ietf-bess-evpn-df-election-framework-06
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Dec 2018 09:12:09 -0000

We're good. Thanks!

Consult with your AD, but for the "updates" question, a way forward would be to make an explicit statement (in the Introduction) to the contrary.

Best,
Adrian
--
Fairy tales from North Wales brought to you for Christmas
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

-----Original Message-----
From: Satya Mohanty (satyamoh) <satyamoh@cisco.com> 
Sent: 14 December 2018 23:17
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>; Adrian Farrel <adrian@olddog.co.uk>; rtg-dir@ietf.org; draft-ietf-bess-evpn-df-election-framework.all@ietf.org; ietf@ietf.org; bess@ietf.org
Subject: Re: Rtgdir last call review of draft-ietf-bess-evpn-df-election-framework-06

Hi Jorge and Adrian. 

Inline [Satya].

Thanks,
--Satya

On 12/14/18, 2:40 AM, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> wrote:

    Hi Adrian,
    
    Thank you very much for your thorough review.
    I incorporated most of your comments, please see the details in-line with [JORGE].
    
    There is one outstanding comment that Satya and I will discuss.
    
    Thank you.
    Jorge
    
    -----Original Message-----
    From: "Satya Mohanty (satyamoh)" <satyamoh@cisco.com>
    Date: Friday, December 7, 2018 at 9:11 PM
    To: Adrian Farrel <adrian@olddog.co.uk>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
    Cc: "draft-ietf-bess-evpn-df-election-framework.all@ietf.org" <draft-ietf-bess-evpn-df-election-framework.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "bess@ietf.org" <bess@ietf.org>
    Subject: Re: Rtgdir last call review of draft-ietf-bess-evpn-df-election-framework-06
    Resent-From: <alias-bounces@ietf.org>
    Resent-To: <jorge.rabadan@nokia.com>, <satyamoh@cisco.com>, <sajassi@cisco.com>, <jdrake@juniper.net>, <kiran.nagaraj@nokia.com>, <senthil.sathappan@nokia.com>, <matthew.bocci@nokia.com>, <stephane.litkowski@orange.com>, <mankamis@cisco.com>, <martin.vigoureux@nokia.com>, <db3546@att.com>, <aretana.ietf@gmail.com>, Stephane Litkowski <stephane.litkowski@orange.com>
    Resent-Date: Friday, December 7, 2018 at 9:11 PM
    
        Hi Adrian,
        
        Thank you very much for your detailed review and comments.
        We will take care of all the nits that you have pointed out and include the reference to the IEEE/ACM TON paper (the link you have pointed out is indeed correct).
        
        However, I had one query. Most of the time research journal/conference papers will be behind a paywall and there may not be a free cached copy available online.
        How do we get across this problem?
        
        Best,
        --Satya
        
        On 12/7/18, 7:20 AM, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
        
            Reviewer: Adrian Farrel
            Review result: Has Nits
            
            Hello,
            I have been selected as the Routing Directorate reviewer for this draft. The
            Routing Directorate seeks to review all routing or routing-related drafts as
            they pass through IETF last call and IESG review, and sometimes on special
            request. The purpose of the review is to provide assistance to the Routing ADs.
            For more information about the Routing Directorate, please see
            ?http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments
            are primarily for the use of the Routing ADs, it would be helpful if you could
            consider them along with any other IETF Last Call comments that you receive,
            and strive to resolve them through discussion or by updating the draft.
            
            Document: draft-ietf-bess-evpn-df-election-framework-06.txt
            Reviewer: Adrian Farrel
            Review Date: 2018-12-07
            IETF LC End Date: 2018-12-18
            Intended Status: Standards Track
            
            Summary:
            
            This document is basically ready for publication, but has nits that should be
            considered prior to publication.
            
            Comments:
            
            This document addresses issues in the default election algorithm used for
            Designated Forwarder Election in EVPN (RFC 7432 and RFC 8124) by defining a new
            election algorithm and a capability to influence the election result for a
            VLAN, depending on the state of the associated Attachment Circuit.
            
            This is an exceptionally clear and well written document. The authors and the
            working group are to be congratulated.
            
            During my review I observed a number of small issues and editorial nits. I
            don't believe any of these is cause for discussion in the working group, but it
            would be sensible to resolve them before publication.
            
            Thanks and Happy Christmas,
            Adrian
            --
            It's Christmas.
            Buy someone you love a book of fairy tales.
            https://www.feedaread.com/profiles/8604/
            Available from your favourite online bookseller.
            Or contact me to receive a signed copy by mail.
            
            ===
            
            Major Issues:
             No major issues found
            
            ===
            
            Minor Issues:
            
            HRW1999 is provided as a normative reference, and from the text I can
            see why. But no URL (stable or otherwise) is given for the reference.
            Using my favorite search engine, I looked for and found a copy of
            the referenced document on the IEEE site behind a paywall. I don't
            think that will do at all. However, there is a version at
            https://www.microsoft.com/en-us/research/wp-content/uploads/2017/02/HRW98.pdf
            That appears to be dated 1998, but otherwise could be the same paper.
    
    [JORGE] ok, we added the link and move it to informative references. Thanks!
            
            ---
            
            When I read in Section 3...
            
               In addition, since the specification in EVPN
               [RFC7432] does leave several questions open as to the precise final
               state machine behavior of the DF election, section 3.1 describes
               precisely the intended behavior.
            
            ... I wondered whether this document is updating 7432 in that respect.
            
            Other features later in the document (such as section 5) confirm this.
    
    [JORGE] it's not the first comment suggesting this. The intend is definitively not to update RFC7432 but to specified new procedures, that was the agreement so far. In other words, this work does not mandate an upgrade of all the systems supporting RFC7432. The RFC7432 are still fine. Maybe we need to rephrase that sentence? 
            
            ---
            
            Notwithstanding the mention of backward compatiblity in section 6, I
            think it would be a good idea to include a very short section 3.2.1.
            
            3.2.1.  Backward Compatibility
            
               Legacy implementations (i.e., those that predate this specification)
               will not advertise the DF Election Extended Community.  That means
               that all other participating PEs will not receive DF preferences and
               will revert to the defailt algorithm without AC-Influenced DF
               Election.
            
               Similarly, a legacy implementation receiving a DF Election Extended
               Community will ignore it and will continue to use the default
               algorithm.
    
    [JORGE] Thank you. We took you text slightly modified:
    
    ***3.2.1. Backward Compatibility
    
       [RFC7432] implementations (i.e., those that predate this
       specification) will not advertise the DF Election Extended Community.
       That means that all other participating PEs will not receive DF
       preferences and will revert to the Default DF Election algorithm
       without AC-Influenced DF Election.
    
       Similarly, a [RFC7432] implementation receiving a DF Election
       Extended Community will ignore it and will continue to use the
       Default DF Election algorithm.***
            
            ---
            
            On first reading, I missed an important subtlty in 3.2. The paragraph...
            
                 - Otherwise if even a single advertisement for the type-4 route is
                   not received with the locally configured DF Alg and capability,
                   the default DF Election algorithm (modulus) algorithm MUST be
                   used as in [RFC7432].
            
            ...is really important because it handles what to do if different
            participating PEs disagree about which algorithm to use.  Your text is
            perfectly fine and adequate, but the "locally configured" sort of hid
            it from me first time around.
            
            Maybe add a sentence to the end of the bullet point to say...
            
            "This procedure handles the case where participating PEs disagree about
            the DF algorithm and capability to apply."
    
    
    [JORGE] added, thanks.
            
            ---
            
            Section 4 introduces 8124 for the first time. It's good that this is
            applicable to private wire EVPN as well as 7432 EVPN. Maybe bring this
            into focus in the Introducion?
            
            It does make me wonder whether you are also updating 8124.
    [JORGE] Added this to the introduction. See my comment above about updating specs.
    "The procedures described in this document apply to [RFC7432] and [RFC8214] EVPN networks."
            
            ---
            
            I think section 7 is good. Since you note that the "unfair" situation
            may be created maliciously, should you note that there is also scope for
            a downgrade attach where the advertisement from one PE is hidden, the
            preferred algorithm is modified to any unexpected value, or any
            unexpected bit in the capabilities bitfield is set? I think such an
            attack assumes either a subversion of the PE (perhaps via its
            configuration) or modification of the BGP message. Thus, it is not a
            probable if adequate existing security mechanisms are used.
    
    [JORGE] added this sentence: *** Note that the network will not benefit of the new
       procedures if the configuration of one of the PEs in the ES is
       changed to the default [RFC7432] DF Election.***
            
            ===
            
            Nits:
            
            The RFC Editor will require that the first section in the document is
            the Introduction.
    
    [JORGE] changed, thanks.
            
            ---
            
            You use VNI and I-SID without expansion.
    [JORGE] expanded in the first occurrence.
            
            ---
            
            2.1
            s/proposes/defines/
    [JORGE] done, thx
            
            ---
            
            2.3
            s/procedure Generally,/procedure.  Generally,/
    [JORGE] done, thx
            
            ---
            
            3.2 has
            
               For the DF election procedures to be consistent and unanimous, it is
               necessary that all the participating PEs agree on the DF Election
               algorithm and capabilities to be used.
            
            This is exactly the type of statement I was hoping for when I opened the
            document, so thanks. But... :-)
            
            This depends slightly on the definition of "all participating PEs". You
            don't need all PEs in the EVPN to use the same algorithm, only the PEs
            that share multi-homing connections.
            
            You also use the term in 2.1 and other places in the document, so
            perhaps I am worrying too much.
    [JORGE] added "all participating PEs ***in the ES***"
            
            ---
            
            4.
            s/the state of the server states/the server states./
            s/on Unix utilities rand and srand/on the Unix utilities rand and srand/
    [JORGE] done, thx
            
            ---
            
            I am not sure why you describe Wrand2 in section 4.2 because you
            immediately decide to not use it. Maybe you can just describe Wrand and
            observe that does the job?
    [JORGE] that's a question for Satya, Satya??
[Satya] Yes, we can remove Wrand2. It is not necessary to describe it.
            
            ---
            
            4.2
               s/HRW solves the disadvantage/HRW solves the disadvantages/
    [JORGE] done, thx