Thank you authors. Reading through this, I have a few questions.
1) I like the idea of being able to support multiple SFC overlays. I can see circumstances when this would be valuable. However, I can not see how it works. (I presume I am missing something obvious.) If the SPI are unique, then sure, it works, but they are not really separate overlays. They are merely administrative slices of the same overlay. The text in section 5 bullet 1 starts with observing that the path state is RT specific. That part is fine. It then asserts that the SFF that receives a packet can somehow tell which RT the packet goes with. How? Since the unerlay is not partitioned into RTs (only the overlay) the transport mechanism does not indicate that. And the data packet does not carry an RT.
2) The Path hop information (for a specific SPI, SI) allows for carrying multiple SFTs. It allows for multiple SFIs, which is important and useful. The multiple SFTs seems to be intended to allow for the case where SFT A or B can be done at hops 9 or 8. Which would be nice to allow. But since the second SFF (at hop 8) will not know whether the first SFF (at hop 9) chose A or B, I do not see how it can correctly choose the opposite. Are there additional assumptions made to enable this? The text in the example of section 8.4 seems to imply a different sort of use case for this multiple SFT at a hop situation. But I can not see how that will be implemented interoperably. Having control know magically that the SFF can correctly select an SFT based on unspecified information seems problematic.
3) I am a bit confused by section 6.1 on looping, jumping, and branching. Looping (more accurately spiraling) should not require any special handling. Simply put the same SFI information at two different SIs in the same SPI, and spiraling occurs. No special handling needed. Jumping seems to be a special case of reclassificaiton. So I would prefer to see it simply handled by the same mechanism (why have two mechanisms that can do the same job.) Branching seems not to handle the most common case where we need to branch. That is the situation where packets in a given SFP, as a result of processing by an SF, will usually continue down the SFP, but under some circumstances (and there are a range of them) will need to take a different path. The Assumption in the SFC work is that the SF indicates the need for reclassificiation by adjusting the flags in the NSH header, and that a classifier co-resident with the SFF then performs reclassification. The mechanism you describe in section 6.1 does not seem to support that. 3') Also, that is why we do not usually describe the classifier as a service function. Classifiers (including in path reclassifiers) are permitted to overwrite the SFP ID. Service functions are not permitted to do that.
4) I notice that the examples still show the SI being adjusted by more than 1. The NSH draft has been clarified, at the request of the AD and WG, to make it clear that the SI is decremented by 1 at each hop. (If that were not the case, we would need additional information in the control as to how much to decrement the SI. Which would be a complication with no value.)
Yours, Joel On 10/30/16 12:19 PM, Adrian Farrel wrote:
Hi Bess WG, We made some updates to this document to tidy it and to get the terminology in line with RFC 7665. Adrian
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
