Subject: Re: [bess] Roman Danyliw's Comments on draft-ietf-bess-nsh-bgp-control-plane-13

From: Roman Danyliw <[email-masked]>
Date: Wed, 24 Jun 2020 15:28:43 +0000

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-masked]> On Behalf Of Adrian Farrel
> Sent: Thursday, May 28, 2020 9:49 AM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]; [email-masked]; 'The
> IESG' <[email-masked]>; [email-masked]
> 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