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

["Joel M. Halpern" <[e-mail]>]

Some of this is going to get long for an email, but I don't see another 
choice.  Also, a lot of this discussion belongs in the SFC working 
group.  We need to figure out how to handle collaboration between IDR 
and SFC for this.

Having said all that, further comments in line.
Yours,
Joel

On 11/1/16 12:53 PM, Adrian Farrel wrote:
> 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.

I had missed the sentence in 4.3 where you said that the SPI are 
disjoint.  If they are disjoint, it is not really separate overlays at 
all.  The RT allows you to reduce stored state, but they are really all 
part of the same overlay (as they have to coordinate.)

If we want to require that SFF are sensitive to the transport 
identification on which packets arrive (which may be MAC addresses, MPLS 
labels, ...) then yes, we could divide by using separate transport 
identifiers for an SFF which is in multiple overlays.  Seems very 
fragile.  I do hope there is a robust way to make it work.

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

If that is the intent of the alternative SFTs, I think the text needs to 
make taht much clearer.  I can see wanting that, given the need to use 
registered SFTs in order to advertise service function availability in 
the control protocol.

Part of my concern is that I could easily see situations in which one 
would want to use the BGP based control for establishing the SFP state, 
but not use BGP for the discovery.  In such a situation, one would not 
need registered types, except to support this capability and the "any 
entity of this type" option.  I worry that defining the SFTs is going to 
be much messier than it looks.

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

SFF forwarding state is explicitly required by the NSH draft to be SI 
dependent.  If an SFF gets a packet with an SI it does not recognize, 
then it is required to drop the packet.  So this SI state is needed.

Also, returning a packet to an earlier SFF, with the SI restored to what 
it was the first time, is a recipe for an infinite loop.  That is why we 
changed the term in the architecture from looping to spiraling.  Now, it 
may be that at several revisted SFF the selection of SF and next SFF are 
the same for the two indices.  But since thigns continue to get 
decremented, we can always terminate.  This is in fact why we look at 
spiraling as a normal part of the chain and not as reclassification. 
Reclassificiaton requires care, as it can easily produce infinite loops.

Having said all that, given that the function to be invoked for your 
special path markers is undefined, I do not see how it is helpful to 
include them in the chain.  The SFF has no way, from that information, 
to know what it is supposed to do.  And having the markers does not help 
it perform better reclassification.  And further, the classifier knows 
what result it wants, so having more specific markers does not seem to 
help anything.

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

Classifiers are described in teh architecture as a separate entity from 
SF.  We found this to be really helpful. This does allow one to have an 
SF with a co-located classifier.  But it is conceptually the classifier 
that changes the SPI / SI, not the SF.  SF are not permitted by the NSH 
draft to adjust the SPI.

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

Agreed, the classifer can be a bump in teh wire, it can be co-resident 
with the SFF, or it can be coresident with the SF.  It is a logical 
function to address specific needs.

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

I am guessing that most of us working on this assumed that "decrement" 
meant "decrease by 1".  The problem is that if the decrease can be 
arbitrary then we need to include in the provisioning model the amount 
to decrease.  We could do that.  And add text making clear that the 
decrement is variable.  Or we could add text making clear what we have 
assumed, that it is unitary.  The fact that you read it as allowing 
larger decrements means that we need to be clearer one way or the other.

Personally, I consider modifying an in-place chain rare enough that 
needing to instead create a new chain, create the state for it, and then 
change the classification rules to use the new chain to be a cleaner and 
more robust way to get there.  But that is just my take.

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

I am not sure what youa re getting at here?

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