Subject: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases

From: Christian Koenning <[email-masked]>
Date: Fri, 6 May 2016 13:30:24 +0000

Dear WG:

We are currently looking into SFC use-cases for mobile networks and are thinking of using the NSH Metadata to carry subscriber identity.

The ip-address to subscriber mapping in todays network is usually propagated via external control-planes, e.g. RADIUS accounting. 

Looking at the possibilities  of NSH, the subscriber identity could easily be carried as metadata per packet. 

However, the 2 most common identifiers in mobile networks are

- Mobile Station International Subscriber Directory Number (MSISDN) 
  E.164 defines this to a maximum of 15 digits
  
- International Mobile Subscriber Identity (IMSI), also defined as a 15 digit number

Now looking at draft-ietf-sfc-nsh-04.txt p.12 3.4 NSH-MD-type 1 each Mandatory Context Header is defined as 4 Bytes.

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Ver|O|C|R|R|R|R|R|R|   Length  |  MD-type=0x1  | Next Protocol |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Service Path ID                      | Service Index |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Mandatory Context Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As you can see, a 15 digit number cannot be represented with 4 bytes. 
Doing the math it shows that  ceiling [ log2 ( ( 10^16 ) -1 ) ]  = 54 bits would be needed
for simple binary representation.

Question: Are there any plans to address this in the MD type 1, for example by defining
concatenation of two Mandatory Context Headers, which then with 64 bits or 8 byte would fit the subscriber identity ?

Many Thanks

Christian Koenning

---

From: Dave Dolson <[email-masked]>
Date: Fri, 6 May 2016 14:48:09 +0000

This expired draft proposed using CH2 and CH3 for sub/endpoint ID.
https://tools.ietf.org/html/draft-napper-sfc-nsh-mobility-allocation-02

I think it is worth reviving it.

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Christian Koenning
Sent: Friday, May 06, 2016 9:30 AM
To: [email-masked]
Subject: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases

Dear WG:

  

Many Thanks

Christian Koenning

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

---

From: Christian Koenning <[email-masked]>
Date: Fri, 6 May 2016 14:56:44 +0000

Excellent. I shall reach out to the authors.

Many Thanks
Christian

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 6 May 2016 15:19:35 +0000

Actually I think the draft you are looking for is:

https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-broadband-allocation<https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-broadband-allocation/>

Jim

Sent from my iPhone

On May 6, 2016, at 10:48 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Christian Koenning
Sent: Friday, May 06, 2016 9:30 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] draft-ietf-sfc-nsh-04 NSH-MD-type 1 use-cases

Dear WG:

Many Thanks

Christian Koenning

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 6 May 2016 12:18:16 -0400

There are privacy considerations that complicate this while pointing a 
way to addressing it.

In order to reduce privacy risks, the SFC Architecture points out the 
fields revealing subscriber specific information should be represented 
indirectly.

Thus, instead of putting the IMSI or MSISDN into the metadata, the 
recommended approach is to put a local-environment-assigned 32-bit 
subscriber ID in as one of the pieces of metadata.

The service functions which need subscriber identity can then either be 
provisioned with the mapping information, or fetch the mapping when new 
packets arrive (SFC does not care which).  For some logging purposes, 
the 32 bit id can even be logged without translation( with a time stamp, 
so the IDs can be reused).

The drawback is that this does require coordination between the 
classifier and the service functions, usually by way of the control system.

Yours,
Joel