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

[Magnus Westerlund <[e-mail]>]

Hi Med,

I think this looks really good. From my perspective this is sufficient to remind
people about the issue. I hope the WG participants takes a look at this and
provide feedback too as it does introduce new recommendations, altough they
align with RFC 8300.

Cheers

Magnus

On Mon, 2020-11-09 at 13:29 +0000, [e-mail] wrote:
> 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.
>