Subject: [sfc] draft-quinn-sfc-nsh-05, optional headers

From: Nicolas BOUTHORS <[email-masked]>
Date: Wed, 4 Feb 2015 17:06:03 +0000

It is great to have the possibility to add optional headers in NSH. However, the mechanism proposed suppose that a specific header type (the  MD Type=0x2) is used in the base header when optional metadata are used.

As a result:

1.     The base header type 0x1 cannot be used with optional headers. Which my make sense for performance point of view

2.     Nor when using header MD type x2  can the "mandatory context headers" be present.

Case 2 can be worked around by defining an optional header that represents the mandatory context header. Which is awkward as SFFs will have to decode the same information in two different ways. Not particularly beautiful !

Why not have a flag (F2)stating that no optional Metadata are present and another one (F1) stating that (what is now called) the mandatory context header is present or not.

We can then specify that the combinations
F2=False implies F1=True
F1=True, F2=True is allowed
F1= False, F2=True is allowed

It seems cleaner. When present, the "mandatory context headers" would always be at the same place in the packet.

Nicolas

This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified.

Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous avez re?u ce message par erreur, merci d'en informer imm?diatement son ?metteur par courrier ?lectronique et d'effacer ce message de votre syst?me. Dans cette hypoth?se, vous n'?tes pas autoris? ? utiliser, copier ce message et/ou en divulguer le contenu ? un tiers. Tout message ?lectronique est susceptible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? au titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Feb 2015 11:38:43 -0500

The metadata is (generally) for the aService Functions, not for the SFF. 
  So the quesiton of programming the SFF to process the information 
seems not especially major.

More significantly, given that the 16 byte type 1 field may carry 
different things in different cases, the SFs will have to be flexible 
about processing the information anyway.  So anything which can handle 
the type 2 information can be reasoanably expected to handle the same 
kinds of information from TLVs (whether one TLV or many).

It therefore seems cleaner to me to recognize that type 1 and type 2 are 
different ways of carrying information, and just use the mechanism each 
supports.

Yours,
Joel

On 2/4/15 12:06 PM, Nicolas BOUTHORS wrote:
> It is great to have the possibility to add optional headers in NSH. However, the mechanism proposed suppose that a specific header type (the  MD Type=0x2)is used in the base header when optional metadata are used.
>
>
>
> As a result:
>
> 1.The base header type 0x1 cannot be used with optional headers. Which
> my make sense for performance point of view
>
> 2.Nor when using header MD type x2  can the “mandatory context headers”
> be present.
>
> Case 2 can be worked around by defining an optional header that
> represents the mandatory context header. Which is awkward as SFFs will
> have to decode the same information in two different ways. Not
> particularly beautiful !
>
> Why not have a flag (F2)stating that no optional Metadata are present
> and another one (F1) stating that (what is now called) the mandatory
> context header is present or not.
>
> It seems cleaner. When present, the “mandatory context headers” would
> always be at the same place in the packet.
>
> Nicolas
>
> This message and any attachments (the "message") are confidential,
> intended solely for the addressees. If you are not the intended
> recipient, please notify the sender immediately by e-mail and delete
> this message from your system. In this case, you are not authorized to
> use, copy this message and/or disclose the content to any other person.
> E-mails are susceptible to alteration. Neither Qosmos nor any of its
> subsidiaries or affiliates shall be liable for the message if altered,
> changed or falsified.
>
> Ce message et toutes ses pièces jointes (ci-après le "message")sont
> confidentiels et établis à l'intention exclusive de ses destinataires.
> Si vous avez reçu ce message par erreur, merci d’en informer
> immédiatement son émetteur par courrier électronique et d’effacer ce
> message de votre système. Dans cette hypothèse, vous n’êtes pas autorisé
> à utiliser, copier ce message et/ou en divulguer le contenu à un tiers.
> Tout message électronique est susceptible d'altération. Qosmos et ses
> filiales déclinent toute responsabilité au titre de ce message s'il a
> été altéré, déformé ou falsifié.
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Feb 2015 16:57:18 +0000

Joel,

I think you are reinforcing a key assumption here -- if the SFF needs the information to do its job, then that information should be neither in Type 1 nor Type 2 metadata.    As an example...  depending on how our continuing discussion on RSP ID goes (i.e, to enable both centralized concrete RSP determination and distributed hop-by-hop "trail-blazed" RSP determination), we may want to "promote" RSP ID from metadata to the standard header.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Thursday, February 5, 2015 11:39 AM
To: Nicolas BOUTHORS; [email-masked]'
Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers

The metadata is (generally) for the aService Functions, not for the SFF. 
  So the quesiton of programming the SFF to process the information seems not especially major.

More significantly, given that the 16 byte type 1 field may carry different things in different cases, the SFs will have to be flexible about processing the information anyway.  So anything which can handle the type 2 information can be reasoanably expected to handle the same kinds of information from TLVs (whether one TLV or many).

It therefore seems cleaner to me to recognize that type 1 and type 2 are different ways of carrying information, and just use the mechanism each supports.

Yours,
Joel

On 2/4/15 12:06 PM, Nicolas BOUTHORS wrote:
> 2.Nor when using header MD type x2  can the "mandatory context headers"
> be present.
>
> It seems cleaner. When present, the "mandatory context headers" would 
> Si vous avez reçu ce message par erreur, merci d'en informer 
> immédiatement son émetteur par courrier électronique et d'effacer ce 
> message de votre système. Dans cette hypothèse, vous n'êtes pas 
> autorisé à utiliser, copier ce message et/ou en divulguer le contenu à un tiers.

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Fri, 6 Feb 2015 00:24:57 +0000

I think there¹s a disconnection here (could be me) between the idea of an
abstract and specific path.

I thought it was pretty clear (and there was significant talk about it
here on the list) that you can't mandate a specific model of function
elasticity - we couldn¹t declare load balancing devices or functions
³dead² but instead assumed that elasticity could be done locally as a SF,
as part of a composite function where the load balancer exists as part of
the logical function being rendered or centrally/statically.  We had
similar dialogues about the need to remain abstract around HA techniques
as well. 

These things make AN individual path, which represents a chain that fits a
specific policy ruleset Š variable Š and we didn¹t want to unnecessarily
define multiple discrete chains to cover this sort of function variance
(which can become quite large, if for example the function X at site Y is
actually 1000 parallel instances to accommodate load, with HA add a
multiplier, per function more multipliers Šfor a single path that at the
abstract level, traversed the same sites Šboom).

These dialogues are captured in the architecture document.

So, when I read the NSH draft, I interpreted the treatment of the SPI and
the Resolved Path as very compatible with that abstraction/concept. It
makes multiple deployment contexts understandable and possible without
overly defining the header with potentially useless fields for every
iterable case. (Editorial - Kind of an art form that we should celebrate,
IMO, if people are going about designing protocols.)

For example, the SFF can be seeded with one and only one NH for the SI/SPI
match - thus the path is resolved and the SI/SPI path IS the rendered
path.  The ³directed² graph that some wanted (where each individual
element in a locally elastic pool is individually addressable and set at
classification) is really a derivative of the same case.

If there is more than one NH seeded for the SI/SPI, then the SFF either
will treat the forwarding as ECMP (e.g. stateless to an anycast pool -
SI/SPI IS the rendered path), or have a local policy to perform an
explicit mapping.  The SFF may also be just handing the packet w/NSH
header off to a local integrated function (like a load balancer) or an
attached composite function that is handling an explicit mapping to
function instances it fronts (and managing same somewhat obliquely to the
SFF and the path itself).

These new contexts don¹t NEED and shouldn¹t GET a separate field in the
general header.  IF, for example, the resolution/mapping of either the
local SFF policy (or the oblique function) is a policy keyed to
classification info like flowID, tenantID, sessionID, something
proprietary - well, you¹ve just redefined the need for metadata (one of
our goals was to be able to preserve classifier info in metadata to avoid
excessive classification), which we all agreed to already - and we know
where to find such a key so there¹s no need to move it.  (Editorial - Note
also the potential for variance of the key source/value across
implementations.)

You shouldn't NEED an explicit RSP ID in the fixed header.  That seems to
work back against the original implicit design goal of the header.

I dunno, if it¹s just me, I haven¹t done protocol design since college Š
maybe I¹m rusty or I need something stronger to drink.

Cheers.

On 2/5/15, 11:57 AM, "Ron Parker" <[email-masked]> wrote:

>Joel,
>
>I think you are reinforcing a key assumption here -- if the SFF needs the
>information to do its job, then that information should be neither in
>Type 1 nor Type 2 metadata.    As an example...  depending on how our
>continuing discussion on RSP ID goes (i.e, to enable both centralized
>concrete RSP determination and distributed hop-by-hop "trail-blazed" RSP
>determination), we may want to "promote" RSP ID from metadata to the
>standard header.
>
>   Ron
>
>
>> It is great to have the possibility to add optional headers in NSH.
>>However, the mechanism proposed suppose that a specific header type (the
>> MD Type=0x2)is used in the base header when optional metadata are used.
>>
>>
>>
>> As a result:
>>

---

From: Wenzhe Zhou <[email-masked]>
Date: Fri, 6 Feb 2015 15:28:18 +0000

Ken,

In your words, mandatory context headers should be removed from NSH.

Wenzhe

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Ken Gray (kegray)
Sent: Thursday, February 05, 2015 4:25 PM
To: Ron Parker; Joel M. Halpern; Nicolas BOUTHORS; [email-masked]'
Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers

Cheers.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Feb 2015 10:43:50 -0500

It seems to me that another way of asking that question (which avoids 
putting words in anyone's mouth) is to ask which header type should be 
mandatory to implement (MTI).

It seems clear to me that one of the types needs to be MTI in order to 
enable data plane interoperability, which is our goal.

Yours,
Joel

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Fri, 6 Feb 2015 16:57:01 +0000

In my words, I am not suggesting changing the draft at all.  I think it’s
sufficient. 

My opinion, is that the suggested changes in this thread show a
fundamental failure to grasp the concepts we hashed out in the
architecture (which I attempted to clarify).  In my opinion, to use an
unfortunate colloquialism - this horse is dead, we should stop beating it.

---

From: Ron Parker <[email-masked]>
Date: Fri, 6 Feb 2015 18:36:50 +0000

Ken,

Certainly, there is a concept that a nice simple deployment of SFC is to have 1 logical instance of each service function visible at the SFC layer.   How each of those instances scales is its own business.   And, certainly, the architecture supports that.   

But, does that adequately satisfy all possible uses cases and deployment scenarios we can construct for SFC?    Here are some use cases that suggest the above concept is necessary but not sufficient:

What if the real-world scale of one of these internally scalable instances is still insufficient?  

What if a higher level of redundancy is desired by deploying more than one of those internally scalable instances?   More than 2 of them?    

What if the SFC is extended across the MAN and WAN (and to avoid argument, let's say we are still in the same administrative domain)?   What if we want to apply location awareness to instance selection in order to optimize the overall behavior?

What if we want to support other instance selection criteria, like gold customers get on the higher performance RSP for a particular functional chain but bronze customers the lower performance RSP for that same functional chain?

And, although it is not a functional use case in the same manner as above, what if some network designers determine it is cheaper and simpler to deploy SFC using service function instances that are simpler and don't have inbuilt horizontal scale?   More along the lines of the "fit VNF" approach (attribution to Contextream).

The group's proposed solution should be measured against the use cases and and deployment scenarios we feel need to be addressed, and this is probably the main difference in viewpoint, here.    To follow on to Ken's colloquialism, my opinion is that the horse is not dead and that the different viewpoints do not reflect a fundamental inability to grasp the concepts.

Thanks.

   Ron

-----Original Message-----
From: Ken Gray (kegray) [mailto:[email-masked]] 
Sent: Friday, February 6, 2015 11:57 AM
To: Wenzhe Zhou; Ron Parker; Joel M. Halpern; Nicolas BOUTHORS; [email-masked]'
Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers

In my words, I am not suggesting changing the draft at all.  I think it’s sufficient. 

My opinion, is that the suggested changes in this thread show a fundamental failure to grasp the concepts we hashed out in the architecture (which I attempted to clarify).  In my opinion, to use an unfortunate colloquialism - this horse is dead, we should stop beating it.

On 2/6/15, 10:28 AM, "Wenzhe Zhou" <[email-masked]> wrote:

>I think there¹s a disconnection here (could be me) between the idea of 
>an abstract and specific path.
>
>³dead² but instead assumed that elasticity could be done locally as a 
>SF, as part of a composite function where the load balancer exists as 
>part of the logical function being rendered or centrally/statically.  
>We had similar dialogues about the need to remain abstract around HA 
>techniques as well.
>
>These things make AN individual path, which represents a chain that 
>fits a specific policy ruleset Š variable Š and we didn¹t want to 
>unnecessarily define multiple discrete chains to cover this sort of 
>function variance (which can become quite large, if for example the 
>function X at site Y is actually 1000 parallel instances to accommodate 
>load, with HA add a multiplier, per function more multipliers Šfor a 
>single path that at the abstract level, traversed the same sites Šboom).
>
>So, when I read the NSH draft, I interpreted the treatment of the SPI 
>and the Resolved Path as very compatible with that abstraction/concept. 
>It makes multiple deployment contexts understandable and possible 
>without overly defining the header with potentially useless fields for 
>every iterable case. (Editorial - Kind of an art form that we should 
>celebrate, IMO, if people are going about designing protocols.)
>
>For example, the SFF can be seeded with one and only one NH for the 
>SI/SPI match - thus the path is resolved and the SI/SPI path IS the 
>rendered path.  The ³directed² graph that some wanted (where each 
>individual element in a locally elastic pool is individually 
>addressable and set at
>function instances it fronts (and managing same somewhat obliquely to 
>the SFF and the path itself).
>
>our goals was to be able to preserve classifier info in metadata to 
>avoid excessive classification), which we all agreed to already - and 
>we know where to find such a key so there¹s no need to move it.  
>(Editorial - Note also the potential for variance of the key 
>source/value across
>implementations.)
>
>You shouldn't NEED an explicit RSP ID in the fixed header.  That seems 
>to work back against the original implicit design goal of the header.
>
>I dunno, if it¹s just me, I haven¹t done protocol design since college 
>Š maybe I¹m rusty or I need something stronger to drink.
>  
>
>Cheers.
>
>
>>I think you are reinforcing a key assumption here -- if the SFF needs 
>>the information to do its job, then that information should be neither in
>>concrete RSP determination and distributed hop-by-hop "trail-blazed" 
>>RSP determination), we may want to "promote" RSP ID from metadata to 
>>the standard header.
>>
>>   Ron
>>
>>
>>It therefore seems cleaner to me to recognize that type 1 and type 2 
>>are different ways of carrying information, and just use the mechanism 
>>each supports.
>>
>>Yours,
>>Joel
>>
>>>However, the mechanism proposed suppose that a specific header type 
>>>(the  MD Type=0x2)is used in the base header when optional metadata are used.
>>>
>>>
>>>
>>> As a result:
>>>
>>> 1.The base header type 0x1 cannot be used with optional headers. 
>>> Which my make sense for performance point of view
>>>
>>> represents the mandatory context header. Which is awkward as SFFs 
>>> will have to decode the same information in two different ways. Not 
>>> particularly beautiful !
>>>
>>> Why not have a flag (F2)stating that no optional Metadata are 
>>> present and another one (F1) stating that (what is now called) the 
>>> mandatory context header is present or not.
>>>
>>> It seems cleaner. When present, the "mandatory context headers" 
>>> would always be at the same place in the packet.
>>>
>>> Nicolas
>>>
>>> this message from your system. In this case, you are not authorized 
>>> to use, copy this message and/or disclose the content to any other person.
>>> subsidiaries or affiliates shall be liable for the message if 
>>> altered, changed or falsified.
>>>
>>> Tout message électronique est susceptible d'altération. Qosmos et 
>>>ses  filiales déclinent toute responsabilité au titre de ce message 
>>>s'il a  été altéré, déformé ou falsifié.
>>>
>>>
>>>

---

From: Sumandra Majee <[email-masked]>
Date: Fri, 6 Feb 2015 23:49:05 +0000

Ron,

If I read the SCH draft again, I believe it is proposing a few different
standard metadata, am I correct?

It is possible to make a RSPID like metadata within NSH and effectively
get similar functionality.

>>And, although it is not a functional use case in the same manner as
>>above, what if some network designers determine it is cheaper and
>>simpler to deploy SFC using service function >>instances that are
>>simpler and don't have inbuilt horizontal scale?   More along the lines
>>of the "fit VNF" approach (attribution to Contextream).

That is a fine goal and I do support that viewpoint, <OFFTOPIC>except I
will not attribute that to Contextream, it is a fairly old problem. VNF
simply added more dimensions and there are multiple ways to solve that
problem. <\OFFTOPIC>.

However does NSH as a protocol hinder that, is there something
fundamentally missing that requires a complete different approach? I don’t
see that. Yes there could be requirement to carry preselected instance of
a given SFC(x) and protocol should be able to convey that. I could also
consider flattening the graph and consider pathID to be absolute.

Having ID doesn’t get rid of states because ultimately it is targeted to
an IP, MAC etc. So it is more than likely to have a mapping of RSP_ID to
REALITY. Now if the reality is elastic then the hashing scheme is likely
to be some kind of consistent hashing scheme. If I add failover to that
equation the actual implementation may not be that simple. I would be very
interested to learn about the scaling issues from you and all. I am in the
middle of some horizontal scaling issue myself and love to get your
opinion on that.

Regards.

On 2/6/15, 10:36 AM, "Ron Parker" <[email-masked]> wrote:

>Ken,
>
>Certainly, there is a concept that a nice simple deployment of SFC is to
>have 1 logical instance of each service function visible at the SFC
>layer.   How each of those instances scales is its own business.   And,
>certainly, the architecture supports that.
>
>But, does that adequately satisfy all possible uses cases and deployment
>scenarios we can construct for SFC?    Here are some use cases that
>suggest the above concept is necessary but not sufficient:
>
>What if a higher level of redundancy is desired by deploying more than
>one of those internally scalable instances?   More than 2 of them?
>
>What if the SFC is extended across the MAN and WAN (and to avoid
>argument, let's say we are still in the same administrative domain)?
>What if we want to apply location awareness to instance selection in
>order to optimize the overall behavior?
>
>What if we want to support other instance selection criteria, like gold
>customers get on the higher performance RSP for a particular functional
>chain but bronze customers the lower performance RSP for that same
>functional chain?
>
>And, although it is not a functional use case in the same manner as
>above, what if some network designers determine it is cheaper and simpler
>to deploy SFC using service function instances that are simpler and don't
>have inbuilt horizontal scale?   More along the lines of the "fit VNF"
>approach (attribution to Contextream).
>
>The group's proposed solution should be measured against the use cases
>and and deployment scenarios we feel need to be addressed, and this is
>probably the main difference in viewpoint, here.    To follow on to Ken's
>colloquialism, my opinion is that the horse is not dead and that the
>different viewpoints do not reflect a fundamental inability to grasp the
>concepts.
>
>Thanks.
>
>   Ron
>
>
>
>

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Sat, 7 Feb 2015 00:20:58 +0000

Happy Friday, Ron.  In line responses ...

>instances is still insufficient?

<keg> The terms “real world” and “insufficient” are vague, but I think
actually a good argument why the secondary key for a lookup by the
balancer/whatever should be kept in metadata - and, as I point out before,
a RELEVANT key is most likely there.  At worst, if it’s in a fixed context
(type1) it’s a 32 bit number and if you need larger, it could be in a
variable length TLV (type 2) …and I’d think “bigger than 32 bits” would be
pretty special.

>one of those internally scalable instances?   More than 2 of them?

<keg> I think you’re making the same argument I was making above.  I
shouldn’t care and it seems like we’re careening further away from using a
fixed field to solve that problem.  Again, if the SPI/SI gets me to my
first “decision point” …a locality where elasticity/HA expansion is taking
place and you use my example of the context header being a secondary key
to guide a lookup to whatever that device is … a unique 32bit value even
for a direct mapping is a HUGE space (Carl Saganesque).

>order to optimize the overall behavior?

<keg> Interesting example and I hear this a lot as far as what you COULD
do with SFC, but if delay is any factor in the policy that controls the
creation of individual chains/SPIDs, then I’d argue that they wouldn’t be
equivalent abstract paths - they would be more or less separate chains in
my view.

But okay, they’re close enough for you not to care … the problem you have
to solve is to select a criteria on which to pick the destination from a
decision point in the path for your elastic/flexible SI/SPI match ... not
how far the NHs that it resolves to are from that point.  Say your NH are
in Cleveland and Chicago … these don’t move relative to the decision point
… so their distance is not a criteria in and of itself - otherwise I would
just weight the NH from the control plane distributing them to reflect
what my valuation of load and distance should be (to reflect my policy).
That’s all static (the NH weight could be updated if Cleveland or Chicago
move or if I change my policy ;^).

>chain but bronze customers the lower performance RSP for that same

<keg> Identity, session, metadata … I think I gave this example.

>approach (attribution to Contextream).

<keg> They have the option of blowing out the SPID space, as I said,
that’s a derivative example of the SPI/SI having a single NH, IMO …each
permutation is a direct mapping and different SPID and what/how you affix
these (policy) is reflected at classification.  The abstraction in the
language was only there to help people imagine the flexibility available
through the usage I describe.

---

From: Ron Parker <[email-masked]>
Date: Sat, 7 Feb 2015 02:54:48 +0000

Ken,

Thanks for the thoughtful responses.

Please see inline Ron>>> below.

________________________________________
From: Ken Gray (kegray) [[email-masked]]
Sent: Friday, February 06, 2015 7:20 PM
To: Ron Parker; Wenzhe Zhou; Joel M. Halpern; Nicolas BOUTHORS; [email-masked]'
Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers

Ron>>> I did originally think of this as metadata, too (regardless of which type), but I'm now questioning my own conclusion.   Wouldn't SFF need to make decisions based on this?   Say for RSP x, after sending to and receiving from a locally connected Service Function Instance,  the next SFF is SFF y.   And SFF is not supposed to care about metadata, certainly not for basic forwarding behavior.

Ron>>> But per the architecture, SFP is not necessarily an exact sequence of concrete next hops.   That thing is the RSP.   Same argument about the SFF usage of this for forwarding.   But do note that as I pointed out previously, for centrally orchestrated environments, only a single level of identifier is needed -- but that identifier is better named RSP ID than SFP ID to match the architectural spec.   And 32 bits is fine.   Where a dual level identifier is needed (I'm proposing 2 32 bit identifiers) is when hop-by-hop trail blazing is used (i.e., late binding) to forge the actual RSP.   Now the RSP ID becomes a hint that the classifier drops into the packet to ensure that all packets with the same hint traverse the same exact sequence.   The first packet seen by SFF with this hint results in a local load balancing decision.   Subsequent packets are forwarded per the very first decision, barring local failures.   What I'm proposing is that the architecture embrace both centrally orchestrated RSP binding and distributed RSP binding.

Ron>>> I'm close to conceding this point, except for the following counter use case -- if the "close" instance is not in overload, then use it, otherwise use the "far" instance.

Ron>>> Per above.    But I could also be convinced that yet higher level policy says to use SFP A preferably, but SFP B otherwise, per your analysis.

Ron>>> I agree.   Use case is withdrawn.   This lends itself to distinct SFP's (i.e., different policy constraints on the SFC).

Ron>>> The architecture states that RSP is the fully concrete sequence of hops.   But mostly, for me, the argument is about the utility of late binding (or not, if you are of that persuasion).

---

From: "Ken Gray (kegray)" <[email-masked]>
Date: Sat, 7 Feb 2015 15:55:16 +0000

A few in line ...

On 2/6/15, 9:54 PM, "Ron Parker" <[email-masked]> wrote:

>Ron>>> I did originally think of this as metadata, too (regardless of
>which type), but I'm now questioning my own conclusion.   Wouldn't SFF
>need to make decisions based on this?   Say for RSP x, after sending to
>and receiving from a locally connected Service Function Instance,  the
>next SFF is SFF y.   And SFF is not supposed to care about metadata,
>certainly not for basic forwarding behavior.

<keg> I’m encouraging you to go with your first instinct ;^).

>Ron>>> But per the architecture, SFP is not necessarily an exact sequence
>of concrete next hops.   That thing is the RSP.   Same argument about the
>SFF usage of this for forwarding.   But do note that as I pointed out
>previously, for centrally orchestrated environments, only a single level
>of identifier is needed -- but that identifier is better named RSP ID
>than SFP ID to match the architectural spec.   And 32 bits is fine.
>Where a dual level identifier is needed (I'm proposing 2 32 bit
>identifiers) is when hop-by-hop trail blazing is used (i.e., late
>binding) to forge the actual RSP.   Now the RSP ID becomes a hint that
>the classifier drops into the packet to ensure that all packets with the
>same hint traverse the same exact sequence.   The first packet seen by
>SFF with this hint results in a local load balancing decision.
>Subsequent packets are forwarded per the very first decision, barring
>local failures.   What I'm proposing is that the architecture embrace
>both centrally orchestrated RSP binding and distributed RSP binding.

<keg> What I’m arguing is that you SHOULDN’T codify this in the fixed
header unless you’re sure it’s the rule instead of the exception.  Even if
it were the rule, how many layers of secondary key should we allow … why
stop at two?  The MD Type1 contexts and perhaps even the TLVs (if you
truly have a case where you want multi-multi levels, “russian doll” style
… and again this is where …if I extend your use case …I go) are a better
place to put these.

>Ron>>> I'm close to conceding this point, except for the following
>counter use case -- if the "close" instance is not in overload, then use
>it, otherwise use the "far" instance.

<keg> Our differences here would go back to my views on the practicality
of an overload bit.

First, I think assuming that the SF would be unmanaged shouldn’t be
encouraged - to me it’s one of the tenants of doing this NFV-thing in the
first place.  If you are imbedding your elasticity management into the
series of NH, then you ultimately will have a situation where the SFC will
fail because you didn’t spin up enough instances or is inefficient because
you spun up too many.  Even if the argument is “old physical thing that’s
not manageable with new tools” my response would be “then just don’t do
it”.

Were someone to pursue the argument that VNFs are unmanaged, then I’d also
encourage the exception-vs-rule logic when it comes to using header bits
to support such a deployment - and argue it’s an exception and they should
move the signal elsewhere than the fixed header (there is so much
“optional” space here in the proposal).

If VMF is managed (which is my assumed dominant case), then allowing the
device autonomy to off-line itself creates potential conflicts (e.g.
ServiceA tells the forwarding path it’s overloaded whilst the management
system doesn’t think so).

Beyond that, I have a fundamental hesitation in using a bit as a signal
that can alter the path - it invites chaos, IMHO.  I think bit-as-signal
between neighbors has to be used very carefully because of the history in
this industry of both hardware and software
corrupting/misinterpreting/bugging bits in not-so-funny ways.  We have
reviewed each bit already suggested - the functionality of the O and C
bits for example are a) universal to all deployments and b)
implementations can provide defense-against-freaking through intelligent
policing.  Yes, we do have examples of this utility in the past, but I
think it’s inappropriate for this paradigm (e.g. ISIS we are building a
cooperative distributed tree view - how many deployments envision that as
the way they would build SFCs, particularly when central control with a
top-down view is available).  And, “overload” historically doesn’t mean “I
think I’ll stop taking traffic at 100Gbps, but keep all your sessions up
to that point” it means “I’m out of resources so my database could be
inconsistent - hence offline for ALL traffic”.

>Ron>>> Per above.    But I could also be convinced that yet higher level
>policy says to use SFP A preferably, but SFP B otherwise, per your
>analysis.
>
>
>>
>Ron>>> I agree.   Use case is withdrawn.   This lends itself to distinct
>SFP's (i.e., different policy constraints on the SFC).
>
>
>>
>Ron>>> The architecture states that RSP is the fully concrete sequence of
>hops.   But mostly, for me, the argument is about the utility of late
>binding (or not, if you are of that persuasion).
>
>
>>