Re: [sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)

[Martin Vigoureux <[e-mail]>]

Hi Ben,

thank you for your review.
Top posting since I'm only replying to point 1: do you think borrowing 
text/ideas from rfc8979 could help here?

Thank you

-m

Le 2021-11-29 à 19:59, Benjamin Kaduk via Datatracker a écrit :
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-sfc-nsh-tlv-09: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> (1) RFC 8300 is pretty clear that "Metadata privacy and security
> considerations are a matter for the documents that define metadata
> format."  Some of the metadata context headers defined in this document
> clearly have privacy considerations that need to be documented (e.g.,
> policy ID and source/destination group serve to concretely identify
> flows that are related in some way), though some may not have much that
> needs documenting (e.g., the forwarding context metadata seems to just
> be extracting out information that is already present in the packet
> being wrapped).  Regardless, we need to have some discussion of the
> privacy and security considerations of the new metadata context headers,
> even if that is just "no new considerations" for some of them.
> 
> (2) I think we need to discuss the Flow ID context header further.  Is
> it intended to just be a container to hold a flow identifier already
> present in the contained packet (such as the IPv6 Flow Label or MPLS
> Entropy Label that are called out), or can it also be used to apply a
> new flow identifier at the SFC layer?
> 
> The named examples of a flow ID are both 20 bits long; if that is an
> exhaustive listing, shouldn't we update the figure accordingly (to
> include Length=3, four leading bits of padding, and a trailing byte of
> padding)?  If that is not an exhaustive listing and longer flow
> identifiers are expected, how do we know what length of flow identifier
> is being conveyed?
> 
> (3) If we are to allow for specifying the "logical grouping of source and/or
> destination objects" in §4.6 (emphasis on "and/or"), but the context
> header always conveys both a source group and dest group field, do we
> need to reserve a dedicated value for "no group information specified"?
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1
> 
>     This document does not address metadata usage, updating/chaining of
>     metadata, or other SFP functions.  Those topics are described in
>     [RFC8300].
> 
> I'm not entirely sure what is meant by "chaining of metadata" (unless
> it's just a synonym for "updating of metadata"?), and having reviewed
> all 18 instances of "chain" and 88 instances of "metadata" in RFC 8300,
> I am not sure which part you're intending to refer to by it.  Could you
> please point to a more specific part of RFC 8300 (at least in this email
> thread for now, not necessarily in a document update)?
> 
> Section 4.1
> 
> I suggest putting a context (forgive the pun) indicator in the figure
> legends, e.g., "Figure 4: Forwarding Context - 2 (QinQ)".  The
> information is already available elsewhere, but having it in the caption
> helps focus the reader on the important/relevant part of the figure.
> 
> Section 4.3
> 
> It might be interesting to say something about when the SPI itself
> suffices to identify the ingress node vs. when this metadata context
> header is needed.
> 
>        Node ID: Represents an opaque value of the ingress network node
>        ID.  The structure and semantics of this field are deployment
>        specific.  For example, Node ID may be a 4 bytes IPv4 address Node
>        ID, or a 16 bytes IPv6 address Node ID, or a 6 bytes MAC address,
>        or 8 bytes MAC address (EUI-64), etc,.
> 
> There seems to be some dissonance between saying this field is "an
> opaque value" and also saying that it might be an IP or MAC address.  In
> the vein of Francesca's Discuss point, I don't think we can have
> interoperability if the NSH implementation is expected to process this
> as IP/MAC address information (as opposed to just an opaque identifier).
> 
> Section 8.2
> 
> URLs for [GROUPBASEDPOLICY] and [GROUPPOLICY] would be helpful.
> 
> 
> 
>