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

[[e-mail]]

Hi Magnus, 

OK to restate it. What about the following:   

==
5.  MTU Considerations

   As discussed in Section 5.6 of [RFC7665], the SFC architecture
   prescribes that additional information be added to packets to:

   o  Identify SFPs: this is typically the NSH Base (Section 2.2 of
      [RFC8300]) and Service Path Headers (Section 2.3 of [RFC8300]).

   o  Carry metadata such those defined in Sections 3 and 4.

   o  Steer the traffic along the SFPs: transport encapsulation.

   This added information increases the size of the packet to be carried
   along an SFP.

   Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network
   operators to increase the underlying MTU so that NSH traffic is
   forwarded within an SFC-enabled domain without fragmentation.  The
   available underlying MTU should be taken into account by network
   operators when providing SFs with the required Context Headers to be
   injected per SFP and the size of the data to be carried in these
   Context Headers.

   If the underlying MTU cannot be increased to accommodate the NSH
   overhead, network operators may rely upon a transport encapsulation
   protocol to the required fragmentation handling.  The impact of
   activating such feature on SFFs should be carefully assessed by
   network operators (Section 5.6 of [RFC7665]).

   When dealing with MTU issues, network operators should consider the
   limitations of various transport encapsulations such as those
   discussed in [I-D.ietf-intarea-tunnels].
==

The control plane is not mentioned on purpose as this is out of scope. 

Cheers,
Med

> -----Message d'origine-----
> De : Magnus Westerlund [mailto:[e-mail]]
> Envoyé : jeudi 5 novembre 2020 09:42
> À : [e-mail]; BOUCADAIR Mohamed TGI/OLN
> <[e-mail]>
> Cc : [e-mail]; [e-mail]; draft-ietf-sfc-
> [e-mail]; [e-mail]
> Objet : Re: Magnus Westerlund's Discuss on draft-ietf-sfc-serviceid-
> header-12: (with DISCUSS)
> 
> On Wed, 2020-11-04 at 16:16 +0000, [e-mail]
> wrote:
> > 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?
> 
> I think you need to be explicit about the issue, especially as it
> might be a
> consideration both in which form of identifiers are used and thus
> their size, as
> well as how many one tries to put on. I think you should state it is
> a
> requirement on the control plane to consider congifuration options
> so that not
> more headers are added than can fit, or the domain operator needs to
> ensure that
> a lower layer transport that support fragmentation is supported.
> intarea-tunnels
> may contribute to context.
> 
> Cheers
> 
> Magnus

_________________________________________________________________________________________________________________________

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.