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

[DIEGO LOPEZ GARCIA <[e-mail]>]

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]
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