Trimming to those issues where I understand the disagreement enough to
comment. I would observe that what we are discussing is really SFC
definition. As such, I would like to ask that we at least copy the SFC
list (I have not done so as this is currently a BESS document.)
Yorus,
Joel
On 11/2/16 3:04 PM, Eric C Rosen wrote:
...
[Joel] The assumption in the SFC work is that the SF indicates the need
for reclassification 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
Actually, the draft does not say anything whatsoever about how the SF
talks to a co-resident classifier.
The draft is really concerned only with the fact that the SFF passes a
packet to a "local" service function, and ultimately gets the packet
back with an NSH that contains an SPI/SI. The question is -- what are
the possible SPI/SI values that the packet may have when the SFF gets it
back? In order to do "fast path" forwarding, the SFF needs to create
forwarding state for this set of SPI/SI's. If arbitrary
reclassification is possible, then any value of SPI/SI may be seen when
the packet comes back, and forwarding state needs to be created for
every valid SPI/SI value. It's good to have some indication in advance
about which SPI/SI values one is likely to see when the packet returns;
this allows one to maintain only the set of forwarding states that one
is likely to see. That's what the markers are for. Of course, this is
just an optimization meant to improve performance and scaling.
Mostly, I think this is backwards. The only valid values for SPI/SI
that can be given back to the SFF by the SF are those for which the SFF
has forwarding state. Any other values will result in the packet being
dropped. the SFF does not create this forwarding state from whole
cloth. It creates this state from the information provided by the
control mechanism (BGP, ForCES, NetConf, XMPP, ...) The SFF does not
care what the SF will hand it. Rather, it cares what it is supposed to
forward, and to where.
Even when arbitrary reclassification is possible, control mechanisms
need to be coordinated such that the markings the classifier wants to
produce correspond to forwarding state the SFF has.
Due to classifier configuration being complex, highly varied, and
outside the scope of SFC, we have not dealt with the quesiton of how
classifiers are configured. I presume similar reasons drive why this
BGP proposal does not do so either.
Your explanation does lead me to a guess as to what the special route
intreis in your draft are for. Are you trying to automate the process
of an SFF knowing that it is effectively the ingress for certain service
function paths? If so, I can understand the value in such information.
But I could not get there from what was in teh draft. Instead of
talking about lopping, jumping, and branching, the case that seems to
need special handling is "ingressing". This can be the result of
reclassification. Or it can be the result of an SF generating a new
packet and marking / classifying it.
Perhaps you are saying that it is impossible to create these markers, as
there is no way to tell in advance just what a classifier may do when
reclassifying.
I am saying that the set of markers in the BGP draft seem to cover cases
they don't need to cover, and not cover cases that they need to cover in
order to handle all of the provisioning of the SFF.
Or perhaps you're saying something else that you don't like these
markers, because they implicitly restrict the sort of reclassification
that can be done.
[Joel] If an SFF gets a packet with an SI it does not recognize, then it
is required to drop the packet.
The NSH draft only requires that the packet be dropped if its SPI/SI do
not "correspond" to a "valid" next hop. Note that the quoted terms do
not appear to be defined. This leaves a lot of leeway for interpretation.
Eric, on this you are stretching. If you really want us to add more
specific wording,w e can. But as a participant it has seemed to me that
the WG has understood these quite well, and that they are actually quite
clear and reasonable words. If you want them clarified, we can do that.
In contrast to your paragraph below, the WG has been clear that if an
SFF has state for SPI X, SI Y, that does not mean that the SFF has state
for any other SI value. While we allow for SFF that also look at other
things (for example load balancing), the SPI/SI match is exact.
For instance, given an SPI, SPI-X, whose elements are <<SF1, SI=10>,
<SF2, SI=5>>, one might decide that <SPI=SPI-X, SI=9> refers to SF2.
Why? Because 5 is the largest SI in SPI-X that is not larger than 9.
If done this way, decrementing the SI by 1 would always get you to the
next hop, even if successive SIs are not successive integers.
Now suppose that an SPI is modified in real time, by adding or deleting
elements. Since the SPIs are learned dynamically, when a change is
made, there will be a convergence period during which not everyone has
seen the change. I think you will see much more predictable behavior
during the convergence period if the SIs are not changed.
[Joel] 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.
I don't know whether this will be rare, but perhaps we don't have to
decide now how rare that will be. Also, I don't see any reason to
believe that replacing one chain with another is "cleaner and more
robust" than modifying a chain that is in use.
On this, reasoanble people may differ. Which is why I asked the SFC
working group how they understand the text. Given the confusion, it
clearly needs to be clarified.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
