Subject: Re: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3)

From: <[email-masked]>
Date: Fri, 15 Nov 2013 10:22:10 +0100

Hi Joel,

Thanks for the feedback. 

The point of that analysis text is to assess whether there are cases where conveying a subscriber-id is needed to be carried as part of the SFC header. The examples are there to illustrate particular cases and are not intended to be exhaustive. 

Over-specifying the solution will make things more complex than the problem we are trying to solve.

Cheers,
Med

>-----Message d'origine-----
>De : Joel M. Halpern [mailto:[email-masked]]
>Envoyé : mardi 8 octobre 2013 18:04
>À : BOUCADAIR Mohamed IMT/OLN
>Cc : [email-masked]
>Objet : Re: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter
>bullet #3)
>
>I find that text extremely biased and centered on particular problems.
>
>Having said that, I agree that we should not have a mandatory field for
>subscriber ID in the header.  I never suggested that we have such a
>mandatory field.  Rather, I was pointing out that one of the uses of
>metadata (and there are many) is to carry subscriber ID.
>
>I would not want the architecture or protocol to mandate exactly what
>metadata is carried in the header, since different situations will need
>different metadata.
>
>Yours,
>Joel
>
>On 10/8/13 5:27 AM, [email-masked] wrote:
>> Hi Joel, all,
>>
>> We updated the section that discuss subscriber-id consideration in the
>sfc analysis draft. The text is available at:
>https://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-00#section-
>4.1.
>>
>> Comments and additions to that text are welcome.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : [email-masked] [mailto:[email-masked]] De la part de
>Joel
>>> M. Halpern
>>> Envoyé : mercredi 25 septembre 2013 09:24
>>> À : Linda Dunbar
>>> Cc : [email-masked]; [email-masked]
>>> Objet : Re: [nsc] New NSC WG Charter - charter bullet #3
>>>
>>> For me, the canonical example of metadata applies to the use case of a
>>> service chain providing residential gateway functionality with network
>>> resident NAT.
>>> If the operator is choosing, due to IPv4 exhaustion, to resuse IP
>>> addresses across subscribers, then some field is needed to identify the
>>> subscriber in the service chain.
>>> In a classic BNG, the physical port, VLAN, or incoming MAC address
>>> provides this function.  But those will all be lost in the service
>chain.
>>>
>>> I have also seen cases where DPI service engines are separate entities
>>> in the chain from services which need the results of the DPI.  That
>>> seems a natural candidate for metadata.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 9/24/13 7:02 PM, Linda Dunbar wrote:
>>>> Adrian,
>>>>
>>>> Very good analysis. Thank you.
>>>>
>>>> "Metadata" has been used extensively in the NSC context. But beyond the
>>> "service chain ID", I can't find any other necessary information
>required
>>> to be exchanged among the "Service Functions" in all the use cases
>>> presented at the Berlin informal BoF and use cases drafts. Can anyone
>give
>>> some examples of the information required to be exchanged among those
>>> "Service Functions" given by the draft-quinn-nsc-arch-00?
>>>>
>>>> A non-exhaustive list of Service Functions includes: firewalls,
>>>> WAN and application acceleration, Deep Packet Inspection (DPI),
>>>> server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
>>>> injection, HTTP Header Enrichment functions, TCP optimizer, etc.
>>>>
>>>>
>>>> Thanks, Linda
>>>>
>>>>> -----Original Message-----
>>>>>
>>>>> I think "metadata" is a particularly poor term to use here because it
>>>>> actually
>>>>> directly means "additional data attached to something specific". So,
>it
>>>>> is
>>>>> metadata when you put it in the encapsulation header on a packet, but
>>>>> if it is
>>>>> out of band, it is what it is.
>>>>>
>>>>> So, let's look at what you might be talking about for "metadata":
>>>>> - The details of the service chain itself (e.g. the service path)
>>>>> - Information that one service node wants to communicate with
>>>>>     another service node (e.g. about how to perform given some
>>>>>     state information)
>>>>>
>>>>> We should also look at what you mean by out-of-band. I think here you
>>>>> mean
>>>>> "using some information exchange protocol."
>>>>
>>>> [Linda] Since each Service-Chain ID represents a list of service
>>> functions, it is possible to use "out-of-band" control channel to pass
>the
>>> information on the sequence of Service Functions associated with the ID.
>>>>
>>>>
>>>>>
>>>>> The charter says:
>>>>>
>>>>> | The Service Function Chaining (SFC) working group will develop
>>>>> | new approaches to service delivery and deployment, by
>>>>> | providing a framework for service function chaining and the
>>>>> | necessary protocols or protocol extensions to convey the
>>>>> | service path and for communication between nodes that
>>>>> | implement service functions
>>>>>
>>>>> and:
>>>>>
>>>>> | 4) Control Plane Mechanisms: A set of documents will be
>>>>> | developed to describe requirements and protocols necessary
>>>>> | to convey information to service function implementation
>>>>> | points. Where possible, existing IETF protocols will be used
>>>>> | and extended.
>>>>>
>>>>> This feels like out-of-band exchange of information is expected.
>>>>>
>>>>> Adrian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> nsc mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/nsc
>>>>
>>> _______________________________________________
>>> nsc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/nsc
>> _______________________________________________
>> nsc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nsc
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 15 Nov 2013 04:27:06 -0500

If the point of the text is to say that some service chains in some 
environments may need subscriber ID, but others will not, then just say 
that.  The current text tries to argue about how common it is, when that 
is not as far as I can tell an important part of the question.

You could then follow it with the observation that there are a range of 
requirements for different metadata in different circumstances, and that 
we need define how this is carried without mandating specific 
information in every packet, since the use cases are varied.

None of that would be over-specifying the solution.
And it would avoid getting into prejudicial text about different 
problems in different environments.

Yours,
Joel

On 11/15/13 4:22 AM, [email-masked] wrote:
> Hi Joel,
>
> Thanks for the feedback.
>
> The point of that analysis text is to assess whether there are cases
> where conveying a subscriber-id is needed to be carried as part of
> the SFC header. The examples are there to illustrate particular cases
> and are not intended to be exhaustive.
>
> Cheers, Med
>> -----Message d'origine----- De : Joel M. Halpern
>> [mailto:[email-masked]] Envoyé : mardi 8 octobre 2013 18:04 À
>> : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked] Objet : Re: [nsc] On
>> subscriber-ID (was RE: New NSC WG Charter - charter bullet #3)
>>
>> Having said that, I agree that we should not have a mandatory field
>> for subscriber ID in the header.  I never suggested that we have
>> such a mandatory field.  Rather, I was pointing out that one of the
>> uses of metadata (and there are many) is to carry subscriber ID.
>>
>> I would not want the architecture or protocol to mandate exactly
>> what metadata is carried in the header, since different situations
>> will need different metadata.
>>
>> Yours, Joel
>>
4.1.
>>> Cheers, Med
>>>> -----Message d'origine----- De : [email-masked]
>>>> [mailto:[email-masked]] De la part de
>> Joel
>>>> M. Halpern Envoyé : mercredi 25 septembre 2013 09:24 À : Linda
>>>> Dunbar Cc : [email-masked]; [email-masked] Objet : Re: [nsc]
>>>> New NSC WG Charter - charter bullet #3
>>>>
>>>> For me, the canonical example of metadata applies to the use
>>>> case of a service chain providing residential gateway
>>>> functionality with network resident NAT. If the operator is
>>>> choosing, due to IPv4 exhaustion, to resuse IP addresses across
>>>> subscribers, then some field is needed to identify the
>>>> subscriber in the service chain. In a classic BNG, the physical
>>>> port, VLAN, or incoming MAC address provides this function.
>>>> But those will all be lost in the service
>> chain.
>>>>
>>>> I have also seen cases where DPI service engines are separate
>>>> entities in the chain from services which need the results of
>>>> the DPI.  That seems a natural candidate for metadata.
>>>>
>>>> Yours, Joel
>>>>
>>>> to be exchanged among the "Service Functions" in all the use
>>>> cases presented at the Berlin informal BoF and use cases
>>>> drafts. Can anyone
>> give
>>>> some examples of the information required to be exchanged among
>>>> those "Service Functions" given by the
>>>> draft-quinn-nsc-arch-00?
>>>>>
>>>>> A non-exhaustive list of Service Functions includes:
>>>>> firewalls, WAN and application acceleration, Deep Packet
>>>>> Inspection (DPI), server load balancers, NAT44 [RFC3022],
>>>>> NAT64 [RFC6146], HOST_ID injection, HTTP Header Enrichment
>>>>> functions, TCP optimizer, etc.
>>>>>
>>>>>
>>>>> Thanks, Linda
>>>>>
>>>>>> I think "metadata" is a particularly poor term to use here
>>>>>> because it actually directly means "additional data
>>>>>> attached to something specific". So,
>> it
>>>>>> is metadata when you put it in the encapsulation header on
>>>>>> a packet, but if it is out of band, it is what it is.
>>>>>>
>>>>>> So, let's look at what you might be talking about for
>>>>>> "metadata": - The details of the service chain itself (e.g.
>>>>>> the service path) - Information that one service node wants
>>>>>> to communicate with another service node (e.g. about how to
>>>>>> perform given some state information)
>>>>>>
>>>>>> We should also look at what you mean by out-of-band. I
>>>>>> think here you mean "using some information exchange
>>>>>> protocol."
>>>>>
>>>>>> | The Service Function Chaining (SFC) working group will
>>>>>> develop | new approaches to service delivery and
>>>>>> deployment, by | providing a framework for service function
>>>>>> chaining and the | necessary protocols or protocol
>>>>>> extensions to convey the | service path and for
>>>>>> communication between nodes that | implement service
>>>>>> functions
>>>>>>
>>>>>> and:
>>>>>>
>>>>>> | 4) Control Plane Mechanisms: A set of documents will be |
>>>>>> developed to describe requirements and protocols necessary
>>>>>> | points. Where possible, existing IETF protocols will be
>>>>>> used | and extended.
>>>>>>
>>>>> _______________________________________________ nsc mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/nsc
>>>>>
>>>> _______________________________________________ nsc mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/nsc
>>> _______________________________________________ nsc mailing list
>>> [email-masked] https://www.ietf.org/mailman/listinfo/nsc
>>>
>