Re: [bess] Ignas Bagdonas' No Objection on draft-ietf-bess-evpn-prefix-advertisement-10: (with COMMENT)

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

Hi Ignas,

Thank you very much for your review.
We addressed all your comments. Please see below.

Thanks,
Jorge

-----Original Message-----
From: Ignas Bagdonas <[e-mail]>
Date: Tuesday, May 8, 2018 at 9:25 AM
To: The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Zhaohui Zhang <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Ignas Bagdonas' No Objection on draft-ietf-bess-evpn-prefix-advertisement-10: (with COMMENT)
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Tuesday, May 8, 2018 at 9:25 AM

    Ignas Bagdonas has entered the following ballot position for
    draft-ietf-bess-evpn-prefix-advertisement-10: No Objection
    
    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)
    
    
    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about IESG DISCUSS and COMMENT positions.
    
    
    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    NVGRE and VXLAN-GPE references throughout the document – would be better to
    replace with Geneve, as NVGRE is historic, and GPE will wait until Geneve
    progresses. This does not change the logic of operation for non-Ethernet NVO
    tunnels.
[JORGE] ok, done.
    
    s2.1, last bullet: TS4 connectivity is not required to be physical, it is just
    connectivity.
[JORGE] I removed "physical"
    
    s3.2: s/fail to install/MUST not install
[JORGE] added MUST NOT
    
    s4.3, steps 1 and 2: what if MAC address is both signaled and learned by
    policy? How would such conflict be resolved? Which one would take precedence?
[JORGE] added: ", however the MAC in the Extended Community is preferred if sent with the route."
    
    s2: s/program/propagate
[JORGE] ok, done.
    
    A few assorted nits:
    
    Document would benefit from reduction of hyphenation of common terms and
    normalizing the spelling of the terms throughout the document (as an example,
    there are forms of route type, route-type, and Route Type intermixed).
    Re-advertise, stripped-off, mass-withdrawal, ip-lookup, mac-lookup, re-used,
    inter-subnet-forwarding, next-hop.
[JORGE] ok, I removed some
    
    s/route-target/Route Target
[JORGE] ok, done.
    
    s/layer-2/layer 2
[JORGE] ok, done.

    s/layer-3/layer 3
[JORGE] ok, done.

    
    RT-2, RT-5: please consider unifying the terminology and use route type 2/route
    type 5, RFC7432 does not use RT-x notation.
[JORGE] since they are defined in the terminology section, I think it should be fine? I left them
    
    S4.4.2: s/IP10/IP1
[JORGE] I think IP10 is correct