[bess] draft-ietf-bess-evpn-geneve-08

[Susan Hares <[e-mail]>]

BESS WG, BESS-chairs, and authors:

I'm excited to see draft-ietf-bess-evpn-geneve-08.  I've provided my review below and attached as a text file.

Reviewer: IDR chair per BESS chair rqequest

Summary: The draft is a great start, but needs a lot of details tied down in the draft related to the Tunnel-encapsulation attribute (TEA).

I've provided comments and outlines for what should be in the draft.

Keep going it is important work on the right track.


I'll be glad to review the tunnel encapsulation details again.

Cheers,


===========

draft-ietf-bess-evpn-geneve-08

Summary: BGP extension description is not ready yet

pro: Basic concepts are solid for a limited down deployment

Con: The specification lacks the detail to provide the following:
a) clear augmentation to existing specifications for BGP tunnel encapsulation attribute,
b) validation of tunnel endpoints,
c) interactions with PMSI,
d) normal caveats (security, manageability, and error  handling)

Issue 1: Tunnels the subTLV is valid for (perhaps a new subsection before 5.10
It is unclear which Tunnels the Geneve Tunnel Option TLV is valid for.
https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml)

This document needs to extend the specification for each tunnel to accept this new SubTLV
(per the table) that this subTLVB is valid for to include subTLVs.

Perhaps it would be useful to have IANA keep track of that.  If that would help you,
I can write a short registration draft with that information.  We could then add
the table in tunnel-encapsulation #4 to IANA.

Issue 2: Sub-TLV clear specification (a revised sectino 5.1)

It is important to understand how subTLV changes (or does not change) the validation
procedures and the error handling for the tunnel.  By the way, whether the encapsulation
tunnel is specified by the Extended-Community or the Tunnel-Encapsulation, the
validation procedure has to be clearly specified.  The Extended-Community assumes
certain values (such as egress endpoint)

Ths SubTLV outline below can help you structure your subTLV portion to include key components.
Please consider putting these in this order.  It will help people quickly review your document.


Issue 3: PMSI interactions (perhaps a new section 5.3)

RFC9012 specifies that you must provide PMSI update if you are specifying a new tunnel.
Since this encapsulation may change the PMSI interactions, please review these questions.

What we are looking for is the answers to be included in a section 5.3

Issue 4: Error handling section.

You are missing an error handling section.  What happens with malformed SubTLV or adding
subTLV to tunnel that doesn't support it.  See RFC7606.

Issue 5: Security section

Two issues need to be include:

security-issue- 1) Walled garden or not?

You propose a walled garden as the EVPN control plane operates in a walled garden.
If you are limiting your tunnels to tunnels only in an EVPN, then section 5 and 6
needs to specify the Tunnel Encapsulation tunnel types you believe are in the walled garden.

Secure-issue-2: You need to consider that Tunnels may provide hidden reaches to your EVPN walled garden.

Look at the security section in draft-ietf-idr-sr-policy-safi.  Perhaps it will help

Issue 6:  Manageability - needs to be added to the draft

You need to consider how the operator is going limit the tunnels to just the tunnels you specify.
You need to consider what configuration errors could occur for those familar:
a) EVPN and not geneve tunnels
b) tunnels and not geneve.


================================
Tunnel encapsulation specification requires the following things for every tunnel:

1) Name -

Do: give a short name
Do not: Please do not replicate a subTLV name (segment lists)
2) Code (TBD or assigned number)

3) Description - short function description or a link to a longr text

4) list of all SubTLV defined for TEA

Do: Look at RFC9012 and any other TEA document you reference
(draft-ietf-idr-sr-policy-safi)
Gather a full list of subTLVs and put it in a table

Tunnel-name   SubTLV Supported   SubTLVs not supported
------------  ------------------ ----------------------


5) A validation procedures

Do: Write up a validation procedure for each Tunnel.
You can look at the validation procedures for [RFC9012],
but you do not have validate using Tunnel-Egress Endpoint.

Don't: Assume that one tunnel validation procedure
matches another.

5) Security Considerations
Please look draft-ietf-idr-sr-policy-safi for a good template.

6) Manageability section.

How is the operator going to create the three new tunnels in
configuration?  What problems do you envision gluing

It will be useful to have these in unique setions.

=================================================

Sub-TLV write-ups:

1) Title: One Line Summary (e.g. RPF Sub-TLV)
2) Type: 124   (either value or TBDXX) (e.g. 124)

3) Encoding of value byte
 3.1 diagram of byte layout
 (most people use 32 bit, but you can use 16 bit)
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               |               |
  +---------------+---------------+

(on the RPF, I cannot tell if you have 1 byte or no bytes)

3.2 Description of each field with:
  a) title, definition  (e.g. RPF Su
  b) size
  c) limits on the field (e.g.

3.3) Error handling

What constitutes malformed subTLV?

3.4) What Tunnels this document specifies it can go in
3.5) Does this subTLV play a part in validation .

=================================================

PMSI + Tunnel Encapsulation template

1) When is the PMSI tunnel Attribute valid to attach by itself
2) When is the PMSI tunnel Attribute + the Tunnel-Encapsulation valid to attach together.
3) When could the PMSI tunnel attribute attachment be wrong.
4) What happnes when PMSI tunnel is malformed, but needs to be attached
5) What happens when the PMSI + Tunnel-Encapsulation are to both be attached and:
5-a) PMSI is malformed, and Tunnel-encapsulation