Thank you Adrian and Satya.

We added this sentence in the introduction section as suggested by Adrian:

"This document does not intend to update [RFC7432] or [RFC8214] but improve the 
behavior of the DF Election on PEs that are upgraded to follow the described 
procedures."

Hopefully this clears the "update" question. Martin, please, let us know if you 
are not okay with it.
Thanks.
Jorge


-----Original Message-----
From: Adrian Farrel <adr...@olddog.co.uk>
Organization: Old Dog Consulting
Reply-To: "adr...@olddog.co.uk" <adr...@olddog.co.uk>
Date: Saturday, December 15, 2018 at 10:12 AM
To: "'Satya Mohanty (satyamoh)'" <satya...@cisco.com>, "Rabadan, Jorge (Nokia - 
US/Mountain View)" <jorge.raba...@nokia.com>, "rtg-...@ietf.org" 
<rtg-...@ietf.org>, "draft-ietf-bess-evpn-df-election-framework....@ietf.org" 
<draft-ietf-bess-evpn-df-election-framework....@ietf.org>, "i...@ietf.org" 
<i...@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: RE: Rtgdir last call review of 
draft-ietf-bess-evpn-df-election-framework-06

    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) <satya...@cisco.com> 
    Sent: 14 December 2018 23:17
    To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>; 
Adrian Farrel <adr...@olddog.co.uk>; rtg-...@ietf.org; 
draft-ietf-bess-evpn-df-election-framework....@ietf.org; i...@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.raba...@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)" <satya...@cisco.com>
        Date: Friday, December 7, 2018 at 9:11 PM
        To: Adrian Farrel <adr...@olddog.co.uk>, "rtg-...@ietf.org" 
<rtg-...@ietf.org>
        Cc: "draft-ietf-bess-evpn-df-election-framework....@ietf.org" 
<draft-ietf-bess-evpn-df-election-framework....@ietf.org>, "i...@ietf.org" 
<i...@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-boun...@ietf.org>
        Resent-To: <jorge.raba...@nokia.com>, <satya...@cisco.com>, 
<saja...@cisco.com>, <jdr...@juniper.net>, <kiran.naga...@nokia.com>, 
<senthil.sathap...@nokia.com>, <matthew.bo...@nokia.com>, 
<stephane.litkow...@orange.com>, <manka...@cisco.com>, 
<martin.vigour...@nokia.com>, <db3...@att.com>, <aretana.i...@gmail.com>, 
Stephane Litkowski <stephane.litkow...@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" <adr...@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
                
                
                
            
            
        
        
        
    
    
    

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Reply via email to