On 11/2/2016 4:50 PM, Joel M. Halpern wrote:
I would observe that what we are discussing is really SFC definition.
That's what you're discussing ;-), but we're just trying to devise a way
that a node can figure out where the next node in the service chain for
a particular packet is, how to get the packet there, and how to set up
the forwarding tables to achieve that.
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.
I don't see any difference between what you stated and what I stated.
However you say it, the SFF has to have forwarding state for whatever
SPI/SI values it might see in an NSH, and does not have to have
forwarding state for values that it will not see.
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.
Of course, that's what I said.
You seem to be trying hard to disagree with something, but I really
don't understand the content of the disagreement.
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.
I think we are having trouble following your argument here. Do you have
an example of how the mechanisms in the draft will produce incorrect
forwarding state?
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, we 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.
The use of undefined terms like this usually hides disagreements and
differing interpretations.
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.
Perhaps the WG did not think of the advantages of allowing a more
flexible scheme. Or to put it another way, allowing more flexibility
here doesn't really seem to damage the architecture in any way. If we
are wrong about that, perhaps someone will explain what goes wrong if
one interprets "SI=n" to mean "whatever SI is closest to n without being
greater than n".
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
