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

[[e-mail]]

Dear Ben,
Thank you. please see the commet resolution inline with Yuehua>>

To Martin,  I really appreciate if you could provide comments to Yuehua-2 and Yuehau-6. 

Best Regards,
Yuehua Wei
ZTE Corporation
------------------原始邮件------------------
发件人：BenjaminKadukviaDatatracker
收件人：The IESG;
抄送人：[e-mail];[e-mail];[e-mail];[e-mail];
日 期 ：2021年11月30日 02:59
主 题 ：[sfc] Benjamin Kaduk's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
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.

Yuehua-1>>Thank you, I update the section to ver10 per you, Stig and John's comments.  please take a look and provide further comments

(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?

Yuehua-2>>You raised a good question. I prefer to add Context Type (CT) to distinguish different flow IDs. I'd appreciate your advice.

(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"?

Yuehua-3>>Very good observation. Shall we state that if there is   "no group information specified" for the source or dest field, the field MUST be sent as zero and ignored on receipt

----------------------------------------------------------------------
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)?

Yuehua-4>> RFC8300 doesn't use “chain”to discribe multiple metadata.
it mentions "If multiple mandatory-to-process Context Headers are required for a   given SFP" and "If multiple instances of the same metadata are included in an NSH   packet" in RFC8300 section 2.5.1
Further comments are welcome


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.

Yuehua-5>> Accepted, will update to ver10

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).

Yuehua-6>> it has relation to 

Section 8.2

URLs for [GROUPBASEDPOLICY] and [GROUPPOLICY] would be helpful.
Yuehua-7>> Accepted, will fix the problem to ver10


_______________________________________________
sfc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sfc