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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Nov 2016 16:53:33 -0000

Hi Joel,

Thanks for engaging in discussion and for supporting some of our ideas.

> Thank you authors.
>
> Reading through this, I have a few questions.
>
> 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.

> 2) The Path hop information (for a specific SPI, SI) allows for 
> carrying multiple SFTs.  It allows for multiple SFIs, which is 
> important and useful.  The multiple SFTs seems to be intended to 
> allow for the case where SFT A or B can be done at hops 9 or 8. 
> Which would be nice to allow.  But since the second SFF (at hop 8) 
> will not know whether the first SFF (at hop 9) chose A or B, I do 
> not see how it can correctly choose the opposite.
> 
> Are there additional assumptions made to enable this?  The text in 
> the example of section 8.4 seems to imply a different sort of use 
> case for this multiple SFT at a hop situation.  But I can not see 
> how that will be implemented interoperably.  Having control know 
> magically that the SFF can correctly select an SFT based on 
> unspecified information seems problematic.

If you build a chain that allows a choice of service functions at a particular
point, then (presumably) you are happy that this choice is made. 

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.

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

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.

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

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

Probably as an aside that belongs on the SFC list - using the protocol spec to
define the behavior of an SF that receives a message, processes the contents,
and then forwards it is suspect. It is using the protocol spec to build the
architecture. And, in practice, you could not enforce the 2119 language since a
downstream node will not know what value SI its upstream neighbor received.
Furthermore, since re-classifiers can be built in anywhere (including into an
SF) the decrement process can be over-ridden. Thus, the best you can achieve in
the NSH spec is "The SF SHOULD decrement the SI by one, but MAY utilize
re-classification to set the SI to any other value."

We also see some value in the "gaps" in a SFP to allow later insertion of more
SFs without renumbering (recall writing code in Fortran ;-). Not renumbering is
helpful for other SFPs that may branch to this one. Note that renumbering
changes the *start* of a chain because the SIs decrement.

Looking forward to discussing this further.

Regards,
Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Nov 2016 13:23:27 -0400

Some of this is going to get long for an email, but I don't see another 
choice.  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.

Having said all that, further comments in line.
Yours,
Joel

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

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

Part of my concern is that I could easily see situations in which one 
would want to use the BGP based control for establishing the SFP state, 
but not use BGP for the discovery.  In such a situation, one would not 
need registered types, except to support this capability and the "any 
entity of this type" option.  I worry that defining the SFTs is going to 
be much messier than it looks.

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

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 why we 
changed the term in the architecture from looping to spiraling.  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.

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.

>    inspection of the SFPR that was advertised.

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.

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

> re-classification and therefore it should be built to expect and SPI/SI on

I am guessing that most of us working on this assumed that "decrement" 
meant "decrease by 1".  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.

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.

> re-classification to set the SI to any other value."

I am not sure what youa re getting at here?

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Nov 2016 18:48:16 -0000

Hi again,

> choice.

I'll do some pruning.

> Also, a lot of this discussion belongs in the SFC working

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.
 
> > 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
> 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]
> > 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.
> >
> > jump into different chains (by changing SPI) so that choices become more
> > limited as the packet executes some functions and moves forward.
> >

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

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

> 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

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.

> what result it wants, so having more specific markers does not seem to

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.

> that changes the SPI / SI, not the SF.  SF are not permitted by the NSH

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

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

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

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 1 Nov 2016 18:34:54 -0400

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.

> instances. Oh, and per-interface label spaces?

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.

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

> SFP (i.e. by re-using an SI) you can save state (by not needing state for other

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.

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

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

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

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 2 Nov 2016 15:04:59 -0400

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Nov 2016 16:50:08 -0400

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

> there is no way to tell in advance just what a classifier may do when
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.

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

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

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 3 Nov 2016 09:54:04 -0400

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.

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

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

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

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 3 Nov 2016 15:27:29 +0000

Comments In-Line..

Jim Uttaro

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Thursday, November 03, 2016 9:54 AM
To: Joel M. Halpern <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [bess] FW: New Version Notification for draft-mackie-bess-nsh-bgp-control-plane-01.txt

[Jim U>] +1

_______________________________________________
BESS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bess