[Joel] 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.)
I think it's pretty well understood how to use the mechanism of RTs and
RDs to install routes for overlapping address spaces, as long as the
addresses are unique in the relevant context. Reusing an SPI value in a
different overlay is no different than reusing an IP address in a
different VPN.
[Joel] 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.
??? When multiple overlays exist over a common infrastructure, it's
quite common to have a separate set of tunnels for each overlay, and to
have a control plane that associates each tunnel with the proper overlay.
[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.
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.
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.
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.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
