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

From: Eric Rescorla <[email-masked]>
Date: Wed, 09 May 2018 17:44:23 -0700

Eric Rescorla 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:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4698

I found this document pretty dense and only gave it a light read.

COMMENTS
S 2.2
>        independent of and not subject to the interpretation of the IPL and
>        the IP value. E.g.: a default IP route 0.0.0.0/0 must always be
>        easily and clearly distinguished from the absence of IP
>        information.
>   
>      o In MAC/IP routes, the MAC information is part of the NLRI, so if IP

You need to define NLRI on first use.

S 3.1
>   
>      o The total route length will indicate the type of prefix (IPv4 or
>        IPv6) and the type of GW IP address (IPv4 or IPv6). Note that the
>        IP Prefix + the GW IP should have a length of either 64 or 256
>        bits, but never 160 bits (IPv4 and IPv6 mixed values are not
>        allowed).

Really shaving the bits tight here, I see.

S 3.2
>      Table 1 shows the different RT-5 field combinations allowed by this
>      specification and what Overlay Index must be used by the receiving
>      NVE/PE in each case. Those cases where there is no Overlay Index, are
>      indicated as "None" in Table 1. If there is no Overlay Index the
>      receiving NVE/PE will not perform any recursive resolution, and the
>      actual next-hop is given by the RT-5's BGP next-hop.

How do I behave if something appears that is not on this table

S 6.
>         overlay MAC addresses, overlay ESI, underlay BGP next-hops, etc.
>   
>      d) An EVPN implementation not requiring IP Prefixes can simply
>         discard them by looking at the route type value.
>   
>   6. Security Considerations

I'm not sure that this is a security consideration, but does the
ability to specify an IP as the next hop mean that you could route
packets somewhere totally off EVPN?

---

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

Hi Eric,

Thank you very much for your review.
I addressed all your comments, please see below.

Thanks.
Jorge

-----Original Message-----
From: Eric Rescorla <[email-masked]>
Date: Thursday, May 10, 2018 at 2:44 AM
To: The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Zhaohui Zhang <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Eric Rescorla's 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: Thursday, May 10, 2018 at 2:44 AM

    

    COMMENTS
    S 2.2
    
[JORGE] done.

    S 3.1
    
    Really shaving the bits tight here, I see.
[JORGE] this is now changed, please see the new text.

    S 3.2
    
    How do I behave if something appears that is not on this table
[JORGE] this is now clarified in the new rev.

    S 6.
    
    I'm not sure that this is a security consideration, but does the
    ability to specify an IP as the next hop mean that you could route
    packets somewhere totally off EVPN?
[JORGE] I think this should be covered by this sentence: "In addition, the security considerations in
   [RFC4364] should also be understood, since this document and
   [RFC4364] may be used in similar applications."

That can also happen in IP-VPN...