Hi again Roman,
Distinct thread from the one on your Discuss...
> 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.
Yes, 1) refers to the SFF. We will add "... (i.e., the SFF)"
> * Section 2.2. Per Figure 1, where is the “Controller” in this reference
> model?
Per the previous quote 2) it would be impractical to show the controllers in
Figure 1 with connectivity to each SFF. Furthermore, the figure is the SFC
(forwarding plane) architecture not the SFC control plane architecture.
But the paragraph immediately before the figure starts "Note that, for
convenience and clarity..." so this is a good place for us to make the clear
how the controllers fit in.
> * 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.?
Yes. Clarified in the text.
> * Section 3.1.1. Per the SFIR Pool Identifier Value being “globally unique”,
> is that globally unique per Controller? Per overlay network?
Per overlay network. Clarified in the text.
Makes note to *never* use "globally unique" again ☹
> * 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?
It is a multiplier. We think that everyone (else) has understood this so far,
but have added a clarifying note.
> * 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?
I think this text is commentary and using 2119 language would be inappropriate.
You can find the actual requirements language in section 4.3.
> * Section 6. Per “Therefore, the use of NSH metadata may be required in order
> to prevent infinite loops”, what is this meta-data?
We'll add a reference to the SFC WG definition of metadata (RFC 8300).
> * 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?
It is expected that a controller that computes an SFP has knowledge of the
functions that need to be included on the path. Such knowledge includes the
ordering of functions (it's not just a set of functions, but a sequence), the
alternative implementations of functions (as conveyed by different SFTs), and
the statefulness of functions. Note that it is not really an implementation
choice whether a function is stateful - much more it is dependent on the
function being performed (I think a bidirectional firewall may be a good
example).
So, having said all that, the SFIRs do not specifically indicate "this SF (or
this SI) is stateful."
> * Editorial Nits:
> - Section 2.2. s/channelled/channeled/
> - Section 4.5.1. s/bevahior/behavior/
Thanks
> - 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.
Missing "if" or "when"
> - Section 8.9.1. Typo. s/is is/is/
Thanks
Best,
Adrian
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
