Hey Yuanlong, Thanks for your thoughtful comments. > I had a review of draft-ietf-bess-nsh-bgp-control-plane-03, thank you for this useful > document and hope it can progress quickly. > > In my opinion, this version still has some ambiguities which need to be cleaned up: > > 1. In Section 3.1.1, it firstly says:" The SFI Pool Identifier is encoded as an 8 octet > value as shown in Figure 4." However, it then says in the end of this subsection: > "The SFI Pool Identifier is a six octet, globally unique value encoded in network > byte order." These two sentences are confusing. Yes. Confusion. The 8 is supposed to refer to the whole extended community, while the 6 refers to the SPI Pool Identifier field. I will clean this up. > The 1st occurrence of SFI Pool Identifier shall be fully spelled out as "SFI Pool > Identifier extended community". Furthermore, "SPI Pool Identifier" in Figure 4 > seems to be "SFI Pool Identifier" as there is no definition for the former term in > the document. There are "SPI Pool Identifier" in other sections need to be > consistent as well, such as "SPI Pool Identifier" in the last paragraph of Section > 3.2.1.3. Oh, thanks! > 2. The definitions of "Service Function Type" in Figure 3 and Figure 9 are > different and ambiguous. Maybe it can be simply defined as "The identifier > for a type of service function". Hmmm, yes the text in 3.1 and 3.2.1.3 is all mixed up! We can't tell the difference between an RD and a pool identifier! > 3. "SFIR-RD List" in Figure 9 may be replaced with "SFIR-RD/SFI pool ID list", as > SFI pool ID is different from SFIR-RD and the list may consist of pure SFI pool > IDs. Yes, again. As noted, 3.2.1.3 is all mixed up. > One further note is, upon processing this variable, we need to distinguish > RD Type and SFI Pool Identifier Type, the IANA will need to take care not to allocate 0x80XX for SFIR-RD Type. Yes, it's all a mess! Looks like we introduced the pool identifier without enough thought :-( What I have done for the next version is make a second sub-TLV of the Hop TLV so that SFIs and SFI Pool Identifiers are kept separate. > Some minor editorial comments: > 4. "SFRIR-RD list" in Section 4.3 is misspelling. Yes > 5. s/a packets/a packet/ Yes > 6. s/ach subtended/as subtended/ Should be "each" > BTW, I think it is useful to support load balancing SFs across multiple SFFs as > described in Section 5.5 of RFC 7665, this will enable a more flexible deployment > of similar service functions in multiple sites across a network, such as in 5G
> transport. > In fact, Figure 11 in your draft already demonstrates that SF Type 41 has two > instances attached to SFF1 and SFF2 respectively, I think another example can > be added for load balancing across multiple SFFs, such as the following: > ------ > | SFIa | > |SFT=42| > ------ > ------ ------ | > | SFI | | SFI | --------- > |SFT=41| |SFT=42| | SFF5 | > ------ ------ ..|192.0.2.5|.. > \ / ..: --------- :.. > --------- .: :.--------- > ------ | SFF1 |--/ --------- | SFF3 | > -->|Class-|.......|192.0.2.1|........| SFF6 |....|192.0.2.3|--> > -->| ifier| --------- |192.0.2.6| :--------- > ------ --------- | > | ------ > ------ | SFI | > | SFIb | |SFT=43| > |SFT=42| ------ > ------ Yes, an example of load balancing is a god thing to include in the examples. Of course, load balancing in SFC is something that has to be done carefully to avoid packet ordering issues and protect stateful SF processing. That basically means that load balancing decisions need to be made with SFP and flow awareness. This is the point made by the examples in Section 8.9, and specifically the examples in 8.9.3 and 8.9.4. Can you have another look at those two examples and say whether they address the load balancing you were thinking about? Thanks, Adrian
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
