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

[Francesca Palombini <[e-mail]>]

Hi Jorge,

Thanks for your update. I am ok with the resolution of the nits / editorial, thank you.

After looking more into the updating issue, I think that the main question here is: do you consider that this will be widely deployed? (As in, you would expect future deployments to widely implement these mechanisms?) 

In answer to Adrian you wrote:
"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? "

I just want to clarify that saying that your doc updates RFC7432 doesn't mean that it becomes mandatory for all the systems.
I understand that you do not want to upgrade all the systems that already support RFC7432. But from my understanding an update to a document can also be an extension or optional mechanism (which is what you have here), which is considered to be an important addition to the existing RFC. We have an example in the CoRE wg with RFC7252 (Constrained Application Protocol) which is updated by RFC7959 (Block-Wise Transfers in the Constrained Application Protocol), which is an optional features, but which specifies:

   A CoAP implementation that does not support these options generally
   is limited in the size of the representations that can be exchanged,
   so there is an expectation that the Block options will be widely used
   in CoAP implementations.  Therefore, this specification updates
   RFC 7252.

This is the only "open point" I have left, and is more of a question than a strong concern. I cc Martin for more input, but if we don't get any, this will be my Gen-ART review of v-07. Then it's up to the IESG to say what's the right way.

Thanks for all your work!
Francesca

On 19/12/2018, 11:19, "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]> wrote:

    Hi Francesca,
    
    Thank you very much for your review.
    Please see in-line how we are resolving your comments in the next revision (07, to be published asap).
    
    Thanks.
    Jorge
    
    -----Original Message-----
    From: BESS <[e-mail]> on behalf of Francesca Palombini <[e-mail]>
    Date: Friday, December 14, 2018 at 5:13 PM
    To: "[e-mail]" <[e-mail]>
    Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
    Subject: [bess] Genart last call review of draft-ietf-bess-evpn-df-election-framework-06
    
        Reviewer: Francesca Palombini
        Review result: Ready with Nits
        
        I am the assigned Gen-ART reviewer for this draft. The General Area
        Review Team (Gen-ART) reviews all IETF documents being processed
        by the IESG for the IETF Chair.  Please treat these comments just
        like any other last call comments.
        
        For more information, please see the FAQ at
        
        <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
        
        Document: draft-ietf-bess-evpn-df-election-framework-06
        Reviewer: Francesca Palombini
        Review Date: 2018-12-14
        IETF LC End Date: 2018-12-18
        IESG Telechat date: Not scheduled for a telechat
        
        Summary: This draft is basically ready for publication, but has nits that
        should be fixed before publication.
        
        Major issues: N/A
        
        Minor issues:
        
        I agree with the reviewers comments saying that this document should update
        RFC7432 and RFC8124. In particular, quoting RFC2232
        (https://tools.ietf.org/html/rfc2223#section-12)
        
           [...] A document that
           merely updates an earlier document cannot stand on its own; it is
           something that must be added to or inserted into the previously
           existing document, and has limited usefulness independently.  The
           terms Supercedes and Replaces are no longer used.
        
           Updates
        
              To be used as a reference from a new item that cannot be used
              alone (i.e., one that supplements a previous document), to refer
              to the previous document.  The newer publication is a part that
              will supplement or be added on to the existing document; e.g., an
              addendum, or separate, extra information that is to be added to
              the original document.
        
        (Yes, RFC2232 is obsolete, but I could not find the same text in the more
        recent RFC7322)
    
    [JORGE] I think this document "can stand on its own" and it is "useful independently" of RFC7432, although the latter document is a normative reference of course. Please see the resolution to Adrian's comment: https://www.ietf.org/mail-archive/web/bess/current/msg03760.html 
    Martin, please let us know if you are not okay with our resolution.
    
        
        Nits/editorial comments:
        
          "but they do not require
           any changes to the EVPN Route exchange and have minimal changes to
           their content per se."
        
        * what does their refer to?
    [JORGE] changed to the following for clarity:
    "These mechanisms do involve changes to the Default DF Election algorithm, but they do not require any changes to the EVPN Route exchange and have minimal changes in the EVPN routes."
        
        * Section 2.2.2: expand MAC-VRF on first usage for readability (or add a
        reference to its definition)
    [JORGE] added to the terminology section.
        
        * Figure 3: add a definition for ANY STATE (the figure is clear, but for
        consistency I would add that in the text as well)
    [JORGE] Added:
    "5.  ANY_STATE: Refers to any of the above states."
        
        * Figure 3: add "or" between VLAN_CHANGE, RCVD_ES, LOST_ES (again, not
        necessary, suggested for readability of the figure)
    [JORGE] done, thx
        
        * Section 3.1: the term "re-entering" needs clarifying: I would consider a loop
        as re-entering the state, but from bullet 8. it seems like you don't.
    [JORGE] good point. Changed 8 to:
    "8.  DF_CALC on VLAN_CHANGE, RCVD_ES or LOST_ES: do *****as in transition 7.******"
        
        * suggestion for figure 4 (otherwise it looks like there are 2 fields Bitmap of
        1B each):
        
              0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             | Type=0x06     | Sub-Type(0x06)| RSV |  DF Alg |    Bitmap     ~
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ~               |            Reserved                           |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    [JORGE] done, thanks.
    
        
        * Section 3.2: why was Bit 0 left unassigned in Bitmap?
    [JORGE] there are implementations of https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-02 using that bit.
        
        * IANA considerations: I think you want to specify that the policy for Alg 31
        is Experimental use (right now the text describing the policy only says "RFC
        required", with no distinction for different values).
    [JORGE] ok, done.
        
        
        _______________________________________________
        BESS mailing list
        [e-mail]
        https://www.ietf.org/mailman/listinfo/bess