Re: [sfc] Editorial issues in draft-ietf-sfc-proof-of-transit

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Tal,

FYI – I’ve created a pull request with a set of proposed changes on the IOAM github to reflect your comments:
https://github.com/inband-oam/ietf/pull/122. If you could give it a quick review, that would be nice.

(cc’ing SFC WG as well)

Thanks, Frank

From: Frank Brockners (fbrockne)
Sent: Mittwoch, 6. März 2019 20:36
To: Tal Mizrahi <[e-mail]>; IETF IPPM WG <[e-mail]>
Cc: Shwetha Bhandari (shwethab) <[e-mail]>
Subject: RE: Editorial issues in draft-ietf-sfc-proof-of-transit

Hi Tal,

Thanks for the comments – they should be addressable before the deadline :-). Several of the “range of possible values” are answered by the YANG model in section 5.2 – but to your point, it does make sense to have a set of references in the main body to the YANG model.

Please see inline (prefix “..FB”).

From: Tal Mizrahi <[e-mail]<mailto:[e-mail]>>
Sent: Mittwoch, 6. März 2019 10:40
To: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: Frank Brockners (fbrockne) <[e-mail]<mailto:[e-mail]>>; Shwetha Bhandari (shwethab) <[e-mail]<mailto:[e-mail]>>
Subject: Editorial issues in draft-ietf-sfc-proof-of-transit

Hi,

As a co-author: we are currently reviewing the draft before submitting an updated version, and a few issues / questions came up during the review. These issues will require some clarification in the next version of the draft (mostly in Section 3). Hopefully to be addressed in the upcoming version or in the next one.

· Polynomial coefficients - What is the range of possible values?
…FB: It could be anything – but as we use the yang model to define the specifics, those are uint64.
· Points on the polynomial - what is the range of possible values of "x"?
…FB: Similar to the above – we’d do the math with uint64 values.
· "polynomial (POLY-1) of degree k" <==> k+1 nodes along the path?
…FB: Yes. A polynomial of degree k is defined by k+1 points.
· "The constant coefficient of POLY-1 is considered the SECRET." - what about the rest of the coefficients?
…FB: This is per SSSS – where the constant coefficient is the secret. See https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing#Shamir's_secret-sharing_scheme. We don’t do anything with the other coefficients.
· "Generates a random number (RND)" - what is the range of this value?
…FB: Again – the yang model answers those specific operational questions – unit64.
· "Each node calculates (Share(POLY-1) + Share(POLY-2)) and CML is updated with this sum." - Not detailed enough. This section is the heart of the algorithm for transit nodes.
…FB: What other details do you expect? The toy example takes you in detail through the math using an example.
· "Prime = 53" - the prime is only described in the example, and not described in the "Basic Idea" section. Is it different per path, what is the range of prime numbers?
…FB: Section 3.2 explains that “The solution leverages finite field arithmetic in a field of size "prime number".” – i.e. everything is computed “modulo prime”. We can emphasize this again in the later sections.
· "Enhanced Version" - the example is broken down into a basic version and enhanced version, but the actual algorithm does not include a basic version. I suggest to merge the two subsections of the example.
…FB: Section 3.1 discusses the basic idea – which corresponds to the basic example. We can probably make this more explicit – or use better titles for the subsections in section 3.3. There is no point in spelling out the “basic algorithm” because it isn’t operationally feasible, as discussed in section 3.1.
· Is OPOT optional, or part of the POT? It is not clear in the current document structure.
…FB: Current the doc says that “ "Ordered Proof of Transit (OPOT)" addresses the need of deployments, that require to verify the order in which nodes were traversed.” – this means that you don’t have to use OPOT unless you want to preserve ordering – which means it is optional.
· "a proper refresh rate for masks, at least as high as the one used for LPCs" - this implies that LPCs are refreshed - need to add text about refreshing LPCs / polynomials.
…FB: LPC refresh (along with other parameters) is part of the yang model. We can add a note about parameter refresh.
· Refreshing of masks / polynomials - there needs to be a discussion about how this can be done atomically (that is, without packets being inconsistently treated along the path slightly before/after the refresh operation).
…FB: Section 5.1 currently states:
All nodes maintain two POT-profiles (an even and an odd POT-profile): One POT-profile is currently active and in use; one profile is standby and about to get used.  A flag in the packet is indicating whether the odd or even POT-profile is to be used by a node.
What we can do is add a sentence that you’d of course refresh the inactive profile.
· Section 3.3 "Illustrative Example" - throughout the example we need to explicitly say "this is done by the controller" / "this is done by the verifier" / "this is done by the transit node". Not clear right now.
…FB: Thanks. We can add some verbiage around those.
Thanks again for the comments.
Cheers, Frank


Cheers,
Tal.