Re: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt

["Adrian Farrel" <[e-mail]>]

Hi Joel,

Thanks for engaging in discussion and for supporting some of our ideas.

> 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 underlay is not partitioned into RTs (only the
> overlay) the transport mechanism does not indicate that.  And the 
> data packet does not carry an RT.

Good catch! 

We wrote (section 4.3)...
   The SPI is unique across all service function overlay networks
   supported by the underlay network.

This certainly makes life easier and comes at negligible cost because the SPI
space can either be in the control of a single controller, or can be partitioned
across multiple controllers.

However, this could be relaxed a little. In the data plane it is the combination
of tunnel/SPI that needs to be distinguishable (compare with how a L3VPN VRF is
identified). In the control plane, the RD/SPI needs to be globally unique. So
we'll update the text to make that clear.

> 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.

If you build a chain that allows a choice of service functions at a particular
point, then (presumably) you are happy that this choice is made. 

Consider for example that three "similar" implementations of a particular
function exist (say a firewall), but that they are given different SFT values
because although they are similar, they are not identical. Suppose further that
the controller is happy for either of the first two implementations to be used,
but not the third. In this case the chain would include a choice not just
between SFIs, but between SFIs of different types. The choice in this case would
be made based on local considerations and would be just like any other choice of
SFI for a given SI.

The use case you give is interesting, but different. You are basically saying
that (part of) the chain consists of a set of functions that must all be
implemented, but where the order is not important. That becomes complicated
because it is not a natural fit with the concept of a chain. To achieve it you
either need some state associated with the packets (like a recorded route -
possibly in metadata) or you have to perform branching (reclassification) to
jump into different chains (by changing SPI) so that choices become more limited
as the packet executes some functions and moves forward. 

Personally, if I had to deploy such function, I think I would opt for the
controller making the decision up front. But if I really wanted to delegate the
choice into the network, I would do it with branching.

> 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.

You are right that jumping, looping (let's keep that term because it is clear
that it means going back to a particular point), and branching are all similar.
That is, they all involve a different behavior from the normal
decrement-SI-and-get-on-with-it style of advancing down the chain. But,
obviously, they are subtly different and pose different problems.

You are also correct that *if* the processing is linear (i.e., no choice
involved) then looping can be encoded as a straight-forward sequence in the SFP,
jumping would be unnecessary because the jumped-over hops would not need to be
in the chain at all, and branching would really just be a shorthand. But we are
covering the case where the progress is conditional on something - call it
reclassification if you like, or consider is a policy-based decision. In these
cases, SFP must encode the choice.

Additionally, the looped-back-to SFF has to have forwarding state dependent on
the SI it is processing. By re-using the SI (i.e., looping back to exactly a
previous point on the SFP) we minimize that state. 

The location of the re-classification is a matter for debate. It is probably an
implementation issue, and I hope that the architecture will not unnecessarily
constrain the implementation. You have suggested here that "a classifier
co-resident with the SFF performs reclassification" and that certainly fits with
our approach although there are two forms of re-classification possible.
1. The re-classifier is programmed though the controller to be aware
   of potential changes (loop, jump, branch) and acts accordingly.
2. The re-classifier learns of options for re-classification through
   inspection of the SFPR that was advertised.
We support both.

On the other hand, draft-ietf-sfc-nsh (section 4) makes it clear that any of the
SFF, SF, and proxy may perform re-classification. In other words, the packet
received back from the SF by the SFF may already have been re-classified so that
the SPI/SI is different from what is "expected". We also support that mode of
operation.

> 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.

We may be getting confused between logical functions and implementation
components. If (as we do) we say that anything that modifies the SPI/SI other
than by  simple decrement of the SI is performing classification, then it is
evident that when an SF or SFF modifies the SPI/SI then it has a co-resident
classifier. That is, the SF or SFF has classifier function built in. Of course,
the classifier may also be a "bump in the virtual wire".

> 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.)

I think you may be using the Future Perfect form of the Present Tense, Joel. The
current version of the draft (-10) shows "decrement" and has no mention of
requiring a unitary decrement.
But, frankly, this is not relevant.
We absolutely support the possibility of decrementing the SI by just one.
But we also support re-classification that is co-resident in the SF and changes
the SI by a different amount.
We think that the SFF does not need to be able to tell whether an SF has invoked
re-classification and therefore it should be built to expect and SPI/SI on
returned packets.

Probably as an aside that belongs on the SFC list - using the protocol spec to
define the behavior of an SF that receives a message, processes the contents,
and then forwards it is suspect. It is using the protocol spec to build the
architecture. And, in practice, you could not enforce the 2119 language since a
downstream node will not know what value SI its upstream neighbor received.
Furthermore, since re-classifiers can be built in anywhere (including into an
SF) the decrement process can be over-ridden. Thus, the best you can achieve in
the NSH spec is "The SF SHOULD decrement the SI by one, but MAY utilize
re-classification to set the SI to any other value."

We also see some value in the "gaps" in a SFP to allow later insertion of more
SFs without renumbering (recall writing code in Fortran ;-). Not renumbering is
helpful for other SFPs that may branch to this one. Note that renumbering
changes the *start* of a chain because the SIs decrement.

Looking forward to discussing this further.

Regards,
Adrian