Re: [sfc] Magnus Westerlund's Discuss on draft-ietf-sfc-serviceid-header-12: (with DISCUSS)

[[e-mail]]

Hi Magnus, 

Eric raised a similar comment but I'm afraid that this is not specific to this spec as we don't have a full visibility on the full set of metadata that will be included in a service chain. This is a generic consideration when deploying NSH. This is why we point the reader to Section 5 of RFC8300. 

As NSH is deployed within a single domain, and that the operator knows the SFs that will inject these headers (but also other context headers) and the full set of metadata to be conveyed on a per chain basis, a first reco in RFC8300 is to increase the MTU.

If the MTU can't be increased, the next reco in RFC8300 is to rely on the fragmentation/reassembly at the transport encapsulation. We can't call a specific transport encapsulation because this is deployment-specific. 

Do you have in mind a specific point that we need to record? Do you see a value if we add an informative reference to draft-ietf-intarea-tunnels? 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Magnus Westerlund via Datatracker [mailto:[e-mail]]
> Envoyé : mercredi 4 novembre 2020 16:45
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; Greg Mirsky <[e-mail]>;
> [e-mail]
> Objet : Magnus Westerlund's Discuss on draft-ietf-sfc-serviceid-
> header-12: (with DISCUSS)
> 
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-sfc-serviceid-header-12: Discuss
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/
> 
> 
> 
> --------------------------------------------------------------------
> --
> DISCUSS:
> --------------------------------------------------------------------
> --
> 
> This looks like a significant problem. If I have missed anything in
> any reference this might be very simple to resolve. However, based
> on this document and looking at RFC 8300 I think this document is
> lacking in discussion of the packet size impact of using both
> dynamic size headers, as well as there are no limits to how many are
> added. Thus, there are significant risk for this header to increase
> the packet size so much that it doesn't fit the underlying layer.
> And as Section 5 in RFC8300 identifies there are no general solution
> provided in NSH. Thus, I really think this issues needs some
> discussion. Even if the actual result of this is a requirement on
> the control plane, the issue exists in the data plane and thus
> warrants discussion in this document.
> 
> 
> 
> 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.