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

From: <[email-masked]>
Date: Tue, 8 Oct 2013 11:27:08 +0200

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 08 Oct 2013 12:04:11 -0400

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

---

From: "Pham, Chuong D" <[email-masked]>
Date: Wed, 9 Oct 2013 10:48:49 +1100

I am happy with the Subscriber-ID being an optional field.

For the purpose of future proofing the document, I do not think the text fragments below are correct.

1)
"Note, current deployments may require an explicit subscriber-ID only
   during the authentication and authorization phases.  These
   deployments do not require explicit subscriber-ID information to be
   conveyed when sending actual data traffic.

Can you please provide some examples where these authentication and authorization take place with sub-id and sub-id is not required during "sending actual data traffic"? In our case (a Mobile Operator), the sub-id is required per IP packet, if the use case needs it. Without it, because IP address is allocated dynamically to a user device, the nodes upstream cannot decide which user an IP packet belong to. 
My point is not making sub-id mandatory is good, but not necessarily because of the reason included in the text fragment above. The reason that not all use cases require sub-id is sufficient.   

2)
"A typical example where complications may arise is a deployment context characterized
   as follows:

   o  Overlapping IP address pools are in use.

   o  NAT function is not collocated with the GGSN or BNG."

To me, those two points are separate issues altogether and not the main reason to make sub-id an optional field.

If an Operator uses user's IP address as subscriber-id (as an optional field specified in this draft) then decided to put the traffic through a NAT, it is the responsibility of the Operator to provide a translation function to reflect the change of user's IP address i.e. an ALG function in the NAT. However in our case (typical for Mobile Operator), MSISDN or IMSI is used as sub-id hence the user's IP address is not used to identify the user. 

Regards,
Chuong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 8 October 2013 8:27 PM
To: Joel M. Halpern; [email-masked]
Subject: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3)

Hi Joel, all,

Cheers,
Med

>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
>
>"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
>>
>>> 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.
>>>
>>> We should also look at what you mean by out-of-band. I think here 
>>> you mean "using some information exchange protocol."
>>
>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.
>>>