[bess] Roman Danyliw's Discuss on draft-ietf-bess-nsh-bgp-control-plane-13: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-nsh-bgp-control-plane-13: Discuss

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-nsh-bgp-control-plane/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 9 cites a number of references (which cite additional references) on
BGP security.  My summary of the highlights is:

(1) RFC4271 => TCP MD5 (RFC2385) is a MUST
(2) RFC4271 => consider RFC 3562 for key management guidance
(3) ietf-idr-tunnel-encaps => caution on Tunnel Encapsulation attribute
(4) rfc4364 => TCP MD5 is a non-rfc2119 “should”
(5) rfc4364 => don’t make connections with untrusted peers
(6) RFC7432 => references the utility of TCP-AO (RFC5925)

- Could the text articulate more clearly de-conflict (1), (4) and (6) – what is
the recommended approach?

- a discuss-discuss – Given the green field nature of this specification (the
shepherd’s report notes no implementation) and the assumed SFC deployment model
(not the internet; a single provider’s operational domain where key management
should be easier), could a more robust transport security option such as BGP
over IPSec be RECOMMENDED?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 2.2.  Could you please clarify connect between these two statements
about the SFC architecture:

1. “The SFIR is advertised by the node hosting the service function instance”

2. “We assume BGP connectivity between the Controller and all SFFs within each
service function overlay network”

Is the node referenced in statement (1) the SFF.  If not, it seems like they
need to be added to statement #2 as entities that have BGP connectivity.

* Section 2.2.  Per Figure 1, where is the “Controller” in this reference model?

* Section 3.1.  Per “If two SFIRs are originated from different administrative
domains …”, are these administrative domains still in a “within a single
provider's operational domain” per Section 2.2.?

* Section 3.1.1.  Per the SFIR Pool Identifier Value being “globally unique”,
is that globally unique per Controller? Per overlay network?

* Section 4.3.  Per the summary notation of “RT, {SFPR-RD, SPI}, m * {SI, {n *
{SFT, p * SFIR-RD} } }”, it isn’t clear to me what this expression is
summarizing.  Also, what does the “*” mean?

* Section 4.5.1. Per “Therefore, while this document requires that the SI
values in an SFP are monotonic decreasing, it makes no assumption that the SI
values are sequential.”, should this “requires” be a RFC2119 MUST or REQUIRED?

* Section 6.  Per “Therefore, the use of NSH metadata may be required in order
to prevent infinite loops”, what is this meta-data?

* Section 7.2.  Per “In such cases it can be important or necessary that all
packets from a flow continue to traverse the same instance of a service
function so that the state can be leveraged and does not need to be
regenerated.”, how is this requirement signaled through the SFIRs for the
computation of SFPs?

* Editorial Nits:
- Section 2.2. s/channelled/channeled/

- Section 4.5.1. s/bevahior/behavior/

- Section 7.1.  Per “As noted in Section 3.2.1.1 SFPRs reference each other one
SFPR advertisement will be received before the other.”, this sentence didn’t
parse for me.

- Section 8.9.1. Typo.  s/is is/is/