Subject: [sfc] Comments on draft-penno-sfc-packet-02

From: Dave Dolson <[email-masked]>
Date: Wed, 2 Dec 2015 21:47:02 +0000

Referring to https://tools.ietf.org/html/draft-penno-sfc-packet-02
(I have also sent the authors some editorial comments.)

There is a simplification to be done for section 5.3.1.
Instead of carrying 4 pieces of meta-data, it can be reduced to 2 pieces that fit in a 32-bit value, using 24 bits for symmetric path ID and 8 bits for an reverse_service_offset.
This is because symmetric_starting_index, starting_index and symmetric_number_hops can be reduced to one 8-bit value.

Derivation:
The formula for reverse service index is:

reverse_service_index = symmetric_starting_index - remaining_hops - 1
where (the current draft has an typo):
remaining_hops = symmetric_number_hops - (starting_index - current_index)

Performing the substitutions,
reverse_service_index = symmetric_starting_index - (symmetric_number_hops - (starting_index - current_index)) - 1
= symmetric_starting_index - symmetric_number_hops + starting_index - current_index - 1

Identify a constant in the first 3 terms:
reverse_service_offset = (symmetric_starting_index + starting_index - symmetric_number_hops)
so that:
reverse_service_index = reverse_service_offset - current_index - 1

Only this 8-bit reverse_service_offset needs to be carried in the metadata vs. the three 8-bit values.

Furthermore, the same offset applies to both directions of the symmetric path, so the reversed packet can use the same value as the forward packet.

>From the example in the draft:
   o  symmetric starting index = 253 (8 bits)
   o  symmetric number of hops = 3 (8 bits)
   o  starting index = 255 (8 bits)

reverse_service_offset = (symmetric_starting_index + starting_index - symmetric_number_hops)
= 253 - 3 + 255
Using 8-bit math:
reverse_service_offset = 0xfd - 0x03 + 0xff = 0xf9

The packet reversal formula for the example forward-path is:
revserse_service_index = 0xf9 - current_index - 1

If SF1 wants to reverse a packet,
reverse_service_index = 0xf9 - 252 - 1= 0xf9 - 0xfc - 1 = 0xfc = 252

If SF2 wants to reverse a packet,
reverse_service_index = 0xf9 - 253 -1 = 0xf9 - 0xfd - 1= 0xfb = 251

If SF3 wants to reverse a packet,
reverse_service_index = 0xf9 - 254 - 1= 0xf9 - 0xfe - 1= 0xfa = 250

It's a bit counter-intuitive that the reverse-path service index can be calculated from a constant that works for the entire path, and for both directions, but there you have it.

To summarize,
- the classifier computes the reverse_service_offset for a path, and includes it in the packet meta-data as an 8-bit value:
    reverse_service_offset = (symmetric_starting_index + starting_index - symmetric_number_hops) mod 256
- any SF in the path can send a packet to where it came from by using the symmetric_path_id and computing the service index as:
   reverse_service_index = (reverse_service_offset - current_index - 1) mod 256
- the reverse_service_offset is the same for both directions

Note that the symmetric_path_id and reverse_service_offset do not have to be carried in metadata. They could be configured per path in the SF.

Even so, I still like solutions in 5.4 better.
BTW, 5.4.1 and 5.4.2 can be formulated as a special case of the above with a hard-coded reverse_service_offset=1.

David Dolson
Senior Software Architect, Sandvine Inc.