Telechat Review of draft-ietf-bess-evpn-df-election-framework-07
review-ietf-bess-evpn-df-election-framework-07-genart-telechat-palombini-2019-01-07-00

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)"
<jorge.rabadan@nokia.com> 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 <bess-bounces@ietf.org> on behalf of Francesca Palombini
    <francesca.palombini@ericsson.com> Date: Friday, December 14, 2018 at 5:13
    PM To: "gen-art@ietf.org" <gen-art@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: [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
        BESS@ietf.org
        https://www.ietf.org/mailman/listinfo/bess