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

From: Ignas Bagdonas <[email-masked]>
Date: Tue, 08 May 2018 00:25:37 -0700

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.

s2.1, last bullet: TS4 connectivity is not required to be physical, it is just
connectivity.

s3.2: s/fail to install/MUST not install

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?

s2: s/program/propagate

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.

s/route-target/Route Target

s/layer-2/layer 2

s/layer-3/layer 3

RT-2, RT-5: please consider unifying the terminology and use route type 2/route
type 5, RFC7432 does not use RT-x notation.

S4.4.2: s/IP10/IP1

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 18 May 2018 19:25:06 +0000

Hi Ignas,

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

Thanks,
Jorge

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

    
    
[JORGE] ok, done.
    
    s2.1, last bullet: TS4 connectivity is not required to be physical, it is just
    connectivity.
[JORGE] I removed "physical"
    
[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:
    
[JORGE] ok, I removed some
    
[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