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

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

Hi again,

> Some of this is going to get long for an email, but I don't see another
> choice.

I'll do some pruning.

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

The cross between IDR and BESS has long since been worked out and I see no
reason to vary it.

The discussion with SFC is, of course important, and *if* we were changing what
the SFC WG had done we might be more interactive. At this point, we have flagged
the I-D to SFC and invited them all to the party.
 
> >> 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.

This fragility has been used in many places without a problem for a while.
I would point at TCP port numbers. I would note the use labels to identify VPN
instances. Oh, and per-interface label spaces?
It works.

> >> 2)
[snip]
> > 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.

OK. Will look at improving clarity for that. Thanks for flagging it.
 
[snip]

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

I think you are making an architectural assumption that a packet received "from
the wire" will be treated exactly the same as a packet received from a local SF.
I can see why you might want to have that (and why it forces the SF to decrement
the SI) but I don't see it in RFC 7665.

Anyway (!) my point was not that no SI state is need, but that by re-entering an
SFP (i.e. by re-using an SI) you can save state (by not needing state for other
SIs).

> 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 true.
But note that re-classification is a recipe for an infinite loop and there is no
protection against that.
We noted the risk at the end of section 6.

> That is why we
> changed the term in the architecture from looping to spiraling. 

Ah, this is why you have been using this term.
But (and just for the record) neither RFC 7655 not draft-ietf-sfc-nsh-10 use the
term spiral or spiraling (or spiralling).
Actually, since there are only five active SFC WG drafts and just two RFCs it
was quick to check that none of the WG documents uses this term.

So I looked in the SFC mailing list and there it is: ticket #5 for the NSH
draft. The ticket was closed as:
| Reply: This was answered on the list: http://www.ietf.org/mail-
| archive/web/sfc/current/msg03188.html and therefore no changes are needed.
| Given that, this item can be marked as resolved.
In the referenced mail you wrote:
|| Thus, I would not expect this document to discuss how service functions
themselves
|| handle revisiting. But metadata clearly allows for a range of behaviors that
will work. 
|| And the path index handles the SFF needs relative to spirals, which is what
we need
|| to handle. 

And, metadata is exactly how we observed that an infinite loop would be avoided.

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

Agreed.
And classification programming, and chain construction, require care or packets
can get sent to the wrong places and have the wrong functions applied to them.

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

I understand half of your point, but disagree. A classifier in your scheme must
be fully programmed, and when new non-simple actions are required it must be
reprogrammed.
In our scheme a simple policy may be installed at the classifier and the
definition of the chain describes the available options.
Furthermore, the choice may be as simple as "load balancing" in which case
calling the function "re-classification" may be over egging.
Lastly, a common "final step" in a chain may be to splice it into another chain.
This saves a lot of programming and allows for management of common chain
segments. That operation requires a specific hop description in the first chain
- effectively a branch instruction.

The bit I don't understand is where you say "the function to be invoked for your
special path markers is undefined," so I can't answer it.

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

I really struggle to see the difference between "a classification function
co-resident with a service function" (RFC 7665 section 4.8 - where it is noted
as typical for re-classification) and a service function that can do
reclassification. Of course, they are separate logical functions and how you
implement your software is up to you, but from the outside the difference is not
apparent: as far as the SFF is concerned, it gave a packet to an SF and the
packet came back having been re-classified.

Aren't we on the head of a pin here especially when looking at section 4 of the
NSH draft as I noted here...

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

We are agreed.
It is a logical function, and thus may be folded in with other logical functions
to make single protocol elements.

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

Guess away!

Actually, I am grumpy.
You said above
"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."
Not only has that update not been made, but you just sent mail to the SFC list
to ask them what they think "decrement" means.
If the WG has already agreed this you surely don't need to ask again.
I do see the question raised by Alia in her review on October 5th, but I see no
follow-up to this point on the list.
So, no, there is no agreement about the SF decrementing by one at each hop.

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

Agreed. Clarity is king.
 
> 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.

It is messy if that chain is used by other chains (as "branch to").

Cheers,
Adrian