Opened 5 years ago

Last modified 5 years ago

#21 new defect

MD#1 Interoperability text (Proposed by Lucy)

Reported by: mohamed.boucadair@… Owned by: draft-ietf-sfc-nsh@…
Priority: major Milestone:
Component: nsh Version:
Severity: Active WG Document Keywords:
Cc:

Description

Add ths NEW text (https://www.ietf.org/mail-archive/web/sfc/current/msg05110.html):

==
This specification allows defining different semantics of metadata type 1 related mandatory context header, but the NSH header does not convey that semantic in the context headers. An SFC-aware SF MUST receive the data extraction schema first in order to get the data placed in the mandatory context header. How an SFC-aware SF gets the data extraction schema for the mandatory context header is outside the scope of this specification. This specification does not make any assumption about the content placed in the mandatory context header. Upon receiving an SFC packet with metadata type 1 present, if an SFC-aware SF is configured to use metadata but does not yet receive the data extraction schema for the mandatory context header, it MUST NOT process the packet and MUST log this error.
==

Change History (2)

comment:1 Changed 5 years ago by mohamed.boucadair@…

An updated version of the text proposal:

==
This specification does not make any assumption about the content placed in the mandatory context field of the NSH header. Further, the NSH header does not reveal the structure of the data included in the mandatory context field.

An SFC-aware SF MUST receive the data extraction schema first in order to get the data placed in the mandatory context field. How an SFC-aware SF gets that data extraction schema is outside the scope of this specification.

Upon receiving an NSH MD#1 packet, if the SFC-aware SF is configured to use metadata but does not yet receive the data extraction schema for the mandatory context field, it MUST NOT process the packet and MUST log this error.
==

comment:2 Changed 5 years ago by jguichar@…

Summary of mailing list textual changes as follows:

(1) Update Section 3.4 as follows:

OLD:

[dcalloc] and [broadalloc] provide specific examples of how metadata
can be allocated.


NEW:

This specification does not make any assumption about the content
placed in the mandatory context field of the NSH header, and
does not describe the structure or meaning of the included metadata.


An SFC-aware SF MUST receive the data semantics first in
order to process the data placed in the mandatory context field. The data
semantics include both the allocation schema and the meaning of the included
data. How an SFC-aware SF gets the data semantics is outside the scope of
this specification.


Upon receiving an NSH MD-type 1 packet, if the SFC-aware SF is configured
for mandatory use of metadata but does not yet receive the data semantics
for the mandatory context field, it MUST NOT process the packet and
MUST log at least once per the SPI for which a mandatory metadata is missing.


[dcalloc] and [broadalloc] provide sample examples to associate a
meaning with the data conveyed in the mandatory context field.


(2) Add this text at the end of Section 3.5.1:

This specification does not make any assumption about TLVs that are
mandatory-to-implement or those that are mandatory-to-process. These
considerations are deployment-specific. However, the control plane
is entitled to instruct SFC-aware SFs with the data structure of
TLVs together with their scoping (See Section 3.3.3 of [I-D.ietf-sfc-
control-plane]).


Upon receipt of a packet that belong to a given SFP, if a mandatory-
to-process TLV is missing in that packet, the SFC-aware SF MUST NOT
process the packet and MUST log at least once per the SPI for which
a mandatory metadata is missing.


If multiple mandatory-to-process TLVs are required for a given SFP,
the control plane MAY instruct the SFC-aware SF with the order to
consume these TLVs. If no instructions are provided, the SFC-aware
SF MUST process these TLVs in the order their appear in the NSH
packet.


If multiple instances of the same TLV are included in an NSH packet,
but the definition of that TLV does not allow for it, the SFC-aware
SF MUST NOT process the packet and MUST log at least once per the SPI
for which multiple instances of that TLV is supplied.

##########

NSH editors: Please update the NSH document with the above changes and then the chairs will close this ticket.

Note: See TracTickets for help on using tickets.