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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Wed, 04 Nov 2020 07:45:07 -0800

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.

---

From: <[email-masked]>
Date: Wed, 4 Nov 2020 16:16:10 +0000

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:[email-masked]]
> Envoyé : mercredi 4 novembre 2020 16:45
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; Greg Mirsky <[email-masked]>;
> [email-masked]
> Objet : Magnus Westerlund's Discuss on draft-ietf-sfc-serviceid-
> header-12: (with 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.)
> 
> 
> 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.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Nov 2020 08:41:56 +0000

On Wed, 2020-11-04 at 16:16 +0000, [email-masked] 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

---

From: <[email-masked]>
Date: Mon, 9 Nov 2020 13:29:42 +0000

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

> De : Magnus Westerlund [mailto:[email-masked]]
> Envoyé : jeudi 5 novembre 2020 09:42
> À : [email-masked]; BOUCADAIR Mohamed TGI/OLN
> <[email-masked]>
> Cc : [email-masked]; [email-masked]; draft-ietf-sfc-
> [email-masked]; [email-masked]
> Objet : Re: Magnus Westerlund's Discuss on draft-ietf-sfc-serviceid-

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 Nov 2020 17:16:13 +0000

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, [email-masked] wrote:
> > > 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
> > > 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?
> > 
> ______________________________________________________________________________
> ___________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;