Hi Adrian! Thanks for the explanations below and the updates made in -14/-15. Please consider these comments resolved.
Regards, Roman > -----Original Message----- > From: iesg <[email protected]> On Behalf Of Adrian Farrel > Sent: Thursday, May 28, 2020 9:49 AM > To: Roman Danyliw <[email protected]> > Cc: [email protected]; [email protected]; 'The > IESG' <[email protected]>; [email protected] > Subject: Roman Danyliw's Comments on draft-ietf-bess-nsh-bgp-control-plane- > 13 > > 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
