Re: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05

[Dave Dolson <[e-mail]>]

Victor,
I’m going to add this section. Does it look OK to you?

3.1.5.  Stateful / Metadata Hybrid


   The basic idea of this approach is for the IBN to save upper domain
   encapsulation information such that it can be retrieved by a unique
   identifier, termed an "hSFC Flow ID".  An example ID is shown in
   Table 1.

   +-----------+-----+-----+----------+----------+----------+----------+
   | hSFC Flow | SPI | SI  | Context1 | Context2 | Context3 | Context4 |
   | ID        |     |     |          |          |          |          |
   +-----------+-----+-----+----------+----------+----------+----------+
   | 1         | 45  | 254 | 100      | 2112     | 12345    | 7        |
   +-----------+-----+-----+----------+----------+----------+----------+

     Table 1: Example Mapping of an hSFC Flow ID to Upper-Level Header

   The ID is placed in the metadata in NSH headers of the packet in the
   lower domain, as shown in Figure 4.  When packets exit the lower
   domain, the IBN uses the ID to retrieve the appropriate NSH
   encapsulation for returning the packet to the upper domain.

      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 Identifer               | Service Index |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      hSFC Flow ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Mandatory Context Header                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Mandatory Context Header                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Mandatory Context Header                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          Figure 4: Storing hSFC Flow ID in lower-level metadata

   Advantages of this approach include:

   o  Does not require state based on 5-tuple, so it works with
      functions that change the IP addresses or ports of a packet such
      as NATs,

   o  Does not require all domains to have the same metadata scheme,

   o  Can be used to restore any upper-domain information, not just
      service path,

   o  The lower domain only requires a single item of metadata
      regardless of the number of items of metadata used in the upper
      domain.  (For MD-Type 1, this leaves 3 slots for use in the lower
      domain.)

   o  No special functionality is required of the SF, other than the
      usual ability to preserve metadata and to apply metadata to
      injected packets.

   Disadvantages include those of other stateful approaches, including
   state timeout and replication mentioned in Section 3.1.1.

   There may be a large number of unique NSH encapsulations to be
   stored, given that the hSFC Flow ID must represent all of the bits in
   the upper-level encapsulation.  This might consume a lot of memory or
   create out-of-memory situations in which IDs cannot be created or old
   IDs are discarded while still in use.



From: sfc [mailto:[e-mail]] On Behalf Of VictorVu
Sent: Saturday, June 18, 2016 12:10 PM
To: DIEGO LOPEZ GARCIA
Cc: [e-mail]
Subject: Re: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05


Hi,

Actually, it only requires 1 metadata slot for as many layers as you want. Lower-level IBNs simply save upper-level hSFC flow ID in metadata and overwrite it. Flow-stateful IBNs can even save all upper-level metadata and recover later, so lower-level domains at any layer are free to use 3 metadata slots.

Regards,

On 6/18/16 9:55 PM, DIEGO LOPEZ GARCIA wrote:
Hi,

The only possible objection someone could come with is the fact that we are limiting a possible hierarchy recursion to three layers (a fourth one could not use any metadata slots) But I would not say that is something I feel very much concerned about (hence the impersonal “someone” rather than a personal “I”)

Be goode,

On 14 Jun 2016, at 16:18 , Dave Dolson <[e-mail]<mailto:[e-mail]>> wrote:

Victor,

Yes, I agree this is a good idea. I intend to add it to the list of alternatives in the draft.
I think it is probably the best of the stateful ideas.
I think to the list of benefits we can also add:
- has potential for security advantages in that it may be harder for a sub-domain SF to attack upper-level paths because the upper-level path is obscured by the flow ID, and the flow ID can be validated as it returns.

I intend to update the draft soon including some changes from the other authors.
If anyone on the list has other feed-back, please let me know.

-Dave
P.S. Victor, it doesn’t appear that your request made it to the list. Hopefully this reply does.



From: Victor Vu [mailto:[e-mail]]
Sent: Friday, June 10, 2016 11:16 PM
To: [e-mail]<mailto:[e-mail]>; Dave Dolson
Subject: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05

Hi,
In draft-dolson-sfc-hierarchical-05, there have been 4 method for restoring upper-level SF path when packets exit lower-level domain, each of them has its disadvantage:
1.  Saving SPI and SI in transport-layer flow state => could not work with SFs wich can change 5-tuple (NAT for example)

2.  Pushing SPI and SI into metadata => MD-type 1 has only 4 metadata slots

3.  Using unique lower-level paths per upper-level path coordinates => too many service paths in lower-level domain

4.  Nesting NSH headers, encapsulating the higher-level NSH headers within the lower-level NSH headers => require SFs in the lower-level domain to be able to parse multiple layers of NSH
Therefore, I would like to propose the Flow-stateful/metadata hybrid solution. The basic idea is to make IBN save top-domain flow information (flow-stateful IBN), and assign each flow an “h-sfc flow ID” mapped to its info and store in 1 Mandatory context header. When packet exit sub-domain, get upper-domain’s info back by the h-sfc flow ID and restore it at the service last hop.
In this way:

  *   Upper domain metadata is preserved, and sub-domains can change it just like a SFs does
  *   Does NOT depend on 5-tuple => work well with NAT
  *   Does NOT require all domains have a same metadata scheme
  *   Scalable: could restore any top-domain information, not just service path
  *   Top domain could use full 4 metadata slots, while sub-domains can use up to 3
  *   Does not require any special functionalities from SFs
  *   ID can be used to differentiate H-SFC and non-H-SFC flows
I would like to listen to your opinions.
Thank you very much.

Best regards,



--

--------------------------------------------------------------

Vu Anh Vu (Victor Vu)

DCN Laboratory - School of Electronic Engineering - Soongsil University

Email: [e-mail]<mailto:[e-mail]> / [e-mail]<mailto:[e-mail]>

Phone: [phone]

Mobile: [phone]

Address: 369 Sangdo-ro, Dongjak-gu (06978), Seoul, Korea

[https://ipmcdn.avast.com/images/2016/icons/icon-envelope-tick-round-orange_184x116-v1.png]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-b>

Virus-free<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-b>


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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [e-mail]<mailto:[e-mail]>
Tel:    [phone]
Mobile: [phone]
----------------------------------


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

[https://ipmcdn.avast.com/images/2016/icons/icon-envelope-tick-round-orange_184x116-v1.png]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-a>

Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-a>