I had thought an earlier discussion in the SFC WG had clarified that the
decrement was by 1. Since that did not happen, I have now forwarded
that question to them.
Other comments in line.
Yours,
Joel
PS: Given the announcement, I should clarify that what I am writing here
is my personal opinion. Even when I comment on WG action, that is based
on my prior participation, not a current conclusion as co-chair.
PPS: One of the reasons I would like to see this discussed more on the
SFC list is that I would prefer that other SFC members take the lead on
these issues now that I am a co-chair.
On 11/1/16 2:48 PM, Adrian Farrel wrote:
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.
Actually, I have seen lots of complaints obout the difficulty of using
per-interface MPLS labels. More importantly, when this was discussed on
the SFC list, folks agreed that per-interface behavior was undesirable,
so we avoided it.
...
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.
That is the assumption the SFC group made during the work on the NSH
document. RFC 7665 does not mandate that, and probably would have been
overly-specifying the solution if it had.
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).
We specifically did not want to have re-entry with the same SPI and SI.
Section 5.4 of RFC 7665 stated the requirement, but not the solution.
Simply using the path, with decrementing SIs, and recurrance of the same
SFF (with or without the same SF) meets this.
We do understand that reclassification can produce loops.
Personally, the "state savings" you are claiming seems very small. And
means that observing the forwarding and diagnosing problems will be
harder since the same SPI with the same SI may lead to different
behaviors. Ouch.
...
And, metadata is exactly how we observed that an infinite loop would be avoided.
Given that SFF are not required to handle any metadata, I do not see how
metadata can prevent infinite loops with the proposed handling. It
seems a significant risk for a tiny state savings.
...
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 problem is that there is no means for the SFF to know from what is
being circulated, hwo to tell when to invoke the special processing and
when not to invoke the special processing.
...
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.
As noted above, I had thought we had agreed to make such a
clarification. I was mistaken. The fact that there waas confusion
means we do need to clarify the text. The SFC WG will have to decide
what it wants regarding the decrement behavior.
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").
I do not see why the ability to branch to a chain adds any complexity.
In general, what we have observed is that most reu-use cases are most
cleanly handled (in terms of human planning and automatic operation) if
the thing branched to is a free-standing chain, not part of something
else. As such, the initial SI will be 255. Thus, it has nothing to do
with the gaps or changes when things are inserted. Again, the state
cost of doing this is small, and the management benefit is high.
I will grant that neither the architecture nor the NSH document prohibit
reclassifying into the middle of another service chain. But I do not
see any reason to optimize for such a case.
Cheers,
Adrian
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
