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

[VictorVu <[e-mail]>]

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://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


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus