Hi Ignas,
Thank you very much for your review.
We addressed all your comments. Please see below.
Thanks,
Jorge
-----Original Message-----
From: Ignas Bagdonas <ibagd...@gmail.com>
Date: Tuesday, May 8, 2018 at 9:25 AM
To: The IESG <i...@ietf.org>
Cc: "draft-ietf-bess-evpn-prefix-advertisem...@ietf.org"
<draft-ietf-bess-evpn-prefix-advertisem...@ietf.org>, Zhaohui Zhang
<zzh...@juniper.net>, "aretana.i...@gmail.com" <aretana.i...@gmail.com>,
"bess-cha...@ietf.org" <bess-cha...@ietf.org>, "zzh...@juniper.net"
<zzh...@juniper.net>, "bess@ietf.org" <bess@ietf.org>
Subject: Ignas Bagdonas' No Objection on
draft-ietf-bess-evpn-prefix-advertisement-10: (with COMMENT)
Resent-From: <alias-boun...@ietf.org>
Resent-To: <jorge.raba...@nokia.com>, <wim.henderi...@nokia.com>,
<jdr...@juniper.net>, <w...@juniper.net>, <saja...@cisco.com>
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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
