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

[Magnus Westerlund <[e-mail]>]

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